Constraining external ripple clocks correctly on external pin (pad_io)

Hi Rysc

Thanks for clearing up the hold time.

After studying your case 3 example in details I finally realized I had misunderstod the way TQ handles ripple clocks completely.

Instead of generating a clock at the flipflop output /in this case the pad IOO) it generates the clocks on the clock input of the FF. Then it takes the delay from this clock to the actual pad IO and move it into the data delay as a negative delay! Very simple when you get it, but very different from what I expected.

The naming of the generated clocks as *_ext in the docs does not make it easier to see,

I would prefer *_int, but never mind it is just names.

I think it would be a help for many people if you added a chapter in your source synchronous document that spell this out (Cut it out in Carbon as we say in Danisch).

So why is it made this way by Synopsys, I can only guess ?

The backside is that when I look at waveform signals in TQ they do not represent the actual Clock signal that drives the external chip.

However I see that it has one advance, if you include delays in clocks nets that vary much between FAST and SLOW HW, you risk the clock edge is before another clock edge in FAST while after in SLOW. This will gives difficulties to decide which clock edge is the right one to use in the analyze. By using fewer signals as clocks and stick to global nets and phase aligned PLL outputs this problem is minimized and the analyze is simpler when having fewer signals as clocks.