Setup and hold times

#1

Hello,
We have made a custom board for the LMS7002M and for a multi channel system are connecting it to a Xilinx Virtex-6 FPGA. The problem is achieving timing closure.
As per the datasheet of the LMS7002M
Tsetup_min = 1ns
Thold_min = 0.2ns
which gives a window of 1.2ns which is very tight and from discussion on a Xilinx forum even the top end FPGAs would have difficulty in achieving this.
That said, the LMS7002M is already in production, numerous LimiMini and USB SDR boards are being used and that too with a normal Altera FPGA. Which means that the constraints do not need to be so tight.
May I ask you to please advise on what kind of constraints need to be used on the setup and hold times for both Tx and Rx to achieve timing closure.

Further, going through the sdc file of the Quartus project for LimeMini,
Tco_max and Tco_min are 1.05 and 2.9. Please advise on how these are measured and what do they mean in context of MIMO DDR mode interface.
LMS_LMS7_Tsu (setup) is 1.20
LMS_LMS7_Th (hold time) is 1.00
is there a typo in the datasheet?
@Zack ?
Regards,

#2

Hi @EnthuMan,

For the TX (FPGA transmits data to LMS7002M):
LMS7002M datasheet specifies Tsetup_min = 1ns, this means that you have to ensure that data from FPGA on DIQ1 bus should be stable at least 1ns before latching edge of FCLK1.
Thold_min = 0.2ns from LMS7002M datasheet means that you have to ensure that data from FPGA on DIQ1 bus should remain stable atleast 0.2 ns after latching edge of FCLK1.

In other words LMS7002M datasheet says that 1.2ns window is enough for LMS7002M to capture data corectly.
Values LMS_LMS7_Tsu and LMS_LMS7_Th in LimeSDR-Mini project are increased and should give a wider window than LMS7002m requires.
This is done because we have to take in mind that real world signals are not ideal - clock jitter, board trace delays, rise and fall times ect…

For the RX (FPGA receives data from LMS7002M):
Tco_max and Tco_min values includes board trace delays which are board specific and are measured at FPGA pins between MCLK2 and DIQ2 lines.

LMS_Tco_max = 1.05 and LMS_Tco_min = 2.90 says that in worst case, stable data reaches FPGA 1.05ns after MCLK2 launch edge, and stays stable for 2.90ns.

#3

Hello @Zack,
Thank you for the answer.
How do we find out Tco_max and min for our board setup? Is there a way to do with code inside the FPGA because measuring it on the board with the BGA package FPGA seems impossible. Further we probably need a fancy oscilloscope to measure time intervals with a resolution of ps.

  1. How does Tco fit in the context of MIMO DDR mode
    Eg: If MCLK2 is 100MHz, then the first DDR sample will start 2.5ns before the first rising edge and finish 2.5ns after the rising edge. So when you say 1.05ns after MCLK2 launch edge does it mean it mean this first sample?

  2. Can you please provide a number about the Tco_max and Tco_min at the output of the LMS chip? We can then factor in our board delays/mismatches and come up with approximate numbers that can be used in our timing constraints.

  3. Should the names be vice versa, i.e., LMS_Tco_max = 2.9 and LMS_Tco_min = 1.05?

Regards,

#4

Hi @EnthuMan,

  1. You can use FPGA resources such as PLL to realign clock to capture data in the middle of data valid window. As we are doing in LimeSDR-Mini and other boards.

  2. Yes, if MCLK2 rising edge (launch edge) appears at 0ns, add Tco_max value and you get when first DDR sample appears.

  3. LMS7002M datasheet provides Data output delay (tOD) which is max 6 ns.

  4. No.

#5

Hello @Zack,
Apologies for persisting on this.

  1. As per the datasheet, data output delay is 6ns is this the same as Tco?

  2. For a typical multilayer pcb 1mm corresponds to 6.5ps.
    So for the LimeMini if the delta between the launch edge and data valid is 1.05ns, that means the clock has been delayed by 6 - 1.05 = 4.95ns which translates to 1313mm of PCB trace length which definitely doesn’t seem right.
    I think I am missing something in my understanding, please advise.

  3. We checked the Gerber of the LimeMini and compared two DIQ2 lines and MCLK2. Both are length matched to within ~0.5mm which means that there is no skew introduced by the PCB or the Tco at the output of the LMS ship should be maintained at the FPGA.
    Regards,

#6

Hello @Zack,
Looking forward to your input.
Regards,

#7

Hi @EnthuMan,

  1. Yes

  2. 6ns is absolute maximum value in worst case conditions specified for LMS7002M, values in LimeSDR-Mini project is what we have measured for for LimeSDR-Mini operating in normal conditions.

My advice for you would be to connect MCLK2 clock from LMS7002M to PLL inside FPGA, set LMS7002M so that it outputs known alternating values on DIQ2 bus. Then you can phase shift clock in small increments, note phase shift value at which you are starting to receive correct data, continue increasing phase shift and note value at which you no longer receive correct data. This way you will get values which you are asking for your board.

#8

Hello @Zack,
Your idea sounds good. Please advise on how to configure LMS to generate alternating values.
I suppose TSG has to be used. But TSG can be configured to generate either fixed values or NCO output.
Hence the question.
Thanks again,

#9
#10

Hello @Zack,
Was finally able to get the setup ready to change the phase of the FPGA PLL output under user control. Thank you for the suggestion.

Status: Able to get clean data up till CGEN = 400MHz (with decim = 2, so DDR data out is at 200MHz with MCLK2 at 100MHz).
However when I try with CGEN = 600MHz, I am unable to get clean data for any phase shift value.
Please advise.

Important concern:
For the CGEN = 400MHz or MCLK2 = 100MHz setup, the high time of clock is 5ns and low time is 5ns.
The range of delay (using PLL) over which the data was obtained without noise is about 1.4ns.

In my understanding the available phase shift range or delay (sorry for using the terms loosely), should be close to 5ns rather than the rather low 1.4ns.
In the above figure, this range is indicated by t1 while the non-usable time is shown by delta1 and 2 (d1 and d2).
Am I missing something?
The lengths on the FPGA board are well matched and in fact the same board has been used to interface a serial LVDS ADC running at 500MHz DDR (in short, the PCB is alright).

There are three attributes which can cause the narrowing of this window:

  1. Jitter on the data lines
  2. Length mismatch in the PCB
  3. rise and fall times
    I am ignoring the setup and hold times of the FPGA as the FPGA is a Virtex 6 FPGA which has tsu and th of the order of a few tens of ps.
    We have checked the total trace length from the chip to the FPGA pins and the maximum mismatch is about 700mils which translates to about 110ps.
    So either there is a lot of jitter on the data lines (DIQ2) or the rise and fall times of the data lines is quite high.

Question 1: Is the phase adjusted in the LimeMini in this way?

Problem 2: Let’s say I am able to get all the LMS ICs give out correct data using this approach (i.e., each IC needs a different phase shift (worst case scenario)).
For my application I need to combine the data (beamforming) so I how do I get them to a common clock domain while maintaining synchronization.
FIFO approach might be one but I am not clear about how it would give me consistent synchronization (not to forget repeatable across power cycles and boards).
Looking forward to your input,

#11

Hello @Zack,
Looking forward to your inputs.
Regards,

#12

Hello @Zack
Looking forward to your inputs to my previous post.
2) Please advise on the clock output delay so that I can try to receive data using timing constraints and have the fpga place & route do the work for me.
Thanks again,

#13

Hi @EnthuMan,

All the timings we use on our boards were provided as well as dynamic phase search suggestion. This is all I can suggest you without hawing real hardware.

#14

Hello @Zack,
Looking forward to your help on this:

  1. We tried your suggestion of configuring the LMS to send out known fixed values using RxTSG.
  2. In the FPGA the phase was tuned to correct data.
  3. RxTSP was configured for normal operation mode.
  4. Did not get correct data
  5. Then went back to RxTSG mode (step1) and acquired data. Data this time was not correct.
    (Nothing was changed from step1 to step 5 except switching between normal mode and TSG mode).
    Please advise and thank you for your time,
    Regards,