Hello,
I've been working with the ADS5400 and TSW1200 for a few weeks now and have been struggling to configure two parallel ADS5400 to synchronously capture data based on an input trigger clock pulse. I've been attempting to get the ADS's to capture on the same CLKin pulse, or if not on the same pulse, to capture data with a repeatable time offset. Instead of a single repeatable offset, I measure several different offset values that will reoccur as more measurements are taken. Although there are a few likely suspects as to what the delay between ADS's will be, I have no reliable way to make a prediction before taking a measurement. This is an issue since our experiment requires two systems to be either perfectly in sync or to show a repeatable delay which we can account for in post processing. The two systems consistently show a series of delays between captured data from one ADS to the other ADS. After running many tests to determine the offset it seems that the delay is always represented by the approx relationship, delay = n*3.5 (ns), n=0,1,2,3,4,5 (keeping in mind that with a 1ns clock the precision of this measurement is plus/minus .5 ns). Furthermore the relative phase of the two captured signals is always consistent with the delay. For example, a typical set of measurements could yield the following time offsets of a 300MHz signal pulsed at 50kHz, where the delay is defined as the time delay between the rising edge of the two pulse envelopes: delay = 3.5 (ns), 7 (ns), 11.5 (ns), and 15 (ns), with one ADS always outputting data before the other ADS. Additionally for values such as 11.5 and 15 (ns) the phase of the pulse envalope appears inverted relative to the first ADS signal. Our best guess based on the data is that our results show a physical delay corresponding to how the clock pulses pick up the signal. In looking at the possible clock signals that could produce a delay on the order of 3.5ns we noticed that the CLKout = CLKin/4 = 4 (ns) and that the latency of the CLKout after a reset pulse (we run in default which I believe is DBM) can be either 0 or 7-8.5 CLKin cycles = 0,7,8.5(ns). It doesn't seem like either of these alone makes any sense (we run a reset pulse after starting the system so both CLKout signals should be aligned before we trigger for data capture) but could they possibly both cause some delay in the same measurement to give one of the following values? e.g. where there are 1-2 missed CLKout pulses or missed CLKout pulses and a delay caused by Latency from both systems? These seem somewhat unlikely, but we are stumped... any thoughts??? Thank you, Jon Our test set up is as follows: Each ADS5400 is connected with a corresponding TSW1200 which is conected via USB to our capture computer. Both ADS systems are in default configuration (except that we hardwired a cable to receive the external trigger). We are using a 1GHz input clock path matched (within ~3ps) to each ADS. The input analog signal sent to both systems is from a single signal generator spit into two path matched (within ~75ps) channels. The data is captured using the Matlab control code that came with the TSW1200 (configured for the ADS5400), slightly modified to read/write from two separate devices. The capture code arms each ADS and tells them to look for an external trigger (based on the forum post explaining the set up an external trigger in Matlab) which is again path matched. The trigger is provided by a single pulse before the system is commanded to write the data and our processing begins. To measure the delay between the two ADS boards, we are running our analog signal in pulsed mode and simply looking at the delay between envelopes.
I should also note that we have not implemented the SYNC mode since we are collecting data through the TSW1200. It seems that to implement the SYNC functionality we would have to remove the TSW1200 and create cables from the LVDS port out to a data capture system (which I suppose would be Matlab).
Hi,
I believe the root of the issue here is that the external trigger to the FPGA is re-registered in the FPGA to synchronize it with the internal clock of the FPGA and this adds a clock cycle or two of uncertainty in exactly when the data capture begins.
The FPGA on the TSW1200 is programmed to use the maximum amount of internal memory available (in powers of 2, which turns out to be 1Mbit) set up as four banks of memory each being 16K words, and each word 16 bits. To get these large memories to run at the speed needed (250MHz) the large memories run synchronously on a 250MHz clock derived from the crystal oscillator on the TSW1200. The actual samples from the ADC are pushed into a small truly asynchronous FIFO using the clock from the ADC. But this small bridge FIFO is unloaded using the 250MHz system clock and the samples are pushed into the large memories synchronously. And all commununication with the PC is by way of state machines running off the 250MHz system clock. So the clock domain of the clock from the ADC stops at the inputs of the small FIFOs. Everything after that is on the 250MHz system clock.
When the external trigger signal occurs, the signal is resynchronized to the 250MHz system clock to be used with the state machines that start the capture. This is where a clock cycle of uncertianty occurs, and by that I mean a clock cycle of the 250MHz system clock. That is simply the precision with which we can start a data capture in response to the external trigger signal, considering the architecture of the capture memory in the FPGA.
I don't know of a way to ensure that two independent capture cards will always begin capture at exactly the same sample relative to each other every time.
Regards,
Richard P.
Hi Richard,
Thank you for the very timely response, your description of the problem is both clear and helpful. So if using two independent capture cards introduces several nano seconds of delay between the boards (in an unpredictable fashion) then it looks like we have to use another option to off board the data. Please correct me if I'm wrong (or missing something) but it seems like the options to retrieve the data are either through the LVDS port which will require a custom SAMTEC cable or through the ADC SPI Interface (which doesn't seem to support the ADS5400). I'm not terribly failure with read/write operations and have little idea what is required to interface and pull the data from the ADS without the TSW, can you offer any guidance in this area?
The only other outstanding issue that is that if we stop using the TSW I'm unsure of how to ensure that the capture begins at the same point in time. We have been using a synchronized TSW SW4 RESET to ensure that the latency of the read/write scripts doesn't show up as a delay in the two data captures. Admittedly I am not an expert in analog-to-digital conversion, however I was under the impression that synchronizing two ADC's within a clock pulse is common practice. If I am missing something fundamental or am misinformed please let me know.
Thank you,
Jon
The SPI port through the USB cable on the EVM itself is not there for pulling sample data from the ADC. The USB conenction for the SPI port is a low bandwidth connection for setting the mode of operation of the ADC through register writes to the ADC. The EVM itself does not have the buffer memory for data capture.
The alternative to the TSW1200 for data capture is a logic analyzer, generally. Our characterization work on new devices is done with a logic analyzer to capture the data which is then uploaded to a PC for processing. The TSW1200 is meant to be a convenience to replace the logic analyzer and to be able to reproduce data sheet performance on the apps bench given suitable signal sources. The TSW1200 doesn't replace *all* capability of the logic analyzer, adn for some applications we have to drop back to using the logic analyzer. (for example when we need to capture more samples than the TSW1200 can support.) For this we have a breakout board (that we can supply) that plugs into the Samtec connector of the EVM and then lets the logic analyzer pod(s) connect to the breakout board. I've never had to set this up, but i suppose a logic analyzer could be set up with logic pods to two EVMs, and then the logic analyzer is triggered to capture from both logic pods together.
It is common practice to synchronize two or more ADCs to a common sourrce, but that is usually when both ADCs are connected to the same capture unit. Synchronizing two capture units to each other complicates that a fair bit. For example, consider the joint EVMs between TI and SPDevices that synchronizes two ADS5474 into an FPGA http://focus.ti.com/docs/toolsw/folders/print/ads5474adx-evm.html or four ADS54RF63 into an FPGA http://focus.ti.com/docs/toolsw/folders/print/ads54rf63-adx4.html. After the capture is done from an ADC into an FPGA on two separate ADC EVMs into two separate FPGAs, synchronizing the two sets of samples becomes harder and the TSW1200 was not created with this in mind. It could have been done, as we had a similar issue with our TSW3100 pattern generators into multiple DAC EVMs and we wanted to synchronize the two DAC paths. We plan to support this level of synchronization for the capture function with our upcoming replacement to the TSW1200, but we are not there yet. It is in development.