1. Home
  2. Field-Programmable Gate Arrays
  3. IDELAY and whether pigs can fly...

IDELAY and whether pigs can fly...

1) Is the V4 IDELAY resolution 75ps like the switching document says or the 78.125ps mentioned in the forum? 78.125 makes sense since it is (1/200MHz)/64. And where does the tap error come from? What is the correct number for THAT? I also saw that the recently updated data sheet says that the per tap resolution is actually an average across the whole 64 tap line. And it is suggested to use at least 5 taps. What is the reason for this???

2) I am trying to figure out the best way to characterize some data coming into the FPGA. I have 4 pairs of LVDS data coming in to input pins. Eventually these pairs (which are from a 1-to-10 LVDS distribution chip - so they are copies of the same data) will be delayed, using the IDELAY, 45 degrees relative to eachother. I will have a 0 phase, 45 phase, 90 phase, and 135 phase data input. Using the DDR ISERDES at 1:8 deserialization, I will have 8 phases of data. The reason I am doing this is to recover the data. I know it is at 312 MHz, but I don't have a clock reference so I sample 8 phases of the same data and choose which one is the best (how is not important for this discussion).

I know that before I can delay the data pairs I must first '0 them out'. Due to board layout, clock skew to the ISERDES, etc, the data pairs (when ALL set to IDELAY = 0) will not be perfectly aligned. Currently, I am using the 312 MHz clock that I clock the ISERDES with to drive, via the ODDR method, an external data generator that sends one byte of data. I'm doing this so that I have a known data-to-clock relationship. I have the byte outputs of the ISERDES connected to ChipScope. I monitor the individual channels and one-at-a-time increment the IDELAY until the data corrupts. I know that the data is now being sampled right at the clock edge -- or at least close enough to break setup. I do this for each channel and I end up with 4 different IDELAY values. I then normalize these delays to the smallest one and I have the offset for each data pair. These offsets should align the data (within error and tolerance) to each other. I can then add the phase delays to the data pairs.

This worked fine when I was using the ISE and could use the ChipScope core inserter. Now I've moved to the EDK and have to use the ChipScope IP. I don't know if that has anything to do with anything though! My problem is that I can find the offsets to make the data align relative to each other, but the phases DO NOT work all the time. For example I can see that 4 phases 'see' the data, one doesn't and then the next one does. If everything is aligned correctly, I should not get any skips in detected phase. They should all be consecutive. Even worse, sometimes all 8 phases 'see' the data. This case is no good since there is no way to determine which one saw it first and therfore which one to use to forward data. There should be at LEAST one phase that does NOT detect the data!! Sometimes only one phase 'sees' the data. This should never happen either. The data is VERY clean coming from the test equipment and the distribution chip. I would say the eye opening is about 90% or more.

Can anyone see any major flaws with what I am doing? Is there a better way to guarentee these phase offsets? There is no way to get absolutely precise timing since the 45 degree increments of phase are not divisible by the IDELAY tap resolution. So I automatically have some error, but even with this error, this little scheme should work. Hell, I've seen it work consistently!! Hopefully I didn't just get lucky.

Sorry for the long post!!!

Reply to
motty
Loading thread data ...

How do you know that the phase difference is constant?

-- Mike Treseler

Reply to
Mike Treseler

Which phases are you asking about? The channel to channel difference? I would hope that given a particular build that the phase difference between them would be constant (within a reasonable amount, that is, within an IDELAY tap resolution). The phase difference will be due to board layout, clock skew at the ISERDES blocks and other routing through the IO pads. At least that is what I figure. Again, once characterized, these phase differences should remain somewhat constant.

Thanks!

Reply to
motty

Reply to
Peter Alfke

Thanks Peter.

After some research this weekend, I saw that the Switching Characteristics Data Sheet for V4 had been updated in Dec. So I got that and it explained a little bit more about the IDELAY. More importantly, it referenced a document that detailed the ChipSync technology -- XAPP707.

As an aside, this document does NOT show up on a search for "IDELAY" on the Xilinx web site. Several other XAPP70X docs do, but not this 707. This is annoying in its own right.

I digress....

This is a quote from the latest update of the V4 User Guide:

"IDELAY is a 64-tap wrap-around delay element with a fixed, guaranteed tap resolution (see Virtex-4 Data Sheet)."

You mean 'see' the Switching Guide? If so, there is an equation that will give you the delay value for a given tap used. It includes +/- error as well. So really the description in the User Guide is misleading. The taps are certainly NOT guaranteed to be a fixed resolution. The whole chain is guaranteed fixed, but not individual taps. In fact, according to XAPP707 there can be some pretty wide swings examing one tap at a time.

So maybe the User Guide shouldn't put such a description. Maybe it should reference the XAPP707 document as well. I will be smarter from now on and look for the data sheet updates and follow their trail for information. No big deal. I just find it frustrating sometimes to find information on non-trivial portions of some of Xilinx technology.

If anyone ever posts here about IDELAY, and I see it and it's applicable, I will first reference them to the 707 document. It is full of great information that can be used to evaluate the IDELAY and whether or not it would work for a particular apllication.

I now see that I need to do more characterization on my design. I CANNOT rely on the IDEALY tap resolution...at least not the way I was. But it would have been nice to know this from the get go. Don't get me wrong, I take responsibility for not scouring the documentation. BUT, it just seems like the information I found on Xilinx' web site concerning IDELAY was at times inaccurate, sometimes misleading, not 'simple' to find, lacking detail, etc. It kinda sucks to have to have at least 3 documents to fully capture one feature of the FPGA.

Just my 2 cents....

Reply to
motty

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.