DAC39J84: 8B/10B disparity error in DAC39J84 setup?

Hi Travis
We have received your question. One of our DAC experts will provide a more detailed response to your question soon.
Best regards,
Jim B

Travis,

Send me the LMFS settings you are using, along with the "K", and "RBD" values, the interpolation factor, SYSREF frequency, and DAC sampling frequency, and I will send you a working configuration file that you can compare to yours.

Regards,

Jim  

Hi Jim,

L (#lanes) = 8
M (#converters) = 4
F (#octets per frame) = 1
S (#samples per frame) = 1
HD = 1
RBD = 32
K=32
Interpolation = 0
Sysref Frequency = 31.250MHz (The FMC120 has an LMK04828 on it, PLL2 is running at 3GHz and has a divide value of 96, so 31.250MHz).

If you've got a config file that would work for this, I'd appreciate it.

Here are the writes I'm doing to init the DAC - this is for the FMC120 on a ZCU102.

// This resets the dac
void reset_and_wake_dac()
{
u8 data;
data = read_cpld(0x02);
data &= 0xCF; // Reset and wake dac
write_cpld(0x02,data);
data |= 0x20; // Clear reset bit
write_cpld(0x02,data);
}


void FMC120_dac_init()
{
reset_and_wake_dac();
write_dac_spi(0x02, 0x0083);
write_dac_spi( 0x4A, 0xFF1E);
write_dac_spi( 0x46, 0x0044);
write_dac_spi( 0x47, 0x190A);
usleep(10000);
write_dac_spi( 0x02, 0x2082);
write_dac_spi( 0x01, 0x0050);
write_dac_spi( 0x03, 0xA300);
write_dac_spi( 0x04, 0x0000);
write_dac_spi( 0x05, 0xFF03);
write_dac_spi( 0x06, 0xFFFF);
write_dac_spi( 0x1A, 0x0000);
write_dac_spi( 0x1F, 0x4440);
write_dac_spi( 0x1E, 0x4444);
write_dac_spi( 0x20, 0x4044);
write_dac_spi( 0x24, 0x0020);
write_dac_spi( 0x33, 0xAF40);
write_dac_spi( 0x3C, 0x0228);
write_dac_spi( 0x3D, 0x0088);
write_dac_spi( 0x3E, 0x0108);
write_dac_spi( 0x3F, 0x0000);
write_dac_spi( 0x00, 0x0018);
write_dac_spi( 0x25, 0x2000);
write_dac_spi( 0x31, 0x1000);
write_dac_spi( 0x32, 0x0000);
write_dac_spi( 0x3B, 0x0800); //config59
write_dac_spi( 0x49, 0x0);
write_dac_spi( 0x61, 0x01);
write_dac_spi( 0x4B, 0x1F00);
write_dac_spi( 0x4C, 0x1F07);
write_dac_spi( 0x4D, 0x0300);
write_dac_spi( 0x4E, 0x0F4F);
write_dac_spi( 0x4F, 0x1cc1);
write_dac_spi( 0x5C, 0x1111);
write_dac_spi( 0x5F, 0x0123);
write_dac_spi( 0x60, 0x4567);
//
write_lmk04828_spi( 0x10F, 0x11 ); Sets the output format of the device clocks. [Note that this is for the LMK, not the dac.]
//
usleep(50000) ;
write_dac_spi( 0x4A, 0xFF1E);
usleep(50000);
write_dac_spi( 0x4A, 0xFF00);
usleep(50000);
write_dac_spi( 0x4A, 0xFF01);
usleep(50000);
write_dac_spi( 0x6C, 0x0);
write_dac_spi( 0x6D, 0x0);
for (u8 i = 0; i < 8; i++)
{
write_dac_spi( 0x64 + i, 0x0000); // Clear alarms
}
}

Hi Jim,
Let me know if there's anything else you need - I could certainly use a second set of eyes, it's driving me crazy.

DAC39J84_841_1G_K32_1X_Int.cfgTravis,

The attached config file uses your settings. With the FPGA configured on our setup, after applying power, I load this config file and get a valid output after it completes. Note that the command called "DAC_RESET" in the file is actually doing a hardware reset to the DAC. All other commands are register writes to the LMK and DAC.

Regards,

Jim

Jim!

That helped a ton; here's what I'm seeing:

On the FPGA side, I see that SYNC gets lost after data gets through, so we're passing ILA:

Here's my question:
Could the repeating SYSREF be to blame for the temporary loss of SYNC? 

Seeing as how the SYNC gets (and stays) valid for such a long time before being lost only temporarily, that means it's probably not the frame buffer or a link issue - otherwise there'd be loss much sooner.

Is there any other way I can attack this problem from the point of view of the DAC39J84? Or put another way: Is there a set of register reads I could do that would prove that the problem was on the FPGA side? 

Thanks a ton, this has been a huge, massive help. It's SO CLOSE to behaving!

EDIT: 

I think sync_n is reporting an error:

disable_err_report_link0/disable_err_report_link1 - config82 and config85, respectively?

Travis,

Can you turn off SYSREF and see what happens? What if you divided SYSREF by 64 or higher? Does SYNC still change at every SYSREF edge or sooner? If this is an issue with SYSREF, there is a test you can do on the DAC side to verify the SYSREF is meeting setup and hold time. Follow the documents attached. Basically, if you run the DAC using the NCO output only, and synchronize the NCO logic with SYSREF, if you leave SYSREF running continuously, every rising edge of SYSREF will reset the NCO logic causing the frequency of the NCO to change. This will appear as many pulses on the DAC output when using a spectrum analyzer. If for some reason SYSREF was not captured properly by the DAC, the NCO would not reset and appear as one solid tone on the DAC output.

On the FPGA side, are you providing the proper ref clk frequency? Is the RBD value less than K? Is matched on both ends?   

Regards,

Jim

SYSREF trouble-shooting.docxDAC38J84 NCO SYSREF Test.pptx

I tried turning off SYSREF and moving to a pulse, triggered by SPI - no dice. I'm able to command a SYSREF pulse, but it doesn't solve the dropout issue.

SYSREF is currently divided by 96 in the LMK04828 (register 0x13A/0x13B, SYSREF_DIV).

The REFCLK for the FPGA should be 500MHz - that looks correct (also it has to be - otherwise I'd never see 0xBCBC for ILA).
The core clock is 250MHz (line rate of 10Gbps/40 for Xilinx JESD core).

SYNC is an input to the FPGA - transceivers being point-to-point links without the ability to apply backpressure, I don't think the FPGA can causing the issue. 

It looks like the I'm seeing the error counter for link0 as all 1's (that's...a lot of errors). I'm in LMF = 841, so I'm thinking I'm only utilizing link0 (1 link containing all 4 converters).

I tried changing the K value to 20 (down from 32) - I don't see a direct match for RBD in the Xilinx JESD core (instead it is listed as the size of a buffer, maximum octets per multiframe is 1024 - 20 frames, 8 lanes per cycle (so 8 octets), the buffer should be good enough (unless my math is off).

I haven't tried the NCO debug approach to check sysref timing yet; I'll get to it this week and update this! Thanks for your help so far.

After the updated config load, I see my ramp signal great on DAC A, but it looks "fuzzy" - it drops to 0 for the briefest instants. I'll update with pictures tomorrow!

Travis,

Anything new to report on your issue?

Regards,

Jim 

This is currently what I'm seeing on the output of the DACs; I'm expecing the ramp, but the fuzz I am not.

This is what I'm seeing looking at the Sync line of the FPGA:

Zooming out, you can see this pattern is repeated:

Same behaviour when I pulse SYSREF rather than have it continuously running.

This is what I'm seeing at the output of the DAC. The ramp is expected - the fuzz is not.

On the FPGA side:

Zoomed out:

You can see it is periodic, it drops out at the same spot every time, and it just isn't behaving. I'm pretty damn sure it has to be a setting, I just for the life of me have not stumbled on it yet. 

I've set SYSREF to be a single pulse as well with no joy. It doesn't look like an EMI/C problem - too periodic. I'm looking at transceiver settings for the DAC - that makes the SYNC behave less predictably (so far), but seeing the results change is somewhat encouraging. 

I'm having this same issue with a Xilinx IP core and the dac39j84.  Looking for some additional TI feedback on this.

David

David,

What Xilinx FPGA are you using? If this is a custom board, please try the attached SYSREF test to verify you have the correct setup and hold time for this input.

What is your sample rate, SYSREF frequency, lane mapping between the FPGA and DAC (If a custom board), LMFS settings, K and RBD values, interpolation factor, NCO settings (if used), internal PLL settings (if used)? With this information I can provide you with a DAC register configuration file.

Regards,

Jim

3060.SYSREF trouble-shooting.docx