Forum Discussion
Honored Contributorwhat can I do to delay the source
I'm using the megafunction ALTDDIO as a receiver which requires the input data to be centered aligned to the rising and falling source clock. Unfortunely I have learned the source and data are going to be coming in edge aligned. I've been trying to find a way to delay the input clock by 90 degrees. I have looked into using the PLL, but because of the wide range of source clock (25MHz to 165MHz), the PLL won't be able to lock onto it so this is not an option.
Is there a way to delay the clock or data so that they meet the ALTDDIO requirement? Your comment is much appreciated.13 Replies
Altera_ForumYes, that's O.K., but you see, that all suggestions are returning to the same points. The contributors don't see from the present thread, that you have already thought about PLLs.
- Altera_Forum
FvM, I was trying to present the problem from a different point of view so that people can understand it better instead of just looking at the PLL.
- Altera_Forum
Hi FvM,
Sorry but I don't see it annoying but the perspective has been widened more than just PLL solution. - Altera_Forum
It's bit annoying, that the topic is presented as a kind of cross post without referring to your previous post. Actually, the options (and requirements) for using PLL reconfugurations have been already discussed. It would be good way to continue the previous thread instead of starting a new one.
http://www.alteraforum.com/forum/showthread.php?t=26950 - Altera_Forum
TimeQuest can help data delays (not clk delay) anywhere within one clock period of 160MHz at least but its control is not fine and may jump coarsley as you change parameters.
This is the very mechanism of getting input io timing when you use set_input_delay. Try experimenting as follows: tell TQ your ddr clk speed of 165 and that data is edge aligned i.e. tCO = 0 so set input delays to zero. Make sure you select io register (fast io) and compile then run TQ and check the datasheet section which tells you figures for setup/hold at FPGA boundary (pins). In effect the timing window which is about .6 ns around clk edge (internally at register) should be moved away from clock edge at pins. e.g. you might see tSU = 2 n and tH = - 1.4ns indicating a delay of about 2ns has been applied to data. If your figure are different then play with delay figures. At the same time TQ will tell you about timing violations in the section called io timing - Altera_Forum
Kaz, are you saying the TimeQuest can help me delay 1.5 ~ 2 ns on the input clock. How is that done?
- Altera_Forum
A PLL solution may be too involved. io delay is not that fine...
One practical option is to look at optimum delay point for all frequencies. Remember, data does not need to be centre aligned per se. What matters is no timing violation at FPGA io registers. My own measurement of stratix 4 io timing window is that it is very small e.g. 0.6ns. Your worst frequency has period of 6 ns and slowest one is 40 ns. so if you push the data towards 1.5 ~ 2 ns from clk egde then it might be ok for all cases I believe. In the case of 40 ns period for example this location will not violate either edge. The trick is to get 1.5 ~ 2 ns strictly under control and TimeQuest should confirm these figures. - Altera_Forum
Dave, I have looked into using the ALTPLL_RECONFIG too, what I read is it only allows dynamically phase shift and clock output change, not input clock change. The switch clock is only good for a 1:2 ratio as I tried too.
- Altera_Forum
The delay chains are not nearly as good as a PLL, because the they are not compensated over PVT. An 800ps delay in the slow corner might only be a 400ps delay in the fast corner. That's why a PLL will allow much higher rates.
That being said, you're not running at super fast rates, and hence it might be possible. But you'll never know without timing constraints. I would put those in first. Doing paper analysis of delay chains and what not is generally too hard, because paper analysis doesn't cover PVT/ODV, etc. Note that your data drives directly to the registers, while the clock has a long way to go, hence it will be the longer delay. That's why same edge capture is so useful. If you don't do that, then the clock delay may be 3ns, and the data delay will have to be more than 3ns, and you'll never meet timing over PVT. With same edge capture, you want your data delays to be shorter than the clock, which is do-able. Again, I would put the constraints in first thing and analyze what they're doing. Once they're correct, start playing with the clock tree. Put it on a global. If that doesn't work, try a regional. If that doesn't work try local routing. - Altera_Forum
Rysc, I have thought of using i/o delay element on the clock. I don't remember where I read this, it says the maximum delay we can put in place is 800ps. That's why I didn't continue in that direction.
In your examples, what is the delay in terms of time we will get, if we can get 1.5ns delay, which is good enough since the most extreme case (fastest clock) is 165MHz = 6ns, a quarter of it is 1.5ns. And I believe this should work for the slow clock too.
