Bursting Data Quickly (PCI-6541)

[Harpoon]

We are implementing a test interface for our board using the PCI-6541 to generate blocks of about 1000 bytes which we'd like to send as bursts every time our board asks for them. This requires a bit of hardware handshaking, and that seems to be at issue. Our board has room for two blocks of data at a time, and we need to make sure that we have received the second block before the first block has been depleted lest the output pipe face a starvation situation.

The desired behavior is very simple. The board asserts a block request, and the PCI-6541 should respond by outputting a block of data. Then it should stop and the next time it sees the block request it should output another block. We'd attempted to pre-load all of the data blocks into the memory on the 6541 so it can respond more or less in real time to the board. But that's not the behavior we're seeing. After it outputs a block it takes a long time for it to respond to the next block request. We are currently using a pause trigger and a start trigger to coordinate this interface. There has to be a faster way to do this. Can anyone help?

[Allen H]

Hi,

How much of a delay between the block request and data output from the 6541 is acceptable for this application? Typically, I would recommend setting up a scripted generation with a script like the one below. There is a shipping example (Dynamic Generation with Script) that shows how to set this up with the driver.

script myScript
wait until scriptTrigger0
generate wfmA
wait until scriptTrigger0
generate wfmB
wait until scriptTrigger0
generate wfmC
... etc.
end script

Using this script, the 6541 will wait for an edge trigger (which can be received on one of the PFI lines), then generate waveform A. After waveform A is finished, the 6541 will go back to its idle state and wait for the next trigger, then generate waveform B, and so on. It sounds like you are interested in the last specification listed on page 21 of the 654x specs document (Start --> Program Files --> National Instruments --> NI-HSDIO --> Documentation --> Specifications). The Delay from trigger to digital data output is 32 sample clock cycles + 160 ns. If you are running at a sample clock rate of 100 MHz, this delay amounts to 480 ns.

The delays associated with a pause trigger are comparable, so I suspect this is what you are running into.

I hope that helps. Let me know how small of a delay you need.

Thanks,
Allen

[emvee]

We do have almost the same requirement, bursting data in chunks of about 1000 samples.

More general, we like to use the PCI-6541 to generate data only when instructed by some hardware. This hardware can either give an enable signal that indicates that it expects data or we can gate a clock so that only when this clock line transitions, the PCI-6541 should give data. The 32 sample clocks delay from from Pause trigger to Pause state specified in the 654x spec is too long.

The solutions we see:
 
Gated clock
We have been looking into the documentation and saw (in the NI Digital Waveform Generator/Analyzer Help file, section clocking) that the CLK_IN signal from the connector can be used as Pattern Generation sample clock, but in the PCI-6541 datasheet is mentioned that the clock requirements for CLK_IN are "Clock must be continuous and free-running".
Does this mean that we can not use the CLK_IN with a gated clock for generation? (we can use STROBE for acquisition)
 
Enable signal
I have checked the NI Digital Waveform Generator/Analyzer Help file but there seems to be no provision for a enable generation signal.
There is a pause trigger, but the delay of 32 sample clocks is too long. Futhermote, it is unknown to me from the documentation on how to continue after pausing. From the documentation it is also not clear to me if a script can be used to minic a level based enable signal (so: generate data while the enable signal is high, stop generating data when the enable signal is low)

[Allen H]

Hi emvee,

How much delay can your application tolerate?

You are correct about the continuous and free-running clock requirement.  For a generation session, you are not able to provide a gated clock to the CLK IN input.  This is due to the heavily pipelined architecture that allows these boards to reach rates of 100 MS/s at 4 bytes per sample.

An incoming trigger is the way in which these boards respond to external signals, even though a generation session has an associated trigger delay.  You can configure the generation to stop for exactly a predetermined number of samples by using the finite wait statement in the script ("wait 24").  However, this does not respond to any external signals.

The pause trigger is level-sensitive, meaning that the generation will pause when the trigger is asserted, then become active again when the trigger is deasserted.  For example, if you are using PFI 0 as the pause trigger, then the generation will pause after PFI 0 goes high, then it will un-pause when PFI 0 goes back low.

I hope that helps,

Allen

[emvee]

Hi Allen,

Thanks for the answer.

I am not sure how much delay we can exactly tolerate, we are still in the design phase, but the longer the more buffer we probably need and the more complicated things become. I am now investigating if we can do with fixed padding after an initial trigger.

Good to know that the CLK IN should not be gated for a generation session.

I just looked again in the NI Digital Waveform Generator/Analyzer Help file and found niHSDIO_ConfigureDigitalLevelPauseTrigger which does the level-sensitive pause trigger (must have overlooked it before).

One remaining question: Does also the level-sensitive pause trigger have the 32 clock cycle delay?

[Allen H]

Hi emvee,

The pause trigger delay is the same when un-pausing the generation.  The delay when pausing is almost the same, and is listed on the same page of the specifications document.  32 clock cycles plus 150 ns instead of 32 +160 ns.

I hope that helps,

Allen