https://open-source-silicon.dev logo
Join Slack
Powered by
<@U016EM8L91B> Thanks for the heads up. I'll do a ...
# verification-be
m
@User Thanks for the heads up. I'll do a regression test. Last night I finally got the storage macro to pass(?) LVS. netgen says that data, address, and wen buses are reversed for each sram, though. @User Even if the data, address, and wen buses were reversed for each sram, it makes no functional difference, correct? I don't know if everything I did was necessary, but here's the list. 1. Removed parasitics from extracted spice and netlist. 2. The 
control_logic_r
had no hierarchy in the layout and text from original sub-cells had been merged and shorted. Renamed the nets in the extracted spice to match the netlist. 3. Added commands to flatten all cells in the 
control_logic_r
block of the netlist. 4. 
precharge_array
contained a VSUBS connection in the extracted spice that wasn't in the netlist, so I flattened those cells in the netlist and removed the VSUBS connection from the extracted spice. 5. In 
replica_column
, I changed the bl0, bl1, br0, br1 nets in the netlist to bl0_0, bl1_0, br0_0, br1_0 to match the extracted spice. 6. In the flattened 
control_logic_r
, I replaced the flattened 
delta_chain
, with a subckt call in the extracted spice. I noticed there were no port statements in the ext files for anything in the sram subcells.
@Tim Edwards @Matthew Guthaus @Ahmed Ghazy I have an idea what the problem might be. I annotated the gds with the spice as you suggested (after renaming the cells). Still had to do 3 and 6 above, but got a relatively clean LVS run. The bus signals were matched backwards. When netgen maps a spice subckt definition to an undefined verilog module call, it probably assigns the bus indices in ascending order. It looks like the storage module is expecting descending order. From the storage module verilog:
Copy code
input [7:0] mgmt_addr;
 input [7:0] mgmt_addr_ro;
 input mgmt_clk;
 input [1:0] mgmt_ena;
 input mgmt_ena_ro;
 output [63:0] mgmt_rdata;
 output [31:0] mgmt_rdata_ro;
 input [31:0] mgmt_wdata;
 input [1:0] mgmt_wen;
 input [7:0] mgmt_wen_mask;
...
sram_1rw1r_32_256_8_sky130 SRAM_0 (
  .addr0(mgmt_addr),
  .addr1(mgmt_addr_ro),
  .clk0(mgmt_clk),
  .clk1(mgmt_clk),
  .csb0(mgmt_ena[0]),
  .csb1(mgmt_ena_ro),
  .din0(mgmt_wdata),
  .dout0(mgmt_rdata[31:0]),
  .dout1(mgmt_rdata_ro),
  .gnd(VGND),
  .vdd(VPWR),
  .web0(mgmt_wen[0]),
  .wmask0(mgmt_wen_mask[3:0])
 );
 sram_1rw1r_32_256_8_sky130 SRAM_1 (
  .addr0(mgmt_addr),
  .addr1({ _NC1, _NC2, _NC3, _NC4, _NC5, _NC6, _NC7, _NC8 }),
  .clk0(mgmt_clk),
  .csb0(mgmt_ena[1]),
  .din0(mgmt_wdata),
  .dout0(mgmt_rdata[63:32]),
  .dout1({ _NC9, _NC10, _NC11, _NC12, _NC13, _NC14, _NC15, _NC16, _NC17, _NC18, _NC19, _NC20, _NC21, _NC22, _NC23, _NC24, _NC25, _NC26, _NC27, _NC28, _NC29, _NC30, _NC31, _NC32, _NC33, _NC34, _NC35, _NC36, _NC37, _NC38, _NC39, _NC40 }),
  .gnd(VGND),
  .vdd(VPWR),
  .web0(mgmt_wen[1]),
  .wmask0(mgmt_wen_mask[7:4])
 );
In summary, the spice - verilog mapping requires the bus indices to be in ascending order (or flattened buses). I'm going to flip the buses and try again.
t
@Mitch Bailey: Should I be treating this as a bug in the netgen verilog reader?
m
@Tim Edwards I thought I could just switch the indices in the verilog, but no go. verilog requires the MSB first, it seems (although I'm no expert). So when mapping a bus to spice, it should probably go from highest to lowest. Something else that might be considered is to require flattened buses in the gate level verilog. But if you're going to allow verilog buses mapped to spice in netgen, netgen would need to map in descending order.
m
Verilog doesn't require MSB first but it can be touchy when using a mixture. I remember this issue dating back to the late 90's.
If you connect a port with MSB/LSB reversed it will indeed swap pins on the bus.
t
@Mitch Bailey: Verilog does not require MSB first. The problem with netgen must be (?) some result of reading in a subcircuit/module instance in verilog, followed by reading the subcircuit itself from SPICE. Correct me if I'm wrong about the order in which you're doing that. That was what I was doing in my caravel top level LVS script. Internally, netgen breaks all buses up into individual pins. When reading the above verilog module, it is supposed to recognize that, e.g., 
.addr0(mgmt_addr)
is mapping 
input [7:0] mgmt_addr
into 
addr0
and will assume the same order of pins, which is to say, 
addr0[7:0]
. Apparently that is not happening.
@Mitch Bailey: One question I need to ask: Where do you get the SPICE netlist for 
sram_1rw1r_32_256_8_sky130
? I realized last week that it does not exist anywhere that I know of outside of https://github.com/efabless/sky130_sram_macros . Late last week I added that repository to the list of repos that 
open_pdks
will download and install as part of the 
make
process. But I also discovered that the netlist has references to old s8 device names and uses M instead of X for transistors. I pushed that correction this morning.
m
@Matthew Guthaus Correct me if I'm wrong, but bus declarations in verilog are always MSB:LSB. However, bus references may be in either order. @Tim Edwards I'm reading the spice for subcells first, followed by the verilog. From the verilog standard:
Copy code
4.3.1 Specifying vectors 
The range specification gives addresses to the individual bits in a multibit net or reg. The most significant bit specified by the msb constant expression is the left-hand value in the range, and the least significant bit specified by the lsb constant expression is the right-hand value in the range.
So it may be possible to assume that the undefined verilog subcircuit buses should be mapped in descending order (and not necessarily the order of the bus in the instance). As for the sram netlist, a week ago @Ahmed Ghazy posted this: https://github.com/efabless/sky130_sram_macros/blob/sky130_name_mapping/sram_1rw1r_32_256_8_sky130/sram_1rw1r_32_256_8_sky130.lvs.converted.sp It's on a different branch.
m
Yes, but is the MSB called 31 or 0? It doesn't standardize that.
m
@Matthew Guthaus Looks like you're correct. I should have read further.
Copy code
The lsb value may be greater than, equal to, or less than the msb value.
@Tim Edwards @Matthew Guthaus The discrepancy in the storage macro appears to be a netgen bug. I haven't looked at the code to be sure. These are the factors that lead to that conclusion. 1. The layout connections are correct. After annotating the GDS with the spice ports, I used CVC to check the connections between the top level, sram and pk_sram. They were all as expected (the bus indices matched). 2. The top level verilog appears to be correct. Removing all the subcells from sram spice to check sram as a blackbox still gives the same bus reversed error. 3. Adding a dummy verilog black box (instead of spice) yields a clean LVS run. Can yosys output flattened busses? That might be the quickest solution.
t
@Mitch Bailey: Given that I only tried reading a SPICE library on top of a verilog netlist recently, I guess it should not be too surprising that it has bugs. I'll look into it. Meanwhile, I have been working on the GPIO I/O pad today. There are a number of issues with the schematics that I'm working through. One is that the schematics like to break up the substrate, while magic does not have any method to do so. I solved that by putting a wrapper around both netlists that short the grounds together. Now there's another issue with a weird tiny metal resistor in the corner of a pin which serves no apparent purpose other than to screw up the netlist. The device counts match, and as far as I can tell, the only problems seem to stem from power and ground busses being split up in somewhat arbitrary ways.
m
@Tim Edwards I'll log an issue with at trivial test case to github in just a bit.
t
@Mitch Bailey: A reduced-size test case would be perfect, thanks.
m
FWIW, I read the lower level cells (libraries) before the verilog.
5 Views
Open in Slack
PreviousNext
Powered by