This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DAC3164 FIFO Pointers / Sync Input

Other Parts Discussed in Thread: DAC3164

Hi TI,

We are using a DAC3164 to generate complex baseband waveforms from an FPGA, going into a discrete integrated upconverter (ie, fairly standard software defined radio applications). We have the ability to produce test patterns from our FPGA to the DAC3164 running at 500 MS/s. The test patterns are Fs/4 tones, Fs/8 tones, etc. When we generate these complex tones, we get the following fairly confusing results: 

  • Fs/4 tones always look fine.
  • Fs/8 shows -45-ish dB attenuated tones at -Fs/8, Fs/4, and -Fs/4
  • As Fs tones approach 0 Hz, more and more side tones appear, but they are no longer at obvious relations to the sample rates (and are not symmetric about 0 Hz).

When investigating this, we have started to think this has something to do with the sample transfer FIFO in the device from DATACLK to DACCLK. We always see FIFO pointers being close (either 1 away, 2 away, or collision), but only on *one* of the two FIFOs (usually A, sometimes B). I have only once seen both FIFOs act “in sync”, which is what I would have expected for the system. I suspect this is the root of the problem (the A/B samples are not aligned).

I am using the “sync” input by asserting "sync" for two clock cycles (4 ns @ 500 MHz), but it doesn’t seem to be done anything. It seems to me that there should be no way to have the A/B FIFOs with different pointer values, since they are both driven by the same clocks. I find this confusing in the part, and I think this is the source of my problem.

For what it’s worth, I tried repeatedly disabling/re-enabling the B clock (register 0x01, bit 14) and repeatedly forcing a SYNC operation and I once got a “reasonable” looking tone out (and the FIFO pointers were all showing valid A and B FIFO pointers), but I have not been able to repeat that.

We are 86.7% sure the board is laid out correctly and we do not have pin pair swaps and/or LVDS pair inversions.

Any ideas how to move forward?

Thanks,

Nathan

  • If you are getting FIFO collision errors or are very close to getting FIFO collision errors and SYNC is not clearing it, then I suspect that you are not using the ALIGN inputs or are not using the synconly_ena bit in register CONFIG0.   The SYNC input will reset the FIFO write pointers.  The ALIGN input will reset the FIFO read pointers.  If these are reset together then the FIFO pointers should be about centered.    If you don’t use ALIGN input, then the synconly_ena can be used to make SYNC reset both sides of the FIFO.  If the FIFO pointers are still not quite centered then the fifo_offset in CONFIG9 may be adjusted away from default to try to fine tune the FIFO centering.    There is an app note on a similar device that goes into great detail on the use of the FIFO initialization, mostly in relation to multi device synchronization but it also still applies to how the FIFOs operate.   But having a SYNC event on the FIFO in side and no similar event on the FIFO out side would not be enough I think.  Are you providing a reset event on the output side of the FIFOs using ALIGN or by setting it up to use SYNC?  If not, would you please?  That app note I mentioned is at:

    http://www.ti.com/analog/docs/litabsmultiplefilelist.tsp?literatureNumber=slaa584&docCategoryId=1&familyId=82

     

    A separate email in from the field indicates you are also trying to use the IOTEST feature but are having trouble with it.   I have used the IOTEST feature on the EVM previously, and have created a ppt document on the use of the feature that I can attach.   The IOTEST pattern test is simply that the customer can create a small 8-sample pattern file and repetitive load that pattern to the DAC.  The 8 patterns would match the 8 pre-stored IOTEST patterns, either by using the default values or by using 8 values that you have chosen to write to the registers.   Then read the SPI register that reports when a bit from the pattern coming in fails to match the expected pattern.  (Have to clear the register first that reports the errors.  Then if there are any new errors after clearing then a bit n the register will set and remain set until the next time it is cleared again.)  This requires the ability to read the SPI registers, which you are able to do since you are watching the FIFO alarms.  Ppt attached, and in that I just used the 8 default patterns and made my external sample pattern to match.   The SYNC is needed along with the sample pattern to tell the IOTEST which of the 8 samples is the first one of the 8.   The ALIGN is not needed as this feature is done before the FIFOs.     The pattern verifier compares each bit of the 8 incoming patterns against the 8 pre-stored patterns.   if there is a mismatch in any bit position, the results register is set and held for that bit position, until the results register is cleared by writing zeros.  If there are no errors, then reading the register simply reads back zero for all bits.  if there is something drastically wrong with the interface then the results register would likely return 14 ones every time it is cleared and re-read to indicate an error in every position.

     DAC3174 Pattern Test Feature.pptx

    Regards,

    Richard P.

  • You got it! Thanks for identifying the synconly_ena bit. I had completely overlooked that in the datasheet and it seems to solve our problem completely. Thank you for the detailed answer.

    For what it's worth, the things that cnfuse me about IOTEST are:
    a) the comparison registers are specified as 14-bit even though the chip is 12-bit
    b) there's no correlation between the expected pattern and whether the expected pattern goes on A/B DACs (so, for instance, is IOTEST pattern 0 on A DAC, IOTEST pattern 1 on B DAC, etc?)
    c) the results register shows up as 0x3fff even before I send a sync out; it seems like I fail even before I start?

    I don't think I actually need an answer to these questions, but I think they should be addressed in the datasheet.

    Best regards,

    Nathan