Post Go back to editing

AD9958: IO_UPDATE overlap with CS

I have a question regarding the behavior of IO_UPDATE with the timing of an SPI transaction.

Here's the scenario:

Let's say I program in a linear sweep to the DDS, then pulse the update. Immediately after, I program in another linear sweep, but do NOT pulse IO UPDATE, so as to store the other sweep in the DDS without pushing it to the output (I want to be able to change sweeps very quickly)

Would there be a problem if the IO UPDATE being high slightly overlapped with the CS going low for the second programming? It's high for about 10ns before the chip select goes low, and remains high for another 20ns before going low again (all while the SPI transaction begins, running at 50MHz)

Parents
  • There "could" be a problem. The way this works is as follows...

    IO_UPDATE is gated by the internal SYNC_CLK signal, which runs a 1/4 of the system clock frequency. So, when you assert IO_UPDATE, the device doesn't "see" it until a subsequent rising edge of SYNC_CLK (as shown on page 30 of the data sheet). Furthermore, it takes 2 SYNC_CLK rising edges for the AD9958 to transfer data from the SPI registers to the internal buffer registers (the registers that actually control the internal device functions). Thus, the worst case delay from asserting IO_UPDATE to a SPI-to-buffer register transfer is 2 SYNC_CLK cycles. At the maximum system clock rate of 500 MHz, this works out to 16ns.

    The SPI port is oblivious to IO_UPDATE. It starts the serial loading process when CSB goes low and SCLK starts toggling. With an SCLK rate of 50 MHz, the SPI bit period is 20ns. What you want to avoid is the SPI port pouring bits into a serial register concurrent with a SPI-to-buffer register transfer (invoked by IO_UPDATE). Fortunately, the first part of a SPI operation requires an instruction byte. This means that when CSB goes low it will take 160ns to deliver the instruction byte. That is, 160ns before IO_UPDATE poses a problem. Assuming 500 MHz operation, you have 144ns to play with (160ns of instruction byte time minus up to 16ns of IO_UPDATE delay).

  • Hi  , one additional question regarding this: is there any downside to keeping IO UPDATE high for an indefinite amount of time while there is no SPI transaction in play?

  • The only downside is that any change to a SPI register will transfer to the associated buffer register automatically with the next SYNC_CLK edge. The implication being that even though there may not be intentional activity on the SPI bus, a change of register contents due to an unintentional SPI write (noise induced, etc.) will affect the device accordingly.

Reply
  • The only downside is that any change to a SPI register will transfer to the associated buffer register automatically with the next SYNC_CLK edge. The implication being that even though there may not be intentional activity on the SPI bus, a change of register contents due to an unintentional SPI write (noise induced, etc.) will affect the device accordingly.

Children
No Data