6561 Acquisition & Generation Application

[Yardov]

Hey Dean,


 


I believe using this device for SPI will not be easy. Although
I am including some workaround on the problems you mention you might want to
consider using the USB-8451 (<a href="http://sine.ni.com/nips/cds/view/p/lang/en/nid/202368" target="_blank">http://sine.ni.com/nips/cds/view/p/lang/en/nid/202368</a>)
or directly FPGA (<a href="http://zone.ni.com/devzone/cda/tut/p/id/3928" target="_blank">http://zone.ni.com/devzone/cda/tut/p/id/3928</a>).


&nbsp;


First the strobe IS available for acquisition but not
generation. You can confirm this on the help file (located in Start»All
Programs»National Instruments»NI-HSDIO»Documentation»NI Digital Waveform help)
on the clock sources of the device section.


To control this clock with the PFI line you will need to
use triggering and retrigger each time you stop it. This can be done with
scripting.


Can you provide more information in why this need to be
implemented with HSDIO?


Regards,


Yardov

[Ryan M]

dean,
&nbsp;
How fast do you need the interface to run?&nbsp; The timing diagram you linked, and SPI in general, does not require a free running clock.&nbsp; The 656x devices, however, require that the clock is always running.&nbsp; Gating the clock could result in clocking or data errors.&nbsp; However, if your interface&nbsp;is running sufficiently slower then the max rate of your 656x then you could use a combination of oversampling and triggering to acquire the signals.&nbsp;
&nbsp;
It may be possible to use the SCK signal as a pause trigger (input the SCK signal into a data line for pattern match&nbsp;or use a level based trigger on a PFI)&nbsp;which you would use as a synchronous event to qualify the data.&nbsp; If the acquisition is running using an onboard clock, then you can oversample the data up to 100MHz using the 6561 or 200MHz using the 6562.&nbsp;
&nbsp;
Please note that in doing this, the data and SCK signals will be sampled using an unsynchronized clock (unless your DUT has a mechanism to run from an external clock source?)&nbsp;so there is a large probability for sample error.&nbsp; This is an artifact of channel to channel skew.&nbsp; Since you can't guarantee phase of a clock relative to the data in an asynchronous system, there is potential that the acquisition clock edge could occur between the SCK data transistion and the MOSI signals.&nbsp; If you are adequately oversampling, though, you can do some post processing to account for that behavior.&nbsp; Since you have to do post processing to deserialize the data, though, this should be a simple amount of overhead.
&nbsp;
Also, some SPI interfaces, on microcontrollers for example, generate a MISO message in response to the MOSI data.&nbsp; The response time of the 656x devices would be dominated by how fast you can pull the data out into your ADE, deserialize and analyze it, generate the response, and download it into hardware.&nbsp; If you have a set of known responses, this can be minimized by downloading all of the reponses intially&nbsp;then just tell the hardware which one to generate at a given time.

[Ryan M]

Dean,
Unfortunately, you have to get the ADE involved in order to do the deserialization.&nbsp; If you run the acquisition using just a 2 MHz clock, for example, you'll sample the data ~4 times for each SCK period (could get 3, may get 5 depending on frequency mismatch between 500k and 2M).&nbsp; Since the timing error would be generated on the first or last of these samples, you can throw them away and only analyze the middle sample(s) since we can guarantee that they will be correct.&nbsp; If you capture the SCK as data, you can then use this to qualify the data further.
Once you deserialize and interprete the data, you can use the "niHSDIO Configure Waveform To Generate" function to specify which predownloaded waveform you need to generate as a response.