DAC39J82: Debugging Advice for Failing ILA in JESD204B

DAC38J82_421_983p04.pptx7181.DAC3xJ8x Device Initialization and SYSREF Configuration.pdf156.25_LMF_4211.cfgKyle,

We are very short handed right now due to trade shows and vacation. See if the following helps. I am assuming you are interpolating by 8 and have an input data rate of 156.25MHz. I generated a config file based on this as well as your other inputs and attached it with a few other documents. TI has a TSW14J10EVM that allows users to test our EVM's with off the shelf Xilinx development boards. Go to this product folder on the TI website to obtain documents regarding this along with sample source code.

Regards,

Jim

   

Hi Jim,

Thanks for your timely reply.  I've made some progress from my last post, and I believe I am getting lane alignment properly now!  I changed my JESD clock divider from an 8 to a 4 (setting the JESD clock to 312.5 MHz instead of 156.25 MHz.)  The Disparity and code sync errors are no longer triggering on the DAC.  I am, however, still getting errors for each of my four lanes complaining about: "write_error : Asserted if write request and FIFO is full" and "read_error : Asserted if read request with empty FIFO".  I am clearing and polling these registers every two seconds while running my system.

I've attached a new updated system timing diagram as seen by the logic analyzer core built into my FPGA showing the ILA sequence and data getting through.

The TI datasheet on my DAC has practically no details about the FIFOs... my best interpretation of my errors is simply that something about my DAC timing configuration is still messed up.  Is there any other insight that you could provide into those FIFO errors?  Have you seen problems with them before very often?  What are the typical issues at play in those cases?

Thank you very much for your time,

Kyle Harris

Kyle,

FIFO errors are usually caused by using an incorrect clock frequency, either for the data rate coming into the device or the DAC sample clock when interpolation is set to any value other than 1.

Regards,

Jim

Hi Jim,

Since my last post we've cleared up the write_errors in the FIFO, but we still are getting read_errors.  I'm going to try to slow down our system (use 3.2 Gbps line rate instead of 6.25 Gbps) and see if that affects anything, but I have a hard time believing it's just a clock configuration issue because  I've gone over the numbers quite a few times now, and _most_ of our data is getting across just fine.  We're verifying by generating our own modulated PRN sequence in our FPGA and sending that through the JESD to the DAC.  We are then correlating our DACs output with a pristine PRN file and we get a very high SNR, telling me what we're sending is very close to what it should be.  But whenever I reset and poll the lane error registers during transmission I always get that read_error.

Should I try setting interpolation to 1 and seeing if it goes away?  Is there any chance my slow down test will yield something useful, or is that a waste of time?  Have you guys ever seen something like this before, where the ILAS is working fine, SYNC is not getting lost, but there are persistent FIFO errors?

Thanks again,

Kyle Harris

Kyle,

What is the actual register address and error data value that you are getting? There is a FIFO read warning that customers sometimes confuse it to be an error. Did you clear the error registers before you read them? Can you send me your complete DAC configuration file and I can try this on our EVM with both an Altera FPGA and Xilinx FPGA to see if I can duplicate it?

Regards,

Jim  

Hi Jim,

Thanks for the timely reply! The registers I get the read_error bit set on are config100 - config103, all four of those (one for each of our lanes.) Specifically each of those registers is reading as 0x0002, and that bit set reads as follows in the TI DAC39J82 datasheet: "bit1 = read_error : Asserted if read request with empty FIFO". I am clearing those registers before I read them, as they are not automatically reset.

I am not using the TI EVM, but I'll see if I can send the python code we're using for setup to you.

Jim,

That worked, thanks!  Unfortunately for me it means that this FIFO error isn't the cause of a different problem we're seeing with our output, but it's good to know not to spend more time worrying over it.

Cheers,

Kyle Harris