Verilog - spice bus signal interface

[d-m-bailey]

How did you handle the verilog - spice bus signal interface? Non-bus signal correspondence can be determined by name, but bus signal order can be tricky. Spice often has the buses in alphabetical order, but verilog generally has them in reverse numerical order.

[growly]

Good question! This hasn't been solved, but hasn't yet been practically necessary to solve either.

I've used this tool extensively to turn a digital design (post PAR) from Verilog + SPEF into Spice, augmented by the Spice descriptions of the standard cells for the library in which it was implemented (e.g. sky130 hd).

The Verilog description of the module contains bus information so this is trivially mapped to a unique Spice node:

a[0] -> a.0
a[1] -> a.1
a[2] -> a.2

etc. The reverse mapping is tricky. As long as there is a Verilog description of the subckt as well as the Spice description, it should be possible to map the elaborated names of bus wires. If the input dialect makes this hard to guess, then we have an error.

I don't know of any Spice dialects that explicitly annotate buses. If they do we can augment the parser to understand them. For those that don't you simply lose information about which wires form a bus and what their position in that bus is, so inferring buses can be heuristic at best. Perhaps if you know something else about the circuit you can provide it as a hint, but otherwise I think we should avoid trying to come up with a canonical heuristic to guess the reverse association.

[d-m-bailey]

I ran into a problems during device level LVS with verilog and spice on the sky130 Google/efabless chips with the SRAM modules.
The spice instance was accessed from verilog using buses for addr0, addr1, din0, dout0, dout1, and wmask0.

 sky130_sram_2kbyte_1rw1r_32x512_8 sky130_sram_2kbyte_1rw1r_32x512_8 (.csb0(net2827),
    .csb1(net2828),
    .web0(sram_wren_b),
    .clk0(clknet_leaf_22_core_clk),
    .clk1(net2826),
    .vccd1(VPWR),
    .vssd1(VGND),
    .addr0({net1843,
    net1270,
    net1161,
    net949,
    net880,
    net1506,
    net1634,
    net1028,
    net1362}),
    .addr1({net2825,
    net2824,
    net2823,
    net2822,
    net2821,
    net2820,
    net2819,
    net2818,
    net2817}),
    .din0({net668,
    net667,
    net665,
    net664,
    net663,
    net662,
    net661,
    net660,
    net659,
    net658,
    net657,
    net656,
    net654,
    net653,
    net652,
    net651,
    net650,
    net649,
    net648,
    net647,
    net1946,
    net645,
    net675,
    net674,
    net673,
    net672,
    net671,
    net670,
    net669,
    net666,
    net655,
    net1947}),
    .dout0({\sram_bus_dat_r[31] ,
    \sram_bus_dat_r[30] ,
    \sram_bus_dat_r[29] ,
    \sram_bus_dat_r[28] ,
    \sram_bus_dat_r[27] ,
    \sram_bus_dat_r[26] ,
    \sram_bus_dat_r[25] ,
    \sram_bus_dat_r[24] ,
    \sram_bus_dat_r[23] ,
    \sram_bus_dat_r[22] ,
    \sram_bus_dat_r[21] ,
    \sram_bus_dat_r[20] ,
    \sram_bus_dat_r[19] ,
    \sram_bus_dat_r[18] ,
    \sram_bus_dat_r[17] ,
    \sram_bus_dat_r[16] ,
    \sram_bus_dat_r[15] ,
    \sram_bus_dat_r[14] ,
    \sram_bus_dat_r[13] ,
    \sram_bus_dat_r[12] ,
    \sram_bus_dat_r[11] ,
    \sram_bus_dat_r[10] ,
    \sram_bus_dat_r[9] ,
    \sram_bus_dat_r[8] ,
    \sram_bus_dat_r[7] ,
    \sram_bus_dat_r[6] ,
    \sram_bus_dat_r[5] ,
    \sram_bus_dat_r[4] ,
    \sram_bus_dat_r[3] ,
    \sram_bus_dat_r[2] ,
    \sram_bus_dat_r[1] ,
    \sram_bus_dat_r[0] }),
    .dout1({net781,
    net780,
    net778,
    net777,
    net776,
    net775,
    net774,
    net773,
    net772,
    net771,
    net770,
    net769,
    net767,
    net766,
    net765,
    net764,
    net763,
    net762,
    net761,
    net760,
    net759,
    net758,
    net788,
    net787,
    net786,
    net785,
    net784,
    net783,
    net782,
    net779,
    net768,
    net757}),
    .wmask0({net1948,
    net840,
    net2023,
    net2178}));

It appears that netgen makes these connections to the spice subckt in the order that the signals appear in the interface.
For example, if the spice signals are in alphabetical order.

\sram_bus_dat_r[31] -> dout0[0]
\sram_bus_dat_r[30] -> dout0[1]
\sram_bus_dat_r[29] -> dout0[10]
\sram_bus_dat_r[28] -> dout0[11]
...

The workaround I did was to rearrange the spice subckt signals into decreasing order like the verilog signals. This is based on the assumption that the verilog buses were defined in reverse order (however reverse order is not mandatory in verilog).

Here's the verilog rtl

sky130_sram_2kbyte_1rw1r_32x512_8 sky130_sram_2kbyte_1rw1r_32x512_8(
        .addr0(sram_bus_adr[8:0]),
        .addr1(sram_adr1),
        .clk0(sys_clk),
        .clk1(sram_clk1),
        .csb0(sram_cs_b),
        .csb1(sram_cs_b1),
        .din0(sram_datain),
        .web0(sram_wren_b),
        .wmask0(sram_maskwren),
        .dout0(sram_dataout),
        .dout1(sram_dataout1)
);

The SRAM LEF has expanded buses, (i.e. addr0[0], addr0[1], etc.), so there's an assumption of bus order being made somewhere during routing.

[growly]

Since spice connections are always by order it sounds like a problem with netgen if it doesn't map verilog ports to the correct position in the Spice instantiation? I'm a bit confused though, you've only shown verilog snippets. How do you know the connections are wrong in Spice?

bigspicy loads the port declarations from both verilog and spice. The port names in the verilog are used as the canonical names for the ports. It is assumed that the spice subckt defines the same port names. The order of those port names is recorded from the spice description. Then, when a port is connected by name in verilog, it can be connected by position in Spice.

[d-m-bailey]

I discovered the problem during caravel LVS when the netlists did not match for sram modules.

I also noticed that, for openlane, there is an rtl stub for the sram module that the router uses to get the connections in the correct order.
So there is an implicit requirement in netgen when merging verilog and spice that the order of the bus signals in the spice netlist must match the verilog stub.

It sounds like bigspicy also requires the spice port buses to be ordered.

I don't believe this ordered bus indices requirement is enforced in schematic -> netlist translations or during layout extraction, so it's something to be careful about.

For non-bus signals, the verilog - spice connections are by name and order is irrelevant. Because the bus signal indices may be intentionally reversed in verilog, a name only mapping to spice for bus signals is not possible.

Here's a trivial example with 2 identical modules connected with bus signals reversed just to illustrate the problem. Neither instance is connected with buses both in order or reversed.

.SUBCKT bus_test in[0] in[1] out[0] out[1]
...
.ENDS

module top(a, b) {
  input [1:0] a;
  input [0:1] b;

bus_test bus_test_1 (
  .in(a),
  .out(b) 
}

bus_test bus_test_2 )
  .in(a[0:1]),
  .out(b[1:0])
}

verilog -> spice

bus_test_1
a[1] -> in[0]
a[0] -> in[1]
b[0] -> out[0]
b[1] -> out[1]

bus_test_2
a[0] -> in[0]
a[1] -> in[1]
b[1] -> out[0]
b[0] -> out[1]

[growly]

Hmm, so I agree that there is a thorny problem to be wary of, but I'm not sure it's the one you're illustrating.

Spice ports have to be ordered, right? In the example you've shown, something has generated a Spice subckt with bus wires in the order you've shown. When ingesting Spice models, bigspicy doessn't actually assume any order to those wires; it will read the .SUBCKT bus_test in[0] in[1] out[0] out[1] line and assign names to the port positions:

in[0] -> position 0
in[1] -> position 1
out[0] -> position 2
out[1] -> position 3

If it then ingests the verilog model, it has to map the literal string "in[0]" to the 0th index of the bus connected to the in port, that is, it has to understand that "in[0]" means "wire 0 of bus in". I think this is the thorny problem, since there is no standard way to create a string name for a bus wire in Spice itself. You could write .SUBCKT bus_test in.0 in.1 out.0 out.1 or .SUBCKT bus_test in\0 in\1 out\0 out\1 to mean the same thing. Spice doesn't care.

Once we know how to determine that "in[0]" maps to the 0th wire of the "in" bus in verilog, we can associate the port that is connected to index 0 of port in with the net that we allocate to the correct port position in the Spice instantiation.

As long as you have a canonical way to map a verilog bus index name to a Spice name, you don't need to assume port order.

(Currently, bigspicy will turn a[3:0] into a.0 a.1 a.2 a.3.)