• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Logic Design
  3. LEF in synthesis flow

Stats

  • Locked Locked
  • Replies 7
  • Subscribers 62
  • Views 19220
  • 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
diablo over 14 years ago

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. 

  • Cancel
Parents
  • diablo
    diablo over 14 years ago

    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. 

     

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • diablo
    diablo over 14 years ago

    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. 

     

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
No Data

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.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information