Frequently Asked Questions#
Why isn’t there an option for a flat non-record hardware interface?#
SystemRDL is inherently a very hierarchical language. For small register blocks, flattening the hardware interface may be acceptable, but this ends up scaling very poorly as the design becomes larger and has more complex hierarchy. Using record compositions for the hardware interface has the benefit of preserving conceptual hierarchy and arrays exactly as defined in the original SystemRDL.
How do I know I connected everything? Records are harder to review#
Initially this can be daunting, but fortunately the tool has an option to generate a
flattened hardware interface report upon export. Try using the --hwif-report
command line option when exporting. This is the easiest way to quickly
understand the structure of the hardware interface.
The generated output does not match our organization’s coding style#
VHDL coding styles vary wildly, and unfortunately there is little consensus on this topic within the digital design community.
The output generated by PeakRDL-regblock-vhdl strives to be as human-readable as possible, and follow consistent indentation and styling. We do our best to use the most widely accepted coding style, but since this is a very opinionated space, it is impossible to satisfy everyone.
The lint tool I am using is flagging violations in generated code#
Code linting tools are a great way to check for user-error, flag inconsistencies, and enforce best-practices within an organization. In many cases, linter tools may be configured to also enforce stylistic preferences. Unfortunately just like coding styles, lint rules can often be more opinionated than practical.
In general, we will not address lint violations unless they flag actual structural issues or semantically dangerous code. Stylistic violations that pose no actual danger to the correctness of the design will rarely be addressed, especially if the change would add unreasonable complexity to the tool.
If you encounter a lint violation, please carefully review and consider waiving it if it does not pose an actual danger. If you still believe it is a problem, please let us know by submitting an issue that describes the problem.