C Register HAL

[roowatt]

I am looking for a C based register HAL, I understand that there are plans to add an exporter fo the PeakRDL tool to do this.

Do you have any advice as to how to approach this? Do you have any design notes or examples of the style of headers and macros you expect? Any gotchas or deal breakers?

I am asking because it makes sense that if we take this on that it is able to be contributed to the project.

[amykyta3]

I'm actually working on the initial architecture for it as we speak, and hope to implement it quite soon.

One thing that will be the biggest help is to get ideas for what specific features people are looking for. Generally, I plan to have the tool generate both a struct overlay for register addressing, as well as #define for field definitions. One good existing example is ARM's CMSIS headers: https://github.com/ARM-software/CMSIS_4/blob/master/CMSIS/Include/core_cm4.h

If there is anything specific you have seen in your experience that you'd like to see in the tool, let me know!

[roowatt]

Seems like fortuitous timing. :) I am approaching this from a standing start (nearly).

Deeply embedded processor sub-systems I have designed and implemented have mostly been a very manual process. This approach is not sustainable, particularly for the projct I am currently working on.

I have talked to one of our SW devs, he agrees the example file you linked to would be good.

Some initial thoughts I have been pondering are below, this is by no means exhaustive but maybe a start;

• Where possible, maximise repeatability of macro/struct names from one RDL build to the next. The idea being to minimise unneccessry/avoidable changes to the Drivers that cuse the register HAL.
• If possible, generate optional C tests to self check and/or exercise register functionality.
• Annotate output (Doxygen?), especially properties like single pulse, clear on read, buffered read/write triggers
• Some kind of versioning that propagates from the RDL, to system verilog register build and through to Register C HAL. The idea being mistmatches can be detected.
• Propagate description strings and perhaps be able to provide URL prefix to link back to html documentation for internal team.

I am keen to help testing if you need/want.

[amykyta3]

Yep that's generally the idea.

• Macro/Struct type names will be derived from the RDL lexical type names where possible (Similar to how the structs are named for peakrdl-regblock)
• Yes tests to be included as an optional feature. Will be making unit tests anyways, so may as well bundle them with the tool too.
• Doxygen is a good idea and a tidy way to include the desc/name strings too. Hadn't thought to do it that way. Thanks!
• Versioning will be difficult to do generically, however if I also export defines for field reset values, that could be used as a common source of truth to bind header+Verilog versioning, assuming you have a version register or similar.
• URL prefix is a really interesting idea! So provide a mechanism to create links back to PeakRDL-html output. I like it.

[roowatt]

Sounds great!

Versioning will be difficult to do generically, however if I also export defines for field reset values, that could be used as a common source of truth to bind header+Verilog versioning, assuming you have a version register or similar.

That would work, binding the header+verilog would be enough I guess. I could always use some kind of command line parameter to pass a GIT hash to a description string.

URL prefix is a really interesting idea! So provide a mechanism to create links back to PeakRDL-html output. I like it.

I haven't set it up yet, but I am planning on using a CI/CD flow for internal releases of FPGA builds prior to ASIC tapeout. There will be multiple build variants and iterations so a link back to html doco will be fantastic.

[amykyta3]

Refactored version released! See v1.0.0