Add analysis support

[LAK132]

This change allows us to run ghdl analysis without having to exit from yosys

[tgingold]

Why not but I am not sure you could easily switch the hooks between analysis and synthesis. And I don't think you need it. The first work of the synthesis is to analyze the files given on the command line (if any). I would simply move this part into a new subprogram so that it could be called from the plugin. I am also not sure you need and want to save the library. PS: the testsuite is failing with your change.

[LAK132]

Thanks for the feedback, I'll look into it some more.

For future reference, my main use case for this feature is a yosys script like this:

ghdl -a --work=xpm xpm_vhdl/src/xpm/xpm_VCOMP.vhd;
ghdl --work=work --latches core/hdmi_tx_encoder.vhdl core/types_pkg.vhdl core/vga_to_hdmi.vhdl -e vga_to_hdmi;
synth_xilinx -flatten -abc9 -nobram -arch xc7 -top blink;
write_json blink.json

[tgingold]

As you can run shell commands from yosys, you could simply do:

!ghdl -a --work=xpm xpm_vhdl/src/xpm/xpm_VCOMP.vhd;
ghdl --work=work --latches core/hdmi_tx_encoder.vhdl core/types_pkg.vhdl core/vga_to_hdmi.vhdl -e vga_to_hdmi;

[LAK132]

!ghdl sounds like it could be annoying for development environments where ghdl can't be found from PATH

[alaindargelas]

@tgingold Adding to this issue as it seems the right one.
I have a verilog top level design that instantiate a bunch of VHDL cells.
Each cell is in a different file, so analyzing them independently and not elaborating them is required. Letting yosys perform the whole elaboration after it read the verilog top.

I can achieve the result in a contracted way by analyzing with the ghdl executable outside of yosys (or with the !ghdl), but then I need to explicitly call in yosys the ghdl plugin with the name of each of the cells. Some preprocessing has to happen to construct the yosys script correctly as there might be more than a cell per file.

Besides more work :-), is there a fundamental reason why the -a option is not natively supported in the plugin?

[tgingold]

I don't see what a '-a' option will provide over '!ghdl'. But, if your verilog design is instantiating a few vhdl cells, you can simply synthesize them before the verilog one: ghdl cell1.vhdl -e ghdl cell2.vhdl -e Or maybe you'd like yosys let know that some vhdl cells exist and syntheize them automatically ? I suppose this is possible; I think this is mostly a work to do in the yosys plugin (and I'd be happy if someone volunteers for that!)

[alaindargelas]

I tried two consecutive calls to
ghdl cell1.vhdl -e
ghdl cell2.vhdl -e

The 2nd call requires the actual top level entity in the file:
ghdl cell2.vhdl -e cell2

Else I get an error that no module was found.

I'm trying to emulate the auto-discovery as you mentioned above. The list of VHDL has been given as a library, with no particular list of top-level entities per file. Then that library is instantiated in a Verilog file. Most commercial tools figure out automatically what to compile.
Because of the limitation above, I require more user input that they typically didn't provide to existing commercial tools, or I need to write a preprocessor that will sort things out in order to build the proper ghdl -e command lines in Yosys.

The separate !ghdl -a invocations do not require to specify which entity to import, but the multiple ghdl -e do.
Is that a bug?