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
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?
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).
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
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.
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.
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... ;-)
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?
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.
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?
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
So ... the ADC has an infernal reference. Do you use it correctly? Do you drive the inputs differentially around V_cm?
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/
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.