https://open-source-silicon.dev logo
Join Slack
Powered by
<@U01634FSETZ> <@U016HSALFAN> I can't seem to get ...
# openlane
m
@User @User I can't seem to get power to my pre-hardened macros when building 
user_project_wrapper
. I've pushed all of the updates to my repo that @User was helping me with (https://github.com/SweeperAA/caravel_skywater130_decred_miner). I have tried to flow 
user_project_wrapper
with 
mpw-one-a
and 
mpw-one-b
openlane and pdks and it always results in the following LVS errors: 
vssd1.extra66                              |vssd1 **Mismatch**
vccd1.extra69                              |vccd1 **Mismatch**
The mpw prechecker confirms this by failing the consistency check saying a macro isn't powered. And a picture of the 
user_project_wrapper
GDS below. Could someone take a look at the configuration scripts in my repo and let me know what I'm doing wrong. For reference, I use 
make user_project_wrapper
to execute the flow.
d
I didn't spot the recent 
CONNECT_GRID
changes in your wrapper power config unless it isn't pushed? example repo: https://github.com/mattvenn/caravel-mph/blob/release/openlane/user_project_wrapper/pdn.tcl#L30
I had power problems until that was added and configured properly
m
I'll try that.
@drr What exactly do I need to add to my config? My pdn.tcl is pretty different than the link you posted.
d
the interactive.tcl seems to call that pdn.tcl for each power domain here: https://github.com/mattvenn/caravel-mph/blob/release/openlane/user_project_wrapper/interactive.tcl#L48 but it only takes effect for the first power domain by unsetting 
CONNECT_GRID
after the first call
m
So are you saying that I already have what's in the referenced repo?
If I add the 
if { $::env(CONNECT_GRIDS) } {
statement I start getting syntax errors during the flow.
Also, do you have a picture of what the GDS should look like if the macro is powered?
d
So are you saying that I already have what's in the referenced repo?
I mean that config looks different, but the equivalent call to the pdn gen seems to be that I am still figuring out how the PDN config works so take this with a grain of salt. I'm not sure if the 
_WITH_STRAPS
config is meant to prevent this problem, I don't have that in my configs. Might be best to confirm with whoever wrote the original config that this is based on
here's what I had after fixing the LVS problems with power. VPWR/VGND are no longer shorted and only the 1 desired power domain is actually connected.
that view is the left side of my user proj, within the wrapper. All layers off except met4/5/vias/met4 label to see "VPWR"/GND
m
Double checking again, but do pre-hardened macros need the power pins specified? As in: 
module decred_hash_macro (
``ifdef USE_POWER_PINS` 
inout vdda1,	// User area 1 3.3V supply
inout vdda2,	// User area 2 3.3V supply
inout vssa1,	// User area 1 analog ground
inout vssa2,	// User area 2 analog ground
inout vccd1,	// User area 1 1.8V supply
inout vccd2,	// User area 2 1.8v supply
inout vssd1,	// User area 1 digital ground
inout vssd2,	// User area 2 digital ground
``endif` One of my macros has this, and one of them doesn't. Besides being a bad inconsistency, are these pins required in the macros?
t
There was no `CONNECT_GRI' because it was using my twekaed pdn script that only generate straps from one of the rails.
And the macros need the above if and only if you use the 
mpw-one-b
way of doing things (with no interactive.tcl) although even then you really need only 
vccd1
and 
vssd11
AFAIU. If you use the older way then you need the name guarded block but with 
VPWR
and 
VGND
.
Did you try the LEF thing ?
m
@tnt I didn't go down the path of editing the LEF for two reasons: 1.) I was concerned that manual steps in this flow process would not be accepted as that's not what the tools do. 2.) I don't know how to do this or what it is intending to do. I'm looking at the lef now for one of my macros (controller) and there's two VPWR pins and one VGND pin. The VPWR pin has two 
RECT
in layer `met4`: 
RECT 174.640 10.640 176.240 187.920 ;
RECT 21.040 10.640 22.640 187.920 ;
The VGND pin has one 
RECT
in layer `met4`: 
RECT 97.840 10.640 99.440 187.920 ;
What is it exactly that I am trying to accomplish here and for what reason?
t
Just quick disclaimer first: This is just my understanding of things, I might be wrong, this is my first ASIC too, so I'm just figuring things out. Now my understanding is that because of a limitation / bug in OpenDB, there was some sort of work around put in place so that the multiple vertical stripes are exported by repeating the 
PIN
multiple times in the LEF rather than having the pin having multiple 
RECT
(which would be the "correct way"). Now AFAICS, this seems to create those 
.extraNNN
notations and I suspect this is what screws with LVS. So what I'm proposing is to fix the LEF into what it should be in the first place and define the 
PIN
with multiple metal shapes as a single pin meaning hopefully all those will have the same net name 
VPWR
and not 
VPWR.extraNNN
.
m
What do you think is my best course of action at this point? Should I wait and try to get @Amr Gouhar and @Ahmed Ghazy help on this or attempt to go down your path of editing the lef files?
And by the way, my other macro has 8 VPWR and 8 VGND pins....
t
If it looks good in the GDS ... I wouldn't sweat it too much.
m
The GDS looks like the picture I posted in this thread - I don't think it looks good, but correct me if I'm wrong. Also, the prechecker is failing the consistency check that the macros are not powered.
a
@Ahmed Ghazy: Can you help out here, because I'm not sure what's the cleanest course of action is? ^
m
For reference, I added the power pins to 
decred_hash_macro
and reflowed 
user_project_wrapper
and my DRCs jumped from 0 to 48, so I'm backing out the 
decred_hash_macro
changes now. 
Metal5 spacing < 1.6um (met5.2)
Metal2 width < 0.14um (met2.1)
@Ahmed Ghazy @Amr Gouhar I can be available to work on this just about any time with some notice. Here is the current state: I have pushed changes so that all macros are built under 
mpw-one-b
openlane, pdks, etc. I also changed all of the 
user_project_wrapper
scripts to go to 
mpw-one-b
default/recommended approach as specified by the 
mpw-one-b
caravel
. The macros themselves have 0 DRC 0 LVS errors. 
user_project_wrapper
now has 100 DRCs and 9 LVS errors. 
user_project_wrapper
also finishes the 64th iteration of detailed routing with 20 violations still. There is no reason there should be any routing problems, there's plenty of space. Running the precheck on this (after 
make ship
) results in 
Consistency Checks Failed+ Reason: Instance decred_hash_macro was not connected to any power in ...
and 75 DRCs. The 
user_project_wrapper
reported DRCs are: 
Violation Message "Metal4 > 3um spacing to unrelated m4 < 0.4um (met4.5b) "found 8 Times.
Violation Message "Metal2 spacing < 0.14um (met2.2) "found 8 Times.
Violation Message "Metal5 spacing < 1.6um (met5.2) "found 78 Times.
Violation Message "Metal2 width < 0.14um (met2.1) "found 6 Times.
The 
user_project_wrapper
reported LVS violations are: 
Subcircuit summary:
Circuit 1: user_project_wrapper            |Circuit 2: user_project_wrapper
-------------------------------------------|-------------------------------------------
decred_hash_macro (4)                      |decred_hash_macro (4)
decred_controller (1)                      |decred_controller (1)
Number of devices: 5                       |Number of devices: 5
Number of nets: 85 **Mismatch**            |Number of nets: 77 **Mismatch**
---------------------------------------------------------------------------------------
NET mismatches: Class fragments follow (with fanout counts):
Circuit 1: user_project_wrapper            |Circuit 2: user_project_wrapper
---------------------------------------------------------------------------------------
Net: decred_hash_block0/VPWR               |Net: vssd1
decred_hash_macro/VPWR = 1               |  decred_controller/VGND = 1
|  decred_hash_macro/VGND = 4
|
Net: decred_hash_block0/VGND               |Net: vccd1
decred_hash_macro/VGND = 1               |  decred_controller/VPWR = 1
|  decred_hash_macro/VPWR = 4
|
Net: decred_hash_block1/VPWR               |(no matching net)
decred_hash_macro/VPWR = 1               |
|
Net: decred_hash_block2/VPWR               |(no matching net)
decred_hash_macro/VPWR = 1               |
|
Net: decred_hash_block3/VPWR               |(no matching net)
decred_hash_macro/VPWR = 1               |
|
Net: decred_hash_block1/VGND               |(no matching net)
decred_hash_macro/VGND = 1               |
|
Net: decred_hash_block2/VGND               |(no matching net)
decred_hash_macro/VGND = 1               |
|
Net: decred_hash_block3/VGND               |(no matching net)
decred_hash_macro/VGND = 1               |
|
Net: decred_controller_block/VPWR          |(no matching net)
decred_controller/VPWR = 1               |
|
Net: decred_controller_block/VGND          |(no matching net)
decred_controller/VGND = 1               |
---------------------------------------------------------------------------------------
Netlists do not match.
Netlists do not match.
a
@Matt Aamold: can we zoom in like 30 minutes (with @Ahmed Ghazy as well)?
m
@Amr Gouhar Yes, I can. I've resolved the detailed routing violations. Hopefully will have those pushed by that time.
@Amr Gouhar Latest updates to address detailed routing violations have been pushed (0 violations at 64th detailed routing iteration). The 
user_project_wrapper
now results in 63 DRCs and 9 LVS errors. The new mpw precheck results in: 
Consistency Checks Failed+ Reason: Instance decred_hash_macro was not connected to any power in ...
DRC Checks on MAG Failed, Reason: Total # of DRC violations is 87
user_project_wrapper DRCs: 
Violation Message "Metal4 > 3um spacing to unrelated m4 < 0.4um (met4.5b) "found 11 Times.
Violation Message "Metal2 spacing < 0.14um (met2.2) "found 14 Times.
Violation Message "Metal5 spacing < 1.6um (met5.2) "found 38 Times.
Total Magic DRC violations is 63
user_project_wrapper LVS: Same as previous post.
2 Views
Open in Slack
PreviousNext
Powered by