Pass Chisel information to firtool to generate debug information for the Tywaves project · Issue #4015 · chipsalliance/chisel (original) (raw)

I have started to work on a better version for my type-based waveform viewer for Tydi and Chisel-related projects (Tywaves).

My chisel fork: https://github.com/rameloni/chisel/tree/tywaves-annotations

Currently, I created a demo to show potential features of types in waveforms and prove its feasibility. Therefore, it only works with a restricted number of cases so far. The demo is divided into 2 main parts:

• Tywaves-chisel-demo backend which generates proper debug information
• Surfer-Tywaves fork of the Surfer waveform viewer able to render Chisel constructs

Although the approach I used for the demo works for some cases, there are some drawbacks related to that both practical and technical. Because of that the need for an integration within the chisel elaboration infrastructure.

The current approach and drawbacks: chisel side

In my demo, I create an external library for chisel that:

• parses Chisel IR, Firrtl IR, and the HGLDD (debug info emitted by firtool to link verilog and firrtl)
• retrieves and joins signals together by identifying IDs (shared between IRs) based on signal names and source locators
• emits a symbol table suited for the viewer from the combination of Chisel circuit, Firrtl circuit, and HGLDD

This leads to the following issues:

1. First of all, it accesses and uses the Chisel IR which is private to chisel3. This may compromise compatibility with future chisel versions.
2. IDs are based on source locators and variable names. This causes for example issues when I have multiple instances of the same module (its internal signals have the same source locators, currently not working in the demo).
3. It relies on HGLDD which can also change in the future since it is not stable and realized for synopsys.
4. In addition HGLDD mainly contains Firrtl-to-Verilog information (except for source locators in chisel). This requires a new file format.

During a CIRCT meeting a few weeks ago, I had the opportunity to present my project and show the demo. Fabian Schuiki and I agreed that these issues would be solved if I managed to pass Chisel information directly to firtool, also simplifying the code itself.
This can be achieved by propagating "Chisel IR information" during the elaboration phase to "Firrtl IR" (from here this GitHub issue).

I explain the drawbacks in a bit more detail here: https://github.com/rameloni/tywaves-chisel-demo?tab=readme-ov-file#drawbacks

New approach: integration during Chisel elaboration and Firtool

To solve the issues of the current demo, I need a systematic method to map Chisel values to Firrtl. In this way, I could provide firtool with the emission of a (new) debug file format. In addition:

• it would simplify the code structure and tool flow
• it guarantees a better integration in the Chisel/CIRCT infrastructure, this...
• since it will be part of the source code of Chisel and firtool, it would be also easier to support new features and eventual changes in the conversion from Chisel-to-Firrtl circuit
• it would solve the issue of (guessing) the IDs, because the "mapping" will be done during the elaboration process for each element, ensuring an exact match between chisel and firrtl elements

Implementation of the new approach in Chisel

Chisel allows passing arbitrary metadata to FIRRTL associated with more targets (elements in a FIRRTL circuit) through the annotation mechanism. The toTarget() function can be used to reference a scala object with a FIRRTL target. Therefore, associating each target with its concrete scala/chisel information.

My goal with this issue is to write an implementation to:

• annotate each firrtl target (modules, instances, nodes, signals...) with chisel types and (possibly) other metadata such as scala parameters (i.e. class MyModule[T<:Data](gen: T, n: T) extends RawModule). This last is more challenging though.
• enable the annotation only for simulation and (maybe) only if tywaves is needed. It's useless to have this annotation during ChiselStage.emitSystemVerilog) for example.
• check if every target is annotated (for eventual bug detection)
• write a list of supported chisel constructs to keep track of the current progress