Add HDL tests

[umarcor]

All the bitstream generation tests currently used in CI depend on f4pga-examples.
We use the Flow JSON files in .github/*_test.json, but the HDL sources are coming from f4pga-examples.
That was done to get an initial working CI to start using and testing f4pga.
This PR adds minimal HDL sources to this repository, so that tests can be done regardless of f4pga-examples.
Eventually, the flow JSON files from .github should be moved to f4pga-examples, and the tests in this repo should be replaced with the local sources.

Moreover, although SymbiFlow's initial scope was Verilog, it was widened to include other HDLs, such as System Verilog (through Surelog) or VHDL (through GHDL) (SymbiFlow/symbiflow-website#59). There is interest in the community with regard to using SV and/or VHDL to generate bitstreams or for ASICs (#292, The-OpenROAD-Project/OpenLane#292...).
This PR shows how the F4PGA ecosystem allows generating bitstreams for Xilinx's 7 Series devices using VHDL sources. In the future, we should also add local SV and SV+Verilog+VHDL tests. There are some SV examples in f4pga-examples, but AFAIAA there is no SV+Verilog+VHDL example in the ecosystem.
Since there is no Conda package for GHDL yet (hdl/conda-eda#171), and f4pga.flows does not support it, a two-step approach is used in this PR. First, a container is used to convert the VHDL design to Verilog. Then, the F4PGA Action is used to generate the bitstream.

[kboronski-ant]

Could you explain, why are you including a VHDL test?

f4pga doesn't support VHDL as for now. I you think we can bring support for VHDL with no big effort, that would be an interesting possibility to consider. I think that in that case, we should probably extend the synth module with input for VHDL if VHDL can be handled by yosys through some plugin. If an external tool is required to create Verilog from VHDL, a separate module would be better.

I think this is something to be left for future development.

[kboronski-ant]

I see this has something to do with that litex PR.

So to be more precise - is there a reason why this test is here? The tool does not support VHDL. If the flow fails, then it's due to ghdl synth, isn't it?

[umarcor]

@kboronski-ant, see the updated description.

Overall, this PR is about showcasing possibilities in the F4PGA ecosystem, not specific about f4pga.flows. As you said, f4pga.flows does not support VHDL yet, and it's not straightforward. Implementing GHDL in f4pga.flows is relatively easy, as you can see in the synth-plugin target of the makefile in this PR. Howver, GHDL is not available in Conda, f4pga.flows does not support executing tools inside containers and there is no container with F4PGA and GHDL.
That's why this PR shows two-step solutions. In the future, when/if GHDL is available in Conda, or if a container is available including F4PGA and GHDL, VHDL tests can be reduced to a single step (a single call to f4pga build).

I see this has something to do with that litex PR.

This PR was created independently of that Litex PR. However, I believe that both Litex and Edalize do implement two-step solutions. They don't use the ghdl-yosys-plugin. Instead, they first use GHDL to convert VHDL to Verilog and then use the regular F4PGA integration.

If the flow fails, then it's due to ghdl synth, isn't it?

It depends. The failure yesterday was because a bug in the flow JSON file of the test. Bugs might be in GHDL, in Yosys, in VPR, in Surelog (when we add SV tests), etc.

[tmichalak]

LGTM