You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently there is no good way for hierarchical header re-use. If a sub-design exports a header, and a separate header is generated at a top-level, this can create namespace collisions (#8)
Provide a mechanism so that a top-level header can intelligently re-use and reference an existing sub-design's header.
Proposed mechanism
Upon generation of the top-level header, a user can provide contextual information about what is eligible to be grafted:
SystemRDL type-name of nodes that are eligible to be grafted
Optional C struct type name to reference when grafting
When generating the top-level header, struct and define definitions for any nodes that match the user-provided type name will be skipped. Instances of grafted nodes will either use the user-provided struct type name, or the expected type name based on existing type name generation semantics.
Since nodes can be parameterized or augmented via dynamic assignments, a user-provided type name can be either the fully mangled type name, or the original generic type name from RDL source. The exporter will check the fully mangled type name for matching first.
Restrictions
In order to limit complexity, and encourage best user practices in RDL, grafting will be limited to:
addrmap, regfile, and mem nodes
Can only graft types that are declared in the global RDL namespace. Internal definitions and anonymous definitions will not be graftable.
The text was updated successfully, but these errors were encountered:
Issue
Currently there is no good way for hierarchical header re-use. If a sub-design exports a header, and a separate header is generated at a top-level, this can create namespace collisions (#8)
Provide a mechanism so that a top-level header can intelligently re-use and reference an existing sub-design's header.
Proposed mechanism
Upon generation of the top-level header, a user can provide contextual information about what is eligible to be grafted:
When generating the top-level header, struct and define definitions for any nodes that match the user-provided type name will be skipped. Instances of grafted nodes will either use the user-provided struct type name, or the expected type name based on existing type name generation semantics.
Since nodes can be parameterized or augmented via dynamic assignments, a user-provided type name can be either the fully mangled type name, or the original generic type name from RDL source. The exporter will check the fully mangled type name for matching first.
Restrictions
In order to limit complexity, and encourage best user practices in RDL, grafting will be limited to:
The text was updated successfully, but these errors were encountered: