Netlist

[desmonddak]

Description & Motivation

This is a netlist synthesizer that produces a netlist for the generated design in an extension of the Yosys output netlist format.
It provides routines for emitting just the hierarchy and ports ("slim" mode) as well as fully expanded and has hooks for even more incremental expansion modes.

Related Issue(s)

None.

Testing

There is a suite of tests that compare the netlist and its names against the SystemVerilog output. This netlist depended on the last central_naming branch to assure that signals in both formats had identical names.

Backwards-compatibility

Is this a breaking change that will not be backwards-compatible? If yes, how so?

No.

Documentation

Does the change require any updates to documentation? If so, where? Are they included?

This is a minor API addition (Module.generateNetlist()) but we will add more documentation and examples of the format, etc.
It will have some options as well, such as multiFile, which should parallel the generateSynth() API.

[mkorbel1]

I don't understand what these changes in Namer are for. Is this mimicking the work that Uniquifier could already do? Why are there these special constant names?

[desmonddak]

The dilemma I have is that the netlister needs to create new elements to make things more easily visualized. Things that disappear when you think about them from an SV perspective. The problem is that means some leaking from netlister down into Namer to ask it for these names. No other synthesizer will see these, I don't believe unless these become constructions in the synth layer (that SV ignores or elides):

  /// Canonical base name for synthesis-created array slice operations.
  ///
  /// Netlist synthesis uses these when a [LogicArray] port or submodule output
  /// must be decomposed into element wires, such as a child reading
  /// `values.elements[0]` from an aggregate array input port.
  static const String synthArraySliceOperationName = 'array_slice';

  /// Canonical base name for synthesis-created array concat operations.
  ///
  /// Netlist synthesis uses these when independently driven [LogicArray]
  /// elements must be reassembled for an aggregate consumer, such as
  /// `values.elements[0] <= a` and `values.elements[1] <= b` feeding a child
  /// array input port.
  static const String synthArrayConcatOperationName = 'array_concat';

  /// Canonical base name for synthesis-created structure slice operations.
  ///
  /// Netlist synthesis uses these internally when a [LogicStructure] aggregate
  /// must expose field wires. The emitted netlist projection can replace them
  /// with `$struct_unpack` cells so field names are preserved.
  static const String synthStructureSliceOperationName = 'struct_slice';

  /// Canonical base name for synthesis-created structure concat operations.
  ///
  /// Netlist synthesis uses these when independently driven [LogicStructure]
  /// fields must be packed back into an aggregate struct output or submodule
  /// input. The emitted netlist projection represents this as `$struct_pack`.
  static const String synthStructureConcatOperationName = 'struct_concat';

[desmonddak]

I could move these back up into netlist as they currently are synthesized there.

[mkorbel1]

Yeah, I think it would be cleaner to just let those names be selected (late if necessary) along with all the other things needing selection, and be uniquified as needed. I had to do something similar with net_connect

[desmonddak]

I moved these down into the synth utilities for now.

[mkorbel1]

i still dont understand why these are relevant constants to define in a central place. what is this SynthOperationNamer for?

[desmonddak]

Netlist optimizations can create NEW slices and concats. These need to be named. There are four flavors: array and struct times slice and concat.

[desmonddak]

These are simply the base names of these special new slices and concats (which are then numbered for uniqueness).

[desmonddak]

Another possibliity is that when we join concat operations, say, we name them by concatenating the names. But most of the time it would be concat_1 merging with concat_2, so concat_1_2 would not really be that meaningful. So these become array_concat (and the next one is array_concat_0.

[mkorbel1]

question: is this already all merged with main and benefits from the common collapsing in the synth stack?

[desmonddak]

I believe netlist passes contains operations that are supersets of the common collapsing that was just added to the synth stack.

• Adjacent $slice outputs feeding a $concat can collapse into one wider $slice; example module: [netlist_test.dart:79]
• Transparent $slice/$buf alias chains can collapse by tracing bits back to the external source; example module: [netlist_test.dart:93
• The netlist pass file also has cleanup passes for trivial concat aliases and unconsumed transparent cells in [netlist_passes.dart:322

Similarly, there is code for structure field extraction and concatenation that also need collapse.

I've factored out the common collapsing code to leverage what is in main, a first layer of optimization.

I think what we can do is generate examples that trigger these passes and see if we want to push these optimizations down into the synth layer. I have a feeling they would subsume the current collapsing code since they are more general.