https://open-source-silicon.dev logo
Join Slack
Powered by
I'm seeing an issue on my submission For `OEB` che...
# gf180mcu
g
I'm seeing an issue on my submission For 
OEB
check. I get the following error 
ERROR: could not expand signal vdd signal vdd not found.
Same for vss. It also reports la_out[50] is shorted to a tie net. It looks the same as all the other la_out signals... I'm using the default 
PRIMARY_SIGNOFF_TOOL Magic
So not sure if I'm seeing the same CVC case sensitivity error as @Egor Lukyanchenko
m
First, is your design passing local precheck (most recent version - 
gfmpw-1d
)?
Copy code
make run-precheck
g
Yes, it passes all except OEB. I had an LVS error, but that was fixed with your SRAM lvs.json changes.
m
Can you share 
precheck_results/<tag>/logs/precheck.log
?
g
I'll run it again fully, this is what I got last night. Today I've been trying things with just running the OEB check. (I might have gotten confused with the LVS check, that doesn't run when you do the check on your side?)
precheck.log
precheck.log
m
LVS may not run on the platform side. I know it doesn’t run for ChipIgnite shuttles, but I thought it was supposed to run for Google shuttles. Is your Makefile from 
gfmpw-1d
? That will effect the precheck settings.
g
I think so. I just did the 
curl ...caravel/gf180mcu/Makefile > Makefile
command. and git reports no changes.
m
Great! The 
MPW_TAG
in the 
Makefile
should be 
gfmpw-1d
. Can you verify?
g
I did synth my design in the wrapper, rather than use a macro. My design has SRAM macros. If that makes a difference?
Copy code
ifeq ($(PDK),gf180mcuD)

	MPW_TAG ?= gfmpw-1d
m
I’m suspecting that the issue might be shorted top level ports. Can you send the 
ext.log
, 
lvs.report
, 
cvc.log
from 
precheck_results/<tag>/tmp
g
lvs.report,ext.log,cvc.log
lvs.reportext.logcvc.log
Okay, any insight will help.
I think I see something. Somehow I've got a PDN grid outside the die area... let me check my configs
core area lower left (12.000 12.000) snapped to (12.320 15.680)
? This seems suspicious in my 3-inital_fp.log file
m
Can you share your 
lvs/user_project_wrapper/lvs_config.json
file too? It looks like the sram settings aren’t being applied. For the LVS error, you might try removing the def labels with 
"MAGIC_DEF_LABELS": 0
next time. If you wanted a quick fix, open 
gds/user_project_wrapper.gds
in klayout and remove the 
net2331
text. Is your top level text 
vdd
and 
vss
?
Sorry, I can’t advise you on the core area lower left snap. Maybe ask in a new thread?
g
That log was run before I saw the SRAM fixes.
Ohh, I had both a config.json. And a config.tcl in my design directory. That's been ignoring the changes I've done to the json. -_-
😬 1
Something I just overlooked, I started with a config.tcl because I could add comments. But then saw the precheck wants you to have a .json.
m
The openlane 
config.json
file and precheck 
lvs_config.json
file are totally separate. The 
config.tcl
or 
config.json
file is in 
openlane/user_project_wrapper
and the 
lvs_config.json
file is in 
lvs/user_project_wrapper
.
g
Thanks for help with this David. For reference to anyone else the core issue was I've used the top wrapper to harden my design. As a result of this the core area was adjusted by openroad during initial floorplanning to be a multiple of the stdcell size. This changed the core_area, and as a result shifted the PDN boundaries. This then caused issues during precheck.
Open in Slack
PreviousNext
Powered by