Timing analysis accuracy when MMMC definition file not given RC corner

[dirac16]

I want to configure my mmmc definition view file such that only a single mode single corner analysis to be defined. For the current design I have given only technology and standard cell LEF files. In the mmmc browser there is a section called RC corner in which a cap table is required to be filled in. I know what the purpose of this RC corner is but I am not sure as to what extent timing analysis among different phases pre-CTS and even post-CTS will be affected by when no RC corner specified in the mmmc file? Would Innovus extract RC values from technology files already given to it?

 

[ThisIsNotSam]

Innovus will do its best to extract "capacitance tables" from the information presented in the LEF file. It generally is a poor estimate and cannot be used for sign off. Evan capTable files are no longer recommended. The standard is to provide .qrc files to Innovus

 

[dirac16]

OK. I am using a particular LEF technology file from tsmc 65 nm process node. In the beginning it has written the following caution:

# The LEF technology files included in this directory contain resistance and
# capacitance (RC) values for the purpose of timing driven place & route.
# Please note that the RC values contained in this tech file were created using
# the worst case interconnect models from the foundry and assume a full metal
# route at every grid location on every metal layer, so the values are
# intentionally very conservative. It is assumed that this technology file will
# be used only as a starting point for creating initial timing driven place &
# route runs during the development of your own more accurate RC values,
# tailored to your specific place & route environment. AS A RESULT, TIMING
# NUMBERS DERIVED FROM THESE RC VALUES MAY BE SIGNIFICANTLY SLOWER THAN
# REALITY.
#
# The RC values used in the LEF technology file are to be used only for timing
# driven place & route. Due to accuracy limitations, please do not attempt to
# use this file for chip-level RC extraction in conjunction with your sign-off
# timing simulations. For chip-level extraction, please use a dedicated
# extraction tool such as HyperExtract, starRC or Fire & Ice QX, etc.

As stated above, timing numbers that will be derived from these RC values will be significantly slower than reality. So if I pass setup/hold slack time for these conservative RC values after post-routing optimization stage, then I will be 100% sure that the circuit will work under the given PVT condition. Is my understanding right?

 

[ThisIsNotSam]

For setup, I think so. For hold, being slower is actually hiding hold violations.

In either case, no sane engineer would do place and route with LEF only. This is a practice from 20+ years ago.

 

[dirac16]

For setup, I think so. For hold, being slower is actually hiding hold violations.

In either case, no sane engineer would do place and route with LEF only. This is a practice from 20+ years ago.

Yes it is true. So based on this LEF file given how can I develop my own precise RC values? I have not given any qrc files.

 

[ThisIsNotSam]

are you doing a real chip or just an academic experiment?

 

[dirac16]

This is

are you doing a real chip or just an academic experiment?

This is actually an academic work.

 

[ThisIsNotSam]

I would ask that you talk to whoever installed the PDK. TSMC usually provides these files even to academic researchers.

Otherwise, I don't have a good answer for you. You can pretend the logic is faster by issuing a derate factor of ~0.9 on all gates. But this is very artificial.

 

[dirac16]

I would ask that you talk to whoever installed the PDK. TSMC usually provides these files even to academic researchers.

Otherwise, I don't have a good answer for you. You can pretend the logic is faster by issuing a derate factor of ~0.9 on all gates. But this is very artificial.

Alright. But there is a command setExtractRCMode with an engine option that can be set to 'detailed'. Following this command ExtractRC can be called in each stage of ASIC flow prior to timing analysis. Does that help?

--- Updated Nov 15, 2021 ---

Oops, I just found a QRC table that was hidden in the PDKs! As it's proprietary I cannot share the file. It's reported both the QRC cap and QRC res for every structure. A structure can be like M1_0.11_0.55 which I do not know what's the meaning of this. Is it what a QRC file should look like? Sorry I'm very new to back-end ASC design.

 

[ThisIsNotSam]

don't worry about the setExtractRCMode. as your design progresses from placed to routed to optimized, the tools will internally set the correct RC extraction mode, starting from basic and then reaching sign-off quality.

about the qrc file, it should not be human readable. just provide it to Innovus via the mmmc file and see if it can be read properly.

 

[dirac16]

don't worry about the setExtractRCMode. as your design progresses from placed to routed to optimized, the tools will internally set the correct RC extraction mode, starting from basic and then reaching sign-off quality.

about the qrc file, it should not be human readable. just provide it to Innovus via the mmmc file and see if it can be read properly.

Thank you. I have just added a qrc file I found for 1p6m_4X1Z0U in my mmmc file. I imported the design and got no errors. But like captables which are defined for specific conditions, should a qrc file be defined for a specific condition too? The qrc file I found had no condition specified, so I am not sure if I have found the right qrc file.

 

[ThisIsNotSam]

Typically there is a handful of variants. They are named typicalRC, bestRC, worstRC. Sometimes you have combinations too, like bestRworstC.