Improve code generation(less verbose) for connecting bundles between modules

[oharboe]

Feature Description

I'd like bundles between modules to be connected using more terse Verilog when there's no modification of the bundles.

Type of Feature

• code cleanup

Related Features

This strongly related to #99

I'll develop an example and attach it to this issue.

[oharboe]

If I have a regular structure realized in Chisel, where there's a bundle of signals going between a lot of modules:

class ConfigurationBundle extends Bundle
{
   val xxx = Bool()
   val yyy = UInt...
}

class ThingAMaBobBundle extends Bundle
{
   val foo = Input(Vec(5, new ConfigurationBundle))
   val bar = Output(Vec(5, new ConfigurationBundle))
}

val a = Module(new ThingAMaBob)
val b = Module(new ThingAMaBob)

// Lots of Verilog for the code below
a.io <> b.io

This will result in lots of Verilog code as all elements in all vectors(if they are nested) will be exanded to named signals.

Whereas really if the the inputs and outputs had been represented as wide integers, then very little Verilog would have been generated.

From a human point of view, there's a single connection between a and b here, the details of those signals are only important inside the ThingAMaBob

[oharboe]

I ran som experiments and to quantize the effect of a feature like this, it would reduce the size of the Verilog generated for a particular module from 24000 lines to 8000 lines. Somewhat guestimated.

For debugging/simulation, it might, sometimes, be useful to have the expanded current symbolic format.

If there was a way to avoid "unrolling" Vec()'s and represent Vec()'s as some sort of array/record in Verilog, that would probably break the break of this "code size explosion problem".

[oharboe]

I read up a bit on Verilog, and I guess what's critically missing from Verilog to reduce the verboseness here is the 'typedef struct' construct that exists only in Verilog.

Like:

https://en.wikipedia.org/wiki/SystemVerilog

 typedef struct packed {
    bit [10:0]  expo;
    bit         sign;
    bit [51:0]  mant;
} FP;

FP     zero = 64'b0;

[oharboe]

The question then becomes, and this is a big question, should Chisel output a subset of SystemVerilog that's supported by open source tools to make the generated code more legible to humans?

I know Intel Altera Quartus supports SystemVerilog, so I can't imagine that Xilinx and other FPGA vendors don't.

Critically Verilator says it supporst SystemVerilog(probably a subset including typedef structs...), Yosys says it supports "a small subset of SystemVerilog).

The generated code from Chisel matters to adption and use of Chisel.

Here's an interesting Youtube video about the Edge TPU by Google and their experience with Chisel. The video is a bit dated, but there are still applicable lessons to be learned:

https://www.youtube.com/watch?v=x85342Cny8c

[seldridge]

Good thoughts @oharboe. Thanks for taking the time to write this up.

I'm in agreement that we should emit either SystemVerilog structs or interfaces. Currently the Verilog emitter is limited to Verilog 2001. However, we do have a SystemVerilog emitter (which is an unmodified child of the Verilog emitter). I think it would be reasonable to build out the SV emitter to included structs and/or interfaces in addition to logic types and the always_* SV variants.

With this approach you can then get strict Verilog 2001 if you need it or "better" SV if your tools support it.

[oharboe]

@seldridge Sounds good! I would encourage Chisel to try to stay within a subset of SystemVerilog that's usable by open source tools: Verilator and Yosys. Otherwise, it's going to be tough to engage the larger community in this support as not everybody has access to $1m/year tools.

[johnsbrew]

Hi @oharboe I find it quite interesting too, my main question is the difference when it comes to synthesis ? In terms of runtime, resources usage and congestion ? As far as I understand current tools : the simpler verilog, the better result (and faster synthesis) despite much larger verilog files. However I have no actual figures to demonstrate this statement so I would be quite interested in actual comparisons for big projects.

Depending how far you want to expend the modification of the emitter, one concern is for example : a register of a SV packed struct is treated as single big register which might cause congestion issues in some case where the tool attempt to have all bits of the signal placed closely although it might not be necessary. (talking from FPGA synthesis, place&route point of view)

[oharboe]

@johnsbrew Excellent point. I guess this argues for outputting both so it is possible to compare quality of results. I have found that Quartus seems to "get" my design and that it doesnt matter much how I articulate it. Really what matters is the amount of logic and wiring per cycle. I have no data to back this up.