In reply to @jackkoenig-57e1805540f3a6eec0665030:gitter.im
From the code you've shared, I agree that is a surprising result. Can you share a little bit more context, perhaps a reproducible example built from the Chisel Scala CLI example? https://www.chisel-lang.org/docs/installation#quickstart-with-scala-cli

This is the source file: https://github.com/chipsalliance/chisel/blob/main/docs/src/installation.md

Every page on the website has a link at the bottom to Edit this page which should work (if it doesn't, let me know 😅)

Thanks! I have started to work on a better version which will integrate into Chisel elaboration and it will be part of the final tool.
This demo I realized served as an example to prove that I can map "Chisel, Firrtl, and Verilog level" sources/signals together to their respective names in the vcd/fst and thus access their values from a waveform viewer able to support a multi-level typed view. In the demo, I managed to do so by:

• parsing Chisel IR, Firrtl IR, and the HGLDD (debug info emitted by firtool to link verilog and firrtl)
• joining signals together by identifying IDs (shared between IRs) based on signal names and source locators
• emitting the symbol table suited for the waveform viewer

However, this approach has some issues related to the IRs parsing and mapping:

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).
3. It relies on HGLDD which can also change in the future since it is not stable and realised for synopsys.

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 the issues of the demo 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".

I explain it with more details here: https://github.com/rameloni/tywaves-chisel-demo?tab=readme-ov-file#drawbacks

Hello! I am currently working on a waveform viewer for chisel. I now have a demo which serves to prove the feasibility of the project as well as to show some features.
I am writing this post since I would like to share it with the community.

Here the link to the repository: tywaves-chisel-demo.

Since it is a demo, it doesn't work with all the examples and it will have an unexpected behaviour. But, if anyone wants to try it and see how it looks like, feel free to clone and install it! Also any feedback will be highly appreciated!

I started working with the final version which will solve all the issues and improve the graphical visualization.

Thanks a lot!

Hey all, I'm running into a situation in which I need to create custom files where I want specific control over the file name.

I've seen the use of ElaborateArtefacts.add(...) , but the filename contains the entire config path.
In the Main() function I can see that the contents are dumped to the build directory as shown in
https://github.com/chipsalliance/rocket-chip/blob/b3476b17df69401b4f8a5bcc400f0ab3259aa631/src/main/scala/diplomacy/Main.scala#L51

Does it seem reasonable to implement a similar approach to just dumping custom files into the build directories and iterating over the files similar to how the ElaborateArtefacts.files are itereated over, or is there a custom file emission API I might have missed?

Hey all, I'm running into a situation in which I need to create custom files where I want specific control over the file name.

I've seen the use of ElaborateArtefacts.add(...) , but the filename contains the entire config path.
In the Main() function I can see that the contents are dumped to the build directory as shown in
https://github.com/chipsalliance/rocket-chip/blob/b3476b17df69401b4f8a5bcc400f0ab3259aa631/src/main/scala/diplomacy/Main.scala#L51

Does it seem reasonable to implement a similar approach to just dumping custom files into the build directories and iterating over the files similar to how the ElaborateArtefacts.files are iterated over, or is there a custom file emission API I might have missed?

I'm facing an issue with non-masked SRAMs where element type is a Vec. The write mask bit is only assigned to 1 for the first element of the vec. The generated CHIRTL and FIRTTL seem to me ok, so it appears to be a CIRCT bug, but I also can't be sure the scope of the issue is not larger.
The Chisel code is as follows:

I'm facing an issue with non-masked SRAMs where element type is a Vec. The write mask bit is only assigned to 1 for the first element of the vec. The generated CHIRTL and FIRTTL seem to me ok, so it appears to be a CIRCT bug, but I also can't be sure the scope of the issue is not larger.
The Chisel code is as follows:

val mem = SRAM(32, Vec(8, UInt(10.W), 1, 1, 0)

Generated FIRRTL:

     wire mem : { readPorts : { flip address : UInt<5>, flip enable : UInt<1>, data : UInt<10>[8]}[1], writePorts : { flip address : UInt<5>, flip enable : UInt<1>, flip data : UInt<12>[8]}[1], readwritePorts : { flip address : UInt<5>, flip enable : UInt<1>, flip isWrite : UInt<1>, readData : UInt<10>[8], flip writeData : UInt<12>[8]}[0]}
    mem mem_sram :
      data-type => UInt<10>[8]
      depth => 32
      read-latency => 1
      write-latency => 1
      reader => R0
      writer => W0
      read-under-write => undefined
...
wire _mem_WIRE : UInt<1>[8]
connect _mem_WIRE[0], UInt<1>(0h1)
connect _mem_WIRE[1], UInt<1>(0h1)
connect _mem_WIRE[2], UInt<1>(0h1)
...)
connect _mem_WIRE[7], UInt<1>(0h1)
connect mem_sram.W0.mask[0], _mem_WIRE[0]
connect mem_sram.W0.mask[1], _mem_WIRE[1]
connect mem_sram.W0.mask[2], _mem_WIRE[2]
..
connect mem_sram.W0.mask[7], _mem_WIRE[7]

I'm facing an issue with non-masked SRAMs where element type is a Vec. The write mask bit is only assigned to 1 for the first element of the vec. The generated CHIRTL and FIRTTL seem to me ok, so it appears to be a CIRCT bug, but I also can't be sure the scope of the issue is not larger.
The Chisel code is as follows:

val mem = SRAM(32, Vec(8, UInt(10.W), 1, 1, 0)

Generated FIRRTL:

     wire mem : { readPorts : { flip address : UInt<5>, flip enable : UInt<1>, data : UInt<10>[8]}[1], writePorts : { flip address : UInt<5>, flip enable : UInt<1>, flip data : UInt<10>[8]}[1], readwritePorts : { flip address : UInt<5>, flip enable : UInt<1>, flip isWrite : UInt<1>, readData : UInt<10>[8], flip writeData : UInt<10>[8]}[0]}
    mem mem_sram :
      data-type => UInt<10>[8]
      depth => 32
      read-latency => 1
      write-latency => 1
      reader => R0
      writer => W0
      read-under-write => undefined
...
wire _mem_WIRE : UInt<1>[8]
connect _mem_WIRE[0], UInt<1>(0h1)
connect _mem_WIRE[1], UInt<1>(0h1)
connect _mem_WIRE[2], UInt<1>(0h1)
...)
connect _mem_WIRE[7], UInt<1>(0h1)
connect mem_sram.W0.mask[0], _mem_WIRE[0]
connect mem_sram.W0.mask[1], _mem_WIRE[1]
connect mem_sram.W0.mask[2], _mem_WIRE[2]
..
connect mem_sram.W0.mask[7], _mem_WIRE[7]

which seems to be correct.
But the generated SystemVerilog is:

  mem_sram_32x80 mem_sram_ext (
      .R0_addr(address),
      .R0_en(1'h1),
      .R0_clk(clock),
      .R0_data(_mem_sram_ext_R0_data),
      .W0_addr(ldCnt),
      .W0_en(_GEN_1),
      .W0_clk(clock),
      .W0_data({
        io_in_bits_data_7,
...
        io_in_bits_data_1,
        io_in_bits_data_0
      }),
      .W0_mask(8'h1)              // <-------- this should be 8'hFF istead of 8'h1
  );

I'm facing an issue with non-masked SRAMs where element type is a Vec. The write mask bit is only assigned to 1 for the first element of the vec. The generated CHIRTL and FIRTTL seem to me ok, so it appears to be a CIRCT bug, but I also can't be sure the scope of the issue is not larger.
The Chisel code is as follows:

val mem = SRAM(32, Vec(8, UInt(10.W), 1, 1, 0)

Generated FIRRTL:

     wire mem : { readPorts : { flip address : UInt<5>, flip enable : UInt<1>, data : UInt<10>[8]}[1], writePorts : { flip address : UInt<5>, flip enable : UInt<1>, flip data : UInt<10>[8]}[1], readwritePorts : { flip address : UInt<5>, flip enable : UInt<1>, flip isWrite : UInt<1>, readData : UInt<10>[8], flip writeData : UInt<10>[8]}[0]}
    mem mem_sram :
      data-type => UInt<10>[8]
      depth => 32
      read-latency => 1
      write-latency => 1
      reader => R0
      writer => W0
      read-under-write => undefined
...
wire _mem_WIRE : UInt<1>[8]
connect _mem_WIRE[0], UInt<1>(0h1)
connect _mem_WIRE[1], UInt<1>(0h1)
connect _mem_WIRE[2], UInt<1>(0h1)
...
connect _mem_WIRE[7], UInt<1>(0h1)
connect mem_sram.W0.mask[0], _mem_WIRE[0]
connect mem_sram.W0.mask[1], _mem_WIRE[1]
connect mem_sram.W0.mask[2], _mem_WIRE[2]
..
connect mem_sram.W0.mask[7], _mem_WIRE[7]

which seems to be correct.
But the generated SystemVerilog is:

  mem_sram_32x80 mem_sram_ext (
      .R0_addr(address),
      .R0_en(1'h1),
      .R0_clk(clock),
      .R0_data(_mem_sram_ext_R0_data),
      .W0_addr(ldCnt),
      .W0_en(_GEN_1),
      .W0_clk(clock),
      .W0_data({
        io_in_bits_data_7,
...
        io_in_bits_data_1,
        io_in_bits_data_0
      }),
      .W0_mask(8'h1)              // <-------- this should be 8'hFF istead of 8'h1
  );

I'm facing an issue with non-masked SRAMs where element type is a Vec. The write mask bit is only assigned to 1 for the first element of the vec. The generated CHIRTL and FIRTTL seem to me ok, so it appears to be a CIRCT bug, but I also can't be sure the scope of the issue is limited to SRAM.
The Chisel code is as follows:

val mem = SRAM(32, Vec(8, UInt(10.W), 1, 1, 0)

Generated FIRRTL:

     wire mem : { readPorts : { flip address : UInt<5>, flip enable : UInt<1>, data : UInt<10>[8]}[1], writePorts : { flip address : UInt<5>, flip enable : UInt<1>, flip data : UInt<10>[8]}[1], readwritePorts : { flip address : UInt<5>, flip enable : UInt<1>, flip isWrite : UInt<1>, readData : UInt<10>[8], flip writeData : UInt<10>[8]}[0]}
    mem mem_sram :
      data-type => UInt<10>[8]
      depth => 32
      read-latency => 1
      write-latency => 1
      reader => R0
      writer => W0
      read-under-write => undefined
...
wire _mem_WIRE : UInt<1>[8]
connect _mem_WIRE[0], UInt<1>(0h1)
connect _mem_WIRE[1], UInt<1>(0h1)
connect _mem_WIRE[2], UInt<1>(0h1)
...
connect _mem_WIRE[7], UInt<1>(0h1)
connect mem_sram.W0.mask[0], _mem_WIRE[0]
connect mem_sram.W0.mask[1], _mem_WIRE[1]
connect mem_sram.W0.mask[2], _mem_WIRE[2]
..
connect mem_sram.W0.mask[7], _mem_WIRE[7]

which seems to be correct.
But the generated SystemVerilog is:

  mem_sram_32x80 mem_sram_ext (
      .R0_addr(address),
      .R0_en(1'h1),
      .R0_clk(clock),
      .R0_data(_mem_sram_ext_R0_data),
      .W0_addr(ldCnt),
      .W0_en(_GEN_1),
      .W0_clk(clock),
      .W0_data({
        io_in_bits_data_7,
...
        io_in_bits_data_1,
        io_in_bits_data_0
      }),
      .W0_mask(8'h1)              // <-------- this should be 8'hFF istead of 8'h1
  );

I'm facing an issue with non-masked SRAMs where element type is a Vec. The write mask bit is only assigned to 1 for the first element of the vec. The generated CHIRTL and FIRTTL seem to me ok, so it appears to be a CIRCT bug, but I also can't be sure the scope of the issue is limited to SRAM.
The Chisel code is as follows:

val mem = SRAM(32, Vec(8, UInt(10.W), 1, 1, 0)

Generated FIRRTL:

     wire mem : { readPorts : { flip address : UInt<5>, flip enable : UInt<1>, data : UInt<10>[8]}[1], writePorts : { flip address : UInt<5>, flip enable : UInt<1>, flip data : UInt<10>[8]}[1], readwritePorts : { flip address : UInt<5>, flip enable : UInt<1>, flip isWrite : UInt<1>, readData : UInt<10>[8], flip writeData : UInt<10>[8]}[0]}
    mem mem_sram :
      data-type => UInt<10>[8]
      depth => 32
      read-latency => 1
      write-latency => 1
      reader => R0
      writer => W0
      read-under-write => undefined
...
wire _mem_WIRE : UInt<1>[8]
connect _mem_WIRE[0], UInt<1>(0h1)
connect _mem_WIRE[1], UInt<1>(0h1)
connect _mem_WIRE[2], UInt<1>(0h1)
...
connect _mem_WIRE[7], UInt<1>(0h1)
connect mem_sram.W0.mask[0], _mem_WIRE[0]
connect mem_sram.W0.mask[1], _mem_WIRE[1]
connect mem_sram.W0.mask[2], _mem_WIRE[2]
..
connect mem_sram.W0.mask[7], _mem_WIRE[7]

which seems to be correct.
But the generated SystemVerilog is:

  mem_sram_32x80 mem_sram_ext (
      .R0_addr(address),
      .R0_en(1'h1),
      .R0_clk(clock),
      .R0_data(_mem_sram_ext_R0_data),
      .W0_addr(ldCnt),
      .W0_en(_GEN_1),
      .W0_clk(clock),
      .W0_data({
        io_in_bits_data_7,
...
        io_in_bits_data_1,
        io_in_bits_data_0
      }),
      .W0_mask(8'h1)              // <-------- this should be 8'hFF istead of 8'h1
  );

I'm facing an issue with non-masked SRAMs where element type is a Vec. The write mask bit is only assigned to 1 for the first element of the vec. The generated CHIRTL and FIRTTL seem to me ok, so it appears to be a CIRCT bug, but I also can't be sure the scope of the issue is limited to SRAM.
The Chisel code is as follows:

val mem = SRAM(32, Vec(8, UInt(10.W), 1, 1, 0)

Generated FIRRTL:

     wire mem : { readPorts : { flip address : UInt<5>, flip enable : UInt<1>, data : UInt<10>[8]}[1], writePorts : { flip address : UInt<5>, flip enable : UInt<1>, flip data : UInt<10>[8]}[1], readwritePorts : { flip address : UInt<5>, flip enable : UInt<1>, flip isWrite : UInt<1>, readData : UInt<10>[8], flip writeData : UInt<10>[8]}[0]}
    mem mem_sram :
      data-type => UInt<10>[8]
      depth => 32
      read-latency => 1
      write-latency => 1
      reader => R0
      writer => W0
      read-under-write => undefined
...
wire _mem_WIRE : UInt<1>[8]
connect _mem_WIRE[0], UInt<1>(0h1)
connect _mem_WIRE[1], UInt<1>(0h1)
connect _mem_WIRE[2], UInt<1>(0h1)
...
connect _mem_WIRE[7], UInt<1>(0h1)
connect mem_sram.W0.mask[0], _mem_WIRE[0]
connect mem_sram.W0.mask[1], _mem_WIRE[1]
connect mem_sram.W0.mask[2], _mem_WIRE[2]
..
connect mem_sram.W0.mask[7], _mem_WIRE[7]

which seems to be correct.
But the generated SystemVerilog is:

  mem_sram_32x80 mem_sram_ext (
      .R0_addr(address),
      .R0_en(1'h1),
      .R0_clk(clock),
      .R0_data(_mem_sram_ext_R0_data),
      .W0_addr(ldCnt),
      .W0_en(_GEN_1),
      .W0_clk(clock),
      .W0_data({
        io_in_bits_data_7,
...
        io_in_bits_data_1,
        io_in_bits_data_0
      }),
      .W0_mask(8'h1)              // <-------- this should be 8'hFF istead of 8'h1
  );

I checked and the issue also exist with the main branches of chisel and circt.

In reply to @kammoh-556059fd15522ed4b3e0d6c3:gitter.im

I'm facing an issue with non-masked SRAMs where element type is a Vec. The write mask bit is only assigned to 1 for the first element of the vec. The generated CHIRTL and FIRTTL seem to me ok, so it appears to be a CIRCT bug, but I also can't be sure the scope of the issue is limited to SRAM.
The Chisel code is as follows:

val mem = SRAM(32, Vec(8, UInt(10.W), 1, 1, 0)

Generated FIRRTL:

     wire mem : { readPorts : { flip address : UInt<5>, flip enable : UInt<1>, data : UInt<10>[8]}[1], writePorts : { flip address : UInt<5>, flip enable : UInt<1>, flip data : UInt<10>[8]}[1], readwritePorts : { flip address : UInt<5>, flip enable : UInt<1>, flip isWrite : UInt<1>, readData : UInt<10>[8], flip writeData : UInt<10>[8]}[0]}
    mem mem_sram :
      data-type => UInt<10>[8]
      depth => 32
      read-latency => 1
      write-latency => 1
      reader => R0
      writer => W0
      read-under-write => undefined
...
wire _mem_WIRE : UInt<1>[8]
connect _mem_WIRE[0], UInt<1>(0h1)
connect _mem_WIRE[1], UInt<1>(0h1)
connect _mem_WIRE[2], UInt<1>(0h1)
...
connect _mem_WIRE[7], UInt<1>(0h1)
connect mem_sram.W0.mask[0], _mem_WIRE[0]
connect mem_sram.W0.mask[1], _mem_WIRE[1]
connect mem_sram.W0.mask[2], _mem_WIRE[2]
..
connect mem_sram.W0.mask[7], _mem_WIRE[7]

which seems to be correct.
But the generated SystemVerilog is:

  mem_sram_32x80 mem_sram_ext (
      .R0_addr(address),
      .R0_en(1'h1),
      .R0_clk(clock),
      .R0_data(_mem_sram_ext_R0_data),
      .W0_addr(ldCnt),
      .W0_en(_GEN_1),
      .W0_clk(clock),
      .W0_data({
        io_in_bits_data_7,
...
        io_in_bits_data_1,
        io_in_bits_data_0
      }),
      .W0_mask(8'h1)              // <-------- this should be 8'hFF istead of 8'h1
  );

I checked and the issue also exist with the main branches of chisel and circt.

Hi everyone, I am trying to migrate to Chisel 5.x/6.x and have already set up a playground for it. However I also have some old dependency hardware designs using Chisel 3.6.0. Is there a way to import those dependencies and make them compatible with the new project of Chisel 5.x/6.x, without upgrading Chisel for these dependencies?
More precisely, I tried old-style Chiseltest-6.0.0 on a Chisel 6.2.0 project, which also has a dependency module using Chisel 3.6. Then I got this:

An exception or error caused a run to abort: Receiver class hwtest.HelloTest does not define or inherit an implementation of the resolved method abstract topFileName_$eq(Lscala/Option;)V of interface chiseltest.ChiselScalatestTester.

Is there a way to import those dependencies and make them compatible with the new project of Chisel 5.x/6.x, without upgrading Chisel for these dependencies?

Unfortunately there is not. You must use the same Chisel major version for all Chisel code/dependencies (because binary compatibility breaks between major versions).