I have also found the FIRRTL language specification doc (https://github.com/chipsalliance/firrtl-spec/releases/latest/download/spec.pdf). I think it is really useful for my purpose since it also explains how FIRRTL high-level types are lowered before the compilation to verilog.

I also thought that @[fileinfo] can be somehow exploited (of course not alone) to rebuild chisel constructs from FIRRTL (and verilog).

But, during chisel elaboration, the chisel IR is lowered to the FIRRTL. Is there any documentation for Chisel IR? For now, I retrieved the types supported in Chisel IR from the code only. The good thing about chisel IR is that it preserves the Data objects.

It's semi-integrated in that if you pass the -g option to firtool it will compile with debug info and print source locator information. You would also need to output the final MLIR to see this. Small example:

FIRRTL version 4.0.0
circuit Foo:
  module Foo:
    input a: {b: UInt<1>}
    output b: {b: UInt<1>}

    connect b.b, not(a.b)

# firtool Foo.fir -g --output-final-mlir=Foo.out.mlir -mlir-print-debuginfo && cat Foo.out.mlir

module {
  hw.module @Foo(in %a_b : i1, out b_b : i1) {
    %true = hw.constant true loc(#loc1)
    %0 = comb.xor bin %a_b, %true {sv.namehint = "b_b"} : i1 loc(#loc1)
    %1 = comb.xor bin %a_b, %true {sv.namehint = "b_b"} : i1 loc(#loc1)
    %2 = dbg.struct {"b": %a_b} : i1 loc(#loc1)
    dbg.variable "a", %2 : !dbg.struct loc(#loc1)
    %3 = dbg.struct {"b": %0} : i1 loc(#loc1)
    dbg.variable "b", %3 : !dbg.struct loc(#loc1)
    hw.output %1 : i1 loc(#loc1)
  } loc(#loc1)
  om.class @Foo_Class(%basepath: !om.frozenbasepath) {
  } loc(#loc1)
} loc(#loc)
#loc = loc("Foo.fir":0:0)
#loc1 = loc(unknown)

Those dbg.* operations are representing the original structure of the design. These will be preserved across inlining, type lowering, etc. The file info is still there, too,

The rough idea is that the frontend language needs to put enough information into the debug dialect. Once that information is there, then the compiler will keep it around and the debug information can be used later to provide links from the Verilog back to the source language. You can play around with this with an example like the following:

//> using scala "2.13.12"
//> using repository sonatype-s01:snapshots
//> using lib "org.chipsalliance::chisel::6.0.0+74-0a437d8f-SNAPSHOT"
//> using plugin "org.chipsalliance:::chisel-plugin::6.0.0+74-0a437d8f-SNAPSHOT"
//> using options "-unchecked", "-deprecation", "-language:reflectiveCalls", "-feature", "-Xcheckinit", "-Xfatal-warnings", "-Ywarn-dead-code", "-Ywarn-unused", "-Ymacro-annotations"

import chisel3._
import circt.stage.ChiselStage

class Baz extends Bundle {
  val a = Flipped(Bool())
  val b = Bool()
}

class Bar extends RawModule {
  val io = IO(new Baz)

  io.b :<>= !io.a
}

class Foo extends RawModule with Public {
  val io = IO(new Baz)

  private val bar = Module(new Bar)
  io :<>= bar.io
}

object Main extends App {
  println(
    ChiselStage.emitSystemVerilog(
      new Foo,
      firtoolOpts = Array("-g", "-emit-hgldd", "-output-final-mlir=Foo.mlir")
    )
  )
}

In reply to @seldridge:matrix.org

It's semi-integrated in that if you pass the -g option to firtool it will compile with debug info and print source locator information. You would also need to output the final MLIR to see this. Small example:

FIRRTL version 4.0.0
circuit Foo:
  module Foo:
    input a: {b: UInt<1>}
    output b: {b: UInt<1>}

    connect b.b, not(a.b)

# firtool Foo.fir -g --output-final-mlir=Foo.out.mlir -mlir-print-debuginfo && cat Foo.out.mlir

module {
  hw.module @Foo(in %a_b : i1, out b_b : i1) {
    %true = hw.constant true loc(#loc1)
    %0 = comb.xor bin %a_b, %true {sv.namehint = "b_b"} : i1 loc(#loc1)
    %1 = comb.xor bin %a_b, %true {sv.namehint = "b_b"} : i1 loc(#loc1)
    %2 = dbg.struct {"b": %a_b} : i1 loc(#loc1)
    dbg.variable "a", %2 : !dbg.struct loc(#loc1)
    %3 = dbg.struct {"b": %0} : i1 loc(#loc1)
    dbg.variable "b", %3 : !dbg.struct loc(#loc1)
    hw.output %1 : i1 loc(#loc1)
  } loc(#loc1)
  om.class @Foo_Class(%basepath: !om.frozenbasepath) {
  } loc(#loc1)
} loc(#loc)
#loc = loc("Foo.fir":0:0)
#loc1 = loc(unknown)

Those dbg.* operations are representing the original structure of the design. These will be preserved across inlining, type lowering, etc. The file info is still there, too,

In reply to @seldridge:matrix.org

The rough idea is that the frontend language needs to put enough information into the debug dialect. Once that information is there, then the compiler will keep it around and the debug information can be used later to provide links from the Verilog back to the source language. You can play around with this with an example like the following:

//> using scala "2.13.12"
//> using repository sonatype-s01:snapshots
//> using lib "org.chipsalliance::chisel::6.0.0+74-0a437d8f-SNAPSHOT"
//> using plugin "org.chipsalliance:::chisel-plugin::6.0.0+74-0a437d8f-SNAPSHOT"
//> using options "-unchecked", "-deprecation", "-language:reflectiveCalls", "-feature", "-Xcheckinit", "-Xfatal-warnings", "-Ywarn-dead-code", "-Ywarn-unused", "-Ymacro-annotations"

import chisel3._
import circt.stage.ChiselStage

class Baz extends Bundle {
  val a = Flipped(Bool())
  val b = Bool()
}

class Bar extends RawModule {
  val io = IO(new Baz)

  io.b :<>= !io.a
}

class Foo extends RawModule with Public {
  val io = IO(new Baz)

  private val bar = Module(new Bar)
  io :<>= bar.io
}

object Main extends App {
  println(
    ChiselStage.emitSystemVerilog(
      new Foo,
      firtoolOpts = Array("-g", "-emit-hgldd", "-output-final-mlir=Foo.mlir")
    )
  )
}

Can I get that information in a separate file?
I tried this but it didn't work:

  ChiselStage.emitSystemVerilog(
      new Foo,
      firtoolOpts = Array("-g", "-emit-hgldd", "--hgldd-output-dir=work", "-output-final-mlir=Foo.mlir"),
    )

I also tried to use emitSystemVerilogFile but it outputs both verilog and hgldd in the same file, I can't get a separate output

I just found this way to achieve that:

 ChiselStage.emitSystemVerilog(
    new Foo,
    firtoolOpts = Array(
      "-g",
      "--split-verilog",
      "-o=workdir",
      "-emit-hgldd",
    ),
  )

In reply to @seldridge:matrix.org
HGLDD is very Synopsys-specific right now and basically governed by what their needs are. So, it will likely change. I brought this up with Fabian and it seems reasonable to have a more generic format that is not driven by the needs of Synopsys. There are some hints of this with the -dump-di option to circt-translate that can be used to dump the debug info in a more human readable format (though this is intended for humans to read and not machines to consume).

In reply to @seldridge:matrix.org
Don't parse MLIR directly. It's not a stable format and it may change at any time. You can have an alternative emission of the debug info, though. That's more getting at this alternative interchange format which has the same data, but isn't being tuned to work with Verdi.

In reply to @rameloni:gitter.im
Schuyler Eldridge: ah alright, I'm also working on a waveform viewer for chisel open source, and I was thinking to use hgldd to map verilog to Firrtl IR. The alternative I thought was to parse directly the debug dialect from mlir but I do think it's gonna be more complex

In reply to @seldridge:matrix.org
It's probably fine to continue what you're doing and then take the feedback later. What I'm proposing is a "translation" (what MLIR calls something goes from X -> MLIR or MLIR -> X, with the HGLDD exporter being one of the latter) that is able to read the debug info and generate an alternative format.

In reply to @rameloni:gitter.im
So far I've based the parsing on what I understood from the values I got from some examples