6555 onboard memory

[EdHopkins]

Ok let me take another example, say we have 12 inputs and 12 outputs and want to use only ONE 6555 card.

So you can set the invidual channel directions, but when you write the 32-bit wide data word (really only the lower 24 bits matter for 24 DIO channels on the 6555), what do the bits mean for the channels that are inputs?

Ed

[Kyle_A.]

If you have 12 outputs, ch 0-11, and for your generation session you set channels 0-11 into the channel list terminal, it will enable the driver for those channels and write the data that is listed. Data can be 0, 1, or Z for tristate (if you are doing serial communication). In the cause of a U32, the bits for the input channels are ignored since those drivers are disabled. Even if you toggled the line, if the driver is disabled, the line will be high impedance and no data will be driven.

Then, for acquisition, if you read ch 12-23, since the driver is disabled for those lines, you'll be able to read off 0 or 1 on those lines, and the bits for those lines will appear on the Read U32 at bits 12-23.

[EdHopkins]

Ok good this is starting to make more sense.  Couple more things:

1.  If we want to use the built-in hardware comparison mode, does the data that we preload to the input signals end up being the compare values?

2.  If we are using all 24 channels (12 for output, 12 for input) and the hardware comparison mode for the inputs, how is the 8 Mb/channel allocated?

3.  We are using the HWS format, generated by importing a VCD from Modelsim into the Digital Waveform Editor (so I am trying to figure out what the max datafile size will be).

4.  Is there any way to detect a "Z" (tristated input) or will it always be 0 or 1?

Ed

[Kyle_A.]

1. Compare values can be written as X, L, H to the generation session for Don't Care, Low, and High respectively. I'd refer you to the shipping examples for Hardware Compare and the help documentation for more information on how to use it. The website has several articles explaining how to use it as well.
2. You should have the same amount of space for HWC as well as normal generation. 8M samples for generation and HWC samples combined.
3. There are a lot of things going on under the hood that affect the memory allocation, so it is rather difficult to give exact numbers beyond the 8M sample number. HWC states use 0, 1, Z, L, H, and X, which cannot be encoded by a single bit. However, the amount of samples should stick to the 8Mbit/ch number (8M samples per channel).
4. Depends on how you want to detect, but since it is floating it could theoretically be any value, and if you read from an input it will not display 'Z' but either 0 or 1. You'll basically have to keep track of the channels used to understand what you set to be generation vs acquisition, and which cycles of generation does Z generate (which effectively tristates the line per cycle, 200 MHz).

[EdHopkins]

Ok so if we use one card for generation only, and use all 24 channels, we can preload with 8 * 24 = 192 Mbits for the entire board?

And if we use a 2nd card for acquisition only using the HWC mode, on all 24 channels, we may have less than this because it uses more than two values for the result?

[AirFrantz]

Yes if you wanted to pre-load the entire waveform on the board 192 Mbits for all channels is the max.  

For the second question, remember that in order to do a HWC, you must load the compare waveform to the device onboard memory.  When you are reading values, you can store either compare results, acquisition data, or both.  Whether or not you need the acquisition data will change how much memory you will use.

It should be noted that when running this, the device memory will not have to store all the acquisition data/compare results at the same time.  You will be pulling data from the onboard memory to your PC while the acquisition is running, and you shouldn't be too worried about running out of memory on the device.

[EdHopkins]

Have been making some progress ... if we use the stimulus / response approach (where each value is 0, 1, Z, L, H, or X rather than just 0 or 1), how does the stored data get broken up?

In other words if there is 192 Mbits of total data on the 6555 card, if I need to store ALL 24 channels in stim/resp mode, which will have to store the stimulus, the response, the actual value, and the error result, for each channel, for each sample, how many samples will I be able to get at the max size?

Thanks.

Ed

[Kyle_A.]

Hi Ed,

Gonna start from the top when describing this, and then work my way through your questions.

You have separate memory for both generation and acquisition, so if you have 8Mb/ch memory on the board, then you will be able to store that much for both generation(stimulus) and acquisition(response).

Data width can change to increase the amount of memory you have for a particular channel if your application calls for fewer channels. For instance, generation sessions have two data width options o the 6555/6 boards, data width of 4 and 2. To use all 24 channels, you are required to use a data width of 4 to have enough bits for all channels, but if you were only using 16 channels or less, you could change the data width to 2, and thus increase the amount of memory you have on that channle from 8 Mb/ch to 16 Mb/ch.

Stimulus/Response applications do use extended data states, but this does not affect your avaliable onboard memory negatively. In other words, you still have 8 Mb/ch for Stimulus memory and 8 Mb/ch for Response memory if you choose to use Hardware Compare. The way we interpret the data in our driver and encode it into our SMC core allows for this conservation of memory space when using extended data states.

The only thing you may have to watch out for is if you choose to mix and match which channels are stimulating and which channels are responding, and how many different unique configurations you have in your HWS file/WDT array. I'll explain this way:

You have 255 unique states that you can encode the channels for stimulus/response applications.

If I had three channels, and decided at t = 0 to drive out values on all three, that is one unique state.

At t = 5, I decide to change all channels from driving to comparing, that is a second unique state.

At t = 10, I decide to change channel 0 to drive, and channels 1 and 2 to compare, that is a third unique state.

*Note: a bit changing from 0 to 1 does not constitute a unique state, only the function of driving or comparing or tristate.

Assuming you are driving on 12 channels and responding on 12 channels the entire time, you will only use a single unique state for the entire generation/acquisition, since the channels only have a single configuration. I don't forsee this being a problem for your application, but I wanted to explain it anyways.

Finally, the error results. The HWC FIFO internal to the board has a depth of 4096 in which it stores errors and their error locations. This is separate from your waveform memory, and does not impact the space you have to use when stimulating/responding. You may read errors off the FIFO at any time during your program running. Every time you read the error samples off of your board, it clears the FIFO so that it can store the next 4096 samples that it receives. If you do receive 4096 errors, and don't read the FIFO, and then more errors come in, those errors will be ignored and not stored in the FIFO until the FIFO is cleared by a read call.

We have several HWC properties that you have at your disposal to build a robust application that monitors when the backlog is full (backlog = errors in FIFO), how many errors have occurred, how many samples compared, and also a feature called cumulative error bits that will give you a channel mask which indicates if an error happened at all on a particular channel. It is a boolean array that does not store total samples but only indicates if an error occured at all.

Hopefully at this point, you will have all the information you need to know about memory and how it is broken up. If you have any questions feel free to ask. A lot of this information I gathered from public facing documentation, but some of it I had to gather internally and will be creating content for it later on. Thanks.

[EdHopkins]

Hmmm I did NOT know about the unique states limitation ... for our current task this is sufficient because we always have the same I/O mapping during each test run.

For the next task, we will be talking to a bidirectional data bus, and the directions will be continously changing during the test.  However, it is only the 32 bit wide data bus lines that will be changing direction and always together.  So I suppose that is two unique states?

Ed

[EdHopkins]

And relating to the error depth ... also good to know as we get more exhaustive testing implemented.

So this 4096 ... what does that store?  Our runs thus far have used up to about 20,000 sample points with 16 channels.  We notice that it stores both the # of error samples received, and the error bitmask for each sample point.

What is the 4096 figure?  Bits or bytes or sample error bitmasks?  And then how do we automate the retrieving the error values and clearing this FIFO?

Ed