RC synthesis flows

Hi Suresh, nothing trivial about this question :) As you know, there are multiple ways to skin the cat. The RC write_template command provides a nice mechanism to generate various template for running RC but most of these are feature driven and not goal driven. It shows you for example, how to do retiming, and not necessarily the different things you can do when doing retiming. The goal of RC is to provide best QoR or close to best with the template flows provided. That being said, sometimes user has a need to make changes to squeeze the very last drop on a particular metric. I hate to give you a non-answer but I will. The issue is that there is no one-size fits-all answer when pursuing every last drop of QoR. There is certainly a trade-off user makes between time-to-good results vs. best results. As you know, time is the worst enemy of engineers. I will try to provide some quick suggestions that may be helpful and encourage you to enlist your local support to help you tailor things further: (1) Targets, targets, targets Targets are a key element of RC optimization, make sure you understand them and adjust flow accordingly (2) Constraints Previous generations of MIS/SIS based synthesis tools relied on over-constraining. This is definitely not the right approach to RC. Only over-constraint if you have a valid reason or evidence that it yields better results in your design using RC. Otherwise you are just giving up area and power for no good reason (3) Best QoR This means different things to different users. If you have time and resources, I always encourage users to do multiple runs to identify performance bounds of their runs. For example, you can run without constraint to obtain an area bound. You can run without timing constraint but provide power constraint to obtain a power-bound (in smaller technologies, area and power do not necessarily correlate. The problem is many times users will demand improvements on a given metric and not always know whether or not it is even feasible. (4) Low Power Design Today, CPF can be used to enable several LP techniques beyond clock gating(MSMV, PSO, DVFS, etc.). RC also provides what-if analysis where you can retarget, on-the-fly a block for a different voltage and see the impact without having to re-run a full synthesis. This will not give you best QoR but will provide you a good idea of what can be accomplished. One key thing when doing LP design is ensure you have representative activity vectors. There is limited value in spending lots of time optimizing a design to vectors that may not be representative of the design activity. You know what they say, GIGO... For large, complex designs, DPA (RC + Palladium emulation) provides best solution to quickly and accurately extract desired activity vectors (5) Physical-aware Especially in smaller geometrics, use of physically aware synthesis has become extremely important to reach the best QoR and avoid surprises when handing over your design to P&R (6) on Multi-VT A lot of effort has gone into the RC multi-VT flow and currently our recommendation is to enable multi-VT in synthesis with an understanding of your operating envelope. However, this depends on your backend flow as well since some tools/flows end up undoing the work here and potentially causing more harm than good. It is therefore important that your P&R flow is complimentary to your synthesis solution hope my non-answer helped, gh-

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-