https://open-source-silicon.dev logo
Channels
aa
abcc
activity
adiabatonauts
analog-design
announce
announcements
b2aws
b2aws-tutorial
bag
basebands
beagleboard
bluetooth
board-respin
cadence-genus
cadence-innovus
cadence-spectre
cadence-virtuoso
caravan
caravel
caravel-board
chilechipmakers
chip-yard
chipignite
chipignite2206q_stanford_bringup
chisel
coalition-for-digital-environmental-sustainability
community_denmark_dtu
containers
courses
design-review
design-services
dffram
digital-design
digital-electronics-learners
discord-mods
dynamic-power-estimation
efabless
electric
events
fasoc
fault
foss-asic-tools
fossee-iitb-esim
fossee-iitb-google-sky130
fpga
funding
fuserisc
general
generative-ai-silicon-challenge
genius-vlsi
gf180
gf180mcu
hardware-beginners
help-
ieee-sscs-cac-23
ieee-sscs-dc-21q3
ieee-sscs-dc-22
ieee-sscs-dc-23
ihp-sg13g2
images
infiniband
j-core
japan-region
junk
klayout
latam_vlsi
layouteditor
lvs
lvs-analysis
magic
magical
maker-projects
maker-zone
microwatt
mpw-2-silicon
mpw-one-clean-short
mpw-one-silicon
neuro-mem
nydesign
open_pdks
open-pdk
openadiabaticlogic
openfpga
openhighqualityresonators
openlane
openlane_cloudrunner
openlane-development
openocd
openpositarithmetic
openpower
openram
openroad
opentitan
osu
pa-test-chip
paracells
pd-openlane-and-sky130
picosoc
pll
popy_neel
power
private-shuttle
rad-lab-silicon
radio
rdircd
reram
researchers
rf-mmw-design
rios
riscv
sdram
serdes
shuttle
shuttle-precheck
shuttle-status
silicon-photonics
silicon-validation
silicon-validation-private
sky130
sky130-ci
sky130-pv-workshop
sky65
sky90
skywater
sram
stdcelllib
strive
swerv
system-verilog-learners
tapeout-job
tapeout-pakistan
team-awesome
timing-closure
toysram
travis-ci
uvm-learners
vendor-synopsys
venn
verification-be
verification-fe
verilog-learners
vh2v
vhdl
vhdl-learners
vliw
vlsi_verilog_using_opensource_eda
vlsi_verilog_using_opensoure_eda
vlsi-learners-group
vlsi101
waveform-viewers
xls
xschem
xyce
zettascale
Powered by
Title
p

proppy

02/14/2023, 1:29 AM
I noticed that there is already a 11K variant in the PDK packaged by open_pdks:
gf180mcuB
t

Tim Edwards

02/14/2023, 2:41 AM
I could recast
gf180mcuC
as having an 1.1um thick top metal, but since we taped out the first MPW run with a 0.9um thick top metal, it's better to leave that one as-is and just specify a new variant called
gf180mcuD
for the 5-metal stack with 1.1um thick top metal. It's trivial to do in open_pdks, which is designed to be configurable for any possible stack (at least the parts of the PDK that I wrote are configurable in that way).
p

proppy

02/14/2023, 4:02 AM
Cool! I can try to send the change for that :)
oh @jeffdi already created an issue for this here https://github.com/RTimothyEdwards/open_pdks/issues/342
a

Amro Tork

02/14/2023, 6:28 AM
@proppy we will need to add that to the DRC as well
We need a PR for that.
p

proppy

02/15/2023, 4:51 AM
@Amro Tork the techlef for the standard cell and the drc decks look similar.
I suspect we need to also update parasitics extraction for magic (@Tim Edwards?) and openrcx enablement (@Tom Spyrou?) to account for the new 11K variant.
We were musing with @mehdi if it should affect timing at all, since it seems that the top layer is mainly used for power delivery.
t

Tom Spyrou

02/15/2023, 6:28 AM
The top layer is a valid routing layer so unless disallowed in the router setup it can be used.
For power grid signoff the top layer needs to be extracted as well.
t

Tim Edwards

02/15/2023, 2:23 PM
@proppy: Typically, a standard cell layout of the complexity of a microcontroller, especially with components like multi-bit adders, multipliers, and barrel shifters, all of which are mostly combinatorial logic, will require four routing layers, two full layers (one vertical and one horizontal) over the whole layout area with no obstructions, and two additional layers (one vertical and one horizontal) for long trunk routes and to take up the overload when the lower layers get too congested. The upper two layers can overlap the power supply layers. That's not ideal, but it makes it possible to do routing with fewer layers. The sky130 process is pretty good for this: The standard cells are routed mainly with local interconnect, and point-to-point routes between neighboring cells can be done with local interconnect. There is room between the power rails for metal 1 routes, then metals 2 and 3 are completely free of obstructions, metal 4 overlaps with the lower power grid, and metal 5 can be used almost exclusively for the power grid. The GF180MCU with a 5 metal stack is harder, and it's made worse by the fact that most standard cell pins are completely blocked in by metal 1, so that point-to-point routes between neighboring cells have to go up to metal 2 and use up metal 2 resources. So metals 2 and 3 are free for routing (but more congested than usual because of the lack of metal 1 routes), but all the overflow will have to be done on metals 4 and 5, threading among the power supply straps. Therefore there is quite a lot of routing on these layers. Also, yes, the parasitics need to be updated for the 1.1um thick metal.