ROHD Hierarchy: an API for compact, generic traversal of a remote design#653
ROHD Hierarchy: an API for compact, generic traversal of a remote design#653desmonddak wants to merge 5 commits intointel:mainfrom
Conversation
mkorbel1
left a comment
There was a problem hiding this comment.
Will be reviewing this next, couple quick comments until I have a moment to continue. This looks really great so far!
There was a problem hiding this comment.
should we include (either copy/paste or via some sort of include if that is supported sufficiently) the rest of the analyzer rules from base ROHD?
| } | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
Split classes into individual files?
|
Question: how do you imagine this package being used/depended on? Would we release it as a separate package on pub.dev? |
| /// ## Quick Start | ||
| /// ```dart | ||
| /// // 1. Create hierarchy | ||
| /// final root = HierarchyNode(id: 'top', name: 'top', |
There was a problem hiding this comment.
nit: multi-line code comment not formatted as nicely as it could have been
| /// The kind of node in the hardware hierarchy. | ||
| enum HierarchyKind { | ||
| /// A module definition in the hierarchy. | ||
| module, |
There was a problem hiding this comment.
should this be called "definition" instead to contrast with "instance"? and actually, more generally, what is a definition in a hierarchy?
| /// Use this before a [HierarchyNode] exists (e.g. when deciding whether | ||
| /// to recurse into a Yosys cell definition). For an existing node, use | ||
| /// the instance getter [isPrimitiveCell] instead. | ||
| static bool isPrimitiveType(String cellType) => cellType.startsWith(r'$'); |
There was a problem hiding this comment.
question: is this yosys conventions leaking into a generic abstraction or is it fine to keep them coupled like this?
| /// Hierarchical address for this node. | ||
| /// Assigned by [buildAddresses] to enable efficient navigation. | ||
| /// Format: [child0, child1, ..., childN] for nested modules. | ||
| HierarchyAddress? address; |
There was a problem hiding this comment.
something feels off about this not being immutable (final) and requires a function later to update it. is there a way to make this safer/more automatic?
| required String direction, | ||
| int width = 1, | ||
| String? id, | ||
| String type = 'wire', |
There was a problem hiding this comment.
"wire" is an SV type -- do we want that to be the default here? in ROHD everything is Logic and ports are by default logic as well in generated SV, wheras LogicNet inOut ports would map to wire
| /// Check if a [node] or any of its descendants match [searchTerm]. | ||
| /// | ||
| /// The search term is split on `/` or `.` into hierarchical segments. | ||
| /// Each segment is matched case-insensitively via substring containment |
There was a problem hiding this comment.
question: why case insensitive?
| root, [root.name], parts, 0, results, effectiveLimit); | ||
| return results; | ||
| } | ||
|
|
There was a problem hiding this comment.
general question: have you considered fuzzy searches?
There was a problem hiding this comment.
question: will this package eventually support tracing connectivity? e.g. connection extractor in rohd bridge?
There was a problem hiding this comment.
why not included in appropriate locations?
| }); | ||
|
|
||
| // ------------------------------------------------------------------ | ||
| // VCD-style dot-separated paths |
There was a problem hiding this comment.
"vcd style"? another new term?
…pact, canonical addresses
Description & Motivation
It would be nice to have a hierarchy api that allows us to remotely traverse a design hierarchy using compact addressing to support a devtools-based debugger. For example, if we receive a dictionary of the design, we can communicate requests for more data from the design by using a compressed addressing scheme like (5th instance, 4th instance below that, 15th signal) to receive a set of data on that signal. If we need 1000s of simulation values, for example, we do not need to transmit all names, providing an order of magnitude savings in transmission bandwidth.
This capability allows us to incrementally a design view over multiple data requests. For now, we primarily have two: a 'slim' view, which is the full hierarchy with names, and then a full view, which is all connectivity. This can be extended to allow for a more incremental dictionary load to allow a remote agent to use limited memory to transit a very large design.
Related Issue(s)
None.
Testing
Tests are provided with a small design fixture using a new netlist format in JSON, equivalent to Yosys JSON. A future netlist synthesizer will provide design data nd this
rohd_hierarchy adapterwill allow us to communicate between remote agents.Backwards-compatibility
No
Documentation
A
README.mdis included to describe the motivation, architecture, and key features of the api.