Understanding training patterns for Stratix-II deserializer DPA

--- Quote Start ---

So from now on I want to rely on exact knowledge.

--- Quote End ---

As far as I understand, you mainly observed the problem, that the receiver isn't stable enough over the intended temperature range. I can't see, how the problem should be related to train patterns or some hidden DPA properties that you suspect.

In my view, is simply a case of operating near the speed limits.

--- Quote Start ---

Out of curiosity, what is the data rate? Do you have an idea how much the data skews?

--- Quote End ---

1000 MBps. Uncomfortably close to 1040 MBps maximum specified in the handbook.

No, I have no idea by how much clock/data relationship floats over time and temperature. I thought that it shouldn't be no more than 100-200 ps, but the practice proved me wrong. So I don't try to guess anymore and direct measurements are rather difficult to setup.

The DPA is used in lots of applications(ethernet, ADCs, chip-to-chip custom protocols, etc.) I don't know the exact details, but note that you're giving it a clock that matches the source(not phase, but 0PPM difference). It creates basically an 8x oversampling. Unlike a CDR circuit, if there are no edges, this circuit should be able to do nothing rather than drift off.

Out of curiosity, what is the data rate? Do you have an idea how much the data skews?

I agree that I am surely over-simplifying, as everything tends to be more complicated when you peel it back, so make sure you open something with Altera rather than just the forum.

--- Quote Start ---

I forget all the DPA connections for Stratix II. Some thoughts:

- Do you know when the open areas area? Maybe you could disable the DPA from aligning during those periods? (I've heard of people disabling it from changing altogether once it's locked on)

--- Quote End ---

I don't quite understand what you mean by "open areas". Relative long runs without transitions? No I can't predict them, but with tiny modification of protocol I can assure that they wouldn't happen at all. Don't believe it will make the difference, since they are already extremely rare and certainly much shorter than "DPA run length" from the handbook.

As to disabling DPA from changing altogether once it's locked on, that's was our original design. Turned out it is not good enough, although I still don't understand why. In our topology the difference between clock path and data path is in order of 200mm, so, according to my understanding, temperature changes could change the relationship by, at worst, few tens of ps. Nevertheless, the practice proved that the drift is much bigger than that. So now I want fully dynamic solution with DPA tracking all the time. May be, now I went too far into "dynamic" direction. Sort of suffering second-system effect :( However, "fully-dynamic" is a solution that I now want.

--- Quote Start ---

- Not sure what the transmitter is, but could you add a "comma-character". This doesn't work with some data types, but just a thought.

- I have heard of one issue where the design had large variations over temperature, specifically the clock was sent directly to the receive FPGA(running DPA), but went through 3 other FPGAs where the third one was the transmitter. Over temperature, the path through the three FPGAs varied quite a bit(many ns) while the clock path did not. This resulted in a FIFO over-flow in the DPA. I "think" they reset the FIFO once the DPA locked, but can't remember for sure.

--- Quote End ---

Well, as I said above, our temperature variations a bigger than we anticipated, but hopefully don't exceed 1-1.5 ns. As to reseting FIFO once the DPA locked, according to my understanding of the manual, in Stratix-II that is a default behavior.

--- Quote Start ---

- Obviously, this shouldn't be happening and it's probably worthwhile filing a Service Request with Altera.

--- Quote End ---

We are starting.

Unfortunately, so far we were not even able to explain to the service person what the problem is. SR process takes time and, at least in my experience, almost never leads to satisfactory results. May be, because I don't tend to ask easy questions that can be answered by re-reading the manuals?

FvM,

I started by using common sense and common knowledge very similar to yours and ended up in where I am now, which, believe me, is not a pleasant place to be. So from now on I want to rely on exact knowledge, preferably directly from the developers of the DPA module in Stratix-II or, at worst, from somebody who can talk to them.

Who knows, may be they cut some corner or simply made a mistake and, as a result, DPA do requires strictly periodic patterns for proper delay tracking?

Most of your questions can be easily answered, if you think about what the DPA does. It adjusts the phase on a bit level, that's all. Thus it basically needs some signal edges.

The problem get's more complicated if consider the properties of your transmission channel. A dispersive cable will introduce an interdependance of subsequent bits. That's a point, where the structure of training patterns starts to matter. But the problem isn't related to FPGA properties rather than to your external circuit.

Another point is, that DPA is often used in a combination with word alingnment. In this case, a training pattern should serve both purposes.

I forget all the DPA connections for Stratix II. Some thoughts:

- Do you know when the open areas area? Maybe you could disable the DPA from aligning during those periods? (I've heard of people disabling it from changing altogether once it's locked on)

- Not sure what the transmitter is, but could you add a "comma-character". This doesn't work with some data types, but just a thought.

- I have heard of one issue where the design had large variations over temperature, specifically the clock was sent directly to the receive FPGA(running DPA), but went through 3 other FPGAs where the third one was the transmitter. Over temperature, the path through the three FPGAs varied quite a bit(many ns) while the clock path did not. This resulted in a FIFO over-flow in the DPA. I "think" they reset the FIFO once the DPA locked, but can't remember for sure.

- Obviously, this shouldn't be happening and it's probably worthwhile filing a Service Request with Altera.

--- Quote Start ---

How can you tell? Do the bits start getting corrupted?

--- Quote End ---

Yes, data is sent as relatively short fixed size frames with word synchronization pattern at the beginning and frame check sequence (CRC) at at the end of each frame. I run the tests over wide span of temperatures and at certain relatively narrow temperature regions I see both "dotty" data errors and more stable bit slips, typically by two bit positions.

--- Quote Start ---

How much does your data change?

--- Quote End ---

On average, there are changes more than 50% of the time.

Worst case, ~300 bits without changes and then a short burst at 100% changes, but worst case is extremely rare.

--- Quote Start ---

As for a training pattern, I've heard pretty much anything with transitions will work, but with fewer transitions it may just take longer. It is not looking for a pattern though(such as 10-bit comma), just transitions to figure out where the data changes and where to center the clock.

--- Quote End ---

That's what I, too, thought would be logical.

However I see different behavior in the field. Sometimes it looks like after achieving initial lock a DPA machine completely stops tracking [very slow in my case] data phase changes. That despite transmitted data containing significant number of transitions.