How to export submodule ports in HW Module using arcilator --state-file (original) (raw)

December 21, 2023, 9:28am 1

I’m currently working with a hardware module described in MLIR and I’ve encountered an issue with Arcilator where I am unable to trace the inner ports of submodules.

I have a simple hardware module as shown below:

module {
  hw.module private @AddOne(in %in : i8, out out : i8) {
    %c1_i8 = hw.constant 1 : i8
    %0 = comb.add %in, %c1_i8 {sv.namehint = "_out_T"} : i8
    hw.output %0 : i8
  }
  hw.module @AddTwo(in %clock : !seq.clock, in %reset : i1, in %in : i8, out out : i8) {
    %i0.out = hw.instance "i0" @AddOne(in: %in: i8) -> (out: i8)
    %i1.out = hw.instance "i1" @AddOne(in: %i0.out: i8) -> (out: i8)
    hw.output %i1.out : i8
  }
}

When I generate the state.json using Arcilator, it only includes the ports of the outer module @AddTwo , but not the inner submodule @AddOne . Here is an excerpt from the state.json :

[
  {
    "name": "AddTwo",
    "numStateBytes": 4,
    "states": [
      {
        "name": "clock",
        "offset": 0,
        "numBits": 1,
        "type": "input"
      },
      {
        "name": "reset",
        "offset": 1,
        "numBits": 1,
        "type": "input"
      },
      {
        "name": "in",
        "offset": 2,
        "numBits": 8,
        "type": "input"
      },
      {
        "name": "out",
        "offset": 3,
        "numBits": 8,
        "type": "output"
      }
    ]
  }
]

I am looking to observe the inner ports of the submodules, similar to how Verilator’s trace levels work. However, the information I found in the arc-tests/rocket-small is quite complex, and I am having difficulty understanding how to implement this for tracing submodule ports.

Could anyone provide guidance or insights on how to export the submodule ports in state.json using Arcilator? Thank you in advance for your assistance.

Hey @Stevengre, I think the --observe-ports option might do what you are looking for. Adding that option will introduce marker ops in the IR that keep track of the module ports throughout the arcilator pipeline. Those will also be written to the VCD file if you enable tracing, and they are also accessible through and exposed in the state JSON file.

Let me know if that works or not! Also check arcilator -h | grep observe for other options you can pass to improve visibility.

Stevengre December 23, 2023, 2:47pm 3

Thank you so much for your guidance! Your solution effectively resolved the issue I was facing!

Great! Glad to hear it worked

Stevengre December 30, 2023, 5:38am 5

Hey @fabianschuiki ,

I’ve got a bit of a challenge here. I need to figure out how to get the module name of an instance, like finding out ‘AddOne’ is the name for the ‘i0’ instance. Any idea on how to pull this off with Arcilator?

Thanks a bunch!

Hey @Stevengre

Arcilator doesn’t track that information out of the box yet, but it’s definitely something we’d want to add. At the moment, the InlineModules pass in arcilator inlines all modules such that you get a nicely schedulable graph of computation. It also annotates instance paths onto state and tap ops, but no module names. That pass was written quite a while ago. In the meantime, CIRCT has gained the debug dialect with its dbg.scope op, which is intended to model instances and modules. One way to better track the information you are looking for would be to create these dbg.scope ops when modules are inlined, which would then give you the full instance and module names. That isn’t implemented yet. Would this be something you’re interested in adding yourself?

Thank you for your comprehensive response. It’s clear now that Arcilator doesn’t currently support the direct retrieval of module names for instances as I require. While this feature would be useful, its absence isn’t critical for our immediate tasks. We’ll prioritize other important work for now but will keep an eye on future updates that might include this functionality. Thanks again for your help!

Sounds great! Let me know if you have any more details regarding your usecase. For example, are you looking for more detailed waveform dumps that include more information about the design hierarchy (including module names and the like), or do you have other requirements that would be good to have arcilator support?

Thanks for the follow-up. To clarify, the current Arcilator version meets our primary requirements. However, I do believe integrating design hierarchy and module names into waveform dumps could enhance traceability.