Multiple LEFs, no GDS, no RAMs?

[maliberty]

Why are there multiple tech LEFs

• prtech/techLEF/N551P6M.lef
• prtech/techLEF/N551P6M_ieda.lef

and multiple std cell LEFs, eg

• IP/STD_cell/ics55_LLSC_H7C_V1p10C100/ics55_LLSC_H7CR/lef/ics55_LLSC_H7CR.lef
• IP/STD_cell/ics55_LLSC_H7C_V1p10C100/ics55_LLSC_H7CR/lef/ics55_LLSC_H7CR_ant.lef
• IP/STD_cell/ics55_LLSC_H7C_V1p10C100/ics55_LLSC_H7CR/lef/ics55_LLSC_H7CR_ieda.lef

There is no GDS for any of the cells nor any RAMs. Are those planned?

Is there any recommended PDN structure or well tap rules?

[povik]

Let me also ask, the README lists a liberty folder for each standard cell set. These folders are not checked in at the moment. Is there a timeline for release of the .lib?

│   └── STD_cell                             # Standard cell library
│       └── ics55_LLSC_H7C_V1p10C100         # 55nm LLSC H7C standard cell library version 1.10
│           ├── ics55_LLSC_H7CH              # HVT standard cells

│           │   ├── liberty

│           ├── ics55_LLSC_H7CL              # LVT standard cells

│           │   ├── liberty

│           └── ics55_LLSC_H7CR              # RVT standard cells

│               ├── liberty

[povik]

Never mind, I think those might be getting populated by the make unzip step.

[myyerrol]

@povik Sorry for the late reply. Your mind is correct. Because the liberty files are very large, we tried managing them like the skywater repository, but it involved too many submodules, making management inconvenient. Using git lfs was limited by capacity and bandwidth constraints, so we hosted the large files in the release of repository. Users need to execute the make unzip command to download and decompress these large files.

[myyerrol]

@maliberty

1. Files with the _ant suffix are specifically optimized for antennas, those with the _ieda suffix are specifically for the iEDA tools, and those without a suffix are ordinary. Generally, only the LEF files without a suffix are needed.
2. Yes, this PDK release does not include GDS and RAMs. GDS data involves a lot of information, and it will not be provided to protect the fab. However, we plan to create a partial GDS to meet everyone's learning and usage needs in the future. We are currently in talks with manufacturers about collaborating on the Memory Compiler, which is expected to be released in the third quarter of next year.
3. We will update the documentation later.

[mole99]

Hi @myyerrol, thank you for your work.

OpenROAD supports reading .gz compressed versions of all supported file formats, see here: The-OpenROAD-Project/OpenROAD#2470
This way, the files don't need to be extracted to the hard disk, but only to RAM.
Maybe support for this could be added to iEDA as well?

It is unfortunate to hear that no real GDS data or spice models will be published. While it's a step up to have open access to the LEF/LIB/CDL/Verilog, I wouldn't call this PDK 'open source' compared to PDKs such as gf180mcu, sky130 and ihp-sg13g2.

[myyerrol]

Hi @myyerrol, thank you for your work.

OpenROAD supports reading .gz compressed versions of all supported file formats, see here: The-OpenROAD-Project/OpenROAD#2470 This way, the files don't need to be extracted to the hard disk, but only to RAM. Maybe support for this could be added to iEDA as well?

It is unfortunate to hear that no real GDS data or spice models will be published. While it's a step up to have open access to the LEF/LIB/CDL/Verilog, I wouldn't call this PDK 'open source' compared to PDKs such as gf180mcu, sky130 and ihp-sg13g2.

Your suggestions is excellent, I will forward this to iEDA team.

The initial release of PDK data does not include GDS data and spice models, ant these will be updated in the future. Rome wasn't built in a day, and we believe the data of 55nm PDK will become increasingly complete.

[maliberty]

"it will not be provided to protect the fab" is a different message than "these will be updated in the future". Please clarify.

[myyerrol]

This version of GDS is currently unavailable for public release, but we can discuss with fab to provide a risk-free GDS.