Are Stratix V IOE delays programmable dynamically?

I haven't worked with Stratix V yet, but one way we have done the same thing is with partial reconfiguration of the PLL, adjusting the phase of the internal and external versions of the clock.

Pete

I recall a white paper call "Morph I/O" that allows you to change some of the IOE settings via JTAG

http://www.altera.com/support/devices/configuration/cfg-solutions.html

It does not explicitly discuss IOE programmable delay lines, but perhaps the registers associated with those delays are accessible via this method.

You could file a service request and ask for more details.

Cheers,

Dave

At this point it’s just an observation I made that it doesn’t look like the delays are dynamically programmable, I mean in the sense of being programmable from logic in the fabric, as I knew I could do with the Virtex-5. It’s not a problem yet. I was just hoping someone would confirm the observation. I’m on an Alera learning curve after using Xilinx for a while.

Dave - It’s interesting to know I might be able to change the settings through JTAG if I need to. Thank you.

Pete – I think I see what you’re saying about changing the relative phase of the internal clock and external clock to get the sampling point right. That could work if all data bus traces are equalized. I wonder about cases where that assumption can’t be made.

I can see that if a data trace has an unusual delay relative to the other traces on the bus that you could compensate by hard-coding the IOE for that trace with a different delay relative to the others. But what if we made 20 boards and wanted to use the same FPGA design on each board? What if different boards had different delay characteristics on the data bus? I guess Altera is assuming the quality of the boards would be consistent enough and the data eyes on the bus would be wide enough that there would be enough error margin to handle any PVT variations from one board to another. I guess.

--- Quote Start ---

I can see that if a data trace has an unusual delay relative to the other traces on the bus that you could compensate by hard-coding the IOE for that trace with a different delay relative to the others. But what if we made 20 boards and wanted to use the same FPGA design on each board? What if different boards had different delay characteristics on the data bus? I guess Altera is assuming the quality of the boards would be consistent enough and the data eyes on the bus would be wide enough that there would be enough error margin to handle any PVT variations from one board to another. I guess.

--- Quote End ---

This is the typical use-case, i.e., you use TimeQuest to assign timing constraints, and then the IOE programmable delays are programmed appropriately.

Since you comment on having had this ability with Xilinx devices; did you ever actually need to use them?

I cannot think of a single case where I have needed to adjust the delay to a specific trace. Typically I will get timing constraints for a design working, then based on the operating frequency of the interface, decide if the PCB layout needs to match traces, and then route the board as appropriate.

In todays FPGAs, the fastest interfaces are the transceiver channels, and other than matching differential pairs, there is no need to match trace lengths across lanes.

A more useful question to pose to this group might be; what FPGA interfaces are you interested in, and at what frequencies, eg., DDR3, QDR II+, etc. Most of these interfaces are implemented on Altera development kits, so users of those kits provide feedback on their experiences.

Cheers,

Dave

On Xilinx when you were interfacing a DDR/QDR memory they provided a tool that generated an interface module that you could include in the design. It contained code that would somehow relearn and reset I/O delays each time the system was restarted. If you wanted you could then query the delays set on each I/O. Usually the delays were almost identical but sometimes not. Since the module took care of it every time we didn’t keep close track of whether or how the delays changed from one restart to another or one board to another.

In another case we had two FPGAs on the board with a high-speed parallel bus between them. On each startup we sent calibration patterns from one FPGA while on the receiving FPGA I wrote code to detect the data eye edges and adjust the input delays accordingly to center the sample point. Here again calibrations were done on each restart rather than once-and-done at development time.

I’m not necessarily advocating the Xilinx way as better. I’m just saying it’s what I’m accustomed to. If the assumption of consistency on the boards is valid then the once-and-done approach sounds more efficient since you don’t need to burn logic resources to execute the calibration and it may be simpler on the silicon if Altera doesn’t need to route clock and control signals to each IOE. Coming from using Xilinx, though, I’m not used to having that assumption made.

Hi John,

--- Quote Start ---

On Xilinx when you were interfacing a DDR/QDR memory they provided a tool that generated an interface module that you could include in the design. It contained code that would somehow relearn and reset I/O delays each time the system was restarted. If you wanted you could then query the delays set on each I/O. Usually the delays were almost identical but sometimes not. Since the module took care of it every time we didn’t keep close track of whether or how the delays changed from one restart to another or one board to another.

In another case we had two FPGAs on the board with a high-speed parallel bus between them. On each startup we sent calibration patterns from one FPGA while on the receiving FPGA I wrote code to detect the data eye edges and adjust the input delays accordingly to center the sample point. Here again calibrations were done on each restart rather than once-and-done at development time.

--- Quote End ---

Ok, these are good examples of where this feature would be useful.

I haven't used the Altera DDR/2/3 IP cores (other than on development kits). Perhaps others can comment on the power-on calibration sequence that the Altera IP performs. I'm fairly sure I recall seeing that the IP does include some form of calibration, though it may be related to driver strength, rather than delays.

I've used PLL phase adjustment (as Pete mentions above) to sweep over the eye-pattern of an LVDS data bus at 1Gbps data rate to measure the eye, and determine the "sweep spot". At that point, I used a fixed value of phase (over ~100 boards in a system), and have not had any detectable board-to-board variation.

--- Quote Start ---

I’m not necessarily advocating the Xilinx way as better. I’m just saying it’s what I’m accustomed to. If the assumption of consistency on the boards is valid then the once-and-done approach sounds more efficient since you don’t need to burn logic resources to execute the calibration and it may be simpler on the silicon if Altera doesn’t need to route clock and control signals to each IOE. Coming from using Xilinx, though, I’m not used to having that assumption made.

--- Quote End ---

Yep, understood. I like your attitude to investigating the different features between Xilinx and Altera. Better to understand the differences now, rather than be surprised later.

Cheers,

Dave

Hi John:

Yes, we use the PLL sweep of the eye pattern at each bootup via the cpu. We have found the results very consistent. run from run, but we never bothered to fix the setting to verify (our bootup time wasn't that critical that it mattered.) We did have matched traces on the data lines. But unless you have significant skew between data lines you should be able to find a place that works.

Running though your process, there shouldn't be significant difference lot to lot, unless you have bad solder joints, or miss-loads that drastically change the timing. Then you would probably be stuck with an unworkable solution anyway.

I could see drastic changes, if they changed the materials used on the board, or messed up the stackup for a run. But those are process issues that I would want to know happened. The eye pattern sweep would probably correct for this, but it could really cause cross-talk, or other issues that would cause problems.

Pete

FYI

I am still investigating but I have reason to believe that the answer to my question is that the IOE delays ARE in fact programmable dynamically.

There is something called an ALTIOBUF that enables something called a dynamic delay chain, which looks like what I'm talking about...

Hi John,

The ALTIOBUF looks like its been available since Stratix III series or so;

http://www.altera.com/literature/ug/ug_altiobuf.pdf

"Can enable dynamic delay chains for I/O buffers"

I'd agree that this appears to provide the functionality you are looking for. The scan chain interface is similar to the interface on PLLs (that Pete and I have used for dynamically adjusting PLL parameters).

I'd recommend instantiating this component and simulating it using Modelsim.

If you synthesize a design, you should be able to view the "default" settings of the IOE delay buffers using the "Resource Property Editor".

Cheers,

Dave