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
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
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
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.)

Forum Discussion

what can I do to delay the source

13 Replies

Recent Discussions

Quartus 25.1std | Signal Tap Crash

BSP generation for I2C

The DC_FIFO issue of Cyclone 10 GX devices

Request of private case

Schematics/layout for TerasIC SoCKit rev. D with Cyclone V