Support for VHDL

[suppamax]

Any plan to support VHDL, e.g. via the GHDL plugin for Yosys?

[nmoroze]

We have a basic prototype of support for GHDL right now, with the ability to convert a VHDL source file to Verilog. You can see this test for an example of how to drive this: https://github.com/siliconcompiler/siliconcompiler/blob/main/tests/tools/test_ghdl.py.

Extending this is probably not on our near-term roadmap, but we'd appreciate contributions towards this! We'd be happy to discuss if you're interested.

[mithro]

FYI - You might find the diagram at https://j.mp/vhdl-flow-diagram interesting. There are also diagrams at hdl/awesome#98 (comment)

[suppamax]

Thank you both for your replies.

@nmoroze Regarding the VHDL support, sure, I'd gladly see what needs to be done and see if I can fit in my agenda.

[nmoroze]

I just did a bit of cleanup of our Microwatt example: https://github.com/siliconcompiler/siliconcompiler/blob/main/examples/microwatt/build.py. I think it would be a nice goal for our VHDL support to get to the point where we could run this core end-to-end through an SC ASIC or FPGA flow.

The current status is that we can get a flattened Verilog output through GHDL, but it seems to insert calls to functions like $fatal(..) that Yosys can't handle. I haven't dug into what's going on here (whether these are GHDL-specific things, or part of the standard that Yosys doesn't support, or what).

Another thing to look into it: we're using GHDL's integrated Verilog backend (we opted to do this over the Yosys GHDL plugin), but last I worked on it this output would only be provided via standard out. Therefore there's a bit of hacky parsing in the tool driver's pre_process() to filter out the messages from the log file and just copy out the Verilog. It would also be nice to find out if a newer version of GHDL would let us do this more cleanly (in particular, by outputting directly to a file). It also seems like the tool driver might be missing support for preprocessor macros, which we drive through the 'define' schema.

[mithro]

I'm pretty sure the preferred way to do VHDL in the open source flow is to use GHDL+Yosys via the plugin. This is what Microwatt tests with for example.

[suppamax]

OK, I can have a look at that example.

As a very poorly educated feedback, I can tell you that:

• in my own VHDL project, I didn't get any $fatal or functions which cannot be processed by Yosys
• [this is actually wrong] if you are using the --synth option in GHDL you can write the verilog file by using --out
• the ghdl-yosys-plugin is basically a wrapper around ghdl --synth, so using one or the other should make no difference

[suppamax]

Regarding the $fatal issue...
These commands are inserted by GHDL (https://github.com/ghdl/ghdl/blob/aff48727a4d0ad4058b7d43a86ebd6ed24b9cc6d/src/synth/netlists-disp_verilog.adb#L1084), but as far as I know this is not a Verilog task. I opened an issue in GHDL's repo about this.

As far as I know, the only way this could be solved is to translate $fatal in $display + $finish, but this cannot be correctly processed by Yosys - from here

The system tasks $finish, $stop and $display are supported in initial blocks in an unconditional context (only if/case statements on expressions over parameters and constant values are allowed). The intended use for this is synthesis-time DRC.

I don't see an elegant solution to this problem, I could propose to workaround this issue by commenting all assertions in the generated verilog and substituting them with ;.

[suppamax]

An even better solution would be to add the --no-formal option

Neither synthesize assert nor PSL.

[suppamax]

In PR #944

• suppress unsupported assertions
• use of ghdl-yosys-plugin (helps getting rid of the hack in post_process)

[jarvis-lorry]

I've been able to run the microwatt design successfully, but I cannot get a basic adder design to run because it requires the '-fynopsys' option. Is there a way to include this ghdl option when running SC?

Here is the design:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity binary_4_bit_adder_top is
Port ( NUM1 : in STD_LOGIC_VECTOR (4 downto 0) := "00000";
NUM2 : in STD_LOGIC_VECTOR (4 downto 0) := "00000";
SUM : out STD_LOGIC_VECTOR (4 downto 0));
end binary_4_bit_adder_top;

architecture Behavioral of binary_4_bit_adder_top is
begin

SUM <= NUM1 + NUM2;

end Behavioral;

[suppamax]

This is exactly what ghdl does in this context: VHDL to verilog conversion.
That's why I think it is just a matter of slightly modifying an existing workflow.
The question to @nmoroze is whether the user is supposed to tweak the existing flow and add ghdl, or better asicflow should support both options and have a configuration parameter, or some other solution should be implemented.

[suppamax]

This is an example of what I mean:

    chip.load_target('freepdk45_demo')
    flow = 'asicflow'
    chip.node(flow, 'import', 'ghdl')

    chip.run()

[nmoroze]

We have a 'frontend' parameter right now that you can use to select which tool to use for 'import'. I think it would make sense for now to add 'vhdl' as an option and map it to ghdl:

https://github.com/siliconcompiler/siliconcompiler/blob/main/siliconcompiler/flows/_common.py

As far as personal workarounds go, however, doing a 2-step process or modifying the flow locally both seem reasonable to me. We're working on some big changes, and something planned is to support modular flows (which I think will include splitting out frontend flows from the implementation backend), so we will probably have a more concrete "best practice" for how we configure non-Verilog frontends once that is complete.

[jarvis-lorry]

@nmoroze Do you expect the approach in @suppamax's last messsage to work?

Another question I have is about importing VHDL packages. Are package files meant to be imported by SC the same way as they are with ghdl or are there other requirements. I'll admit that I'm not great with VHDL, having used Verilog for most designs.

[suppamax]

Regarding VHDL packages, I suggest you to have a look at the Microwatt example. Basically, you have to treat packages as normal files and compile them before the "entity" files.