pxi 6561 memory problem

[Timothy 123]

Hi,

I have a pxi 6561 for use for testing chips in my lab. I have asked various questions related to this problem in previous threads, but now wish to post the entire problem to see if anyone has any suggestions. The basic problem is that I am aquiring data at 40MHz across all 15 channels of the pxi 6561 for 15 chips. One channel will be used for exporting signals (commands) to the chips I am testing, and I am using the LVDS clk out DDC connector to issue a clock to the chips I am testing. The clock also operates at 40 MHz. I have the 16Mb version of this device and wish to conserve as much memory as possible during the acquisition sessions.

I have been following the dynamic generation and acquisiton-source synchoronous.vi example quite closely. When I issue a command to the device, I also issue a data active event and export this to the PFI -1 connector. I then wire the PFI-1 connector to the PFI-2 connector. I then wish to stop the acqusition when the data from the chip reaches a serial termination bit pattern of 1000,0000,0000,0000 on each chip. I am thinking of doing this by using an external circuit that looks for this pattern and then fires a trigger when it sees this pattern. I will then route this trigger to the PFI-3 connector. I also do not want to fetch the memory of the 6561 after every generation and acquisition cycle. I wish to do multiple generation and acquisiton cycles before fetching data in order to conserve the on board memory on the pxi 6561. When the memory on the pxi 6561 is almost full, then I will fetch from it.

Does anyone have any suggestions for solving this problem?

Thank you,

-Tim

[Ryan_M]

Tim,

The 656x is fundamentally a parallel interface.  You can use it as a serial device but the SER/DES function much be done in software.  There isn't a hardware mechanism internal to the 656x that can perform a trigger function on a serial stream.  If you have an external device that can do a shift and compare function then that can be used as a trigger but the 656x will not be able to do it without software processing.

Also,  I'm curious why you do not want to fetch data from the device during operation?  One of the best tricks you can do to increase your memory utilization is to pull data out of the memory so that more data can be stored.  There is a streaming to disk example ("Continuous Acquisition - Stream to Disk.vi") shipped with the latest HSDIO driver that illustrates this.  The purpose of the onboard memory is to to be able to sustain much higher rates than the PC bus can handle.  For streaming applications, you can think of the onboard memory as a giant FIFO.  If you don't fetch data out of the FIFO until its full then you're going to stall the interface.  If you make sure to pull data out of the FIFO as fast as you can, then you can make sure that the FIFO will stay empty longer allowing for more data throughput.  Using the fetch backlog attribute, you can see how samples have been acquired into memory and fetch them out without interrupting the hardware timed acquisition on the front panel of the device.

other memory utilization tricks may include using a pause trigger so that you're not acquiring data you don't care about.  Please note that you cannot use a pause trigger with the streaming example I mentioned before.  For applications using the NI 655x, you can use the hardware compare feature for stimulus/response test.

Message Edited by Ryan M on 11-06-2006 12:41 PM

[Timothy 123]

Hi,

I think I have the old driver, but is this similar to the example of Dynamic Acquisition with Large Buffer Size. I will look into your example vi later today. If I use the approach that you suggest, is there any interuption in between when I am fetching data. Suppose I wish to acquire data that is larger than my onboard memory of 16MB, and I want to acquire it as one continuous acquisition without any interuptions. Will I get any interuptions if I use your approach that is shown in the Continouous Acquisition - Stream to Disk.vi example. I did not want to fetch data during the acquisition because I was worried I would get some interuptions in my data stream. Before this my approach was to send a command to the chip, start acquiring data for a number of samples, fetch it, and then restart the process again and again. I was thinking of building an external circuit that could decode the incoming bit stream and see if it contained the bit pattern 1000,0000,0000,0000. If so it would send a trigger to pause the acquisition and then trigger the device to send out another command.

Thank you,

-Tim

[Ryan_M]

Tim,

In order to "fetch more than the amount of onboard memory" you have to use the streaming application.  If you don't stream the data out of the onboard memory, you will run out of memory if you acquisition is larger than your maximum memory on the device.

The fetch from memory by your application and the storage of data into that memory by the hardware are independent processes.  That's why using the FIFO analogy works so well.  On the input of the "FIFO" you have a hardware timed operation which is totally system independent.  Its controlled purely by the clocks, events, and triggers to which you provide the hardware.  On the  output of the FIFO you have your software fetch which is a system dependent process.  It is controlled by your LabVIEW code and the HSDIO driver calls you make.   The memory decouples the system from the actual acquisition so your hardware timed operation will not be affected by any system limitations you may have. 

That being said, if in a streaming application you don't fetch data out of the memory fast enough, the memory will eventually fill up.  Fetching from memory will extend the duration of the acquisition, but if you cannot fetch faster than you store data, you will eventually run out of room.  The rate at which you can fetch data will be totally dependent on your system.  IE, how fast is your harddrive, do you have other PXI devices using the bus too, etc. 

There will be interruptions in fetching data from memory, but you will not lose any data.  By using the backlog or the streaming example, you are fetching chunks of data at a time.  The size of each consecutive fetch may be different but the data is continuous.  That is, the first sample of your second fetch will have been captured one clock cycle after the last sample of your first fetch.

Using an external device, you could fire a signal when the serial stream outputs some pattern.  You could output that as a trigger to your generation to send the next command.  You could certainly use it as a Pause trigger as well but it seems that the trigger would deassert on the next sample as the pattern has shifted through so you're really only saving a single data point.  Using some PLD i'm sure you could make the trigger a little more smart than just a shift register and pattern matcher to gain bettern triggering but that would be totally dependent on your application.

[Timothy 123]

Thank you for your suggestions. They are very helpful.

I was thinking of using a PLD whereby I would feed the clock going into the chip and the data out from the chip into this PLD as well as into the pxi 6561. I would then wait for the pld to find the bit pattern and send a trigger to the pxi 6561. Do you think that this will work. I would program a logic into the pld so that if it saw a 1 followed by 15 zeroes it would return a 1 which would pause the pxi 6561. It would also cause the pxi 6561 to start to send another command to the chip. This would then output a data active event and then it data would be acquired as well. By the way do you recommend any PLDs for doing this.

Thank you,

-Tim

[Ryan_M]

Tim,

If you fork the data out from your DUT to the PLD and to the 656x then you may run into timing and transmission issues.  I would probably recommend running the data to the PLD then redriving it out of the PLD.  In this fashion you can prevent any forks in the transmission path and you can make sure that the trigger you generate based on the serial pattern is synchronous to the data.  If the data is sent directly to the 656x and the trigger is generated in reponse to that data in the PLD, then there will be some latency introduced in that trigger relative to the data which may give you issues if the latency is large enough.  That latency should be deterministic so you may be able to compensate for it using DataDelay but it is still something that needs to be considered.

Also, if the trigger is refreshed every sample then you may only be pausing out a single data point which may not be worth the effort.  For example, if my data stream is


0011000110

and my serial trigger is "11000" then my trigger on a sample by sample basis would be:

0   - no trig
0   - no trig
1   - no trig
1   - no trig
0   - no trig
0   - no trig
0   - TRIG
1   - no trig
1   - no trig
0   - no trig

In this case I'm capturing 9 points out of 10.  Depending on the length of your patterns, you may not be saving much room at the expense of having to use an external triggering circuit.  However, if you know that the data right after the serial pattern can be ignored (such as if the trigger is a "stop" character from the DUT) then you can can use the PLD to extend the TRIG until whenever you see fit to pause off significant portions of the data stream.

[Timothy 123]

Hi,

Thank you for all your suggestions. They are all very helpful.

You had said earlier that the rate at which I can fetch data is dependent upon my computer and other devices I have connected on the pxi chassis. Is there a way I can find out the rate at which I can fetch. Also the data that I have has a header bit stream and a trailer bit stream. If the rate is fast enough, I would just use the PLD to trigger when commands are sent to the device. I could just start and stop the device after I finish an entire test since I could parse out the parts I don't want later in software using Labview.

Another thing is the chip outputs data with a header and a trailer bit stream. I was thinking of using a PLD to send triggers when it saw the header and trailer bit streams to start and stop acquisition of data. That way I would have the minimum amount of unnecessary data on my device.

Thank you,

-Tim

[Timothy 123]

Hi,

Do you also think this will work if I am acquiring data on all 15 channels at 40 MHz each since I can only read data from the pci bus at 33 MHz. I had seen another thread where someone had gotten this to work for the case of acquiring data at 3 MHz. I don't think I will be able to fetch the data out fast enough to make room on the on board memory for additional data.

-Tim

[Ryan_M]

You should be able to get faster rates if you're not storing the data onto a harddrive.  Anecdotally I've heard of streaming to PC memory at 80MB/s.  You're limited by the size of your PC memory at that point so if you have to push it to the harddrive you're going to be limited by that HD speed which is significantly lower (maybe 20MB/s).

Is the serial stream you are receiving have a deterministic length?

[Timothy 123]

Hi,

The serial stream is deterministic in that the length of it can be controlled by issuing an external trigger to stop acquiring data after the termination bit stream is seen. I had done some rough estimation that the this would be roughly 4MB in the case at which the maximum size data packet would be sent.

-Tim