DAC3482: Spurious signals generated by SIF sync.

Hello Gavin,

I would advise that you check if the same SIF SYNC signal is being used to initialize the QMC and also the FIFO logic. The same SIF SYNC, if configured by config 30 to config32, to be registered to multiple DSP blocks, could potentially cause these type of transient response. The FIFO logic, especially, need to be disabled to register the SIF SYNC after the initial data interface bring-up. The reason is that the same SIF SYNC signal could reset the FIFO read pointer, and cause momentary reset in the data path (connected to the FIR and NCOs)

We can certainly check your configuration file if you are comfortable sharing. If you don't feel comfortable sharing, you may contact your local sales team to have them send over the configuration. I know there are dedicated team calling on your account.

-Kang

Thank you, Kang.
I will check this. I believe several registers are configured for SIF sync update and I don't believe we have changed this configuration from previous versions of our device. We have used this device for many years and not seen this issue. Suddenly we are seeing this issue and I don't believe anything related has changed.
Of note, we see this issue in some devices, but not on others. We are currently cross-referencing device date codes to see if we observe a correlation between date codes and this issue. However, what you suggest could definitely be related.

Using SPI communications, we configure the 3 sync configuration registers as follows:

dac3482_write(mod, DAC3482_CONFIG30, 0x1181);
dac3482_write(mod, DAC3482_CONFIG31, 0x818C);
dac3482_write(mod, DAC3482_CONFIG32, 0x2401);

Those values broken down are:

config30:
15:12 - syncsel_qmoffset(3:0) = 1h = Bit 12: Auto-sync from register write
11:8 - Reserved (0x1 default) = 1h
7:4 - syncsel_qmcorr(3:0) = 8h = Bit 7: sif_sync (via config31)
3:0 - Reserved (0001 default) = 1h

config31:
15:12 - syncsel_mixer(3:0) = 8h = Bit 15: sif_sync (via config31)
11:8 - Reserved (0x1 default) = 1h
7:4 - syncsel_nco(3:0) = 8h = Bit 7: sif_sync (via config31)
3:2 - syncsel_dataformatter = 11b = 11: No sync
1 - sif_sync .. Toggled for SIF Sync event, causes bad behavior in some units.
0 - reserved = 0, default.

config32:
15:12 - syncsel_fifoin(3:0) = 2h = Bit 13: FRAME
11:8 - syncsel_fifoout(3:0) = 4h = Bit 10: OSTR – Dual Sync Sources Mode
7:1 - Reserved (0x0 default) = 0h
0 - clkdiv_sync_sel = 1b = FRAME, SYNC, or SIF SYNC based on syncsel_fifoin source selection (config32, bit<15:12>)

Hi Gavin,

If it just a few devices, I would suggest that you also check the DVDD rail at the DAC3482 device pin. The DVDD consumes the most amount of current, and sometimes, through power supply filtering and PCB traces, the actual voltage with the device running may be lowered than the device limit. Try elevate by 50mV or so to see if this problem persists. 

We have also seen cases that the DVDD supply would sag (due to power supply loop constant and local decoupling limitations), and caused a momentarily dip in the DVDD rail and caused the logic inside the DAC3482 to glitch. This usually happens when DVDD rail is shared with other devices such as FPGA. I cannot think of ways that the DAC3482 sif sync trigger could cause sufficient current draw for potential voltage dip, but perhaps other sequence of other logic devices such as FPGA in executing the sif sync could cause this. 

Other recommendations on the settings. 

Gavin Schmidt said:

config30:
15:12 - syncsel_qmoffset(3:0) = 1h = Bit 12: Auto-sync from register write
11:8 - Reserved (0x1 default) = 1h
7:4 - syncsel_qmcorr(3:0) = 8h = Bit 7: sif_sync (via config31)
3:0 - Reserved (0001 default) = 1h

please try to set QMcorr to auto-sync (something besides SIF_SYNC) and retry

Gavin Schmidt said:

config31:
15:12 - syncsel_mixer(3:0) = 8h = Bit 15: sif_sync (via config31)
11:8 - Reserved (0x1 default) = 1h
7:4 - syncsel_nco(3:0) = 8h = Bit 7: sif_sync (via config31)
3:2 - syncsel_dataformatter = 11b = 11: No sync
1 - sif_sync .. Toggled for SIF Sync event, causes bad behavior in some units.
0 - reserved = 0, default.

Please advise if data formatter ever had a sync source. It should match the FIFO input sync source such as FRAME in your case. It is used to format the I/Q data in between the data paths. I can understand that after the initial data interface synchronization you can set it to 0 as no sync, but before and during the data interface synchronization, you must select FRAME and use FRAME to initialize this part of logic.

Gavin Schmidt said:

config32:
15:12 - syncsel_fifoin(3:0) = 2h = Bit 13: FRAME
11:8 - syncsel_fifoout(3:0) = 4h = Bit 10: OSTR – Dual Sync Sources Mode
7:1 - Reserved (0x0 default) = 0h
0 - clkdiv_sync_sel = 1b = FRAME, SYNC, or SIF SYNC based on syncsel_fifoin source selection (config32, bit<15:12>)

clkdiv_sync_sel should be OSTR to match the FIFO output pointer. It is meant to initialize the all the DSP logic after the FIFO output to ensure deterministic latency, and also ensure the FIFO output clocks are initialized the same ways as the OSTR pointer.

You may refer to the following app note for the details of the mechanics of the synchronization logic.

www.ti.com/.../slaa584.pdf