https://open-source-silicon.dev logo
Join Slack
Powered by
<@U016EM8L91B> attempting to abstract `user_projec...
# magic
m
@Tim Edwards attempting to abstract 
user_project_wrapper
and extract as a black box with only pins. Merely adding the property 
LEFview
true yields an 
ext
file with the 
abstract
property, so that the extracted netlist contains no cells, but the 
ext
file still contains 
use
statements that cause the hierarchical extraction and inclusion of orphaned cells in the extracted netlist. With designs containing hundreds of thousands of instances, the abstract extraction can take hours. I attempted to create the 
LEFview
after removing all the instances in a block, and this was faster - just under an hour. However, shorts between pins were still extracted as 
merge
statements in the 
ext
file that don’t appear as zero ohm resistors in the extracted layout spice but seem to affect the hierarchical connectivity. Tried to use 
lef write -hide -pinonly
to create a lef view with only pins. This does create a lef file, but even though I can read in the lef file, I can not write it as a mag file with port information and it also does not extract aa a black box.
Copy code
magic
tech sky130B
timestamp 1712474934
<< properties >>
string FIXED_BBOX 0 0 292000 352000
string LEFview true
<< end >>
Is there a command to write a lef file as a mag file containing pin definitions (and obstructions)?
@Tim Edwards Looking at the maglef generator in 
open_pdks/common/foundry_install.py
, and it doesn’t look straight forward.
Ok, sorry for the misdirection. Looks like 
lef write
will create a file that has pins and obstruction, but can only be read with 
lef read
if the cell does not exist. (edited for clarity). It appears that 
flush
removes all the data leaving an empty but existing cell that will not be overwritten. I don’t think 
cellname delete <cell>
will work, because there is still an instance.
My confusion came from the lef manual page.
Copy code
write [cell] [-tech] [-hide [distance]] [-toplayer] [-pinonly [distance]] [-nomaster]
  Write LEF for the current or indicated cell.
lef write
creates a lef file for the currently loaded 
cell
. The default output file name is 
cell
.lef and the lef macro name is 
cell
. 
lef write differentName
creates a lef file for the the currently loaded 
cell
, with the output file name of 
differentName
.lef. The name of the macro in the lef file will be 
differentName
 
cell
. (corrected) It does not create the lef file from 
differentName
.
@Tim Edwards I implemented a solution that requires two magic executions. One to create a lef representation and one to actually extract. I couldn’t figure out how to read the lef file to replace the original in a single exectuion. • First execution: abstract cells by deleting all the instances and running a 
lef write
on the result. Without deleting instances, 
lef write
doesn’t complete when there are many (700000+) instances. Deleting instances can still take a long time (90min for 900000+). If there’s a better solution (deleting all the instances at once without selecting them individually first), please let me know. • Second execution: read the lef definitions first, and then gds. The lef definitions will have precedence. However, this solution still does not resolve the problems with shorted pins in the abstracted cells. It appears that 
lef write
does connectivity extraction and shorts pins. Ports for different shorted pins overlap in the lef file which extracts as a short without a 0 ohm resistor. Since lef does not contain an original pin location, it’s impossible to tell which is the actual port. On the other hand, the extraction setup I’m using for LVS extraction, adds a zero ohm resistor between shorted ports. For example, the lef file produced contains pin definitions that have coincident ports. (2 shown as an example).
Copy code
PIN io_out[15]
    PORT
      LAYER met2 ;
        RECT 2635.750 3519.900 2636.310 3524.800 ; io_oeb[15]
        RECT 2717.170 3517.600 2717.730 3524.800 ;
      LAYER met3 ;
        RECT 2919.900 3485.420 2924.800 3486.620 ; io_oeb[14]
        RECT 2919.900 3418.780 2924.800 3419.980 ;
        RECT 2919.900 3219.540 2924.800 3220.740 ;
        RECT 2919.900 3153.580 2924.800 3154.780 ;
        RECT 2919.900 2954.340 2924.800 2955.540 ;
        RECT 2919.900 2887.700 2924.800 2888.900 ;
        RECT 2919.900 2688.460 2924.800 2689.660 ;
        RECT 2919.900 2621.820 2924.800 2623.020 ;
        RECT 2919.900 2422.580 2924.800 2423.780 ;
        RECT 2919.900 2356.620 2924.800 2357.820 ;
        RECT 2919.900 2157.380 2924.800 2158.580 ;
        RECT 2919.900 2090.740 2924.800 2091.940 ;
        RECT 2919.900 1891.500 2924.800 1892.700 ;
        RECT 2919.900 1824.860 2924.800 1826.060 ;
        RECT 2919.900 1625.620 2924.800 1626.820 ;
        RECT 2919.900 1559.660 2924.800 1560.860 ;
        RECT 2919.900 1360.420 2924.800 1361.620 ;
        RECT 2919.900 1293.780 2924.800 1294.980 ;
        RECT -4.800 1204.700 0.100 1205.900 ;
        RECT -4.800 943.580 0.100 944.780 ;
        RECT 2919.900 762.700 2924.800 763.900 ;
        RECT 2919.900 696.060 2924.800 697.260 ;
        RECT -4.800 683.140 0.100 684.340 ;
        RECT 2919.900 563.460 2924.800 564.660 ;
        RECT 2919.900 496.820 2924.800 498.020 ;
        RECT -4.800 422.700 0.100 423.900 ;
        RECT 2919.900 364.220 2924.800 365.420 ;
        RECT 2919.900 297.580 2924.800 298.780 ;
        RECT -4.800 226.860 0.100 228.060 ;
        RECT 2919.900 164.980 2924.800 166.180 ;
        RECT 2919.900 98.340 2924.800 99.540 ;
    END
Copy code
PIN io_oeb[15]
    PORT
      LAYER met2 ;
        RECT 2635.750 3517.600 2636.310 3524.800 ;
    END
Copy code
PIN io_oeb[14]
    PORT
      LAYER met3 ;
        RECT 2917.600 3485.420 2924.800 3486.620 ;
    END
I’m thinking that the ideal solution would be to not short pins during lef creation.
t
@Mitch Bailey: One possibility that comes to mind: Magic is very fast at flattening layouts, even large ones. Try flattening the cell first and then create a LEF of the flattened cell, with "-hide".
Are you using 
ext2spice blackbox on
?
m
@Tim Edwards thanks for the suggestion. That may speed things up. I don’t think that will solve the short problem though. I don’t think the 
ext2spice blackbox on
option is set. I’ll check.
t
But the ultimate solution here is probably to implement a special property, e.g., "noextract", which can be dropped in a cell and force magic to ignore it during extraction (although that might already be accomplished by adding the property "device", which treats the cell as a low-level device).
m
I’ll try 
device
and 
blackbox
although 
blackbox
may not make a difference. Currently an empty subcircuit is extracted. I think the problem is that the 
ext
file have the shorts defined as 
merge
statements.
@Tim Edwards • Flattening the cell was faster than removing all the instances. However, trying to create the LEF with 
-hide 10
is still going after 6 hours. • The documentation for the 
device
property states that there are 2 cases. If the string starts with 
primitive
I think the ports will be extracted. If it doesn’t the ports have to be enumerated. I’ll try 
primitive
.
t
The problem is that an accurate LEF file needs to record the gate and diffusion area on every net connected to a pin, which means isolating every pin-connected net and running that computation. You could get away with something simpler by deleting everything in the center of the layout. That risks having inaccurate antenna information as a tradeoff for faster processing.
m
The problem is that an accurate LEF file needs to record the gate and diffusion area on every net connected to a pin, which means isolating every pin-connected net and running that computation.
Ouch. The memory size for the lef computation was at 26GB. Maybe lef isn’t the way to go. Tried 
property device primitive
and 
property LEFview true
, verified that the 
ext
file contains the 
abstract
and 
primitive
lines, but magic still extracts the sub-hierarchies. Maybe those are just netlist directives. I’ll check if there’s a difference - I’m pretty sure 
abstract
will short ports, maybe 
primitive
will ignore merge statements. So still looking for a way to extract just the ports in a layout. ahh. 
primitive
won’t work as a generic way to abstract blocks. Looking into a way to programmatically remove everything except the ports in abstract cells.
t
Seems like what you might want is an option to 
lef write
that does not output gate and diffusion areas, and so does not have to spend the time checking for them. If that part of the procedure is ignored, then writing LEF is very fast.
m
I think I have a solution kludged together. However, writing lef is dropping ports. I’m trying to write the lef for 
user_project_analog_wrapper
where the 
io_analog
signals have pins on the metal3, metal4, and metal5 layers, but lef only writes to one layer.
Copy code
PIN io_analog[6]
    PORT
      LAYER met3 ;
        RECT 879.470 3511.500 904.470 3524.000 ;
    END
    PORT
      LAYER met3 ;
        RECT 827.970 3511.500 852.970 3524.000 ;
    END
  END io_analog[6]
  PIN io_analog[5]
    PORT
      LAYER met3 ;
        RECT 1086.470 3511.500 1111.470 3524.000 ;
    END
    PORT
      LAYER met3 ;
        RECT 1137.970 3511.500 1162.970 3524.000 ;
    END
  END io_analog[5]
In order to just write ports, I delete all layers that don’t have ports. The selected port list only shows one layer though.
Copy code
% select area metal5 
% what
Selected mask layers:
    metal5   ( ota_0  Topmost cell in the window )
Selected label(s):
    "io_analog[4]" is attached to metal4 in cell def IS_user_analog_project_wrapper (2 instances)
    "io_analog[5]" is attached to metal4 in cell def IS_user_analog_project_wrapper (2 instances)
    "io_analog[6]" is attached to metal4 in cell def IS_user_analog_project_wrapper (2 instances)
Here the metal5 text is selected, but shown in 
what
as metal4 text.
@Tim Edwards this may have something to do with the 
-pinonly
option (just a guess). I’ll look for a open source example and create an issue.
When I 
lef write
on the original data, all the layers show up with the ports. 🤔
ahh. I was flattening with 
-dotoplabels
which before lef write. Maybe some of the labels weren’t getting copied.
4 Views
Open in Slack
PreviousNext
Powered by