PLE - physical layout estimator 

Hi

Can some one can explain or send me a pointer to a document  what is PLE and how to use it.

Thanks
             Mattan

Hi Mattan, Please see the RC Synthesis Flows document, chapter 2, Physical Aware Flow: http://sourcelink.cadence.com/docs/files/Release_Info/Docs/rc_start/rc_start6.1.2/rc_startTOC.html

Thanks

But does this flow work only on RC61 ?

it works on rc52 but it is not as good as rc61.

li siang

One thing not covered in the documentation is whether it's particularly important to have a proper cap table if you already have the technology LEF. The docs say that the capacitance information can be derived from LEF, but that you can also provide a cap table. Unfortunately, there's no discussion of what QoR differences might be expected for the case of having vs. not having the cap table.

it depends on the p&r tool you used. If you use SOCE as p&r tool and it uses capTable then you will want to use the same capTable for RC. You will get better timing correlation.

li siang

Hi ,

I have 2 Questions

1) I didn't found any explanation how the RC compute the net length , does someone know ?
2) from Where I can download a CapTable file ?

Thanks
Mat

you can use command "generateCapTbl" to generate the capTable. You will need lef and ITF (interconnect technology file) from you foundry. I will let someone from Cadence to answer question #1.

li siang

Hi Mattan,

For you question (1), I think there is a swift in mindset in pre-layout synthesis not to care about net length. I am not R&D, but if you understand gain-base methodology (I think gain-base is public domain, and not patented. Anyone can correct me here?) The following is a short explanation on how this can be done:

1. From the .lib, we can calculate the delay of a cell if it is in an "average critical path" (e.g. the output load is 2.7 times of input cap. Sometime refer to ideal load, as it is related to the fastest way to drive a large load)
2. Using design constraint (e.g. SDC) and using the delay in (1), we can find out the paths that fail and paths that pass.
3. For paths that failed, we can make the cell faster (in layout term, it mean very short wire, and less fan-out), but there is a limit how fast the cell can be made faster, and how many cell can be made faster (in layout term, we can put some cells very close together, but we cannot put many cells close together). Those cells with delay shorter than (1) and is in the path with negative slack not now in "super critical path".
4. For paths that pass, we can make the cell slower by using slower architecture and lower drive strenght.

RC might use a totally different approach, but I just wish to point out that with this type of "timing budget process", you ready can don't care about the wireload/wire-length (see step 1-4 above that no wireload estimation is made).

By the way, I was told that even the application engineers have very little knowledge about LPE, so I think this wondering LPE method is kept a tight secret!

Regards,
Eng Han

Hi

I have two queries :
1) How can I calculate my scaling factors in RC so that my results can match with GPS?
2) Does anyone has tried PLE flow with DEF in RC? do it gives better co-relation with GPS database?

Regards,
Vikas

Hi Vikas,

By "GPS", do you mean the result from Encounter P&R?

I think the flow is the other way round. Encounter P&R flow requires the users to co-related the scaling factor between the cap-table and sign-off RC extractor (e.g. QX). The result of co-relation is the RC factor. It make sense to use the same RC factor in synthesis, if a re-synthesis is needed.

I think wire-load is not as useful as PLE. So just have to use it as there is no other choice... :>

Regards,
Eng Han

Hi Eng,

By GPS I meant, Only Placing the data and Not the routing part.

You are correct that RC factors should be calculated with QX spef but that is to corelate before and after route.

My question was, That I have a database which is timing clean in RTL compiler (Cadence Logical synthesis tool) but has violations when I place it using GPS(Cadence encounter), so can I use some RC scaling factors in Rtl compiler PLE flow so as to correlate my Timing results before placement and after placement.

Regards,
Vikas

Hi Vikas,

in the past we've had reasonable success using the path_adjust flow. In my mind, this is a better approach since, unless you truly have a global scaling problem, you will penalize all paths in the design to address only a handful that have correlation issues. Moreover, the path_adjust flow will gain you back some on the correlation issues where things are pessimistic in synthesis.

just my 2c.
gh-

Vikas,

     The way you deal with correlation between RC's PLE results and the physical timing really depends on the cause of the differences. Scale factors may be the right answer if there is a large difference between the lef/capTable data and the final QX numbers. This would be the case if you saw that statistically all the nets in the design were off by some percentage. It is also possible that the correlation may be due to some very long nets that are harder to predict during synthesis. These can be addressed in a number of different ways. You may want to use a path_adjust flow for these nets, or in some cases allow FE to fix them later. These would have to be dealt with on a case by case basis. I would strongly recommend that you spend some time understanding the root cause of these violations in order to devise a strategy to address them.

Hope this helps.

jflieder