How to generate odd number of samples with PXI-6551 HS-DIO?

[CT]

I tried to implement a test on a PXI system that has five PXI-6551 modules. The original test was done on another system that is no longer in service due to its age. Basically the test is to run a certain number of stimulus (digital patterns) on a digital card and at each interval a pulse width measurment is taken. Simple enough for the PXI, right? Wrong! The PXI-6551 will not allow odd number of samples to be configured and generated. I was told that this is a hardware limitation and it's designed that way. So, my questions to NI design engineers of this module are: Does everyone use this module never need to generate odd number of samples? Or do you think that add or subtract a sample to or from a digital waveform to make it have even number of samples is the same as if it had odd number of samples?

If it's the PXI-6561 module, there is a feature called DDR (double data rate). I probabley can get it to work by doubling every sample for each clock cycle. But this feature is not available on the PXI-6551 module.

Any advice or suggestion is welcome. Please do surprise me with a solution. At this point I don't even know where the entrance of the tunnel is yet.

[Allen H]

Hi CT.

These are good questions.  The 6551 does indeed require waveforms to be of even-numbered length, as you can see on page 17 of the 655x specs document (Generation Waveform Quantum).  Let me start by asking you for some more information about your waveforms.  We have seen many cases where the waveform quantum may appear to be a restriction to begin with, but is easily worked around.  Here are some examples of information that will be useful in this case:

Do you need to generate just the one waveform a single time?  Will you need to link this waveform together with other waveforms that you have downloaded to the device?  Will you need to repeat the waveform?  Are you using the Data Active Event, or some other signal to indicate to the receiver that data is being transferred?

The design of the 6551 allows for very rapid transfer of data from its onboard memory to the pins.  This transfer was made to be as efficient as possible at the high rates this device is capable of, and one of the tradeoffs was the waveform quantum of 2.  As I mentioned before, I believe you will be able to manipulate some of the other features on this device to ultimately do what you need.

Thanks in advance for the extra information.

Allen

[CT]

Do you need to generate just the one waveform a single time?

Yes. The application requires to generate many unique waveforms once in a sequence.

Will you need to link this waveform together with other waveforms that you have downloaded to the device?

There is no direct link between two waveforms in onboard memory. The waveforms are stored in onboard memory by read out certain number of samples from a large HWS digital waveform file and given waveform names. For example, HWS file has 39 signals with 32867 samples. These 39 signals are mapped to channels across 5 PXI-6551 modules. Then write named waveforms will break up this HWS file into sequential sections and assign a waveform name for each section while download onto the devices. So, all 5 devices would have waveforms in memory like this: wfm1 - from sample 0 to 65, wfm2 - from sample 66 - 193, wfm3 - from sample 194-253, so on and so forth. There is no immediate link between two waveforms. I use script and software trigger for generation. Say, I need to take some measurement after wfm1 is generated, when the measurement is done, wfm2 will be generated.

Will you need to repeat the waveform?

No. In this particular application, there is no need to repeat any of these waveforms I described above. Although I can see in other similar application I could use repetitive waveforms.

Are you using the Data Active Event, or some other signal to indicate to the receiver that data is being transferred?

Yes. The acquisition is triggered by Data Active Event.

As far as I am concerned, my application does not require very rapid transfer of data and I don't understand why can't 6551 be configured (assume it's all done thru its FPGA) not to have this waveform quantum of 2 restriction. How fast does the transfer of data matter if the waveform generation/aquisition speed is limited to 50 MHz? It seems to me the design of the 6551 got the tradoffs priority wrong.

Thanks for your help.

CT

[Allen H]

Hi CT,

Thanks for the information.  Based on your description, I am going to make a couple of assumptions about your setup.  First, I assume that you are using NI-TClk to synchronize the five 6551 boards.  Is that correct?  Second, it sounds like you have extra data lines to work with (you only mentioned 39 channels out of 100).

I think one of the new features contained in the new version of HSDIO (1.4) can help you in this situation.  With that new version, the NI 655x devices have per-channel, per-sample tristate capability.  Using this feature, you can pad your waveform(s) with one sample of tristate either at the beginning or end, bringing the total size to an even number.  If you do this, keep in mind that Data Active will be asserted during the extra tristate sample.  If that is a problem, you can easily create a custom data active signal on one of the unused data lines.

Since it sounds like you are pausing the generation between successive waveforms, the extra tristate sample should not harm the overall timing of your application.

If you are interested, you can download version 1.4 here: https://www.ni.com/en/support/downloads/drivers/download.ni-hsdio.html#326806

You can learn how to use the tristate functionality by looking at the Dynamic Generation with Cycle-cycle Tristate example that installs with this version.

I hope that helps.  Does this sound like a good solution to you?

Allen

[CT]

Allen,

I do use NI-TClk to sync all five 6551 modules. I already installed HS-DIO v1.4 and actually used per cycle tristate feature in my application (not for this purpose though). Can you be more specific about what problem I may have with the Data Active from the extra tristate sample? Will that throw the acquisition off? I am still trying to figure out a better way to utilize waveforms created with the NI Waveform Editor saved in HWS file in LabView. May be you can help me with the problem of this disconnect between the Waveform Editor and the digital data in a HWS file for LabView.

In LabView, you can read/write attributes like “Group Name”, “Waveform Name” from/to a HWS file, but none of this information will show up when you open the HWS file in the Waveform Editor. Vice versa, I can create “Bus”es to group signals together in the Waveform Editor, but when it’s read in LabView, that information is not there. I guess what LabView calls “Groups” and “Waveforms” and can set names are those what the Waveform Editor calls the “Buses” and “Signals”.

Sometimes I have multiple signals in a HWS file created in Waveform Editor that will be used on the same channel of a particular 6551 module depends on the situation. So I can’t use the channel mapping, but WDT and call out signals by names. The problem with the “niHSDIO Convert Binary to WDT.vi” is that if there are more than 32 signals (say 33), then I can’t apply the mask since it’s only 32 bit wide.

Another observation on the WDT format as the result from “niHSDIO Convert Binary to WDT.vi”, it has all these wonderful L and H or Z values in there, but it’s saved in HWS, it can’t be displayed in the Waveform Editor. The only way to see it is in LabView’s digital data or digital graph.

Now I mentioned digital graph, you can bring in an array of data in WDT and display as buses (may be I should call them groups since it’s in LabView) for each bus represent each element of the array, but again you can’t read the file saved from that in the Waveform Editor.

Don’t get me wrong. I think that NI Waveform Editor is a very useful tool and we use it a lot. I just wish it’s better made and tied to the LabView.

It’s very typical for an ATE to have hundreds of digital I/O’s, our application is nothing new in the industry. May be it’s new for the PXI and LabView, in that case may be NI should investigate more in that area to make the PXI platform more useful for automated digital testing.

Thanks,

CT