I noticed that the examples in test/Conversion/ExportVerilog use sv.wire and sv.reg, but I don’t see anything like sv.logic or some other type which converts to sv.logic. I also noticed that interfaces and ports sometimes generate logics in the exported verilog. What should the MLIR representation look like to represent SystemVerilog’s logic in the generated output?
1 Like
I haven’t thought this through entirely, but I expect we may want to move towards a notion of sv.net and sv.variable. Emission of logic vs. reg then becomes more of a “which Verilog/SystemVerilog standard do you want” when emitting sv.variable as opposed to directly representing different, equivalent constructs in Verilog/SystemVerilog.
The SV dialect is more focused on an IR for V/SV emission as opposed to representing the V/SV language directly. We already diverge when appropriate to make this easier (e.g., always blocks include the clocks/resets as opposed to just using sensitivity lists). logic emission may fall into a similar category.
Put differently, is this is a question of “I need to model the semantics of sv.logic” or “I want to see sv.logic in the output”?
Currently ROHD generates SystemVerilog directly and offers access to equivalent levels of abstraction as SystemVerilog. For example, declaring a signal (object of type Logic in ROHD) currently always generates a SystemVerilog logic in the generated output.
Users of ROHD will be interested in thinking about signal declarations in a familiar way (logic) and the generated output should use logic instead of wire and reg.
I’m looking to replace the SytemVerilog generator in ROHD with CIRCT, but the first question I ran into is how to declare signals in the same way. A generic “hardware signal” would be sufficient as long as it was flexible enough to cover the use cases of logic and could be configured to generate logic in the exported SystemVerilog output. So I guess the answer is both?
What’s the recommended way to describe a generic hardware signal without explicitly identifying it as either a wire or reg?
For anyone else coming across this question, since SystemVerilog reg and logic are functionally the same, it’s fine to use sv.reg from a functional perspective. This doesn’t fully address the desire to generate code which has logic in it instead of reg, but is fine for a workaround for now. Thank you to the attendees of the CIRCT meeting on 1/5/2022 for the suggestion!
FYI, we added sv.logic based on the discussion of the last ODM.
https://github.com/llvm/circt/pull/3455
1 Like