Honored Contributor
Honored ContributorI realize I made a mistake in my previous post. With worst-case setup and hold times of -0.6 nsec and 2.1 nsec and a 200-MHz clock, I think I was mistaken in saying the worst case data transition window was 1.5 nsec. With respect to the DAC clock, the data needs to transition no more than 0.6 nsec after the clock transition and no more than 2.9 nsec (5 nsec period - 2.1 nsec tHOLD) before the clock transition. Therefore, my data can transition anywhere in a 3.5 nsec (2.9 + 0.6 nsec) range and meet the timing specs for the DAC. At any rate, I have a good idea now of where (when) I need to make my data transition in order to make this system work.
I went ahead and created a project targeting the Cyclone IV in the Quartus software. I created a PLL to drive the logic in the design and set it in Normal mode to compensate for the global clock delay. Quartus reported clock to output delay times of 5.10 and 1.85 nsec for slow and fast models respectively. Compared to the range of values reported in the timing spreadsheet, it looks like I've gained ~250 psec as far as timing uncertainty under the full range of PVT. A step in the right direction! Then, by adjusting the programmable delay in the PLL, I am able to move the reported clock to output delay over what looks like a +/-1 period range. Does Quartus have newer/better information about clock to output delays for the Cyclone IV device than the timing spreadsheet?
