Stats

  • Locked Locked
  • Replies 7
  • Subscribers 62
  • Views 19217
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

LEF in synthesis flow

diablo

Hi,

In RTL compiler synthesis flow, i have

set_attribute interconnect_mode ple /

And, i have inlcuded the cap table as well

set_attribute cap_table_file {$CAP_TABLE/bst.cap } 

Do i need to include the LEF library for std cells and io cells as well for correct interconnect delay estimation even after including cap table?

It seems including LEF file gives significant difference in total number of cells and area after synthesis as reported from RTL compiler. Below is the snippet of area report for two flow, 

one excluding LEF

 Cells       Cell Area       Net Area

 23283       715947       391632

and the other including LEF file 

Cells       Cell Area       Net Area

 22664       967042       246572

 Which one is correct flow? Or, which one is the better flow?

Thanks for your suggestions and your time.

Regards. 

  •  Hi diablo,

     likely case is you are missing some LEF models for your memories. By default RC will zero macros that do not have corresponding LEF info. Indeed you always need your LEF models for cells, process, etc. The reason is the capTbl does not include any of that information. capTbl strictly has process information so it is more detailed in that respect but still missing plenty of information. As per recommended flow, you should certainly read in all LEFs as well as the capTbl. Setting the mode to PLE is not required since reading any LEF or capTbl will make RC default to PLE which is indeed the recommended mode. Here are some articles from http://support.cadence.com that may be of interest to you

     

    87%
    How is cell area picked in RC-PLE flow?

     

    During optimization with PLE mode does RC use the lib area or lef area? Also is there a way to force RC to use the LEF area? Using the LEF area is supported in 7.1 and is default in this version.
    Show Attributes

    10-27-2009
    84%
    RC PLE: Cell area for macros is shown as zero. Why?

     

    Shouldn't the area be taken from .lib in absence of LEF information? As per the current behavior, if physical information or LEF for some macros are missing then their area will be shown as 0. The area of 0 is expected when LEF for the corresponding macros have not been read in.
    Show Attributes

    10-01-2008
    73%
    What can go wrong if the cell areas in Liberty library are different from LEF?

     

    Problem: What can go wrong if the cell areas in Liberty library are different from LEF? Solution: RC uses the area numbers from the LEF files when the LEF files have been read in.
    Show Attributes

    07-07-2010
    70%
    Does RC use cell areas from LEF or from Liberty in PLE mode?

     

    Problem: Does RC use cell areas from LEF or from Liberty in PLE mode? Solution: The cell dimensions defined in the LEF will be used if the LEFs have been imported and the tool is in PLE mode.
    Show Attributes

    02-02-2009

     

    regards,

    gh-

  • Thanks gh for the suggestion. I would go with recommended LEF flow.

    But I still do not understand what extra information does LEF provides that help the synthesis tools in synthesizing the logic? Could you please elaborate on the utility of LEF file in the synthesis process. I was in the impression that most of the timing,area and functionality information is already in the .lib file for all the std and io cells. So, the only extra information the synthesis tool needs is to estimate the interconnect delay. I am assuming the pin loading information from liberty file and the RC equivalent is estimated from CapTable, and that loading value is used in timing table in liberty file to pick up the right timing.

    While i was going through RC documentation, i found there is synthesize -to_placed as well. I usually do synthesize  -to_mapped only. If I was doing synthesize -to_placed then it makes more sense to read in def_file or lef_file. What kind of advantage does synthesize -to_placed provide over synthesize -to_mapped? Is synthesize -to_placed also the recommeded flow over synthesize -to_mapped before releasing the netlist to the Encounter for placement and routing.?

    Thanks for you help.

    Regards. 

     

  • Hi diablo,

    There are two type of LEF information that RC can use. Tech LEF & MACRO LEF.  The tech LEF has all routing pitch, width & spacing for each metal layer. Res is also included in the tech LEF if not specified in the CapTable. Using this information RC can then index correctly into the captable to find correct side wall cap, fringe cap, and area cap. This is done using PLE interconnect mode which is more advanced and more accurate then area based wire load models. Strictly speaking no MACRO lef are required to run PLE mode. However to run synth -to_place you will need all LEF both MACRO and TECH else this will fail since synth -to_place runs EDIS under the hood. Why is running synth -to_place better then straight synth -to_map. Synth -to place will complete a placement then optimize the design based on this placement. This can then account for long wires crossing say memories or complications based on a port location. Synth -to_place also has a number helpful congestion analysis features and auto/semi-auto fixing mechanism.

    Hope this helps,

      Mike

  •  Hi Mike,

    Thanks a lot for the info. Yes it make sense to have MACRO lef to run synth -to_place. However, after synthesized netlist is imported in Encounter, the placement and wirelength optimization are done in Encounter. By doing synth -to_place, are we just letting RTL compiler to do placement which could have been done in Encounter? Is it the same thing if i do synth -to_mapped in RTL compiler and later placement with optimization in Encounter? 

    Thanks again for your time.

    Regards. 

  • Hi diablo,

     Synth -to_place does have some advanced congestion optimization capabilities not available in EDIS today. Incremental performance gains are often reported using a flow where both a netlist & DEF are feed forward to EDIS from RC. Keep in mind the original intent of RC-Physical was to provide earlie predictability (timing, utilization & congestion) within RC to avoid iterations between Synth & P&R. Best to solve the obvious problems during RTL development where there exists detailed design knowledge.

    Cheers,

  • Hi diablo

    Synth -to_place does have some advanced congestion optimization capabilities not available in EDIS today. Incremental performance gains are often reported using a flow where both a netlist & DEF are feed forward to EDIS from RC. Keep in mind the original intent of RC-Physical was to provide earlie predictability (timing, utilization & congestion) within RC to avoid iterations between Synth & P&R. Best to solve the obvious problems during RTL development where there exists detailed design knowledge.

    Cheers,

  • Hi Mike,

    Thanks again for the quick reply and the nice explanation. The early predictability and reduce iterations totally make sense.

    Cheers. 

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.