API For Tagging Signals

[jackkoenig]

Emits a Verilog (or other) mapping from tag to full hierarchical signal path. The intent is to allow people writing more traditional Verilog or SystemVerilog testbenches to better hook into Chisel DUTs.

[jackkoenig]

Useful information we probably want to help people access via first class feature:

1. Hierarchical path of a wire, reg, instance, etc.
2. Width of a wire or reg
3. Module relative name (possible Module.signal or just signal)
4. Module name

3 and 4 would be useful for people who want to bind things to a given module (eg. SystemVerilog assertions).

[scottj97]

One use case: my DUT has an AXI slave port, to which I've connected a third-party VIP AXI master driver, which is implemented as a UVM agent in SystemVerilog. My testbench has to configure this VIP by (among other things) telling it about the memory map: what address ranges it can access through this port.

I need to get this information from the design in Chisel and format it into the correct SystemVerilog function calls, which are specific to this brand of VIP.

[scottj97]

Another (related) use case: this AXI VIP has a data integrity checker which checks that any value read through the port match the previous value written to that address. But this requires that the VIP have knowledge of the initial values in the memory, which (in a Chisel-generated memory with +define+RANDOMIZE_MEM_INIT) are unpredictable.

If I knew the hierarchical path to each memory that's accessible through this port, and the size & width of each, I could read those memories' contents right after reset, and feed that data into the VIP.

[scottj97]

Use case: my DUT includes a CPU with many memories connected. I want to initialize these memories with a compiled program which the CPU will execute. Typically this is done by creating hex files and loading them via $readmemh in the testbench.

Given a DUT, I need a way to figure out the address map visible from the CPU, then create a process that can automatically create the appropriate hex files from a compiled ELF binary. Also need to create the testbench code that does the $readmemh of each of those files into each memory.

This may include knowledge of caches, in order to warmstart them with real data.

[jackkoenig]

Thank you for the feedback and use cases, Scott. I'm trying to figure out what exactly the right amount of work for Chisel to do here. I see two main things that would be useful:

1. Emit a Verilog header with the String mapping to hierarchical path
   • Useful for simple Verilog testbenches
   • Could optionally provide local path so people could use this mechanism to emit simulation modules that they bind to the Chisel Module in question
   • Probably wouldn't work for advanced use cases like the ones @scottj97 provided
2. Emit a YAML or JSON with the mapping
   • Provides more flexibility to handle @scottj97's use cases above
   • Requires users with simple test cases to write a script to emit Verilog from the mapping

Perhaps the answer is a compromise: emit a mapping of the tags to hierarchical paths (and other information), but provide a script that converts the mapping to the simple use case Verilog header.

[scottj97]

Use case: building third-party IP. Some third-party IP requires additional build steps to generate the configured design. If my Chisel design includes such third-party IP, I want to be able to detect this in the build process and run the appropriate steps. I could implement this by having the Chisel module that connects such IP provide an indicator in its JSON. It could also indicate any special licenses needed for simulation.

[scottj97]

Use case: communicating simulation knobs to downstream tools. A testbench component with a plusarg-controlled knob can communicate its availability and purpose to downstream tools which then apply it as needed.