The Property Rulebook
SystemRDL defines a vast assortment of properties that can be specified for each component definition. Each property has its own set of semantics, and quirks. The PropertyRuleBook class provides an interface to query each property’s rule class. It also maintains a list of user-defined property rules.
Each property rule is encoded as a Python class with various static variables and classmethods
Each rule class has the following static variables set:
List of component types it can be applied to
List of types that are allowed to be assigned to it
Whether it can be dynamically assigned
List of mutually exclusive other properties
Unambiguous default value, if any
Rule classes also have the following classmethods:
- assign_value(cls, comp_def, value)
Used by the compiler for either static or dynamic prop assignments After the value’s type has been validated to be appropriate, and mutex rules checked, apply it to the component def. Base class will simply toss it in the property dictionary. Some properties extend this if they have additional side-effects that impact other properties
- get_default(cls, node)
Used when the user queries a property, and it was not explicitly set. Default values are not always directly known. Sometimes they depend on one or more other properties. The base class will simply return the static variable’s value but for more complex ones, this method will derive it from the context class
For local property assignments, the parse visitor will blindly collect all properties into a dict, where the key is the property name. If any assignment already exists in the dict, throws an error immediately.
At the end of the component body, flip through each local property assignment and:
Check for mutex collisions
Coerce assignments to appropriate type (predict expr type, assignment cast, etc…)
In grammar, property names include existing keywords, and other non-keyword ID
LHS assignments can be:
reference to a signal instance
reference to a “virtual signal” property
Reference to any other component types? I don’t think so?
RHS references can be:
only a “virtual signal” property of a field or reg
These are shown in the spec in Annex G, marked under the “Ref target” column.
It looks like RHS reference to copy a component property’s value is NOT a thing. In fact, it hardly has anything to do with the property that bears its name. Instead, it looks like its reference implies a “virtual signal” that has its own dynamic behavior based on the component’s state.
Each property has an expected type
Some can accept more than one type (numeric OR signal ref)
Some properties are mutually exclusive
Each mutex set is listed in Annex G
Not all are allowed to be dynamically assigned
User-set defaults are propagated according to namespace scope, not by structural parent->child inheritance Defaults may need to be propagated at parse time instead Spec basically implies another “default property” namespace