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

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 is

1) 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 separate question I was trying to look up the source impeadance/input impeadance of V2 outputs/inputs, couldn't find the number anywhere. Are they specified?

Thanks in adavance for taking time out to read the post. Brijesh

Reply to
Brijesh
Loading thread data ...

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

Reply to
Peter Alfke

Brijesh, Have you considered using the strobe signal at a latch enable rather than a clock? Rise time is then unimportant. t\The IOBs' storage elements can be latches, IIRC. As for pin impedances, you need to use the IBIS files to determine this. Do you have HyperLynx? Cheers, Syms.

Reply to
Symon

Hello Peter,

Its DDR scheme. Data is clocked in both on the rising edge and falling edge.

My main question is still how slow is too slow?

Thanks

Brijesh

Reply to
Brijesh

Hello Symon,

Its DDR scheme so simple Latch scheme wont work, as data is only stable during the rising/falling edge of the strobe.

Even otherwise, as I mentioned there are multiple channels and all of them work just fine, except this one. Thats led me to believe its not design problem, but SI issue.

Have not really worked with IBIS files. I did peek into IBIS files for the first time and found they do not have a direct number. :-) Don't have HyperLynx, will read up about it.

Thanks Brijesh

Reply to
Brijesh

noise

edge

falling edge.

Reply to
Peter Alfke

I'd look to see why is that channel slower ? Slow edges also mean timing skew. You could also deliberately slow a good one down, to see if that causes similar errors, and slow the poor one a little more, to see if it worsens.

-jg

Reply to
Jim Granville

Peter,

I understand that DDR does not invalidate your response. Just mentioned it clear up things.

I just wanted to know if I was heading in the right direction by suspecting that slower rise time may be causing the problem.

Since I didnt know how slow is too slow, hence the question. So now I know there is no fundamental limiting factor on how slow a edge can be on V2. I will concentrate my efforts on identifying if the strobe line is being corrupted by noise or cross talk.

I was hoping there was some rule of thumb from experience that edges slower than X ns/V is inviting trouble. :-)

Jim Granville,

Thanks for the response. Yess, I am going slow the edge on other channels and also on this channel and see if the errors occurs more frequently.

Thanks Brijesh

Peter Alfke wrote:

Reply to
Brijesh

Brijesh, It is possible to de-glitch your clock in the FPGA. Like this. Let's call your input clock, 'CLOCK'. OK, feed this into and back out of an unbonded IOB with the input delay turned on. This gives you 'CLOCK_DELAYED'. Add a SR latch. When CLOCK = '1' and CLOCK_DELAYED = '0', set the latch. When CLOCK = '0' and CLOCK_DELAYED = '1', reset the latch. The output of the latch is your new clock. The IOB-delay filters any glitches shorter than the delay. Cascade more unbonded IOBs for more delay. Horrible or what? Make sure you use MAXDELAY constraints in the UCF file, especially for 'CLOCK' to the latch. Manually place the latch next to the 'CLOCK''s input IOB. Cheers, Syms.

Reply to
Symon

According to the ATA/ATAPI spec, you need input buffers with at least

320 mV of hysteresis. The appendix notes that double clocking of the CRC calculator while capturing the correct data or calculating the correct CRC while capturing wrong data had been observed, thus the requirement. Maybe that's your problem? BTW: The spec also notes that your inputs must be 5 V tolerant, which AFAICS can't be achieved on a pure Virtex-II while keeping the correct dimensions of the series resistors. The FPGA must even widthstand 6 V ringing voltages. I don't know if a Virtex-II can do this.

I don't know much about these issues (I design circuits for FPGA/ASICs and do no "real" hardware), but don't you need to take LVCMOS33 for outputs?

The ATA/ATAPI specs dictate that the series termination plus input impedance is between 50 and 85 Ohms. How have you taken the values for your board without knowing those of the FPGA?

Sebastian Weiser

Reply to
Sebastian Weiser

There is an old slide presentation of mine on the web, where slides 100 and 101 describe a simple way to cope with double-pulsing clocks

.

formatting link

Peter Alfke ============================ Sebastian Weiser wrote:

occurs

same

correct

On

FPGA/ASICs

impeadance/input

Are

for

Reply to
Peter Alfke

Seems like I gave you a bad URL. Try this one:

formatting link

Peter Alfke

Reply to
Peter Alfke

Hello Sebastian,

The double clocking of the CRC generator mentioned was when strobe was directly used to clock the CRC generator. In my design I am using internal clocl for CRC generator. Although I am still using the strobe to clock in the data at the IOB's. So right now I suspect thats where the problem is.

So currently Iam trying to identify the cause, Is it really the double clocking that is causing the trouble? Is the double clocking occuring of ringing or because of cross talk? Trying to answer the above questions. Currently I am planning to slow the rise time further and see its effect.

We are using voltage clamp device from TI to limit the input volate to 3.3v.

formatting link

The Voh and Vol for LVCMOS33 and LVTTL33 on V2 device are identical and match that of the IDE spec. Also just read that the LVTTL and LVCMOS inputs have approximately 100mV of hysteresis.

The typical suggested values were used. Plus the spec recommends that we should terminate the cable rather than the device, ie. the termination resistors are placed as close to connector.

Thanks for the input. Brijesh

Sebastian Weiser wrote:

Reply to
Brijesh

Thanks for the link. It has some helpful tips and tricks.

Reply to
Brijesh

Hello,

How do you know when new values are available to take them into your core clock domain? Can double clocking occure at this point?

You could put the captured data on a debug output, capture it with an logic analyzer and compare it with your reference. High effort, though.

Really? I read in the ds031.pdf (v3.4) on page 4 in module 3, that Voh is 2.4 V for LVTTL and Vcco-0.4 for LVCMOS33. But anyway, the requirement is 2.4 V for UDMA3. I had the more restrictant Voh2=VDD3-0.51V in mind, which is required for UDMA5 and greater.

Again for UDMA5 and greater, there are additional requirements for the input thresholds to keep the average of the two close to 1.5 V. I think this is to ensure that a rising STROBE and a falling DATA edge will switch at the same time. Hmm - I see that the requirement for the 320 mV hysteresis is for UDMA5 and greater only, too.

Sebastian Weiser

Reply to
Sebastian Weiser

You have to distinguish between specs abd eality. The output voltage specs for LVCMOS and LVTTL are different, for historical reasons, since CMOS pulls up to the rail, and TTL traditionally had two diode drops below Vcc, therefore the 2.4 V (going back to T.I. in the 'sixties) In reality, the two types of outputs are the same, and "both" pull up to the rail. Similarily with Vol = 0.4 V. That stems from bipolar outputs that never reach ground. In CMOS (and all FPGAs are CMOS) the Vol at zero current is really zero volt. We carry a lot of distracting baggage, accumulated during 40 years of digital IC evolution... Peter Alfke

Reply to
Peter Alfke

That were my guess, but I usually try to stick to the exact wording of a specification, only to be sure.

Wouldn't it be possible to write the more stringent values to the Xilinx specs, independent of what JEDEC (or whatever) says? In some corner cases (such as the ATA/ATAPI requirements) this may help a bit. Currently I have a similar problem with a microcontroller specification: The given values may reflect maximum worst case, but are that pessimistic that they don't help at all.

Sebastian Weiser

Reply to
Sebastian Weiser

up

of

bit.

Reply to
Peter Alfke

Hello,

Just a follow up. Iam right now waiting for a better oscilloscope to see the ringing and crosstalk if any, hence the delay in response.

I sample the strobe signal at 133MHz and detect the edge. That way I kno w when new data is present on the IOB's.

Rest of the stuff guess has been answered by Peter :-)

Brijesh

Sebastian Weiser wrote:

Reply to
Brijesh

Simple test for double-pulsing: Just feed the signal under investigation as a clock into a toggling fip-flop. You will see double-pulses easily, they look like missing triggers, since they double-trigger. Even a slow scope shows that... Peter Alfke

Reply to
Peter Alfke

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.