DAC34SH84: Multi Device Synchronization Problem

Hey Bert, 

Which clock domain is being used to generate the OSTR signal inside the FPGA? Is it the 156.375MHz or 617.5MHz? The fact that you're seeing a play of 4 samples in time and the DAC's input data rate is 4x the internal FPGA rate makes is interesting. Have you looked at any of these signals on an oscilloscope? How does the timing at the OSTR signal look relative to the dataclk?

Regards, 

Matt

Hi Matt,

The OSTR signal is generated within the 154.375 [MHz] domain (single pulse for one clock cycle) and then delivered as an 8-bit data word to a Xilinx’s OSERDESE3 running in DDR-mode, which is clocked with both the 154.375 [MHz] clock and the 617.5 [MHz] clock. After that it goes through an ODELAYE3 and finally to an OBUFDS, which drives the LVDS pins of the FPGA. So, outside of the FPGA OSTR is a pulse of about 6.478 [ns].

I did not measure the signals with an oscilloscope yet – but I will try. You wrote the timing between OSTR and DATACLK is of interest. Did you mean timing between OSTR and DACCLK because these both have to fulfill specific requirements?

Hi Matt,

we made some progress here ... for LVPECL connections (DACCLK and OSTR) we used preferred configuration mentioned in data sheet page 46, figure 78. For OSTR we forgot to assemble the termination resistors (Rt = 150 [Ohm]). Since we added these resistors, the behavior is like described und point 3. in the original post – random alignment of the DACs outputs to each other.

What I also tried was measuring the signals with an oscilloscope. Therefore, I attached four small wires to the positive transmission lines of DATACLK, DACCLK, ISTR and OSTR. Since we have only 1 [GHz] bandwidth probes on a 1 [GHz] bandwidth scope to adapt these wires, DACCLK was not measurable. DATACLK, ISTR and OSTR behave like expected. All these three signals are also responding to the FPGA output delay settings properly – it is possible to shift them over 512 taps (5 [ps] per tap).

To make things more tangible, I would prefer to look at a single DAC first. The observed behavior is that the alarm status register (config5) shows a random state for bits 13:11 (alarm_from_fifo(2:0)) after each synchronization try (single pulse on ISTR and OSTR at the same time). Means, if I read the register I get “all fine”, or “pointers are 2 away” or “pointers are 1 away” or even “FIFO pointer collision”. What can cause this behavior for a single DAC?

Hey Bert, 

have you tried playing with the fifo_offset field? Maybe try a smaller value like 2 or 3 and see if the behavior changes. 

Regards, 

Matt

Hi Matt,

yes I tried to vary fifo_offset. It did not change the behavior - still random status in alarm_from_fifo(2:0)" after resetting read- and write pointer of the FIFO. Any other suggesetion?

Hi Bert,

Have you tried a sif_sync to see if a single DAC's 4 outputs become aligned? Please see register 0x1F field syncsel_fifo_input(1:0). Can you share the device configuration/registers for us to review? I imagine all 4 DAC configurations are the same, correct?

Regards, Chase

Hi Chase,

The outputs of a single DAC are perfectly aligned, no matter I use sif_sync, ISTR in single sync source mode or ISTR and OSTR in dual sync source mode. What is different, is the behavior of alarm_from_fifo(2:0) in these three cases:

• sif_sync: alarm_from_fifo(2:0) shows all states randomly,
• ISTR in single sync source mode: alarm_from_fifo(2:0) shows stable state (2-away, like set in register config9),
• ISTR and OSTR in dual sync source mode: alarm_from_fifo(2:0) shows all states randomly.

The configuration of all 4 DACs is identically. Please finde below a dump of one of them, if software is running (each row shows a single register (address/data)):

0x0/0x19c
0x1/0x100e
0x2/0x7082
0x3/0xf001
0x4/0x449f
0x5/0x1860
0x6/0x4100
0x7/0xffff
0x8/0x0
0x9/0x4000
0xa/0x0
0xb/0x0
0xc/0x400
0xd/0x400
0xe/0x400
0xf/0x400
0x10/0x0
0x11/0x0
0x12/0x0
0x13/0x0
0x14/0x0
0x15/0x0
0x16/0x0
0x17/0x0
0x18/0x280f
0x19/0x440
0x1a/0x20
0x1b/0x800
0x1c/0x0
0x1d/0x0
0x1e/0x1111
0x1f/0x1118
0x20/0x2400
0x21/0x0
0x22/0x1b1b
0x23/0xffff
0x24/0x0
0x25/0xaaaa
0x26/0x5555
0x27/0xaaaa
0x28/0x5555
0x29/0xaaaa
0x2a/0x5555
0x2b/0xaaaa
0x2c/0x5555
0x2d/0x4
0x2e/0x0
0x2f/0x0
0x30/0x0
0x7f/0x5428

Hi Bert,

I understand the issues now:

1. Each of the 4 outputs of each DAC is aligned with respect to each other, however the 4 DACs are not aligned.
2. Within a single DAC, the fifo error is not deterministic meaning that the fifo read and write pointers are random with each attempt to sync.

As the FIFO acts as an elastic buffer between the DATACLK and the DACCLK, these two rates should be equal (1235MHz/2x interpolation == 617.5MHz data clock, so no issue there). As long as the FIFO write pointer and read pointer are reset at the same time, the pointers will have an offset of 4 positions in the FIFO. And as long as the incoming DATACLK is the same as the DACCLK, then the FIFO pointers will never change position with respect to each other. They should always be 4 samples/positions apart. I know you mention the 1GHz BW limitation of your scope, but is there any way you can verify the output of the LMK04610 to ensure it is exactly 1235MHz and measure the FPGA DATACLK to be 617.5MHz?

Bert Borkam said:

• sif_sync: alarm_from_fifo(2:0) shows all states randomly,
• ISTR in single sync source mode: alarm_from_fifo(2:0) shows stable state (2-away, like set in register config9),
• ISTR and OSTR in dual sync source mode: alarm_from_fifo(2:0) shows all states randomly.

Regarding these different states:

• sif_sync: alarm_from_fifo(2:0) shows all states randomly,
  
  This is as expected behavior. As only the write pointer is reset while the read pointer is left untouched. It should be arbitrary. 
  
  
• ISTR in single sync source mode: alarm_from_fifo(2:0) shows stable state (2-away, like set in register config9),
  
  This is NOT as expected behavior. The behavior in single source mode should be the same as the sif_sync mode above. These are both single source methods of resetting the write pointer. I'm not sure where you are coming up with 2-away. Register 0x9 shows the initial fifo_offset as 4 in your register sequence. This is only applicable if both pointers are reset. Single source syncing will leave the output pointer in an arbitrary relative position as above.
  
  
• ISTR and OSTR in dual sync source mode: alarm_from_fifo(2:0) shows all states randomly.
  
  This is NOT the expected behavior either. The write pointer and read pointer of FIFO should be reset synchronously and upon every reset, the difference should always be the value in the fifo_offset register (which shows being set as 4 as I mentioned previously). 

Another thing I am curious about is whether the error is constant or if the position changes over time without resetting the fifo pointer after the 'initial' reset?

Regards, Chase

A few more notes:

If the position changes over time, if you disable the clkdiv_sync_ena (write 0x00 with 0x0198) AFTER initial reset, does it still drift? You can also try changing the clkdiv_sync_sel to be the ISTR signal rather than OSTR (write 0x20 with 0x2401). 

Also, I want to clarify the cases above for single source sync, the location of the output pointer is arbitrary so long as the syncsel_fifoout field remains set as OSTR while only the ISTR is applied. If you change this field to reset output fifo using ISTR (bit 9 on), then both pointers should reset synchronously and the offset should be 4.

Also, are you clearing the alarms each time by writing 0x05 with 0x0000?

Regards, Chase

Can you try with value 0x1F set as 0x1110 instead of 0x1118? The result should be the same but we have seen strange things in general happen over the years.

Hi Chase,

thanks for the detailed and fast answer ... First I would like to mention that there is no drift. I can leave the system over night, look at it in the morning and see that the output is in the same state and also alarm_from_fifo(2:0) has not changed. The only thing, which influences output and status is a synchronization event. So, I think from clocking point of view, everything is fine.

To your comments in blue:

• This is as expected behavior. As only the write pointer is reset while the read pointer is left untouched. It should be arbitrary.
  • sif_sync was used in dual sync source mode and set as source for FIFO write- and read pointer reset (config32 was 0x8801). So, my interpretation is that both pointers are reset. You mentioned that read pointer is left untouched. What is the right assumption? Why do I get random content in alarm_from_fifo(2:0)?
• This is NOT as expected behavior. The behavior in single source mode should be the same as the sif_sync mode above. These are both single source methods of resetting the write pointer. I'm not sure where you are coming up with 2-away. Register 0x9 shows the initial fifo_offset as 4 in your register sequence. This is only applicable if both pointers are reset. Single source syncing will leave the output pointer in an arbitrary relative position as above.
  • What I understood from the datasheet is that single sync source mode does not mean that only FIFO write pointer is reset. I was thinking that ISTR is used to reset the write pointer, is synchronized into the DACCLK domain AND used there to reset the read pointer (config32 is 0x2201). The other thing is that writing a 0x4000 to config9 should result in a FIFO pointer distance of 2, since fifo_offset(2:0) is located in bits 15:13 (a 0x8000 should be a distance of 4). Am I right?
  • So from my point of view a resulting 2-away in alarm_from_fifo(2:0) is what I expected. The problem in this mode is that the output delay is not reproducible over several synchronization events or over several startup.
• This is NOT the expected behavior either. The write pointer and read pointer of FIFO should be reset synchronously and upon every reset, the difference should always be the value in the fifo_offset register (which shows being set as 4 as I mentioned previously).
  • Here I am completely with you - this is not the behavior I would expect.

The tests you mentioned, I will do tomorrow and then come back ... It would be fine if you can go over my comments in before.

Best regards

Bert

Hi Bert,

I clarified my comments about this previously. if single source sync mode the syncsel_fifoout remains as OSTR then only write pointer is touched.

Regards, Chase