AD9173 - issues with STPL test and not outputting data on DAC1

for #1, note that you still need to setup a "JESD mode" in dual link, since this sets up clocking on the intended datapaths. So if you had setup for mode0 as a single-link, the DAC1 datapath will not be active. I setup dual link mode 0 for both links (I run the entirety of table 53).  Also, I have the physical lanes mapped to logical lanes 0 and 1 for Link 0 and lanes 4 and 5 for link 1.  If what I said has nothing to do with what you’re suggesting then please expand on “setup JESD mode” :)

Consider paging both datapaths and DACs together, so you could write SPI at the same time and be sure that both are setup identically.  I do (where possible). I also tried individually.  Same results.

It would be great to have a 2nd board on hand to compare results. You can also use any the AD917x boards to compare mode0, in case you have one already.  We don’t.

Have you tried using ACE to program the EVB without it being connected to the KC-705? This would verify whether the board functions - we know programming via ACE yields the expected results. Yes.  That was my first test.  For the things that I can test in standalone mode this fails in a similar fashion.  (See numbered item 1 in my initial email below).  I can get DC tone on DAC0 most of the time when configuring DC test tone on Main NCO at 1GHz.  Never get a test tone from DAC 1 using main NCO test tone.  However, always (in the 5 tests I did) get a test tone from both DACs using channel NCO.  

your comment on "DAC1 randomly will not output a signal" is a curious one. Is this an intermittent issue you are seeing with DAC1? Or is the lack of output on DAC1 consistent? DAC 1 is “reliably intermittent”. DAC 0 is "unreliably intermittent."  I know that sounds odd, but I can count on DAC1 not producing a tone more times than not.  DAC 0 seems more resilient.  In some cases, DAC0 is outputting a waveform and DAC1 is not.  The JESD cores on the FPGA are being fed the same data stream (literally, the input data stream is duplicated in HW from a single source in RAM).  Every possible register that I can read which indicates status shows that both links are up and solid.  (See #3 below for which registers I’m reading).  And the fifo bits are clear (so no overrun, no underrun). The sync is a solid high, and the FPGA is streaming data (verified with chibscope on the MGT lines).  Is there a bit on the DAC that says: Yes the QBD is de-framing and the data is going to the DAC?  I can easily check it.    Also, I checked the board for physical damage or loose components.  I found none. 

Generally speaking (see comments about test modes below):  The chip behavior and the manual (and ACE) are inconsistent.  I get it, it’s a complex chip and this is rev 0 of the data sheet, so it is bleeding edge.  Which is why I’m asking for your help. 

Example 1:

what’s described in the manual always passes for the STPL test procedure.  Even if the wrong word is programmed into the check sequence.  Step 9 of the STPL test mode on page 44 of the data sheet (right hand column of the page).  It reads: "Wait for the desired time. The desired time is calculated as 1/(sample rate × BER). For example, given a bit error rate of BER = 1 × 10−10 and a sample rate = 1 GSPS, the desired time = 10 sec. Then, set SHORT_TPL_TEST_EN to 0.” If I set the SHORT_TPL_TEST_EN to 0 like they suggest, this test always passes even when I program the check values to be wrong.  (Incidentally, that led to no less than two wasted days while I tried to figure out how STPL could pass but no data was streaming).  The fix was to not set SHORT_TPL_TEST_EN to 0.  Then everything works as expected.  That fix was simple.

Example 2:

Look at table 58 on page 72.  This is the end of the startup routine.  The write to register 0x085 says to set it to 0x13 and the comment reads: “Set to the default register value”.   That is correct, this is the default value.  BUT, on page 88 the recommendation is to set it to a different value at the “end of the startup routine”.  So which is it?  I took a look at ACE and dumped the configuration stream out of it and did a line for line compare with the manual… that showed me ACE was doing a lot of additional writes to the AD9173 that aren’t described and/or even mentioned in the data sheet.  And I don’t mean a few additional writes, I mean 5x to 10x more.  If you convert the startup sequence of the data sheet into instructions, it comes out to about 100-200 SPI write instructions (I don’t remember the exact number).  ACE is doing closer to 1000…. And if I try to decode ACE, a lot of the registers it is writing to are not documented in the data sheet.

for #1, note that you still need to setup a "JESD mode" in dual link, since this sets up clocking on the intended datapaths. So if you had setup for mode0 as a single-link, the DAC1 datapath will not be active. I setup dual link mode 0 for both links (I run the entirety of table 53).  Also, I have the physical lanes mapped to logical lanes 0 and 1 for Link 0 and lanes 4 and 5 for link 1.  If what I said has nothing to do with what you’re suggesting then please expand on “setup JESD mode” :)

Consider paging both datapaths and DACs together, so you could write SPI at the same time and be sure that both are setup identically.  I do (where possible). I also tried individually.  Same results.

It would be great to have a 2nd board on hand to compare results. You can also use any the AD917x boards to compare mode0, in case you have one already.  We don’t.

Have you tried using ACE to program the EVB without it being connected to the KC-705? This would verify whether the board functions - we know programming via ACE yields the expected results. Yes.  That was my first test.  For the things that I can test in standalone mode this fails in a similar fashion.  (See numbered item 1 in my initial email below).  I can get DC tone on DAC0 most of the time when configuring DC test tone on Main NCO at 1GHz.  Never get a test tone from DAC 1 using main NCO test tone.  However, always (in the 5 tests I did) get a test tone from both DACs using channel NCO.  

your comment on "DAC1 randomly will not output a signal" is a curious one. Is this an intermittent issue you are seeing with DAC1? Or is the lack of output on DAC1 consistent? DAC 1 is “reliably intermittent”. DAC 0 is "unreliably intermittent."  I know that sounds odd, but I can count on DAC1 not producing a tone more times than not.  DAC 0 seems more resilient.  In some cases, DAC0 is outputting a waveform and DAC1 is not.  The JESD cores on the FPGA are being fed the same data stream (literally, the input data stream is duplicated in HW from a single source in RAM).  Every possible register that I can read which indicates status shows that both links are up and solid.  (See #3 below for which registers I’m reading).  And the fifo bits are clear (so no overrun, no underrun). The sync is a solid high, and the FPGA is streaming data (verified with chibscope on the MGT lines).  Is there a bit on the DAC that says: Yes the QBD is de-framing and the data is going to the DAC?  I can easily check it.    Also, I checked the board for physical damage or loose components.  I found none. 

Generally speaking (see comments about test modes below):  The chip behavior and the manual (and ACE) are inconsistent.  I get it, it’s a complex chip and this is rev 0 of the data sheet, so it is bleeding edge.  Which is why I’m asking for your help. 

Example 1:

what’s described in the manual always passes for the STPL test procedure.  Even if the wrong word is programmed into the check sequence.  Step 9 of the STPL test mode on page 44 of the data sheet (right hand column of the page).  It reads: "Wait for the desired time. The desired time is calculated as 1/(sample rate × BER). For example, given a bit error rate of BER = 1 × 10−10 and a sample rate = 1 GSPS, the desired time = 10 sec. Then, set SHORT_TPL_TEST_EN to 0.” If I set the SHORT_TPL_TEST_EN to 0 like they suggest, this test always passes even when I program the check values to be wrong.  (Incidentally, that led to no less than two wasted days while I tried to figure out how STPL could pass but no data was streaming).  The fix was to not set SHORT_TPL_TEST_EN to 0.  Then everything works as expected.  That fix was simple.

Example 2:

Look at table 58 on page 72.  This is the end of the startup routine.  The write to register 0x085 says to set it to 0x13 and the comment reads: “Set to the default register value”.   That is correct, this is the default value.  BUT, on page 88 the recommendation is to set it to a different value at the “end of the startup routine”.  So which is it?  I took a look at ACE and dumped the configuration stream out of it and did a line for line compare with the manual… that showed me ACE was doing a lot of additional writes to the AD9173 that aren’t described and/or even mentioned in the data sheet.  And I don’t mean a few additional writes, I mean 5x to 10x more.  If you convert the startup sequence of the data sheet into instructions, it comes out to about 100-200 SPI write instructions (I don’t remember the exact number).  ACE is doing closer to 1000…. And if I try to decode ACE, a lot of the registers it is writing to are not documented in the data sheet.