# Forum: FPGA, VHDL & Verilog Determining trace delay for input delay constraints

Rate this post
 0 ▲ useful ▼ not useful
I'm currently fighting with an LTC2228 ADC which exhibits a parallel
data interface. I'd like to read in this data into a Xilinx FPGA with a
sampling frequency of 60 MHz. In order to set up the input delay
constraints I require an estimation for the additional delay which
arises due to the PCB tracks (approx. 60 mm track length between FPGA
and ADC). So far i used the datasheet values:

set_input_delay -clock ClockNet -min 1.4 DataLine
set_input_delay -clock ClockNet -max 5.4 Dataline

The values of 1.4 ns and 5.4 ns I obtained from the ADC datasheet,
however, the additional delay on the PCB traces was neglected. As far as
I understood, I had to account for them in the -max constraint twice
(the clock is generated from the FPGA, has to travel to the ADC and the
data has to travel back to the FPGA, so a total effective lenght of 120
mm would have to used). No what is a useful approximation for the
additional delay time I catch due to the traces?

The reason I'm asking is, that the values I read in are heavily noisy,
around 6 of the 12 bits seem to be more or less random. I would usually
look for the issue in the analog front since with filtering the data
matches the required result. However the PCB was already proven to work
fine with a different software - the only thing that changed was the
constraints and the clock frequency. I would have expected garbage data
for all of the bits if a timing violation causes the problem. Would
there be a justification why only the lower bits are affected if I mess
up timing?

: Moved by Moderator

Rate this post
 0 ▲ useful ▼ not useful
Timing violation schrieb:
> The reason I'm asking is, that the values I read in are heavily noisy,
> around 6 of the 12 bits seem to be more or less random.
Why? How do the signals look with a scope and a ground spring probe?
https://electronics.stackexchange.com/questions/40420/what-is-the-name-of-this-springy-type-oscilloscope-probe-accessory
Whats the timing difference between the edges in the data signals and
the clock signal?

> the clock is generated from the FPGA, has to travel to the ADC and the
> data has to travel back to the FPGA
And what of those "clocks" is used for sampling the "original" one or
the "returning" one?

> Would there be a justification why only the lower bits are affected if I
> mess up timing?
A timing problem would affect all of the bis. A timing problem cannot
distinguish the binary value of a signal.

What happens, when you (just for a test) sample with the "other edge" of
the clock? What happens when you add some 10cm into the clock line? What
happen when you slow doen the clock to 6MHz?

Rate this post
 0 ▲ useful ▼ not useful
Lothar M. schrieb:
>> The reason I'm asking is, that the values I read in are heavily noisy,
>> around 6 of the 12 bits seem to be more or less random.
> Why? How do the signals look with a scope and a ground spring probe?
>
https://electronics.stackexchange.com/questions/40420/what-is-the-name-of-this-springy-type-oscilloscope-probe-accessory
> Whats the timing difference between the edges in the data signals and
> the clock signal?

Unfortunately the signals are not really accessible (buried in PCB).

Lothar M. schrieb:
> And what of those "clocks" is used for sampling the "original" one or
> the "returning" one?

The clock is not returning from the ADC. The clock for sampling the data
stays in the FPGA.

Lothar M. schrieb:
>> Would there be a justification why only the lower bits are affected if I
>> mess up timing?
> A timing problem would affect all of the bis. A timing problem cannot
> distinguish the binary value of a signal.

That's what I thought, except that maybe the line drivers for the lower
bits are slower (would be a very rare coincidence indeed). I wouldn't
have thought in this direction if I wasn't very sure that the board
(especially it's analog part) are known to work.

Lothar M. schrieb:
> What happens, when you (just for a test) sample with the "other edge" of
> the clock? What happens when you add some 10cm into the clock line? What
> happen when you slow doen the clock to 6MHz?

I can't add anything to the lines. Slowing down the clock doesn't change
the noisiness but seems to change the DC-offset of the ADC (from 2 LSB
to 8 LSB, so still within the limits of the datahseet).

Rate this post
 0 ▲ useful ▼ not useful
https://www.analog.com/media/en/technical-documentation/data-sheets/222876fb.pdf

Page 14.

The ADC outputs the Bits tD (min: 1.4ns typ: 2.7ns max: 5.4ns) after
rising edge.
So you could use the falling edge to capture the Data.
Even @ 60 MHz tD_max (5.4 ns) + 2x trace travel time (<< 1ns) is short
enough that the data arrives before the falling edge (8.333ns).

Timing violation schrieb:
> The reason I'm asking is, that the values I read in are heavily noisy,
> around 6 of the 12 bits seem to be more or less random.

Could you post your HDL?

: Edited by User

Rate this post
 0 ▲ useful ▼ not useful
Gustl B. schrieb:
> The ADC outputs the Bits tD (min: 1.4ns typ: 2.7ns max: 5.4ns) after
> rising edge.
> So you could use the falling edge to capture the Data.
> Even @ 60 MHz tD_max (5.4 ns) + 2x trace travel time (<< 1ns) is short
> enough that the data arrives before the falling edge (8.333ns).

I understand that I could do that, but why would that be an advantage?

Gustl B. schrieb:
> Could you post your HDL?

Unfortunately I'm not allowed to. I understand that without the code it
will be difficult to determine, maybe I can strip it down on such a
basic level that I can place it here.

Rate this post
 0 ▲ useful ▼ not useful
Timing violation schrieb:
> but why would that be an advantage?

Because the data is stable at the falling edge.
In the FPGA you can use a dual clock fifo for clock domain crossing. Or
just use the data you captured with the falling edge with the rising
edge.

You also could only use rising edges and shift the fpga clock vs. the
Take the systemclock to an mmcm/pll and generate two 60MHz clocks. One
is only for the ADC. And the other is for capturing the data. And both
clocks are Phase shifted by 180°. You can try different shift angles
till it works.

Rate this post
 0 ▲ useful ▼ not useful
Timing violation schrieb:
> Gustl B. schrieb:
>> So you could use the falling edge to capture the Data.
> I understand that I could do that
And you didn't simply try it?
For me it looks like the safest way to get stable data.

And about clocks: how do you generate that clock? And how do you put
that clock out to the FPGA pin? Is there a skew in your internal clock
to the clock signal at the pin?

Timing violation schrieb:
> Unfortunately the signals are not really accessible (buried in PCB).
I didn't tell anything that measurig may be some kind of "easy". At this
very moment you see how useful it is to have testpads in the layout for
probing close to the pin... ;-)

Rate this post
 0 ▲ useful ▼ not useful
Lothar M. wrote:
> And you didn't simply try it?
> For me it looks like the safest way to get stable data.

I will will do so and report the result here once I had the opportunity.
I just didn't see why this would have been advantageous but your
explanation makes sense.

Gustl B. wrote:
> You also could only use rising edges and shift the fpga clock vs. the
> Take the systemclock to an mmcm/pll and generate two 60MHz clocks. One
> is only for the ADC. And the other is for capturing the data. And both
> clocks are Phase shifted by 180°. You can try different shift angles
> till it works.

And also this I will try out. But I assume I require some multi cycle
constraints to tell the tool on which edge I want to capture the data? I
have to look this up again.

Lothar M. wrote:
> And about clocks: how do you generate that clock? And how do you put
> that clock out to the FPGA pin? Is there a skew in your internal clock
> to the clock signal at the pin?

The Clock is generated by an MMCM. I output it by using a DDR flip flop
with constant inputs. I guess that's the way you are supposed to do it?

When I have a lock at the timing report, all these elements seem to be
accounted for. The reason I started worrying about the trace delay was,
that in the timing report a lot of slack is caught due to 'routing
delays' which tend to be in the range of 1-1.2 ns (and therefore larger
than the delays of simple signal buffers). However, you mentioned that
the trace delay would be "<< 1 ns". Why is the external delay so much
smaller although the physical dimensions on the PCB are for sure larger
than the tracks inside the chip? I assume that the output buffer driving
the FPGA output pin has a way smaller output impedance than the buffers
used on chip-level?
Just for curiosity: how would you estimate the PCB trace delay? I trust
you that it might be irrelevant here but what would be typical
estimations?

Rate this post
 0 ▲ useful ▼ not useful
Timing violation wrote:
> The Clock is generated by an MMCM. I output it by using a DDR flip flop
> with constant inputs. I guess that's the way you are supposed to do it?

You do not need the FF. Just connect the MMCM output to the FPGA Pin.

Rate this post
 0 ▲ useful ▼ not useful
Timing violation wrote:
> Lothar M. wrote:
>> And you didn't simply try it?
>> For me it looks like the safest way to get stable data.
>
> I will will do so and report the result here once I had the opportunity.
> I just didn't see why this would have been advantageous but your
> explanation makes sense.

I tried and it seems to not make a difference.

Timing violation wrote:
> Gustl B. wrote:
>> You also could only use rising edges and shift the fpga clock vs. the
>> Take the systemclock to an mmcm/pll and generate two 60MHz clocks. One
>> is only for the ADC. And the other is for capturing the data. And both
>> clocks are Phase shifted by 180°. You can try different shift angles
>> till it works.
>
> And also this I will try out. But I assume I require some multi cycle
> constraints to tell the tool on which edge I want to capture the data? I
> have to look this up again.

And also this lead to the same results.

Guess I'm chasing the wrong issue? This is not a timing problem?

Rate this post
 0 ▲ useful ▼ not useful
Timing violation wrote:
> I tried and it seems to not make a difference.
> This is not a timing problem?
For sure not!
Otherwise you may have seen a difference when you reduce the speed.
You should have seen a difference when you sample with the other clock
edge. And the design must work when you do both of it together (reduce
speed to 10MHz and use the falling edge for sampling).

: Edited by Moderator

Rate this post
 0 ▲ useful ▼ not useful
So ... the ADC has an infernal reference. Do you use it correctly?
Do you drive the inputs differentially around V_cm?

Rate this post
 0 ▲ useful ▼ not useful
Timing violation wrote:
> Why is the external delay so much
> smaller although the physical dimensions on the PCB are for sure larger
> than the tracks inside the chip? I assume that the output buffer driving
> the FPGA output pin has a way smaller output impedance than the buffers
> used on chip-level?

Here I can't give a precise answer. If someone can explain this better
than me, I would appreciate it.

Inside the chip you have much much smaller traces and therefor a higher
resistivity. As you sad, the I/O pad can drive much more current than
the internal logic (It's size is also huge compared to the logic).

Inside FPGAs you not only drive copper/aluminium/polysilicon tracks you
go trough many switch boxes. They are made out of "pass gates" which are
anti-parallel connected MOSFET and allow bidirectional current flow
(Similar to those in traditional analog muxes like 4066).

> Just for curiosity: how would you estimate the PCB trace delay? I trust
> you that it might be irrelevant here but what would be typical
> estimations?

From my head it is around 70% of the speed of light. These article goes
into more details (unfortunately our firewall is broken and I can't
access EDN since weeks...):
https://www.edn.com/rule-of-thumb-3-signal-speed-on-an-interconnect/

• $formula (LaTeX syntax)$