Properly optimizing enable to clock gating enable

Thanks everybody for your participation.

A lot of good things have been said here and I would agree that good planning i.e. a clock gating aware architecture is the best path to success. However we don't always have that and even when you do have a FF drivign the enable it is no guarantee that your path will be as fast as it could as this path will meet timing without problem in synthesis and thing like arearecover migth actually slow this path down as there is a large positive slack. Granted post route optimization should be able to optimize this fairly easily but it will be better to have it as fast as possible to start with.

In addition in many physical implementation the clock gating cells are duplicated based on where they are on the clock tree i.e.  havign a single instance of a clock gating near the root of the clock is good  for something control with a signal like IP_ON_OFF but not too practical if the enable is generated deep in the block. So depending on the physical distribution of the flop you want to gate the cloning strategy of your clock gating cell might differ and tool can now handle that in the backend the part they don't handle very well is the enable logic and mostly because there is no "universal constraints" to define those signal and constrained them

We all agree that if you can have a backend estimate of your clock latency and strategy and a stable it is not too hard to solve this problem the problem is who ever get that and has a chance to go back all the way back to the syntheisis. In General at that point my manager is pushing to tape it out and screw it if it is not the best/most robust solution

So from what I have read so far I take:

• max_delay is a good sytnhesis only solution (i.e.  this can be interpreted differently by different tool )
• path_adjust is  a good option to explore in RC. Does anybody knows if FE will understand that correctly even when switching from pre to post CTS timing?
• Most accurate solution is to model the latency at each of the clock gating element and let the tool do the calculation however I am not sure this doesn't results in too many clocks and doesn't have a negative impact on your run time. Advantage is that this should be properly handled in pre vs post CTS timing .

Now my wish is to get a set_afap constraint that could be used on those signals.

On using false path on enable I will say be very carefull and this is fine for global  on/off signal for which you don't care when they occur, for thing that need to be cycled accurate (typically controllng write to config register, internal memoreis, ...) this is the best way to end up with gate level simulation not matching your functional  simulation despite the fact that your formal equivalency pass!! Ever been beaten by that one due to the clock latency makign your enable being seen one cycle too late?

Eric.
 

Originally posted in cdnusers.org by evenditti

Thanks everybody for your participation.

A lot of good things have been said here and I would agree that good planning i.e. a clock gating aware architecture is the best path to success. However we don't always have that and even when you do have a FF drivign the enable it is no guarantee that your path will be as fast as it could as this path will meet timing without problem in synthesis and thing like arearecover migth actually slow this path down as there is a large positive slack. Granted post route optimization should be able to optimize this fairly easily but it will be better to have it as fast as possible to start with.

In addition in many physical implementation the clock gating cells are duplicated based on where they are on the clock tree i.e.  havign a single instance of a clock gating near the root of the clock is good  for something control with a signal like IP_ON_OFF but not too practical if the enable is generated deep in the block. So depending on the physical distribution of the flop you want to gate the cloning strategy of your clock gating cell might differ and tool can now handle that in the backend the part they don't handle very well is the enable logic and mostly because there is no "universal constraints" to define those signal and constrained them

We all agree that if you can have a backend estimate of your clock latency and strategy and a stable it is not too hard to solve this problem the problem is who ever get that and has a chance to go back all the way back to the syntheisis. In General at that point my manager is pushing to tape it out and screw it if it is not the best/most robust solution

So from what I have read so far I take:

• max_delay is a good sytnhesis only solution (i.e.  this can be interpreted differently by different tool )
• path_adjust is  a good option to explore in RC. Does anybody knows if FE will understand that correctly even when switching from pre to post CTS timing?
• Most accurate solution is to model the latency at each of the clock gating element and let the tool do the calculation however I am not sure this doesn't results in too many clocks and doesn't have a negative impact on your run time. Advantage is that this should be properly handled in pre vs post CTS timing .

Now my wish is to get a set_afap constraint that could be used on those signals.

On using false path on enable I will say be very carefull and this is fine for global  on/off signal for which you don't care when they occur, for thing that need to be cycled accurate (typically controllng write to config register, internal memoreis, ...) this is the best way to end up with gate level simulation not matching your functional  simulation despite the fact that your formal equivalency pass!! Ever been beaten by that one due to the clock latency makign your enable being seen one cycle too late?

Eric.
 

Originally posted in cdnusers.org by evenditti