Setting DAC registers during run

[John Owen (EnTegra Ltd)]

My customer wants to stream to the DACs from the PC and experiment with different settings in the DAC5682Z registers. The X6-400M manual says the DACs SPI is memory mapped to 0x890 and shows an example of writing 0x20E4 to 0x890 (page 123).

According to the table on the previous page, to access register 2, the data should be 0x200E4, so I think this is a misprint.

I found that using 0x20040 0x890 l! does indeed write 40 to register 2, which causes the DAC to treat the data as offset binary rather than 2's compliment.

But writing to other register bits in reg 2 has no effect on the analogue output, eg writing 0x200%% where %% ranges from C0 to CF and E0 to EF made no difference to the waveform rate, whereas I would of expected it to enable x4 interpolation and modulation.

Should I be writing to other registers as well to use these features? Are there any limitations on writing to the DAC once streaming has begun? If so, how could the user write to the registers before streaming is enabled but after Malibu has written its values?

[jhenderson]

John -

There are no known restrictions on DAC register access via SPI and in fact, that method is used to initialize the DAC during Malibu's stream start initialization.

Hook the board's BeforeStreamStart handler in the ApplicationIo object in order to override the value of any Malibu initialization value. This event fires after all Malibu initialization, but immediately before the run bit is asserted to initiate streaming.

[John Owen (EnTegra Ltd)]

Here are a few insights that may be useful to others who want to use the DAC interpolation mode.

Malibu does not currently support setting the interpolation mode (as far as I can see), and so a few steps must be taken to use x2 or x4 interpolation.

1. The clock to the data output of the FPGA must be slowed down. This must be done just before Stream.Preconfigure(); is called. Eg:
// Reduce clock for stream to Dacs by the factor of 2
double Freq = Module().RawClockDevice().Pll().OutputFrequency(4);
Module().RawClockDevice().Pll().OutputFrequency(3, Freq / 2 );
Module().RawClockDevice().Pll().OutputFrequency(4, Freq / 2 );

2. Write new settings to Dac registers, including enabling FIR by setting bit 4 of config 1, and then setting config 2 register accordingly. Eg. Dual channel mode, x2 interpolation would be:
Module().PokeLogic( 0x890, 0x10010 );
Module().PokeLogic( 0x890, 0x200C0 );

The frequency set at the PLL is now the conversion rate of the DAC, the DAC will now clock data from the FPGA x2 or x4 slower.

3. These changes worked for my application which was <160MSPS, clocking the DAC faster revealed a data integrity issue which is possibly to do with the DLL delay register settings.

[jhenderson]

You can access the DAC SPIs a little easier by

Module().Output().Spi( device, address, data) and
Module().Output().Spi( device, address)...the former writes the latter reads.

ADC SPI is on the Input() device.

In your case the first command would be:

Module().Output().Spi(0, 0x1, 0x10);


The clock setup on this board is complex - the value of the clocks the logic expects relative to the sample rate depends on the number of channels AND the rate and I'm not sure how this interpolation fits in across the board.

It is possible that this difference is what made your other test fail. I'll ask the logic people here about what is really needed for this mode at all frequencies.