https://open-source-silicon.dev
Join Slack
Hello, I need some help with the `OEB` check in the precheck. I double checked that all `io_oeb` sig...
# gf180mcu
l
Hello, I need some help with the 
OEB
check in the precheck. I double checked that all 
io_oeb
signals are connected. When I run it for my design, it fails with the following: 
ERROR OEB FAILED, stat=5, see /path/to/precheck_results/07_NOV_2023___07_23_42/logs/OEB_check.log
The last lines in the log file are:
Copy code
...
ERROR: No model match xpredec0_512x8m81/MX1 M pfet_03v3 ad=1.01p pd=4.6u as=0.439p ps=2.22u w=1.7u l=0.6u
ERROR: No model match xpredec0_512x8m81/MX2 M pfet_03v3 ad=0.439p pd=2.22u as=1.01p ps=4.6u w=1.7u l=0.6u
ERROR: No model match xpredec0_512x8m81/MX3 M pfet_03v3 ad=0.439p pd=2.22u as=0.448p ps=2.23u w=1.7u l=0.6u
Missing models

nfet_03v3 M
pfet_03v3 M

ERROR: Model file problem
[?1034h** Stage 1/7: Enter command ?> c 6

> c 6
continuing for 6 step(s)
ERROR: skipped due to problems in model/power/fuse files
 gpio |   in   |   out  | analog |  oeb min/sim/max  | Message
Is this a problem on my end or with the precheck? @Mitch Bailey I think this is your area of expertise, I would appreciate any help.
Here is the whole log file (for 
gfmpw-1b
):
OEB_check.log
Btw, with the gfmpw-1b tag the 
OEB
passes and only prints a warning: 
WARNING ERC CHECK FAILED, stat=4, see /home/leo/Dokumente/workspace-gf-mpw-1/leosoc-gfmpw-1/precheck_results/07_NOV_2023___12_09_05/logs/OEB_check.log
The content of the log file is the same as before.
This is with 
gfmpw-1c
OEB_check.log
t
@Leo Moser: Without seeing the netlist, I'd say that the netlist is using "M" records for the transistors while all the device models are subcircuits ("X" records). I'm not sure which of the netlists that's coming from. It's a different problem with a different solution for schematics and layout.
From the log file, I think the schematic is the source of the "M" records; which means that in the Simulation menu, you need to have "Use 'spiceprefix' attribute" checked before you generate a netlist.
l
That sounds interesting, is this something that should be done automatically since this is a digital design?
Also, I am using the foundry provided SRAM, if that makes any difference. Is there any file I can upload that would help?
t
If you know where the two netlists that get compared by LVS are, then upload those. It's possible that a CDL file is being included for a block like the SRAM instead of the SPICE. Which would have nothing to do with xschem, of course.
@Mitch Bailey: Do you know where the GF SRAM would be getting its netlist for LVS?
I'm pretty sure this error comes from the LVS script including the netlist for the GF SRAM from the "cdl" directory and not from the "spice" directory of the PDK.
l
I had a look but couldn't find the netlists. I think we have to wait for @Mitch Bailey, maybe he knows the location. But in the 
tmp/
folder of the precheck I see a mention of 
user_proj_example
which I do not use anymore, so maybe I need to update the 
lvs_config.json
also for the OEB check? I am currently not running LVS because of the SRAM and the issue noted above: https://open-source-silicon.slack.com/archives/C03R1GRP9LG/p1699021310239599
m
Sorry, for the late reply. The OEB check is based on the output of CVC which requires a netlist with mosfet models. There is a conversion script that changes the extracted 
X
device mosfets to 
M
devices. It looks like the problem is that there are 3.3V devices being extracted when only 6V devices should exist. This is probably caused by what magic considers to be invalid device structures in the sram. Implants are added at higher hierarchies. magic can not correctly extract cross hierarchy devices - all the layers for a device must exist at the same hierarchy. The solution is to flatten all the hierarchy of the srams. This is done with the hierarchical 
lvs_config.json
files. Currently, only the 256x8 version of the 
lvs_config.json
file is in mpw_precheck. Here’s the 512x8 version.
Copy code
{
  "EXTRACT_FLATGLOB": [
    "*018SRAM_*",
    "*nmos_*",
    "*pmos_*",
    "*pmoscap*",
    "*$$*",
    "*M?_M*_*",
    "*M?_?ACTIVE*_*",
    "*M?_PSUB*_*",
    "*M?_POLY*_*",
    "*M?_NWEL*_*",
    "*via1_*",
    "*ypass_gate*",
    "*power_route*",
    "*alatch*",
    "*Cell_array*",
    "*dcap_*",
    "*new_dummyrow*",
    "*dummy*",
    "*mux821_*",
    "*strapx2b_bndry*",
    "*predec?_*",
    "*rarray*",
    "*prexdec_top*",
    "*xdec_*",
    "*xdec8_*",
    "*xdec32_*",
    "*xdec64_*",
    "*din_*",
    "*sacntl_*",
    "*sa_*",
    "*m2_saout*",
    "*outbuf_oe*",
    "*wen_wm1_*",
    "*saout_*",
    "*m2m3_*",
    "*wen_*",
    "*gen_*",
    "*G_ring_*",
    "*x8M8W_PWR_*",
    "*power_*",
    "*control_*",
    "*GF018_*x8M8WM1_*",
    "*col_*",
    "*rcol4_*",
    "*lcol4_*"
  ],
  "EXTRACT_ABSTRACT": [
    ""
  ],
  "LVS_FLATTEN": [
    ""
  ],
  "LVS_NOFLATTEN": [
    ""
  ],
  "LVS_IGNORE": [
    ""
  ],
  "LVS_SPICE_FILES": [
    "$PDK_ROOT/$PDK/libs.ref/gf180mcu_fd_ip_sram/spice/gf180mcu_fd_ip_sram__sram512x8m8wm1.spice"
  ],
  "LVS_VERILOG_FILES": [
    ""
  ]
}
If you save this as 
lvs/lvs_config.sram512x8m8wm1.json
you can reference it in your 
lvs/user_project_wrapper/lvs_config.json
file like this
Copy code
"STD_CELL_LIBRARY": "gf180mcu_fd_sc_mcu7t5v0",
    "INCLUDE_CONFIGS": [
        "$LVS_ROOT/tech/$PDK/lvs_config.base.json",
        "$LVS_ROOT/tech/$PDK/lvs_config.sram512x8m8wm1.json"
    ],
    "TOP_SOURCE": "user_project_wrapper",
    "TOP_LAYOUT": "$TOP_SOURCE",
    "EXTRACT_FLATGLOB": [
        ""
    ],
    "EXTRACT_ABSTRACT": [
        ""
    ],
    "LVS_FLATTEN": [
        ""
    ],
    "LVS_NOFLATTEN": [
        ""
    ],
    "LVS_IGNORE": [
        ""
    ],
    "LVS_SPICE_FILES": [
        ""
    ],
    "LVS_VERILOG_FILES": [
        "$UPRJ_ROOT/verilog/gl/user_proj_example.v",
        "$UPRJ_ROOT/verilog/gl/$TOP_SOURCE.v"
    ],
    "LAYOUT_FILE": "$UPRJ_ROOT/gds/$TOP_LAYOUT.gds"
}
This will flatten the sram before extracting so that all the devices are extracted correctly and the OEB check should work.
t
@Mitch Bailey: Thanks. I didn't know that CVC converts non-subcircuit components. Also, I thought that the platform handled all of the SRAM blocks in the PDK (it really ought to).
👍 1
l
Thanks @Mitch Bailey I will try that! Btw. in 
mpw_precheck/checks/be_checks/tech/gf180mcuD
there are already two files 
lvs_config.sram256x8m8wm1.json
and 
lvs_config.sram512x8m8wm1.json
with slightly less entries in 
EXTRACT_FLATGLOB
and they are referencing a 
.cdl
file in 
LVS_SPICE_FILES
. I don't know if that has any relevance or whether they are even used, but just so you know.
m
@Leo Moser Thanks. Working on a fix.
👍 1
l
I can confirm that with the new docker image and your configuration file for the SRAM the OEB check runs through 🎉️ Unfortunately, I got oeb errors 😅️ Can I ask you for your advice @Mitch Bailey? This is the result:
Copy code
> q
 gpio |   in   |   out  | analog |  oeb min/sim/max  | Message
  35  |      4 |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  26  |      4 |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  17  |      4 |      2 |        |   vss/     /      | 
   4  |        |      1 |        |      /     /      | ERROR: oeb must have possible low for output
  36  |      4 |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  27  |      4 |      2 |        |   vss/     /      | 
  18  |      4 |      2 |        |   vss/     /      | 
   5  |        |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  37  |      4 |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  28  |      4 |      2 |        |   vss/     /      | 
  19  |      4 |      2 |        |   vss/     /      | 
   6  |        |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  29  |      4 |      2 |        |   vss/     /      | 
   7  |      4 |        |        |      /     /      | 
   8  |        |      2 |        |      /     /      | ERROR: oeb must have possible low for output
   9  |      4 |        |        |      /     /      | 
  10  |        |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  20  |      4 |      2 |        |   vss/     /      | 
  11  |      4 |        |        |      /     /      | 
  30  |      4 |      2 |        |   vss/     /      | 
  21  |      4 |      2 |        |   vss/     /      | 
  12  |        |      2 |        |   vss/     /      | 
  31  |      4 |      2 |        |   vss/     /      | 
  22  |      4 |      2 |        |   vss/     /      | 
  13  |        |        |        |   vss/     /      | 
   0  |        |      1 |        |      /     /      | ERROR: oeb must have possible low for output
  32  |      4 |      2 |        |   vss/     /      | 
  23  |      4 |      2 |        |   vss/     /      | 
  14  |      4 |      2 |        |      /     /      | ERROR: oeb must have possible low for output
   1  |        |      1 |        |      /     /      | ERROR: oeb must have possible low for output
  33  |      4 |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  24  |      4 |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  15  |      4 |      2 |        |   vss/     /      | 
   2  |        |      1 |        |      /     /      | ERROR: oeb must have possible low for output
  34  |      4 |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  25  |      4 |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  16  |      4 |      2 |        |   vss/     /      | 
   3  |        |      1 |        |      /     /      | ERROR: oeb must have possible low for output
The gpio column is the number of io_out/io_in/io_oeb, correct? What does the in and out column mean? For some of my gpios the error makes sense I think: I have some I/Os that I use only for input, therefore io_oeb is tied high and io_out is set to zero. But the oeb check expects for all gpios with a io_out value that io_oeb can become low, right? This would mean I need to set io_out as not connected. But if I do not assign any value to 
io_out
than I get e.g.: 
Warning: Wire user_project_wrapper.\io_out [11] is used but has no driver.
during synthesis. These are my connections:
Copy code
/*--------------------------------------*/
/* User project is instantiated  here   */
/*--------------------------------------*/

// Not used

assign io_out[4:0] = 5'b00000;
assign io_oeb[4:0] = 5'b11111;

// SPI

assign io_oeb[8:5] = 4'b0100;
assign io_out[7] = 1'b0;

// UART0

assign io_oeb[10:9] = 2'b01;
assign io_out[9] = 1'b0;

// UART1

assign io_oeb[12:11] = 2'b01;
assign io_out[11] = 1'b0;

// Blinky

assign io_oeb[13] = 1'b0;

// GPIO - use 24 bits

wire [31:0] gpio0_in;
wire [31:0] gpio0_out;
wire [31:0] gpio0_oe;

assign io_oeb[37:14] = ~gpio0_oe[23:0];
assign io_out[37:14] =  gpio0_out[23:0];
assign gpio0_in = {8'b00000000, io_in[37:14]};

leosoc leosoc_i (
`ifdef USE_POWER_PINS
	.vdd(vdd),	// User area 1 1.8V power
	.vss(vss),	// User area 1 digital ground
`endif
    .clk        (wb_clk_i),
    .reset      (wb_rst_i),

    .uart0_rx   (io_in[9]),
    .uart0_tx   (io_out[10]),
    
    .uart1_rx   (io_in[11]),
    .uart1_tx   (io_out[12]),
    
    .gpio0_in   (gpio0_in),
    .gpio0_out  (gpio0_out),
    .gpio0_oe   (gpio0_oe),

    .blink      (io_out[13]),
    
    // SPI signals
    .sck        (io_out[5]),
    .sdo        (io_out[6]),
    .sdi        (io_in[7]),
    .cs         (io_out[8])
);
m
in
is the 
io_in
connection, 
out
is the 
io_out
connection. If this is your 
user_project_wrapper
level, you probably don’t want to run synthesis at this level. You might try adding a tie_low and tie_high pin to leosoc and putting the assign statement there. Then you can connect the actual top level 
io_out
and 
io_oeb
to those signals as appropriate. It bothers be that your vdd signal is not showing up. Is it shorted? You can check 
precheck_results/<tag>/tmp/ext.log
l
Why would I not want to run synthesis on the 
user_project_wrapper
? Are there issues with the precheck? Because with gfmpw-1b I was even able to successfully finish the tapeout job. This is how my design currently looks:
Here is `ext.log`:
ext.log
I don't see any obvious, but I also do not know what to look for 😅
t
@Mitch Bailey: The problem seems to be in the OEB check. Leo has OEB set to static 1 with the output tied to static 0 and the check is complaining it's an error---I don't see why.
m
I don’t see any short messages. Many designs run synthesis on the 
user_proj_example
equivalent block, and use 
SYNTH_ELABORATE_ONLY
on 
user_project_wrapper
to just do the connections. Since you’re not placing any standard cell rows, you won’t have adjustments for timing or be able to tie anything. @Tim Edwards that’s in the rtl. We need to check how that’s being synthesize in the gl.
l
Yes, that's how I did it for previous designs. But this time I would like to synthesize my dual core SoC in the 
user_project_wrapper
. For this I enabled the placement of standard cell rows. The sea of gates you see in the picture is just that.
This is the corresponding 
config.json
:
Copy code
{
  "PDK": "gf180mcuD",
  "DESIGN_NAME": "user_project_wrapper",
  "STD_CELL_LIBRARY": "gf180mcu_fd_sc_mcu7t5v0",
  "VERILOG_FILES": [
    "dir::../../verilog/rtl/defines.v",
    "dir::../../verilog/rtl/user_project_wrapper.v",
    "dir::../../verilog/rtl/leorv32/rtl/leorv32_pkg.sv",
    "dir::../../verilog/rtl/leorv32/rtl/leorv32.sv",
    "dir::../../verilog/rtl/soc/rtl/leosoc.sv",
    "dir::../../verilog/rtl/soc/rtl/core_wrapper.sv",
    "dir::../../verilog/rtl/cache/rtl/direct_mapped_cache.sv",
    "dir::../../verilog/rtl/sram/rtl/sram_gf180.sv",
    "dir::../../verilog/rtl/arbiter/rtl/arbiter.sv",
    "dir::../../verilog/rtl/uart/rtl/uart_rx.sv",
    "dir::../../verilog/rtl/uart/rtl/uart_tx.sv",
    "dir::../../verilog/rtl/uart/rtl/peripheral_uart.sv",
    "dir::../../verilog/rtl/gpio/rtl/peripheral_gpio.sv",
    "dir::../../verilog/rtl/peripheral_trng/rtl/peripheral_trng.sv",
    "dir::../../verilog/rtl/spi_flash/rtl/spi_flash.sv",
    "dir::../../verilog/rtl/util/rtl/synchronizer.sv"
  ],
  "CLOCK_PORT": "wb_clk_i",
  "CLOCK_PERIOD": 25,
  "RUN_CTS": 1,
  "MACRO_PLACEMENT_CFG": "dir::macro.cfg",
  "VERILOG_FILES_BLACKBOX": [
    "dir::../../verilog/gl/gf180_ram_512x8_wrapper.v",
    "dir::../../verilog/gl/trng_1x3.v",
    "dir::../../verilog/gl/trng_1x5.v",
    "dir::../../verilog/gl/trng_1x7.v",
    "dir::../../verilog/gl/trng_2x3.v",
    "dir::../../verilog/gl/trng_2x5.v",
    "dir::../../verilog/gl/trng_2x7.v",
    "dir::../../verilog/gl/trng_8x3.v",
    "dir::../../verilog/gl/trng_8x5.v",
    "dir::../../verilog/gl/trng_8x7.v",
    "dir::../../verilog/gl/trng_32x3.v",
    "dir::../../verilog/gl/trng_32x5.v",
    "dir::../../verilog/gl/trng_32x7.v",
    "dir::../../verilog/gl/trng_128x3.v",
    "dir::../../verilog/gl/trng_128x5.v",
    "dir::../../verilog/gl/trng_128x7.v"
  ],
  "EXTRA_LEFS": [
    "dir::../../lef/gf180_ram_512x8_wrapper.lef",
    "dir::../../lef/trng_1x3.lef",
    "dir::../../lef/trng_1x5.lef",
    "dir::../../lef/trng_1x7.lef",
    "dir::../../lef/trng_2x3.lef",
    "dir::../../lef/trng_2x5.lef",
    "dir::../../lef/trng_2x7.lef",
    "dir::../../lef/trng_8x3.lef",
    "dir::../../lef/trng_8x5.lef",
    "dir::../../lef/trng_8x7.lef",
    "dir::../../lef/trng_32x3.lef",
    "dir::../../lef/trng_32x5.lef",
    "dir::../../lef/trng_32x7.lef",
    "dir::../../lef/trng_128x3.lef",
    "dir::../../lef/trng_128x5.lef",
    "dir::../../lef/trng_128x7.lef"
  ],
  "EXTRA_GDS_FILES": [
    "dir::../../gds/gf180_ram_512x8_wrapper.gds",
    "dir::../../gds/trng_1x3.gds",
    "dir::../../gds/trng_1x5.gds",
    "dir::../../gds/trng_1x7.gds",
    "dir::../../gds/trng_2x3.gds",
    "dir::../../gds/trng_2x5.gds",
    "dir::../../gds/trng_2x7.gds",
    "dir::../../gds/trng_8x3.gds",
    "dir::../../gds/trng_8x5.gds",
    "dir::../../gds/trng_8x7.gds",
    "dir::../../gds/trng_32x3.gds",
    "dir::../../gds/trng_32x5.gds",
    "dir::../../gds/trng_32x7.gds",
    "dir::../../gds/trng_128x3.gds",
    "dir::../../gds/trng_128x5.gds",
    "dir::../../gds/trng_128x7.gds"
  ],
  "EXTRA_LIBS": [
    "dir::../../lib/gf180_ram_512x8_wrapper.lib",
    "dir::../../lib/trng_1x3.lib",
    "dir::../../lib/trng_1x5.lib",
    "dir::../../lib/trng_1x7.lib",
    "dir::../../lib/trng_2x3.lib",
    "dir::../../lib/trng_2x5.lib",
    "dir::../../lib/trng_2x7.lib",
    "dir::../../lib/trng_8x3.lib",
    "dir::../../lib/trng_8x5.lib",
    "dir::../../lib/trng_8x7.lib",
    "dir::../../lib/trng_32x3.lib",
    "dir::../../lib/trng_32x5.lib",
    "dir::../../lib/trng_32x7.lib",
    "dir::../../lib/trng_128x3.lib",
    "dir::../../lib/trng_128x5.lib",
    "dir::../../lib/trng_128x7.lib"
  ],
  "EXTRA_SPEFS": [
    "gf180_ram_512x8_wrapper",
    "dir::../../spef/multicorner/gf180_ram_512x8_wrapper.min.spef",
    "dir::../../spef/multicorner/gf180_ram_512x8_wrapper.nom.spef",
    "dir::../../spef/multicorner/gf180_ram_512x8_wrapper.max.spef",
    "trng_1x3",
    "dir::../../spef/multicorner/trng_1x3.min.spef",
    "dir::../../spef/multicorner/trng_1x3.nom.spef",
    "dir::../../spef/multicorner/trng_1x3.max.spef",
    "trng_1x5",
    "dir::../../spef/multicorner/trng_1x5.min.spef",
    "dir::../../spef/multicorner/trng_1x5.nom.spef",
    "dir::../../spef/multicorner/trng_1x5.max.spef",
    "trng_1x7",
    "dir::../../spef/multicorner/trng_1x7.min.spef",
    "dir::../../spef/multicorner/trng_1x7.nom.spef",
    "dir::../../spef/multicorner/trng_1x7.max.spef",
    "trng_2x3",
    "dir::../../spef/multicorner/trng_2x3.min.spef",
    "dir::../../spef/multicorner/trng_2x3.nom.spef",
    "dir::../../spef/multicorner/trng_2x3.max.spef",
    "trng_2x5",
    "dir::../../spef/multicorner/trng_2x5.min.spef",
    "dir::../../spef/multicorner/trng_2x5.nom.spef",
    "dir::../../spef/multicorner/trng_2x5.max.spef",
    "trng_2x7",
    "dir::../../spef/multicorner/trng_2x7.min.spef",
    "dir::../../spef/multicorner/trng_2x7.nom.spef",
    "dir::../../spef/multicorner/trng_2x7.max.spef",
    "trng_8x3",
    "dir::../../spef/multicorner/trng_8x3.min.spef",
    "dir::../../spef/multicorner/trng_8x3.nom.spef",
    "dir::../../spef/multicorner/trng_8x3.max.spef",
    "trng_8x5",
    "dir::../../spef/multicorner/trng_8x5.min.spef",
    "dir::../../spef/multicorner/trng_8x5.nom.spef",
    "dir::../../spef/multicorner/trng_8x5.max.spef",
    "trng_8x7",
    "dir::../../spef/multicorner/trng_8x7.min.spef",
    "dir::../../spef/multicorner/trng_8x7.nom.spef",
    "dir::../../spef/multicorner/trng_8x7.max.spef",
    "trng_32x3",
    "dir::../../spef/multicorner/trng_32x3.min.spef",
    "dir::../../spef/multicorner/trng_32x3.nom.spef",
    "dir::../../spef/multicorner/trng_32x3.max.spef",
    "trng_32x5",
    "dir::../../spef/multicorner/trng_32x5.min.spef",
    "dir::../../spef/multicorner/trng_32x5.nom.spef",
    "dir::../../spef/multicorner/trng_32x5.max.spef",
    "trng_32x7",
    "dir::../../spef/multicorner/trng_32x7.min.spef",
    "dir::../../spef/multicorner/trng_32x7.nom.spef",
    "dir::../../spef/multicorner/trng_32x7.max.spef",
    "trng_128x3",
    "dir::../../spef/multicorner/trng_128x3.min.spef",
    "dir::../../spef/multicorner/trng_128x3.nom.spef",
    "dir::../../spef/multicorner/trng_128x3.max.spef",
    "trng_128x5",
    "dir::../../spef/multicorner/trng_128x5.min.spef",
    "dir::../../spef/multicorner/trng_128x5.nom.spef",
    "dir::../../spef/multicorner/trng_128x5.max.spef",
    "trng_128x7",
    "dir::../../spef/multicorner/trng_128x7.min.spef",
    "dir::../../spef/multicorner/trng_128x7.nom.spef",
    "dir::../../spef/multicorner/trng_128x7.max.spef"
  ],
  "FP_PDN_MACRO_HOOKS": [
    "leosoc_i.wram.*sram512x8_i0 vdd vss vdd vss",
    "leosoc_i.wram.*sram512x8_i1 vdd vss vdd vss",
    "leosoc_i.wram.*sram512x8_i2 vdd vss vdd vss",
    "leosoc_i.wram.*sram512x8_i3 vdd vss vdd vss",
    "leosoc_i.peripheral_trng_i.trng.* vdd vss vdd vss"
  ],
  "PL_BASIC_PLACEMENT": 0,
  "PL_TARGET_DENSITY": 0.3,
  "ROUTING_CORES": 14,
  "MAX_FANOUT_CONSTRAINT": 4,
  "#QUIT_ON_SYNTH_CHECKS": 0,
  "#FP_PDN_CHECK_NODES": 0,
  "#RUN_CVC": 0,
  "#RUN_LINTER": 0,
  "RUN_LVS": 0,
  "SYNTH_READ_BLACKBOX_LIB": 1,
  "FP_PDN_ENABLE_RAILS": 0,
  "MAGIC_ZEROIZE_ORIGIN": 0,
  "FP_SIZING": "absolute",
  "DIE_AREA": "0 0 2980.2 2980.2",
  "CORE_AREA": "12 12 2968.2 2968.2",
  "FP_PIN_ORDER_CFG": "dir::pin_order.cfg",
  "UNIT": 2.4,
  "FP_IO_VEXTEND": "expr::2 * $UNIT",
  "FP_IO_HEXTEND": "expr::2 * $UNIT",
  "FP_IO_VLENGTH": "expr::$UNIT",
  "FP_IO_HLENGTH": "expr::$UNIT",
  "FP_IO_VTHICKNESS_MULT": 4,
  "FP_IO_HTHICKNESS_MULT": 4,
  "FP_PDN_CORE_RING": 1,
  "FP_PDN_CORE_RING_VWIDTH": 3.1,
  "FP_PDN_CORE_RING_HWIDTH": 3.1,
  "FP_PDN_CORE_RING_VOFFSET": 14,
  "FP_PDN_CORE_RING_HOFFSET": 16,
  "FP_PDN_CORE_RING_VSPACING": 1.7,
  "FP_PDN_CORE_RING_HSPACING": 1.7,
  "FP_PDN_HOFFSET": 5,
  "FP_PDN_HPITCH_MULT": 1,
  "FP_PDN_HPITCH": "expr::60 + $FP_PDN_HPITCH_MULT * 30",
  "FP_PDN_VWIDTH": 3.1,
  "FP_PDN_HWIDTH": 3.1,
  "FP_PDN_VSPACING": "expr::5 * $FP_PDN_CORE_RING_VWIDTH",
  "FP_PDN_HSPACING": 26.9,
  "VDD_NETS": [
    "vdd"
  ],
  "GND_NETS": [
    "vss"
  ],
  "SYNTH_USE_PG_PINS_DEFINES": "USE_POWER_PINS",
  "FP_DEF_TEMPLATE": "dir::fixed_dont_change/user_project_wrapper.def",
  "BASE_SDC_FILE": "dir::base_user_project_wrapper.sdc",
  "SIGNOFF_SDC_FILE": "dir::signoff.sdc"
}
I disabled LVS because of the issues with the SRAM, 
SYNTH_READ_BLACKBOX_LIB
could also be removed again. I had this initially because I instantiated some gates directly which are now in a macro.
@Mitch Bailey I tried to grep a bit in the GL netlist and it seems that 
io_oeb
is indeed connected to tie cells:
Copy code
$ grep -n 'io_oeb' user_project_wrapper.v
11:    io_oeb,
31: output [37:0] io_oeb;
299016:    .Z(io_oeb[14]),
299022:    .Z(io_oeb[15]),
299028:    .Z(io_oeb[16]),
299034:    .Z(io_oeb[17]),
299040:    .Z(io_oeb[18]),
299046:    .Z(io_oeb[19]),
299052:    .Z(io_oeb[20]),
299058:    .Z(io_oeb[21]),
299064:    .Z(io_oeb[22]),
299070:    .Z(io_oeb[23]),
299076:    .Z(io_oeb[24]),
299082:    .Z(io_oeb[25]),
299088:    .Z(io_oeb[26]),
299094:    .Z(io_oeb[27]),
299100:    .Z(io_oeb[28]),
299106:    .Z(io_oeb[29]),
299112:    .Z(io_oeb[30]),
299118:    .Z(io_oeb[31]),
299124:    .Z(io_oeb[32]),
299130:    .Z(io_oeb[33]),
299136:    .Z(io_oeb[34]),
299142:    .Z(io_oeb[35]),
299148:    .Z(io_oeb[36]),
299154:    .Z(io_oeb[37]),
983668: assign io_oeb[0] = net348;
983669: assign io_oeb[10] = net118;
983670: assign io_oeb[11] = net355;
983671: assign io_oeb[12] = net119;
983672: assign io_oeb[13] = net120;
983673: assign io_oeb[1] = net349;
983674: assign io_oeb[2] = net350;
983675: assign io_oeb[3] = net351;
983676: assign io_oeb[4] = net352;
983677: assign io_oeb[5] = net115;
983678: assign io_oeb[6] = net116;
983679: assign io_oeb[7] = net353;
983680: assign io_oeb[8] = net117;
983681: assign io_oeb[9] = net354;


$ grep -n 'net348' user_project_wrapper.v
24769: wire net348;
205481: gf180mcu_fd_sc_mcu7t5v0__tieh user_project_wrapper_348 (.Z(net348),
983668: assign io_oeb[0] = net348;

$ grep -n 'net349' user_project_wrapper.v
21406: wire net349;
204275: gf180mcu_fd_sc_mcu7t5v0__tieh user_project_wrapper_349 (.Z(net349),
983673: assign io_oeb[1] = net349;
m
The problem might be that 
FP_PDN_ENABLE_RAILS
is set to zero. I bet none of your standard cell row nwells are connected to power! Can you check the gds?
l
Thanks so much! I totally forgot about that variable when enabling the standard cell rows in the 
user_project_wrapper
. I started OpenLane with that change, let's see if that was it 👍
👍 1
The OEB check was successful 🎉
👍 2
28 Views
Open in Slack
PreviousNext
Powered by

What is Linen?

Linen is a search-engine friendly community platform. We offer integrations with existing Slack/Discord communities and make those conversations Google-searchable.

Powered by