Hello,We have a board with multiple IDE interfaces implemented in Virtex2 device. We are using UDMA 3 protocol.One of the boards is giving a CRC error at random times, erros occurs once in 12 hrs of continous read operations. Error occurs on the same IDE channel.There does not seem to be anything wrong with internal logic, as other instantances of the same IDE module(multiple IDE interfaces) work fine on the same board at the same time.The strobe is routed to general I/O and then routed to IOBs to clock the data in. The data is then picked up by internal clock. Hence strobe is used as a clock only at the IOB's. I also carefully selected the strobe and the data IOBs so as to be able to use the long Hex lines present on the vertical side of the FPGA to route the strobe signal. Hence the skew and delays on the strobe are minimum and within setup and hold times.Yet their are CRC errors once in a bluemoon, the CRC error rate varies from board to board, some boards dont show it at all, others do.The rise time on channels not showing errors is about 10ns and final Vih is about 3.2V.The rise time on channel with CRC error is about 15ns and fianl Vih is about 3V.The above measurements were taken near the cable connector after the termination resistors. From the point of measurement to FPGA there is about 6" of PCB trace. (The termination resistors are near the cable connector as per UDMA spec to match the cable impeadance.)Question is1) How slow can a strobe/clock signal be before it starts to cause trouble clocking the data?(Due to cross talk or double clocking or any other reasons)Is 15ns rise time too slow for V2 FPGA?All these lines(data/strobe and other lines) run parallel for 6-8" inches on PCB board so I suspect some crosstalk or other SI issues are casuing the problem.All inputs are LVTTL 3.3V, no IBUF delays used on strobe or data. On Strobe pins I have enabled DCI with 50 Ohm resistor. But now my understanding is that for LVTTL 3.3V input pins, DCI does no good.A...

If you use STROBE as a rising-edge clock input, then excessive noisemight be superimposed on its falling edge, such that the falling edgeactually contains a rising edge clock, which would give you weirdtiming.Just a wild guess...Peter Alfke

Slow rising strobe used to clock IOB's, can it cause trouble?

S

Sebastian Weiser 21 years ago

In this very case, it would be even simpler (without scope). The size of a single transaction is programmed by the host. You could simply count the number of received words (feeded into the CRC calculator).

Sebastian

Vote

S

Sebastian Weiser 21 years ago

So you have a clock domain crossing here. Could it be a problem of metastable flipflops? What are your constraints of the inter-domain paths? How many stages has your synchronizer logic?

Sebastian

Vote

B

Brijesh 21 years ago

I use two stages to synchronize the Strobe signal. I doubt its metastable issue. Cause there are 8 channels of IDE and only one channel always gives the error. It cannot be that selective :-).

One thing that points this not being metastable issue or synchronization issue is that, the frequency of CRC errors seems to be data dependent. By that I mean, the CRC errors occur more frequently when data toggles a lot of bits. Iam rigging up test to check this more thoroughly.

New observation is that new model of hard disks are more prone to CRC errors than older ones I was testing with. Probably they have stronger drivers :-). Will find out once I have scope to properly measure the rise time and ringing.

I will also try out what Peter suggested, regarding checking for double clocking. I have been hesitant to make code changes or a new place and route before understanding the issue. But now I guess I am pretty confident there is nothing wrong in the design and/or timing constraints. So will go ahead with above changes.

Once again thanks for all the help.

Brijesh

Vote

Slow rising strobe used to clock IOB's, can it cause trouble?

Join the Discussion

Didn't find your answer?