PLE - physical layout estimator

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