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

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

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. 

Peter Alfke wrote:

> 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
> 

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

Symon wrote:

Hello Symon,

> 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.

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.

> As for pin impedances, you need to use the IBIS files to determine this. Do 
> you have HyperLynx?
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


> Cheers, Syms. 
> 
> 

There is no fundamental limit. A flip-flop will be clocked, even if the
clock takes seconds or minutes to rise. But the longer the transition
time, the bigger the chance of picking up noise, and creating a
double-pulse. And the fact that you use DDR does not invalidate my
prvious response. Noise then has a chance to disturb either edge or
both.
Peter Alfke
============
Brijesh wrote:
> Peter Alfke wrote:
>
> > 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
> >
>
> 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

Brijesh wrote:
> Symon wrote:
> 
> Hello Symon,
> 
>> 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.
> 
> 
> 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.

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

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:
> There is no fundamental limit. A flip-flop will be clocked, even if the
> clock takes seconds or minutes to rise. But the longer the transition
> time, the bigger the chance of picking up noise, and creating a
> double-pulse. And the fact that you use DDR does not invalidate my
> prvious response. Noise then has a chance to disturb either edge or
> both.
> Peter Alfke
> ============
> Brijesh wrote:
> 
>>Peter Alfke wrote:
>>
>>
>>>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
>>>
>>
>>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
> 
> 

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. 

Brijesh <brijesh_xyz@cfrsi_xyz.com> wrote in message news:<d33k4c$sjr$1@solaris.cc.vt.edu>...
> 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.

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.
 
> 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.

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?

> 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?

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