https://open-source-silicon.dev
Join Slack
What causes MetSpc routing violations and what is the best way to fix those? Getting ```violation ty...
# openlane
a
What causes MetSpc routing violations and what is the best way to fix those? Getting
Copy code
violation type: MetSpc
srcs: repeater1/OBS wb_clk_i
bbox = ( 71.34, 137.105 ) - ( 71.445, 137.275 ) on Layer li1
Design is https://github.com/AmoghLonkar/openram_testchip. Thanks
m
Routing issues are likely due to congestion. What does your placement look like?
a
Capture.PNG
perhaps reducing placement density would help?
m
I can't really see the placement. Is that a macro block that you created ?
Rather than making a macro that gets placed in user_project_wrapper, I would recommend putting your design directly in user_project_wrapper
a
didn't create any macro blocks
m
what is that then? is that openram_testchip?
according to your repo, you are making a macro called openram_testchp that I assume will get placed in user_project_wrapper?
(or at least there is an openlane/openram_testchip/config.tcl...)
a
I had created initially, but I'm not using it since the logic will be in the top level
m
Ah, ok, delete that to make it less confusing then 🙂
👍 1
a
the result I sent was from klayout in the runs/results/floorplan
m
from user_project_wrapper?
a
yes
m
The png files are a bit hard to see sometimes, so I recommend viewing them in magic:
Copy code
lef read merged_padded.lef
def read user_project_wrapper.def
👍 1
(from that directory since there should be a .magicrc to set up the technology in there)
If congestion is a problem, you can set PL_TARGET_DENSITY to spread the cells out more. You can also adjust GLB_RT_ADJUSTMENT to reserve more global wires which can cause routing to spread out.
👍 1
m
@Amogh Lonkar I have seen this before when CTS inserts one of the cells that are part of the drc exclude list (https://github.com/RTimothyEdwards/open_pdks/blob/master/sky130/openlane/sky130_fd_sc_hd/drc_exclude.cells). Do you have any of those in your def file, especially 
sky130_fd_sc_hd__lpflow_lsbuf_lh_hl_isowell_tap_1
?
a
None of the exluded cells seem to be in the placement def file
m
@Amogh Lonkar You can check where the violation is happening exactly by loading the def file in klayout from File -> import -> DEF/LEF. Then under 
import file
, point to the def file. And, under 
With LEF files
point to the 
merged.lef
which you can find in 
<run-dir>/tmp/merged.lef
. Then, after the def is loaded go to Display -> Go To Position. Then type the first coordinate 
71.34, 137.105
. That should give a hint to why it is happening.
a
I will try that, thank you!
m
@Manar Abdelatty I've never been able to get klayout to open the lef cells. I actually filed a bug and it was recently fixed in the newest klayout. What version were you using that that worked?
@Amogh Lonkar you can also do this in magic if that doesn't work: lef read merged.lef def read file.def drc find (must be in a directory with a .magicrc for the technology)
👍 1
a
from the klayout view, it just seems to be pointing to a wire/pin but hard to determine what the is causing the problem.
m
@Matthew Guthaus Mine is 
KLayout 0.26.9
.
a
@Matthew Guthaus my magic has some issues reading the lef and def files and adding the sky130A.magicrc was causing segfaults and killing magic.
m
@Amogh Lonkar make sure you have a recent version. If it comes in a package it is probably too old
👍 1
m
@Amogh Lonkar Is it flagged inside a cell ? You can also try to slightly increase the 
GLB_RT_ADJUSTMENT
This should help with routing violations in general.
a
I can try doing that. There aren't any standard cells placed there and I've set macros to be placed at fixed position 75(violation occurs at 71) and can't see those being placed in klayout even though the placement def file says they've been placed.
m
@Amogh Lonkar Probably you didn't load the LEF file (merged.lef) when you imported the def file
a
just double checked, did import both
Basic question, but this is how it should be right?
m
@Amogh Lonkar Yes that is right. It could be the same issue that @Matthew Guthaus pointed out with loading the LEF file in klayout
a
weirdly, we were able to see macros in klayout in a smaller intermediate design we were testing which failed because of the same violations
Once my magic is updated, I'll check in that
m
You'll see lines through the cell names in the cell pane if they aren't loaded
@Amogh Lonkar are you sure you didn't see routing and power? I've never gotten the LEF to load
It's literally a bug that was fixed https://github.com/KLayout/klayout/issues/777
It's only when the LEF cells have a "foreign" statement which means it is looking for the gds instead of the lef
a
Not sure what it was then, I was looking at it on Jesse's screen and we saw two smallish squares blocked on the bottom left. We assumed they were the sram macros since the position seemed correct
m
If the SRAM macros don't have a foreign statement, it'll work. I think I removed it in OpenRAM
The standard cells have it, however
a
It looks like a standard cell is being placed on a metal layer. Is there a way to define where std cells can be placed?
In general, it seems like the top level std cells are being placed all over instead of closer to the macros.
m
@Amogh Lonkar I don't think that is a standard cell. You need to expand the view to view all levels of hierarchy. Click outside the area, press "s" to select everything, type "x" to expand all
It could be an antenna diode or somethign
It's in the halo so it is definitely not a standard cell. Not sure what it is
a
label says sky130_fd_sc_hd_comb_1 #1529
m
What cell is that?
Also, is that really a problem? That is metal5 over the cell right? There should be M1-M4 to route on
a
those are the coordinates of the violation, not sure if that exact cell is the problem. There isn't anything else there to cause an issue.
m
I mean, it's a valid cell, so that alone isn't an error. You can iterate through the errors in magic with "drc find"
a
there aren't any drc violations
m
Where is that error message from?
Can you share the design?
a
it comes from reports/routing/21-triton.drc
m
what layout are you viewing?
are you viewing the input to the router?
Or do you see routes?
a
I can see the routes
there's a repeater touching the SRAM macro, but still no drc violations from 
drc find
. I'm moving the macro further away and seeing if that fixes it
m
Can you share the design somehow?
a
Finishing up a run, I'll share the def/lef files
I think my macro placement might be the issue, still getting the same error but still need to increase the gap with the repeater
user_project_wrapper.defmerged.lef
Has nothing to do with the macro, it is the repeater insertion causing the problem.
m
@Amogh Lonkar You have one of the cells that are part of the drc exclude list in the def file design 
sky130_fd_sc_hd__lpflow_lsbuf_lh_hl_isowell_tap_1
This PR should fix this issue https://github.com/The-OpenROAD-Project/OpenLane/pull/412 . You can wait until its merged or apply it locally. Also, if you have std cells at the top level you will need to remove the configs starting from here https://github.com/efabless/caravel_user_project/blob/main/openlane/user_project_wrapper/config.tcl#L57.
👍 1
a
Thank you!
a
@Rameen Anwar
✅ 1
3 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