0
\$\begingroup\$

Given a common setup:

enter image description here

The green box is a PCB mainly consisting of a data acquisition device (ADC+RF frontend) which is controlled by a Spartan-6 FPGA.

The ADC & FPGA use a clock from a Tektronix signal generator which itself is configured to take the 10 MHz reference clock from a R&S SMW200A Vector Signal Generator.

Data acquisition is started from a laptop which sends a trigger event to the FPGA. Internally, the FPGA has multiple clocks but all of them are synchronuous to (and generated from) the 80 MHz clock.

The trigger event is synchronized to the respective FPGA clocks and start ADC capture. Furthermore, the "Trigger Signal" is synchronized to the FPGA slowest clock and stretched.

The SMW200A is configured to start outputting data exactly at this "Trigger Signal". Assuming all clocks are synchronized, all delays should be fixed for each trigger event.

However, this is the captured data for multiple runs:

enter image description here

The data always starts at either 118.5us or 118.75us delay. The difference is exactly one ADC sample (ADC is 4 MSps but uses the 80 MHz clock).

Now I am trying to figure out what could be wrong here.

  1. Does the output of the SMW200A always start exactly after a constant time after the trigger is applied (I don't think so).
  2. Is the trigger on the SMW synchronized to an internal clock? If so, which clock is this?
  3. How can this clock be synchronized with the rest of the system? (I assume the 10 MHz reference clock sharing only makes sure that that all systems share the same frequency uncertainties)
\$\endgroup\$
  • \$\begingroup\$ I can help you make the measurement result , but this is far from the method that will do this. what exactly do you want? Full s-parameter sweeps? on what signal and impedance? \$\endgroup\$ – Tony Stewart Sunnyskyguy EE75 Jun 20 '18 at 2:03
  • \$\begingroup\$ No, this is an entire system-level test involving LTE signals, digital-in-digital-out. S-parameters, impedances etc. have been measured and are am abstraction level below. The block diagram only shows relevant parts but I am happy to fill in more details if it facilitates understanding. The question is really generic - how to properly synchronize a vector signal analyzer in such a scenario and/or if the random time shift could have other reaons. \$\endgroup\$ – divB Jun 20 '18 at 2:19
  • \$\begingroup\$ The trigger for the VNA could be to start the spectral sweep of its internal RF out and internal VNA output which after processing and buffering has latency that you see . But you don’t show any RF connections. Can you define the test result you expect? I would think a water fall test would be more useful. \$\endgroup\$ – Tony Stewart Sunnyskyguy EE75 Jun 20 '18 at 5:46
  • \$\begingroup\$ Any chance of the ADC barely missing a trigger? They seem to be running on to the same external clock, but it seems that the ADC trigger is internally generated (stretched) right? \$\endgroup\$ – Sven B Jun 20 '18 at 6:25
  • \$\begingroup\$ @TonyStewartolderthandirt: Ops by mistake I used "Signal Analyzer" in the title. There is no VSA or VNA only a VSG (ARB) which acts as a modulated signal source. Its baseband samples have to be synchronized with the rest of the system I think. The purple connection is the RF connection (but I omitted much stuff that's just not important because time delays would always be constant). All I would expect is that if I issue the trigger to the system, the recorded signal at the ADC always starts at the same time. Reproducibly. \$\endgroup\$ – divB Jun 21 '18 at 23:12
0
\$\begingroup\$

Although there are a lot of hidden asynchronous delays in your Spartan slow clocks , they must be race - free in syncing ASG trigger to delayed ADC.

It seems there is a skew of 1 cycle of 80MHz which indicates a race condition exists. However it is not obvious in the lack of timing details where the variation in skew or race condition occurs and how small or large the jitter is that causes a cycle skip delay.

It could be < <1ns shift on the edge or it could be as much as +-6ns.

Therefore you must analyze why and where there is skew and how much jitter due to dependent variables like supply voltage, temperature or CMOS delays or whatever.

Then the trigger and ADC start sync can be done if necessary at a slower 10 MHz clock rate with a variable but accurate “ xxx ns” 1 shot delay. A digital delay is possible, but harder to control as well as the resolution of a pot.

Using a synchronous counter /N to test your system for both triggers , you can determine where the window of results is jitter free and actual system latency.

\$\endgroup\$
  • \$\begingroup\$ I'm afraid you are right. Without even sampling the data I let a counter run up and this gives me the same off-by-ones here and there. In the simulator (iSim) it works perfectly. BTW it happens at any clock frequency (even 100kHz!) Aaaah! \$\endgroup\$ – divB Jun 22 '18 at 4:56
  • \$\begingroup\$ have no fear. Just understand how it works then fix it \$\endgroup\$ – Tony Stewart Sunnyskyguy EE75 Jun 22 '18 at 5:12
0
\$\begingroup\$

You say the trigger from the laptop is synchronised to the FPGA clock and the slowest FPGA clock, are these separate syncronisers?

The thing I am thinking is that two syncronisers (even to the SAME CLOCK) are not guaranteed to transition on the same edge.

I would be syncronising with the slow clock and then using the fact that that clock is edge is syncronous with the fast clocks to avoid the need for further syncronisers (You would probably have to use some multi cycle path stuff in the constraints file).

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.