Targeting Non-Verilog Backends

Are there any plans to have a non-verilog backend ? I wonder if it would be interesting to have a more low-level output. Some examples I’m thinking of:

1 Like

Yes, that is certainly in scope. Right now we are concentrating on really good SystemVerilog output, but one could further lower and map the comb and reg dialects into device primitives and use the existing SV output to create a netlist, for instance. We are also targeting Yosys with SV (though I haven’t been involved with that work), but the JSON input format is certainly something we could target.

I personally am interested in targeting alainmarcel/UHDM: Universal Hardware Data Model. A complete modeling of the IEEE SystemVerilog Object Model with VPI Interface, Elaborator, Serialization, Visitor and Listener. Used as a compiled interchange format in between SystemVerilog tools. Compiles on Linux gcc, Windows msys2-gcc & msvc, OsX (github.com) even though I do not have an immediate use case.

I think it’s a great idea. It is common for many systems to output VHDL and/or SystemC too. Building a direct interface to yosys could be useful too. Targetting lower level systems like Reticle or could be done, but would seem to require pulling lower levels of the design flow up to the CIRCT level: Personally, I think logic synthesis and mapping would be the place to start here, rather than low-level physical design, but everything has it’s place. :slight_smile: We’ve done some experiments along these lines targetting RapidWright internally, but nothing in a shape to upstream at this point.

3 Likes

Yeah, supporting something like this would make sense. That said, we should only do this if it is motivated by a specific win and we have a clear use-case, because it will incur significant maintenance cost, requires a real design effort and is likely to bit rot unless it receives ongoing love. I’d prefer to not to take this on as a proof of concept.

2 Likes

thanks for the awesome information.