Synthesizable RTL export

[aproxp]

Hello,

I am currently working with a proprietary in-house tool-chain for generating register map documentation, UVM packages, c-headers as well as synthesizable RTL that can be directly used in IPs. As most of the problems and limitations that I encounter are already solved with SystemRDL and the awesome compiler that you wrote, I am strongly considering migrating that tool-chain to the one based on SystemRDL.

The only thing that is blocking is the ability export synthesizable RTL modules, which would basically be "register slaves" modules for each addrmap and interconnects between parent and children addrmaps. Additionally, having named parameters available for generating those RTL modules (for one-to-one mapping between parameters in SystemRDL and SystemVerilog) would be very helpful (#58). Alternatively, from my brief review of the code I could also use the NamespaceRegistry before the elaboration to get those.

I am willing to invest my time into developing that feature, and possibly contribute it back (not entirely in my hands). Would you happen to have any thoughts on adding such a feature?

Regards,
Alex

[amykyta3]

Exellent!
I've been quite humbled about the enthusiasm about this project lately. It started off as a silly hobby project that "got out of hand".
I'm thrilled to see people start building their own in-house tools.

I actually started implementing an open-source register block generator a few months ago. I already have a skeleton project started, and a lot of random nodes/ideas for how to implement.

What I started relies heavily on the Jinja template engine to generate the SystemVerilog. I recall I approached the problem by breaking it apart into several layers to allow for more compartmentalization and flexibility:

• Bus Interface layer - How does the user connect the given protocol to the block (SV Interface? or using discrete I/O ports)
• Bus protocol layer - What protocol does this block use (APB, AHB, AXI, Wishbone, etc...)
• Address decode layer - Decodes accesses into register strobes
• Register block - Implementation of registers/fields/etc
• HW I/O layer - Defines how the register/field controls get exposed to the user (individual signals, struct, SV interface, etc...)

I completely forget what state I left it in, since I got distracted by several other hobby projects (and nice summer weather!). I'll try to clean it up and push what I have onto GitHub, even though it is far from complete.

Regarding deferred parameters (#58), see my recent comments in that ticket. It should be pretty clear that adding support for that adds significant complexity. Realistically, I would only allow for a small subset of values to be based on a deferred parameter. Stuff like the number of array elements, base addresses, and the value of the ispresent property seem like reasonable starting points. I'm open to ideas.

[aproxp]

If you could push whatever you have laying around I would love to take a look. I also have some lose thoughts based on my previous experiences.

• On the bus side my main consideration would be the ease of use. For that I would lean heavily towards APB - converters can always be applied on the edge. Using SV interfaces would be my first choice, however for interoperability (different tools + mixed VHDL/Verilog/SystemVerilog code-bases) discrete ports are much safer.
• For address decoding there are actually at least two levels here. One is at a module level, where each "block" would need to know that the transaction belongs to it. The logic for this can be either embedded in the the block itself, or be a part of the interconnect. The second level is at the registers, where each block needs to know which register the transaction accesses.
• For the HW I/O I would lean heavily for each field to have it's own set of ports, derived from field access properties, possibly with names suggesting the behaviour.

The reason behind asking for the deferred parameters is in the following use cases:

• Assuming we instantiate a register block multiple times, each instance can have different initial (reset) values of registers. The reset value will then be determined with parameters passed during instantiation in RTL.
• Additionally, each instance will have have a different base address.

With those in mind, the work-flow and the division of responsibilities between what is handled by elaboration in SystemRDL and what is handled by elaboration in SystemVerilog is a little unclear to me. Does each change in the global parameter passed to the register block require a full run of the SystemRDL-compiler (exporting updated RTL), or maybe it should be enough just to pass the same parameters to the SystemRDL-compiler for documentation only, but the exported RTL would not change.

Most of those would probably get clearer if/when I actually start working on this.

[udif]

@amykyta3 I would really welcome any RDL to RTL commit, in any state, as I would expect such an export module to be highly customized anyhow. The original RDL tool from Cisco (that was later sold to Denali and marketed as "Blueprint") had perl backends that were customized for the specific RTL output desired.
I really hope to push RDL where I work now, and this would really help.

[udif]

VHDL based AXI4-Lite slaves
Initial support for Verilog

The Verilog translation (by me) initially corrsponds to the VHDL code 1:1 . Once I can verify the coed works, I can remove all the redundant signals derived from the VHDL code.

Also note that at the moment only simple registers work.

Not working:

• regfiles
• arrays (not checked, but I'm pretty sure these would not work).

[hughjackson]

Hi, I was also doing something similar and only just got around to checking it in. It is based off of the PeakRDL-uvm repo, but with the exporter and templates updated. Sorry to bring, yet another solution in to the mix. Whichever ends up being popular, I would be keen to contribute. My version is here https://github.com/hughjackson/PeakRDL-verilog (I borrowed your name, obviously very happy to change if you want!).

At the moment it uses a parameter as the base address of the module and decodes absolute addresses for each register. The bus is something very simplistic but would be easy to convert.

I haven't got around to testing it yet, but after seeing this thread it seemed like a good time to share what I've got so far. I think some combination of VUnit and Verilator for testing would possibly be best, although using PeakRDL-uvm in a little UVM TB could work well too!

[udif]

First, let me say that I like your solution more than my current fork of hectare.
Your solution handles multiple instances of regfile, which as far as I remember , hectare didn't handle correctly.
Second, I need something much closer to your simple bus than to AXI-Lite. I went with AXI-Lite simply because that's what the original hectare code used.
In addition, the more I looked at the hectare code, the less I understood why they chose to add their own listeners instead of using the tree already in memory, using the systemrdl API. In fact, I also started taking a look at a scratch-built solution based on https://github.com/SystemRDL/PeakRDL-html , but you have gotten much further than me. (It's been a month since I've touched this code, so all of this is what I vaguely remember ).

[amykyta3]

I am actively developing the SystemVerilog exporter here: https://github.com/SystemRDL/PeakRDL-regblock

The scope of the project is pretty ambitious as I intend to fully support all SystemRDL properties, as well as allow for "RTL-time" parameterization someday.

Feel free to watch that project for updates & releases. I'm pretty close to having an initial functional release, but I anticipate it will still remain in an "alpha pre-production" state for some time.