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 Suresh, I am assuming when you indicate no wireload, you are indeed reading all appropriate physical collateral to enable PLE synthesis. 20% higher frequency indeed sounds excessive as does 250 ps uncertainty but I do not even know your clock period or technology so hard to say. As per the 20% number you mention I would ask, what is the basis for 20% ? rule of thumb or any specific experience with this design and technology. In general I would recommend a number that account for SI impact, OCV impact, and effects known not to be captured in the synthesis portion of the flow. Usually this number is around 5-10% + uncertainty to model skew, PLL jitter, etc. As per optimizing DW vs CW, there should not be a significant differences either way. Using the high-level constructs is always preferred if possible but depending on what functions you are trying to model with xxWare this may or may not be desirable. If you suspect of RC picking the wrong xxWare, I would first take a look at the 'targets' in your log. The architectures chosen will be largely driven by those hence make sure they are a true reflection of what you expect. I think your last paragraph is not accurate. RC does not try to target cost functions orthogonally. On the contrary, it tries to address them concurrently such that the best trade-off is made. The comment about not affecting others is somewhat misleading. We all know 'you do not get something for nothing' When you pick a really fast address, it is usually bigger than the slow adders so there certainly is an impact but the goal of concurrent optimization to make decisions that yield the best QoR. If I tried to go only for, say area, first and then do the rest, I will spend considerably more time fixing timing or may not be even able to do so. hope this helps clarify, gh-
Reply
  • HI Suresh, I am assuming when you indicate no wireload, you are indeed reading all appropriate physical collateral to enable PLE synthesis. 20% higher frequency indeed sounds excessive as does 250 ps uncertainty but I do not even know your clock period or technology so hard to say. As per the 20% number you mention I would ask, what is the basis for 20% ? rule of thumb or any specific experience with this design and technology. In general I would recommend a number that account for SI impact, OCV impact, and effects known not to be captured in the synthesis portion of the flow. Usually this number is around 5-10% + uncertainty to model skew, PLL jitter, etc. As per optimizing DW vs CW, there should not be a significant differences either way. Using the high-level constructs is always preferred if possible but depending on what functions you are trying to model with xxWare this may or may not be desirable. If you suspect of RC picking the wrong xxWare, I would first take a look at the 'targets' in your log. The architectures chosen will be largely driven by those hence make sure they are a true reflection of what you expect. I think your last paragraph is not accurate. RC does not try to target cost functions orthogonally. On the contrary, it tries to address them concurrently such that the best trade-off is made. The comment about not affecting others is somewhat misleading. We all know 'you do not get something for nothing' When you pick a really fast address, it is usually bigger than the slow adders so there certainly is an impact but the goal of concurrent optimization to make decisions that yield the best QoR. If I tried to go only for, say area, first and then do the rest, I will spend considerably more time fixing timing or may not be even able to do so. hope this helps clarify, gh-
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.