PXI

cancel
Showing results for 
Search instead for 
Did you mean: 

6555 onboard memory

Hi I am working on a project where we recently have purchased the PXI chassis with several 6555 cards.  The technical support gal, although she was very nice, did not know the gory detail of some of the questions I have, so I am hoping someone on the forums here has run into these or would know who to ask.

 

The specs for the NI PIXe-6555 card claim 8 MB per channel.

 

* Is it really 8 MB per the 24 DIO channels (so 192 MB total)?

* Is this mega BYTES or BITS?

* If I have a large dataset that is more than 8 MB, is there a way to pre-load or something so that there is not a break in the datastream?

* If we have four of the 6555 cards in one chassis, how close (what is the tolerance or slop) can I get the data streams to be synch'ed at the max speed (200 MHz)?

* If I am driving data at 5V logic levels on our DUT (device under test), can I get the full 200 MHz speed?  I am seeing conflicting info on this in the help files.

 

Thanks!

 

Ed

 

0 Kudos
Message 1 of 21
(6,294 Views)

Ed,

 

I'll try to answer these questions one at a time:

 

*The 6555 has 8Mb per channel.  Total for all 24 channels would be 192Mb, but it is important to note that you cannot exceed 8Mb on any individual channel.

*This is in bits for this particular device.

*If your dataset is larger than 8Mb, you can still generate larger datasets by streaming from disk.  There is information available in the HSDIO Help for streaming from disk, but basically the onboard memory is continuously overwritten as the samples are generated.  Search for some community examples for streaming from disk with HSDIO for strategies for doing this.

*There are a few different ways to synchronize this in a PXIe system, but in this case it would probably be easiest with the NI-TClk driver.  The skew times will vary based on which strategy you use to synchronize, but you should be able to get fairly low skew times (pico-seconds range).  Here is some information about synchronizing with NI-TClk: http://www.ni.com/white-paper/3675/en/

*If you are generating you will only be able reliably generate 5V levels at 50MHz and 3.3V levels at 100MHz.  You can choose to generate faster than this (up to 100MHz for 5V), but the result may be noisy and/or not reach your threshold levels.  This is outlined on page 18 of the product manual: http://www.ni.com/pdf/manuals/375749g.pdf

 

Hope this helps!

------------------------------------------------------------------------------------------

Jon F.
Technical Support Engineer
National Instruments
0 Kudos
Message 2 of 21
(6,269 Views)

I noticed I made a mistake in that last response.  It is possible to use more than 8Mb per channel, but you would have to use less channels to do so.  You can do this by changing the Data Width.  This is outlined in the document here: http://www.ni.com/white-paper/7283/en/#toc3

 

Also, I would like to add that aside from data streaming, you could also implement scripting to manage your memory usage.  If the data has long periods of zeros or repeated patterns you can minimize the memory used by generating from a script.  Here is a document about scripting: http://www.ni.com/white-paper/7285/en/

 

If you are worried about the speed, I want to mention that 3.3V will work for many TTL applications.  This will depend on a few factors such as termination and how fast your data is changing (i.e. are you oversampling?).

 

The page below links to many great articles about our HSDIO products:

 

http://www.ni.com/white-paper/7282/en/

------------------------------------------------------------------------------------------

Jon F.
Technical Support Engineer
National Instruments
0 Kudos
Message 3 of 21
(6,258 Views)

I apologize for the confusion here but I was correct initially about the memory per channel.  The PXIe-6555 does not support the Data Width strategy so you will be limited to 8Mb per channel.  Some of our other HSDIO products have that feature.

 

Some added clarification about the rates for the board:  The data rate of the 6555 is 200MHz for 3.3V logic and 100MHz for 5V.  The toggle rates are 100MHz and 50MHz respectively.  Think of it as if you generated 010101... at 200 MHz data rate with 3.3V swing. The resulting signal out of your board would be at a 100 MHz rate because you generate a 0 on one 200 MHz cycle and a 1 on the next 200 MHz cycle.

 

Also, if you decide to implement streaming, know that you cannot stream Hardware Compare samples.  If that is something you will need you won't be able to use data streaming.

------------------------------------------------------------------------------------------

Jon F.
Technical Support Engineer
National Instruments
0 Kudos
Message 4 of 21
(6,247 Views)

Excellent info Jon, thanks much, this pretty much confirms my initial interpretation.

 

One more question ... when you say that each of the 24 DIO channels on the PXIe-6555 card, can store up to 8 megabits, is that actually packing each bit to be sent into the 6555 memory, or does it treat one time slice as a byte or word?  In other words if I have a data stream like:

 

1010 1010 1010 1010

 

Is that consuming 16 bits of the memory, or 16 * 8 bits (byte per value)?

 

Since the card can set and compare voltage levels in addition to just high or low I want to be clear that we are packing this (as opposed to 8-bit samples).

 

Thanks.

 

Ed

 

0 Kudos
Message 5 of 21
(6,226 Views)

Hey Ed,

 

With some further investigation, I've found that some information on the features of the 6555 were out of date.  The 6555 DOES support data width for generation.  Only Data Widths of 2, 4 are allowed for generation and 1, 2, 4 for acquisition.

This is important for your question.  Let's say you are using data width = 2 bytes, and are therefore outputting 2 bytes of information across 16 channels.  With data width = 2, you have 16Mb/ch available or 2MB/ch or 32MB total.  32MB/(2B per sample) = 16M samples.

 

If you do not change the Data Width and use default of 4 bytes and you only use 16 channels, you would only be able to have 8M samples.

------------------------------------------------------------------------------------------

Jon F.
Technical Support Engineer
National Instruments
Message 6 of 21
(6,217 Views)

Ok so now I am confused ... we are testing a CPLD that uses 15 inputs and 11 outputs (so we need 15 DIO channels configured for pattern generation, and 11 DIO channels configured for pattern acquisition.

 

Our intention was to use all 24 channels independently (really we need to use two cards to get to 26).  When the LabView VI program sends data out does it need to bitmask in each channel into a dataword and write a word at a time, or does it take the input stream from the HWS file as bitwise channels?

 

Ed

 

0 Kudos
Message 7 of 21
(6,215 Views)

Hi Ed,

 

Hopefully this clears up confusion about how to write data to the generation session of an HSDIO board: How to Write Serial Data for Any Channel on a High Speed Digital I/O Board

 

If your data width is 1 byte, each bit corresponds to each lane. so 0000 0000 in your byte is a single sample bit for channels 0-7. To write data to independent streams at the same time, you'll have to combine the streams into the U8/16/32 format. For instance, two data lines toggling out of phase with each other on channel 0 and channel 7 looks like so:

 

Sample 0: 1000 0000

Sample 1: 0000 0001

Sample 2: 1000 0000

Sample 3 :0000 0001

 

serialized for ch 0: 0101

serialized for ch 7: 1010

 

If you want to drive only those two channels, while doing other independant operations on channels 1 through 6, you simply only include ch 0, 7 in your Channel List for the Generation Session through the HSDIO driver. By default, the channels not included in the channel list for generation will have their drivers disabled, and can be used for acquisition.

 

The memory issue here is that for generation, you still have to populate channels that are unused for generation based on the data width. Writing to two channels takes 2 bytes per sample in the above example since U16 (Data Width = 2) is the smallest for the board. This is less than if the samples were 4 bytes wide (U32, Data Width = 4), which takes double the amount of space in memory.

 

This KB is slightly outdated at the time of posting this, but it explains more about optimizing memory usage with HSDIO and Data Width. Ignore the 655x statements, as 655x only referred to 6551/2 boards at that time.  HSDIO Data Width and Memory Allocation

 

So in summary, it does bitmask based on the channel list into the generation session. It also writes one word (U8/16/32) at a time, for the channels that are enabled for generation, and this does take up memory space on the onboard memory. For your case, to write 11 outputs will require a U16 at least, which is smaller than the default U32, so I would recommend changing data width to 2 for acquisition and generation to obtain the maximum amount of memory available on your device.

Kyle A.
National Instruments
Senior Applications Engineer
Message 8 of 21
(6,211 Views)

So the other thing I observed by following your links there is that the direction (generation vs. acquisition) can only be set in groups of 8 channels (you cannot individually set the direction of each channel), correct?

 

So it seems like the best use since we have two cards is to set one card for all outputs and one for all inputs.

 

In that case our data width will need to be wide enough to contain all of the channels we are using.  So I am still confused on the 6555 card's storage capacity, is really 8 Mbit per channel it is per all 24 channels total?

 

Say for arguement's sake I use all 24 channels and set them all as outputs, how many 4-byte data words can I store on the 6555 card?

 

Ed

 

0 Kudos
Message 9 of 21
(6,207 Views)

Some of our older boards only had bank controlled direction. The 6555 can select per channel the direction control. You set this by the channel list option on our VI/function calls to the driver.

 

Each channel is 8Mbit/channel static for memory. However, consider the case where you use all 24 channels, hence needing a U32 to store one sample per all channels. U32 is 4 bytes of data, and we have the ability to store 8M samples. This equates to roughly to a memory size of 32 MB that is divided between channels. Now, reduce the U32 to U16 data. You cannot address the last 8 channels on the board with a U16, but you store each sample with 2 bytes vs 4 bytes. This is half the space per sample, thus allowing you to pack twice the amount of samples into the same memory as before. That increase is 16M samples using U16 vs 8M samples using U32.

 

To answer your last question, the board can hold 8M samples for all 24 channels, or 16M samples for 16 channels by reducing data width.

Kyle A.
National Instruments
Senior Applications Engineer
0 Kudos
Message 10 of 21
(6,205 Views)