firrtl | Flexible Intermediate Representation for RTL | Parser library

You are currently using the old way to generate Verilog with the execute function. Replace your object in the test.scala by:

The documentation linked in the other answer mentions this but I want to highlight a piece:

The only caveat is if you are passing something of type Data as a “generator” parameter, in which case you should make it a private val.

This is due to the fact that if you make a class parameter a val, it becomes a public field of the class. The hardware fields of a Bundle are defined to be "the public fields of the class of type Data". Thus, val OperandType is a field of the class, it would be the same as writing:

You cannot do this in Chisel. Chisel only supports a small, synthesizable subset of Verilog targeting synchronous, digital design. An important part of the ethos of Chisel is that simulation matches synthesis (you're simulating what you're taping out). While I totally see the use case in clearer waveforms, delays do so much more than that and aren't really appropriate for what Chisel is trying to accomplish.

It would be nice if waveform viewers themselves provided visual cues to help make this more clear rather than forcing the user to resort to delay tricks.

Good Question. I think you are you have pretty much everything right. I don't usually find that I need the command line to alter my tests, my development cycle usually is just poking values in the test params directly running. I use intelliJ which seems to make that easy (but may only work for my habits and the scale of projects I work on).

But I would like to offer you a suggestions that will get you away from ExecutionOptions style as that is going away fast.

In my example code below I offer basically two files here in line, in the first there a few library like tools that use the modern annotation idioms and, I believe, minimize boiler plate. They rely on stringy matching but that is fixable. In the second, is your GCD, GCDSpec, slightly modified to pull out the params a bit differently. At the bottom of the second is some very minimal boiler plate that allows you to get the command line access you want.

Good luck, I hope this is mostly self explanatory.

First file:

This check is supposed to disallow impossible situations when referring to a specific BlackBox. Namely, the following must be true:

• If the BlackBox has no parameters, then all ports must have the same name, same width, and be in the same order
• If the BlackBox has parameters, then all ports must have the same name and be in the same order (but may have different widths)

It sounds like either your example is producing BlackBoxes that violate the latter condition (since your BlackBoxes have parameters) or this has exposed a bug in that FIRRTL compiler check.

The actual Verilog module is never checked and can't cause any problems here.

Could you update your question to provide the FIRRTL IR that is producing these errors? Specifically, what does the FIRRTL IR for XilinxSimpleDualPortNoChangeBRAM and XilinxSimpleDualPortNoChangeBRAM_1 look like? This should be in a file like "Foo.fir". Alternatively, you can do something like:

I'd like to provide a more complete example, but I wanted to make sure to at least write something up. This also needs to be fleshed out as a proper example/tutorial on the website.

FIRRTL has robust support for tracking names of signals across built-in and custom transformations. This is a case where the infrastructure is all there, but it's very much a power user API. In short, you can create FIRRTL Annotations that will track Targets. You can then emit custom metadata files or use the normal FIRRTL annotation file (try the CLI option -foaf / --output-annotation-file).

An example FIRRTL Annotation that has will emit a custom metadata file at the end of compilation:

I think the problem is that the firrtl compiler cannot be sure that every element of test0 has been initialized to something. I have filled out your examples, with values supplied and a couple of stylistic changes to this.

Many thanks to the Chisel team. It seems the answer is to do the conversion like this.

Just to have an answer, I ended up using a combination of what myself and Jack Koenig went back and forth on.

If time permits I'll see if there is a way to make a "template" or LazyModule wrapper that does this for testing purposes (for each of the main protocols) and submit it to the Chisel repo.