<@U02GU6KPHUH> looks like a metal density issue. ...
# tapeout-job
j
@User looks like a metal density issue. you need to check the logs to find out which layer failed the check. it is likely you are under density (too much clear area) on one of the metal layers.
a
where can I check these logs? I can't find the full logs anywhere. Thank you
o
@User you need to go onto
Open Galaxy
and navigate to the path in your job logs which is
Copy code
u6276_aurorat/design/elpis-light-mpw3/jobs/tapeout/b4145f1a-c86e-4c8b-aa1b-d0bb4dd050c6/logs
a
@User Thank you! I am inside it but how can I access to that file? I just can open a manager window
o
you can right click and open a terminal wherever you are
a
@User Thank you very much!
@User @User I have seen the following errors. Do you know why does this happen? Thank you!
o
@User these errors can be ignored @User can explain why they are showing up, but they should not be the cause of your metal density issue.
a
@User Thanks for answering. So I can't find any other errors in the log files.. the fom_density succeeded and met_density seems to be ok šŸ˜• What else can I check?
o
you need the to check the
met_density_report.xml
and debug from there, that file is located in the
outputs
directory
a
@User Thanks a lot Ahmed, I obtained this short file:
o
yes, this file is a marker database that contains the single violation you see in your logs on the website. @User can help with how to move forward from there.
you should be able to load this inside
klayout
and look at it yourself.
r
Hi, what I should load into klayout? the xml alone? how? first the gds and the the xml? how can I open the xml after the gds?
o
we do provide a simple way to load the
gds
and the
xml
together. It can be invoked by running
view-job-errors
in a terminal while at the root of your project. @User can provide more help as I am not well versed in it.
r
ok, thanks
a
@User Is the pink thing what is wrong? How can I know it? Isn't this too much for just 1 DRC violation?
o
Apologies, I won't be able to help you with this specific technical issue as I don't know enough. This is more of a question for @User .
j
@User did you use view-job-errors to open klayout?
it should open a window with the marker database
a
@User Hi Jeff, yes the picture of the layout I uploaded is using the view-job-errors command
fyi - i was hoping there was a image of the marker database window, but i don’t see it
do you see it? if so, you can expand the list of marker in the left pane and select them to view each error.
a
@User I have reexecuted, how does the marker should look like? because I see the same
I think I know what you are referring by the marker, but it marks all in red, let me take a screenshot:
@User
j
@User you have the same issue I just commented on for @User
your LI density is too high. we recommend replacing the decap_12 cell with a modified version
add the following to your
config.tcl
for each macro
set ::env(DECAP_CELL) "sky130_ef_sc_hd__decap_12 sky130_fd_sc_hd__decap_3 sky130_fd_sc_hd__decap_4 sky130_fd_sc_hd__decap_6 sky130_fd_sc_hd__decap_8"
reharden your macro, then rerun precheck and tapeout
r
At least one of the macros crashes (We are checking the other macros, but are slower to complete the workflow) at step index 24. This is the error:
[INFO DRT-0033] FR_MASTERSLICE shape region query size = 0.
[INFO DRT-0033] FR_VIA shape region query size = 0.
[INFO DRT-0033] li1 shape region query size = 134860.
[INFO DRT-0033] mcon shape region query size = 224226.
[INFO DRT-0033] met1 shape region query size = 41723.
[INFO DRT-0033] via shape region query size = 1750.
[INFO DRT-0033] met2 shape region query size = 1169.
[INFO DRT-0033] via2 shape region query size = 1400.
[INFO DRT-0033] met3 shape region query size = 1173.
[INFO DRT-0033] via3 shape region query size = 1400.
[INFO DRT-0033] met4 shape region query size = 360.
[INFO DRT-0033] via4 shape region query size = 0.
[INFO DRT-0033] met5 shape region query size = 1.
[INFO DRT-0165] Start pin access.
[ERROR DRT-0073] No ap for FILLER_100_110/VNB.
[ERROR DRT-0073] No ap for FILLER_101_115/VNB.
terminate called recursively
terminate called after throwing an instance of 'std::runtime_error'
[ERROR]: during executing: "openroad -exit /openlane/scripts/openroad/or_droute.tcl |& tee >&@stdout /project/openlane/chip_controller/runs/chip_controller/logs/routing/24-tritonRoute.log"
[ERROR]: Exit code: 1
[ERROR]: Last 10 lines:
child killed: SIGABRT
[ERROR]: Please check openroad  log file
[ERROR]: Dumping to /project/openlane/chip_controller/runs/chip_controller/error.log
the other two macros have crashed in the same way. So the three macros crashed with the same error
Here is as example one of the config.ctl that we use
@User is this working for you? have you done any extra thing to get working this?
m
@User Working on it… My laptop is a little bit slow 😁
j
@User can you please comment?
m
@User @User Same issue here…
@User Are you currently working on such issue? https://skywater-pdk.slack.com/archives/C02KCG2DZK7/p1636665995044400?thread_ts=1636641705.031800&amp;cid=C02KCG2DZK7 I asked because I saw you’re participating in this topic: https://github.com/google/skywater-pdk/issues/343
t
@User: Yes, I'm working on the issue, and am testing a solution right now. I have to re-work the open_pdks install to have magic generate all of the LEF views, because the original SkyWater (Cypress) LEF files have the incorrectly-defined multiple ports per pin, and those incorrect views ended up in the skywater-pdk repository.
m
@User That’s great. Is it going to be working before the submission deadline? Or is there a work around for now?
@User @User Any work arounds for the main issue (metal density) without changing the DECAP? Looks like the new DECAP provides some routing issues because of PDK’s related bugs 😢
a
@User I also hope there is a solution šŸ˜“