dean,
How fast do you need the interface to run? The timing diagram you linked, and SPI in general, does not require a free running clock. The 656x devices, however, require that the clock is always running. Gating the clock could result in clocking or data errors. However, if your interface 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.
It may be possible to use the SCK signal as a pause trigger (input the SCK signal into a data line for pattern match or use a level based trigger on a PFI) which you would use as a synchronous event to qualify the data. 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.
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?) so there is a large probability for sample error. This is an artifact of channel to channel skew. 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. If you are adequately oversampling, though, you can do some post processing to account for that behavior. Since you have to do post processing to deserialize the data, though, this should be a simple amount of overhead.
Also, some SPI interfaces, on microcontrollers for example, generate a MISO message in response to the MOSI data. 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. If you have a set of known responses, this can be minimized by downloading all of the reponses intially then just tell the hardware which one to generate at a given time.
