DAC3161: Guidance needed on internal FIFO of the DAC3161

Hi,

when I asked the design team about the timing required to bypass the FIFO I was told that this mode was not characterized, so I do not have timing data to support this mode of operation.  It is possible, but not recommended.  Or at least not supported by characterization data.

The FIFO is there to decouple the digital data clock from the DACCLK so as to make the digital sample bus not have to have any particular phase requirement relative to the DACCLK.   The DACCLK could then be a clean, low-jitter large swing clock from a clean clock source while the DATACLK can be just a digital signal from the FPGA.   But the presence of the FIFO can introduce some indeterminancy in the latency through the FIFO which is just what your customer would need to avoid.   There are ways to deal with that.

A very comprehensive document on dealing with the DAC clocking and FIFO can be found in the document http://www.ti.com/lit/an/slaa584/slaa584.pdf .  This is a different part number, but the handing of the FIFO is essentially the same.  Keep in mind that some devices will call the signal to reset the Write pointers of the FIFO either SYNC or ISTROBE (for Input Strobe).  And some devices will call the signal to reset the output side of the FIFO either ALIGN or OSTROBE.   These are the same signals though.

The simplest way to reset the FIFO is to use the SYNC input as the signal to reset both sides of the FIFO.   The SYNC will reset the pointers into the FIFO and then also reset the pointers out of the FIFO to be lagging by four samples through the FIFO.  The SYNC signal would have to meet setup and hold time relative to the DATACLK and so the resetting of the FIFO write side would be deterministic, but the timing of this same SYNC input would be unknown relative to the DACCLK and so the resetting of the FIFO read side would have a cycle or so of variability.  This is fine for many applications using a single DAC device, but not for a bank of DACs that are to remain synchronous to each other.    For this application, the ALIGN signal would also be used.   All DACs in a system would get the same SYNC input that meets setup and hold time relative to the DATACLK so all DACs reset the Write side of the FIFO at the same time.   All DACs in a system would get the same ALIGN input that meets setup and hold time relative to the DACCLK so that all DACs reset the read side of the FIFO at the same time.  In this way the latency through all the DACs in the system can be identical.

A common way of generating the ALIGN signal when it is used is to have a clock device (such as one of our LMK family of clock devices) drive the DACCLK to the device and also drive the ALIGN signal using a clock divider of 8, or 16, or 24.    It is okay to have a repetitive signal on ALIGN if the periodicity of the signal is a multiple of 8 samples.  The subsequent ALIGN pulses will 'reset' the FIFO each time but because the signal has a periodicity of 8 it will reset the FIFO to the pointer location that it already had anyway.    So if a clock chip that drives DACCLK can also drive an appropriate ALIGN signal then we can control the timing of ALIGN.    If the FPGA that drives the DATACLK will also drive the SYNC signal then the timing of SYNC can be known as well.   That is what must be done to control the latency through the FIFO for known synchronous behavior - control the timing of SYNC relative to DATACLK and ALIGN relative to DACCLK.  Again, that app note I believe will present an exhaustive treatment of this mater.

The drive levels of the DATACLK and the SYNC inputs are standard LVDS.   A standard LVDS driver can be the source for each of these.  A nominal LVDS swing of +/-350 mV is fine, at the normal VCM of about 1.2V. 

The drive levels of DACCLK and ALIGN are expected to be larger, such as a typical LVPECL driver.  A large swing for DACCLK is expected, such as the typical +/-800mV swing (1600mv p-p diff) of an LVPECL driver.   But the common mode requirement for DACCLK is *not* typical of an LVPECL signal.   The DACCLK is expected to be biased to about 0.9V or about midway between the DAC supply voltage and ground.   (the datasheet editor was confused by the statement that the common mode should be about CLKVDD/2 and the phrase turned into "approximately CLKVDD18 and CLKVDD2".  He didn't understand the slash meant divide-by. This will be fixed in a later revision.)  The DACCLK input has an internal self-biasing circuit so that if the clock is AC coupled then the unusual biasing takes care of itself and the clock can be driven by a standard LVPECL driver.   Because the ALIGN input if used is expected to meet timing relative to DACCLK it was implemented with an input buffer that is a copy of the DACCLK input complete with the same self-biasing if the signal is AC coupled. AC coupling on the ALIGN signal is possible if the ALIGN signal is periodic as mentioned earlier.   It is not normal practice for the FPGA to drive the DACCLK as it is not common to get a clock from an FPGA with low enough phase noise or jitter.   A more common approach is to have a very clean clock source to the DAC, usually LVPECL, with a copy of that clock delivered to the FPGA for the FPGA to turn that clock back around for the DATACLK output.    The presence of the DAC FIFO means that the round trip timing of the clock from the source to the FPGA and through the FPGA back to the DAC is not critical - the FIFO absorbs any phase mismatch.  But to control the latency through the FIFO requires the use of the SYNC and the ALIGN signals.

If the FPGA *must* source the DACCLK and the purity of that clock is adequate for the AC performance of the DAC, then perhaps an LVPECL buffer between the FPGA and DAC would be best.  Likewise for the ALIGN signal, but the ALIGN signal would need to be shifted in phase relative to DACCLK so as to meet setup/hold time into the DAC.

Regards,

Richard P.