Parasitic Extraction for new PDK

[sebinho]

Hi Guys and @maliberty ,

As I already mentioned on other discussion threads, I am trying to integrate a new PDK with OpenROAD/SiliconCompiler.
Most of the issues have been solved, I have a clean LVS and DRC setup.
But for the time being I have been using dummy PEX files taken from Sky130. This is the last piece of the puzzle to have the full stack up and running.

I am now in the process of generating the extraction rules for my PDK. I am trying to follow the steps described here:
https://openroad.readthedocs.io/en/latest/main/src/rcx/doc/calibration.html

Step A was easy and is successful, to generate a *.def and *.v after loading the technology LEF file.
Step B was also successful (as far as I can tell). We did use our own external tool to generate the patterns in *.spef format.

But I am unable to get the next steps to work properly. The log file is in attachment.
log.txt

Actually I am also unable to make the same flow to work using Sky130. What I did is the following.
Go into the folder OpenROAD/src/rcx/calibration/ and run run.sh.
The only thing I had to change is the location of the golden *.spef file. I am not sure which file to use, as the referenced file generate_pattern.spefok is missing. I tried to recover it from the archived openRCX github repo but I get similar errors. See log in attachment.
log_sky130.txt

I wanted to get the Sky130 example up and running to have a reference to compare to, but it seems to be broken or maybe I am missing something.
But logs are quite similar.

Could someone give me some clues on what to look for? Thanks a lot

[sebinho]

What I have noticed when diving into the DEF and SPEF files is the following.

• The tool creates a lot of simple nets with 2 pins: an output pin named XXXX and an input pin named XXXX_BL. This can be seen inside the DEF file (generated by the rcx tool).
• Once we look into the SPEF file generated, it seems that the tool removes all the XXXX_BL pins.

This seems to be related to the fact that during LVS, because the two pins are connected via a net with zero resistance, it sees a short and removes half the labels. As a consequence a lot seems to be removed when generating the SPEF file.
Not sure this helps.

One side note that might be related, the SPEF file we generate with our own tool does not contain any *RES section at all. Probably related somehow.

[maliberty]

There shouldn't be zero resistance for a non-zero length wire. Not having a *RES section will be a problem. It sounds like an issue with your golden tool.

[sebinho]

indeed, this is what we are looking into at the moment. We have to tell our tool what resistance to use for the wires. I suppose this is custom and will depend on which tool is used (case per case basis).

[sebinho]

We were able to sort it out using our golden tools. We now have correct rules for all corners.
Thanks for your help @maliberty

[sebinho]

Not sure if this makes sense, but maybe it could help other people in the future to have a reference generate_pattern.spefok for sky130 that runs properly with run.sh?
Just a side thought.

[maliberty]

That file is generate the output of a proprietary signoff tool and so can't be made public. I'm glad you've solved your issue.

[mkhaliq12]

Hi, I'm kinda facing a similar problem. Could you help me regarding the spef file generation. Which tool are you using to generate the file, I am trying to configure a pdk with the flow and was trying to generate the .rules files. Also, maybe I am mistaken but this tool does not ask for the .lib files, especially as they are the only ones which are corner specific.