Stats

  • Locked Locked
  • Replies 4
  • Subscribers 62
  • Views 16379
  • 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

RC synthesis flows

sureshm

 Dear all,

The question may be quite trivial for many out in this forum .. .i would like to discuss more of a methodology related  question with respect to RC tool usage ...for synthesis .!!! 

What are the several Synthesis flows recommended by RTL compiler? 

 Not all designs are computational intensive datapaths,  Few are intensive datapaths, Few are Clock intensive paths( more of clock path generation) and few designs  are  Memory intensive..  

 What is the best way to deal with each type of the Designs interms of methodologies .. ? how do we ensure that we have optimized the best possible way? How to verify for any improvements in the design QoR, timing, area & power...?

Apart from CG gating, what other techniques do we employee to target the low power synthesis?  

I also found that Multi-Vt optimization in synthesis is not a  good idea  from the tool perspective as this is not giving a good results?

Usually, DC provides a lot of template scripts targetting for timing, area & power separately? Any such tricks available in RTL compiler as well?? 

 Please share your views !! 

 

thanks

suresh 

Parents

  • Hi gh,

    Thanks for the answer !! 

    You are right, RC template scripts are mainly feature driven, unlike DC provides the goal driven template ( best fit-in template for the given target accepted by most of the designers )

    I am currently using 20% higher frequency with no wireload model and an uncertainity of 250ps ( blanket) for all the clocks, Do you think it is a right approach ? or any other approach that you find is more appropriate !! 

    Also, I am not sure if RC picks up the right architectures for most of the DW components !!, Do you have any idea, if RC optimizes CW components than to DW components better? 

    Analyzing design for different perfomance bounds is a very good idea, keeping one target @ a time.. however, how to take those details in the final design run, where all the targets are in place independent of each other. However, RC claims, that the tool  try to fix the targets, orthogonally,which means it tries to employ best algorithms to meet the target withtout effecting others !!

     Thanks

    suresh

     

Reply

  • Hi gh,

    Thanks for the answer !! 

    You are right, RC template scripts are mainly feature driven, unlike DC provides the goal driven template ( best fit-in template for the given target accepted by most of the designers )

    I am currently using 20% higher frequency with no wireload model and an uncertainity of 250ps ( blanket) for all the clocks, Do you think it is a right approach ? or any other approach that you find is more appropriate !! 

    Also, I am not sure if RC picks up the right architectures for most of the DW components !!, Do you have any idea, if RC optimizes CW components than to DW components better? 

    Analyzing design for different perfomance bounds is a very good idea, keeping one target @ a time.. however, how to take those details in the final design run, where all the targets are in place independent of each other. However, RC claims, that the tool  try to fix the targets, orthogonally,which means it tries to employ best algorithms to meet the target withtout effecting others !!

     Thanks

    suresh

     

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.