Determining trace delay for input delay constraints

Timing violation Guest #6418382
Rate this post
• ▲ 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?
Reply Quote Edit Move Thread sperren Anmeldepflicht aktivieren Anpinnen Delete topic Thread mit anderem zusammenführen Report post
Lothar M. Moderator (Company: Titel) #6418409
Rate this post
• ▲ 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?
Reply Quote Edit Delete Report post
Timing violation Guest #6418587
Rate this post
• ▲ 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).
Reply Quote Edit Delete Report post
Gustl B. #6418769
Rate this post
• ▲ 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?
Reply Quote Edit Delete Report post
Timing violation Guest #6418837
Rate this post
• ▲ 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.
Reply Quote Edit Delete Report post
Gustl B. #6418851
Rate this post
• ▲ 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 
ADC clock.
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.
Reply Quote Edit Delete Report post
Lothar M. Moderator (Company: Titel) #6419318
Rate this post
• ▲ 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... ;-)
Reply Quote Edit Delete Report post
Timing violation Guest #6419419
Rate this post
• ▲ 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
> ADC clock.
> 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?
Reply Quote Edit Delete Report post
Timing violation Guest #6420464
Rate this post
• ▲ 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
>> ADC clock.
>> 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?
Reply Quote Edit Delete Report post
Lothar M. Moderator (Company: Titel) #6420510
Rate this post
• ▲ 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).
Reply Quote Edit Delete Report post
Christophz Guest #6421497
Rate this post
• ▲ 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/
Reply Quote Edit Delete Report post
Watch this topic

Reply

Please log in before posting.

Existing account

or

Log in with Google account

No account?

Registration is free and takes only a minute.

Register now