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.

Aside from using time constraints (which I wouldn't recommend) I think using a PLL is your best bet, assuming the multiple clocks you are talking about are at known discrete frequencies. You can use multipliers within the same PLL to generate the derived clocks, specifying different phases as desired (you can have 5 different outputs with 5 phases and frequencies from the same PLL on the Cyclone II for example) Otherwise, you can use clock switching (mentioned in the Altera PLL Megafunction User Guide.)

Why don't you think the PLL will lock? It should, but you will just have to work a little harder. The ALTPLL_RECONFIG Megafunction can be used to program the feedback parameters of the PLL and phase-shift the clocks. If you have another reference oscillator clock, eg. 125MHz, you can use that to measure the frequency of the variable frequency incoming clock. For example, I have a design where I pulse a control line (for a ~100ms) and count the number of 125MHz clocks and number of reference clock periods during the pulse high time. Then with that I can estimate an external reference clock frequency. In my case, I am just confirming it is the frequency I expect. In your case, you would use the measured frequency to then determine PLL settings, and reprogram the PLL via the ALTPLL_RECONFIG interface, and check that the lock signal locks. Then you can pulse the phase shift circuits on the PLL and capture data. If you know what the data is supposed to be, then you can perform a sweep such that you get bad data, then good data (hopefully at multiple settings) and then bad data again. You then move the capture location to the center of the eye pattern. Take a look at the ALTPLL_RECONFIG function and see if it will work for you. Depending on the FPGA you are using, there are also delay elements in the FPGA IOEs. I recall seeing a program MORPHIO I believe ... yes, this document, http://www.altera.com/literature/wp/wp_morphio_reconfig.pdf where they used JTAG commands to manipulate I/O settings. If this scheme allows you to change IOE delays, and there is enough delay range to meet your timing requirements, then that might be another option for you. I would recommend the PLL option though, as that has direct support, and you'd likely get help if you could not figure out how to use that method. Cheers, Dave

165Mhz DDR might be do-able without a PLL, it's just tight. Depends on device and what-not. Note that if you can do that, then the lower rates should just work, as the edges move out. You'll want to add a multicycle to make sure you're doing "same-edge" capture. Assuming they come in edge-aligned: create_clock -period 6.060 -name fpga_clk [get_ports fpga_clk] create_clock -period 6.060 -name ext_clk derive_clock_uncertainty set_input_delay -clock ext_clk -max 0.5 [get_ports {data[*]}] set_input_delay -clock ext_clk -min -0.5 [get_ports {data[*]}] set_input_delay -clock ext_clk -max 0.5 [get_ports {data[*]}] -clock_fall -add_delay set_input_delay -clock ext_clk -min -0.5 [get_ports {data[*]}] -clock_fall -add_delay set_multicycle_path -setup 0 -rise_from ext_clk -rise_to fpga_clk set_multicycle_path -setup 0 -fall_from ext_clk -fall_to fpga_clk The multicycles are the most confusing part, but they basically go for same edge latching. This is good since the clock tree will be longer than the datapath, and hence will buy you some setup margin.

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.

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.

what can I do to delay the source | Altera Community

13 Replies

Altera_Forum
Honored Contributor
15 years ago
Aside from using time constraints (which I wouldn't recommend) I think using a PLL is your best bet, assuming the multiple clocks you are talking about are at known discrete frequencies.

You can use multipliers within the same PLL to generate the derived clocks, specifying different phases as desired (you can have 5 different outputs with 5 phases and frequencies from the same PLL on the Cyclone II for example) Otherwise, you can use clock switching (mentioned in the Altera PLL Megafunction User Guide.)
Altera_Forum
Honored Contributor
15 years ago
Why don't you think the PLL will lock? It should, but you will just have to work a little harder. The ALTPLL_RECONFIG Megafunction can be used to program the feedback parameters of the PLL and phase-shift the clocks.

If you have another reference oscillator clock, eg. 125MHz, you can use that to measure the frequency of the variable frequency incoming clock. For example, I have a design where I pulse a control line (for a ~100ms) and count the number of 125MHz clocks and number of reference clock periods during the pulse high time. Then with that I can estimate an external reference clock frequency. In my case, I am just confirming it is the frequency I expect. In your case, you would use the measured frequency to then determine PLL settings, and reprogram the PLL via the ALTPLL_RECONFIG interface, and check that the lock signal locks.

Then you can pulse the phase shift circuits on the PLL and capture data. If you know what the data is supposed to be, then you can perform a sweep such that you get bad data, then good data (hopefully at multiple settings) and then bad data again. You then move the capture location to the center of the eye pattern.

Take a look at the ALTPLL_RECONFIG function and see if it will work for you.

Depending on the FPGA you are using, there are also delay elements in the FPGA IOEs. I recall seeing a program MORPHIO I believe ... yes, this document,

http://www.altera.com/literature/wp/wp_morphio_reconfig.pdf

where they used JTAG commands to manipulate I/O settings. If this scheme allows you to change IOE delays, and there is enough delay range to meet your timing requirements, then that might be another option for you.

I would recommend the PLL option though, as that has direct support, and you'd likely get help if you could not figure out how to use that method.

Cheers,
Dave
Altera_Forum
Honored Contributor
15 years ago
165Mhz DDR might be do-able without a PLL, it's just tight. Depends on device and what-not. Note that if you can do that, then the lower rates should just work, as the edges move out. You'll want to add a multicycle to make sure you're doing "same-edge" capture. Assuming they come in edge-aligned:
create_clock -period 6.060 -name fpga_clk [get_ports fpga_clk]
create_clock -period 6.060 -name ext_clk
derive_clock_uncertainty
set_input_delay -clock ext_clk -max 0.5 [get_ports {data[*]}]
set_input_delay -clock ext_clk -min -0.5 [get_ports {data[*]}]
set_input_delay -clock ext_clk -max 0.5 [get_ports {data[*]}] -clock_fall -add_delay
set_input_delay -clock ext_clk -min -0.5 [get_ports {data[*]}] -clock_fall -add_delay
set_multicycle_path -setup 0 -rise_from ext_clk -rise_to fpga_clk
set_multicycle_path -setup 0 -fall_from ext_clk -fall_to fpga_clk

The multicycles are the most confusing part, but they basically go for same edge latching. This is good since the clock tree will be longer than the datapath, and hence will buy you some setup margin.
Altera_Forum
Honored Contributor
15 years ago
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.
Altera_Forum
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
Kaz, are you saying the TimeQuest can help me delay 1.5 ~ 2 ns on the input clock. How is that done?
Altera_Forum
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
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

Forum Discussion

what can I do to delay the source

13 Replies

Recent Discussions

Trouble Getting started with Stratix 10 SOC

JTAG Chain Broken on Agilex 7-I Dev Kit

Agilex 5 Power

Issue with configuring EPCQ64A & Cyclone10LP using NiosV as processor.

Agilex5 A5EB013BB23BE4S BSDL