Replies: 2 comments
-
The core language validation step is more for verifying that the input RDL meets the rules defined by the SystemRDL specification. If you want to validate against additional rules, this is more appropriate in a specific exporter. In all the core exporters such as peakrdl-regblock, etc, I will often do a second-pass validation to screen for unsupported constructs. For example in the regblock exporter, there is the design scan phase that collects information about the design and checks for unsupported property combinations beyond what the spec defines: https://github.com/SystemRDL/PeakRDL-regblock/blob/main/src/peakrdl_regblock/validate_design.py At a first pass, i would simply rely on the existing rule checks in the exporters to ensure your organization is not using unsupported constructs. |
Beta Was this translation helpful? Give feedback.
-
Thanks allot for the design guideline! I've moved the additional validation to the exporter.. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
SystemRDL allows for a huge solution space of possible hw/sw access permissions and property combinations.
In a corporate environment, especially when integrating this flow for the first time, users often ask for a fixed set of commonly used/"approved" field types. (defined via e.g. preprocessor `define aliases).
Is there a way to implement this, other than modifying or deriving from src/systemrdl/core/validate.py (ValidateListener.enter_Field()) ?
That is external to the code base?
Thanks in advance, Gal.
Beta Was this translation helpful? Give feedback.
All reactions