Does a well balanced clock tree with significant delay introduce hold cells on inputs of a design?

[oharboe]

I am probably missing something fundamental about clocks and clock trees. I thought that the clock tree latency wasn't particularly critical for a macro. At the top level, I imagined that it would be possible to delay the clock for a clock period minus the clock tree propagation time within a macro and then the clock for a macro would have zero latency relative to the data input/output signals.

If we take the mock-array as an example, we find that at 1000ps clock period (in master), there are a LOT of hold cells at the mock-array level, even if the clock tree is quite well balanced (22ps or so, that is roughly 10% of the clock tree latency).

mock-array is imagined as a macro that fits into an overall design where the inputs and outputs of mock-array are registered just outside the mock-array itself, so the input/output delay at mock-array level should be very close to zero. Today it is 20%, but as the registers should be just outside of the mock-array, perhaps 5% would be more approperiate.

There are strategies to try to minimize the clock distribution time, but ultimately distributing a clock across mock-array will take time.

Is there a strategy to delay the clock into mock-array such that it allows mock-array time to distribute the clock?

If so, how would this be expressed in mock-array .sdc(?) files when generating the mock-array macro?

set_clock_latency ?

My expectation from this is that the hold cells should go away and that it should be possibly to significantly increase the clock frequency of mock-array.

[maliberty]

All your hold cells are on IOs from what I see. The clock tree delay in the block is interacting with the io constraints.

I think you need to consider how you plan to bring signal to this block. Currently your .sdc is using the fairly typical default of 20% of the clock period for input/output delays. That may or not may not be realistic depending on the rest of your system. You could easily make these disappear by setting clk_io_pct to something higher if that is realistic (eg 0.5).

[oharboe]

What would happen if I set clk_io_pct too high and the hold cells are gone from the mock-array. Would the hold cells be added at the level above mock-array?

[maliberty]

Possibly - it depends what is happening at the top level.

[maliberty]

In general you want the block level constraints to reflect the context accurately.

[oharboe]

Just to confirm: setting the input latency to 0.5 * clock period, does remove the hold cells.

However, this doesn't really answer my concern or point to a viable strategy to work with a design area that approaches a significant percentage of the clock period in terms of clock tree propagation time.

To my mind, there should be a way to make a design work when it has combinational logic between registers well within a clock period(i.e. there is plenty of time within a clock period to do the combinational logic), but a large clock tree distribution time.

[oharboe]

After reading https://www.semiconductor-digest.com/clock-tree-optimization-methodologies-for-power-and-latency-reduction/, I decided to run a quick experiment with one clock pin per row in mock-array #1247: hold cells vanished.

I'm shooting from the hip w.r.t. how to articulate the .sdc file here...

Considerable positive slack for setup and hold:

Many clock tress in the clock tree viewer :-)

[rovinski]

@oharboe just be aware for an actual design that this is just moving the clock skew from the inside of this module to the outside of the module. By creating multiple clock pins, it effectively creates an ideal signal with no skew between each clock pin which is not realistic. There will always be some amount of skew/jitter between these pins, but now they are not being modeled.

[oharboe]

This is a tricky problem. No quick fixes...