Which std. lib we use for synthesis: worst, typ or best?

Status
Not open for further replies.

Alosevskoy

Member level 3
Joined
Oct 11, 2011
Messages
55
Helped
19
Reputation
38
Reaction score
19
Trophy points
1,288
Location
Zelenograd (Moscow)
Activity points
1,634
So,
As I understand whichever of the characterized libraries we use the synthesizer (in my case Cadence RC) gives us the same netlist. After that we run STA analysis with worst case stdlib to check setup time violations and best case to check hold time... Please, correct me if I'm wrong. My attemp to find some info in the Internet was failed.

I would be thankful for any advice!
 

ya you are correct..we use worst case libraries for setup time checks and best case libraries for hold time checks
 

The worst library is usually used during the synthesis phase to meet the setup requirement.

During the PR, in the "basic" mode, you define the worst library set to check the setup and the best library set to check the hold time. Now the tool have the MMMC feature, means MultiMode-MultiCorner. You could indicate which multiple library sets to check the setup and multiple library set to check the hold time. the same library set could be used for setup & hold time.

At STA phase, the setup & hold must be check in all corner worst/best, and it's better with also the three parasitics extraction (worst-typical-best) and also si/no si mode. Then if you have three timing library (worst,typical,best), you will check the setup & hold in 3*3*2=18 cases.
 
Hi,

You are correct. we use the worst case libs (max delay) for setup checksn and best case libs (min delay) for hold checks, because setup violations are caused due to slow data paths or fast clock paths and hold are caused due to fast data and slow clock paths.

If you set your operating condition to bc_wc (synopsys tools), the above description works

But we also have the feature of on_chip_variation, where we use max_delays for data paths and min_delays for clock path during the setup check and mnin_delays for data path and max delays for clock path during hold check, allowing more pessimism.

regards,
charan.:-D
 
Thanks for replies!
One more question has come up
As I mentioned in the head post worst, best and typical libraries give us the same netlist; worst lib helps to check setup time violations, best - hold times... so the question is... wherefore does typical lib exist? As I see we can always use worst case lib during synthesis, because nothing can be bad than this case.
 

The chip will work at the typical corner, the worst/best are here to check the chip at the limits without expected to work at this limits.
So the typical is used to check the max freq for the typical usage (as example).

---------- Post added at 15:14 ---------- Previous post was at 15:13 ----------

you could also generate the SDF for the typical to execute a power simulation...
 

rca, You mean I can use SDF for synthesized netlist simulation to get swithing activity info for power analysis?
 
You are right. We need worst .lib to do for synthesis. Typically power numbers we quote to customer are typical in that case we will need typical .lib
 


Hi all,

Do we get the same netlist for different libraries (worst/best/typical) after synthesis?
How can it be?

For one particular path, it uses more worst case cells compared to best/typical case cells.
If this is the case, hw can we get same netlist?

regards,
Subhash C
 

Netlist will be same, The sdf which gives the delays will be different.
 


Logic implementation will also change depending upon the delays & frequency of operation => netlist has to change, right?
 

Design is same for every .lib You need to meet all with the same Design
 

Hm... Parasitic extractions and timing libraries... Don't RC-extractions (lets say SDF) include internal timing of cells? What does it mean "timing library"? Timing of cells depends on the loads, etc... Is all this info taken from RC-extraction?
Why for example best timing lib be run with worst RC-extraction? How could it happen in a real world?
 

Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…