https://open-source-silicon.dev logo
Join Slack
Powered by
Hello everyone, does the Magic version which is no...
# magic
e
Hello everyone, does the Magic version which is now used in the updates Mpw9f shuttle precheck have updated DRC rules? We were previously getting no DRC errors during the Magic DRC stage of the precheck, and now over 1000 have appeared!
m
@Ellen Wood what errors are you seeing?
e
All of these!
Previously I fixed them all including the Deep N Well one on your advice and last night got the precheck totally DRC clean (but on the MPW9e version). I've never seen any Magic DRC errors appear on MPW9e check (and in our local version of Magic, DRC style (full) also shows no errors). What version of Magic is the precheck using now? I will update our local one and hopefully these will appear?
m
I believe you can find the magic version and the PDK commit in 
precheck_results/<tag>/logs/precheck.log
. If you have the previous version, you might try diff?
👍 1
e
I'm not actually in the office today but tomorrow I will freshly install a new caravel_user_project repo with the correct tag and correct precheck, and update our local Magic to the precheck one, and then work through all of these. They don't look too difficult, it's just so strange they have only just appeared. Our local magic/local precheck version was very recent!
👍 1
t
@Ellen Wood: I think it's likely that you are looking at results from the DRC style 
drc style drc(full)
. The DRC decks in magic are split into simple 
drc style drc(fast)
and full, because the DRC is interactive, and the full DRC deck can be a huge processing load when working with a large layout. So the "fast" style is used by default. It checks all the basic rules but is missing some of the more computationally expensive rules.
e
Hi @Tim Edwards - yes you're right, it was the DRC style that was hiding the errors in my local Magic where I've been working. What is more strange (and worrying) is that my local shuttle pre-check has showed 0 Magic DRC errors throughout. I've just cloned a brand new 
mpw-9f
repo, ran 
make setup
and 
make precheck
, and my local pre-check is still showing 0 Magic DRC's (even though I can now see them in my design)
message has been deleted
I'm not sure whether I can trust anything else this pre-check is saying now 😬
I only found out about them because they showed up on @Paweł Sitarz pre-check. He's sharing the area and integrating all of the designs. This was from his pre-check which he sent me:
m
@Ellen Wood can you check your magic drc log? It may be that magic is failing and that is leaving an incomplete report with “no errors”. If that’s the case, we need to fix that quickly. Thanks for bringing it to our attention. The precheck log should give the magic version and open pdks version.
e
Will check this for you as soon as possible :)
Here's the log - looks like there's a few problems in there?
m
@Ellen Wood This is bad. As you can see drc was not run. The problem is that it’s looking for 
sky130A.tech
in 
sky130B
pdk. I’ll log an issue. Thanks for the report!
👍 1
e
I think @Paweł Sitarz’s check was probably working because he was using the 
sky130A
pdk?
Our design is 
sky130B
- would that be causing the error?
m
Exactly!
e
🙂 One more question... when I was building 
user_project_wrapper
with Openlane, should this step have failed too?
message has been deleted
There were >1000 DRCs in the GDS we gave it
(I thought I had checked 
drc(full)
and got 0 errors, but I hadn't run '`drc check/update`' nor waited for all the drcs to load in the large design!)
m
Can you share 
30-drc.log
too?
e
It weirdly looks like its found 1200 errors, but hasn't reported them in the flow
m
@Ellen Wood Can share 
user_project_wrapper/openlane-signoff/drc.tr
? Looks like it’s trying to count the number of 
violations
from that file.
e
Hi @Mitch Bailey, I can see a drc.tr file in 
user_project_wrapper/runs../reports/signoff
, however its empty (0 bytes) and nothing in it when I try to open it
m
So 
drc.rpt
has errors but 
<http://drc.tr|drc.tr>
does not?
e
Thats correct
Here's the 
drc.rpt
m
@Ellen Wood thanks for bring this up. I believe I’ve found the problem (and it could be affecting all designs since April!). Can you create an issue on the Openlane repo with your data?
👍 1
e
Will do. 🙂 I am trying to switch over from Sky130B to Sky130A. I ran 
export PDK=sky130A
, and re-ran 
make setup
etc. Now trying to rebuild my TOP_digital macro using Openlane, but its still creating a .mag file with cells read from the sky130B pdk directory. Is there any way to tell Openlane which PDK to use?
message has been deleted
message has been deleted
t
Generally, the only places Openlane gets "sky130A" from is the 
$PDK
variable. However, there will be occurrences in every 
.mag
file, and potentially may be in setup files like 
.magicrc
if they were copied from the PDK into the working directory.
The quickest thing to do is to set 
$PDK
. To get all 
.mag
files updated quickly, start magic with 
sky130A.magicrc
for the startup file, and then do 
load <top_cell> -force
to load the sky130B design into the sky130A technology, and do 
writeall force
to rewrite all the files out with 
sky130A
as the technology.
e
Thanks Tim - I had forgotten to update the 
$PDK
in the .bashrc! Will re-write the files now.
5 Views
Open in Slack
PreviousNext
Powered by