FIRRTL VHDL Emitter #7
Conversation
Signed-off-by: Schuyler Eldridge <schuyler.eldridge@ibm.com>
| firrtl -e verilog | ||
|
|
||
| # To emit both Verilog and VHDL | ||
| firrtl -E verilog -E vhdl |
There was a problem hiding this comment.
Note that generally it may not be possible to emit VHDL and Verilog from same AST.
(My knowledge of FIRRTL possibilities is only basic.)
It may seems as easy to do. If we talk about emitting Verilog 2001 and VHDL < 2008. The Verilog does not support proper array initializations and VHDL requires temporary variables for type conversions and does not support ternary in side of an expression and requires explicit declaration of types used as an array types....
And there are other problems like renaming of variables due collision with target language keywords, etc.
From this reasons in my project using an explicit transformations that ensure that the intermediate format (FIRRTL) is in correct format before emmiting target language. I am using dictionaries to cache the changes and make changes only temporary. And thus avoid modification of the intermediate format in the cost of slowdown.
I did not find better way how to ensure always correct 100% deterministic output without any sideefect.
There was a problem hiding this comment.
I'm in agreement with this. The starting point for a Verilog, VHDL, or some other language emitter would be Low FIRRTL. Currently language-specific optimizations are not saved and are only used to help generate the emitted String in the target language. The actual emitter transform is only adding annotations that include the emitted String.
The existing path from Low FIRRTL to "Low FIRRTL Optimized and ready for Verilog conversion" is here to show some flavor of what's done: https://github.com/freechipsproject/firrtl/blob/master/src/main/scala/firrtl/Emitter.scala#L949. None of this is saved to the IR, though. I'd expect a similar set of passes would be necessary for VHDL.
Scoping to one specific Version of VHDL would make sense. There's no necessity on why FIRRTL couldn't support additional versions eventually. Related to this, the SystemVerilogEmitter is really just the VerilogEmitter with a different file suffix. Eventually, this could include other custom transforms (e.g., interface construction) that specialize better to the features of that language.
Fortunately, removal of collision with a set of keywords can be made parametric. I expect that there's similar optimization transforms that can be written to be reusable across language backends.
Good thoughts, thanks!
| - This should be a model for how new back-ends should be added. | ||
| - This should be a starting point for thinking about what back-end `Stage`s should look like. This would either be part of this RFC as it evolves or it would be part of a future RFC about building back-end stages. | ||
|
|
||
| It would be beneficial if we had a dedicated owner of the VHDL back-end and if we had dedicated VHDL users. Without either of these, a VHDL back-end is likely to diverge and become difficult to maintain. Granted, we can't have VHDL users now if we don't emit VHDL. Any users would be mixed-language ones. |
There was a problem hiding this comment.
It may be possible to check Verilog/VHDL for semantic equivalence using hdlConvertor, current state of hdlConvertor is enough for the needs for FIRRTL (parses and emits VHDL/Verilog from/to same AST), but it currently does not support 100% of VHDL2008/SystemVerilog2017 (+-0.5y).
| A potentially cleaner implementation would be to treat the VHDL backend as a separate stage. This can still be a `Transform`, but it would be wrapped up in a separate VHDL emitter `Phase` that could be run independently. This, while deviating somewhat from the current Verilog emitter family, would potentially be easier to maintain long-term and act as a demonstration for how to refactor the Verilog emitter going forward. | ||
|
|
||
| Nonetheless, it is likely easier to get all the VHDL emitter `Transform`s integrate with the way things work now and then refactor the emitter to be a separate stage. | ||
|
|
There was a problem hiding this comment.
It may be possible to reuse some existing back-end. Because it may be more simple to convert between the format rather than writing emitter again. (It would be also nice to see all those HCL tools compatible with each other, this is good beginning.)
| ## Open Source Tooling | ||
|
|
||
| VHDL has no open source compiler equivalent to [Verilator](https://github.com/verilator/verilator). Some open source tools do exist, notably [GHDL](https://github.com/ghdl/ghdl), but the performance is not up to snuff with Verilator or VCS. Integration with GHDL would likely be needed as part of this PR and that adds further complexity of needing to maintain additional back-ends in testers. The existing factoring of things where post-emission back-ends live in testers may be worth reconsidering. | ||
|
|
There was a problem hiding this comment.
Ah, cool. I wasn't aware of this one...
There was a problem hiding this comment.
Seeing build status it does not build up much trust, but I was able to run programaticaly translated RISC-V 7months back.
Proposal to add a VHDL emitter to FIRRTL.