09-06-2012 12:39 PM
Do you require pretrigger samples? If not, then you would be best suited by just using a counter instead of the record state machine.
If you do require pretrigger samples (most applications in practice do), what latency to rearming the trigger can you tolerate? If your trigger period is relatively large compared to your record period, then you can use the "Simple" acquisition engine. Simply change it to use the U64 data type and use the Join Number LabVIEW node to build up a 64-bit integer from your 4 16-bit integers (and adjust the host side code accordingly). You can find this example in LabVIEW\examples\FlexRIO\FlexRIO Building Blocks\573X\Simple. There are three example FPGAs in this one project.
I would recommend starting with the Multiple Records personality. In this case, you can modify the multi record version of the example to use the "single record" state machine VI (LabVIEW\instr.lib\FlexRIO\Libraries\Acquisition Engine\FPGA\Implementation\acqEngineRecordStateMachine.vi). This removes the record count input and makes the acquisition always reinitiate on a start trigger, with no maximum count.
You may wish to increase the size of the "To Host FIFO" DMA FIFO to insure that you have sufficient buffering to never back up. PCIe traffic can be bursty at times. However, if that happens, the VI will simply throttle the acquisition to prevent it from triggering. No acquired data will be lost.
acq.Initiate is level sensitive. It will abort if it goes false during an acquisition.
If you require a very large number of pretrigger samples, you may need to fall back on a DRAM acquisition engine (like the Instrument Driver personalities). This can be made to work, but it will be harder to make it support continuous acquisition.
09-10-2012 04:46 PM
Greetings,
I have the following system:
1 - NI PXIe1082 chassis
1 - NI PXIe 8133 Controller (RTOS)
2 - NI PXIe 7965R FPGAs
2 - NI PXIe 5781 Digitizers
2 - Ettus XCVR2450 RF Transceivers
Running LV 2011
We are working on a communications system.
One thing that we have been having difficulty with is the handshaking between different processing sections in the code.
We came across the "4-wire protocol" and have been trying to implement it.
When we loaded the FlexRio Dev Lib we saw that it actually has some VIs to help us implement this protocol.
However, the blocks do not have any documentation with them.
Q1. Is there documentation for them? Will there be soon?
We are running in SCTLs ranging from 50 - 150MHz.
Q2. Are the "4-wire" blocks in this library meant to run a certain speed?
Also missing from the library is a bit unpacker.
For efficiency it is desirable to have a block that will unpack a U64 or a U128.
the "4-wire" protocol is definitely needed here.
I am attaching our FPGA block that does this (U64 --> bit-unpack)
We have not tested this block extensively but would like to present it to the community for improvement.
This is definitely a Library that is useful and needs to continue to expand.
Thanks,
-loera
09-11-2012 12:31 PM
So, the 4-wire blocks that are in the FlexRIO Instrument Development Library are there as a way of allowing a user to create a 4-wire interface without having to think about the 4-wire semantics, with an implementation bias toward high throughput (the 4-wire block looks almost exactly like a shift register from a timing perspective). The truth is that there are a number of ways to implement handshaking that will make trade-offs betweeen efficiency and abstraction, but that discussion is a little too involved for a forum post.
Relevant to your VI, you could use the 4-wire block to success because you have a 64-bit input. You would simply connect your logic to the 4-wire block, but send it the Ready For Output when you consume the last bit of data on a Ready for Output.
The 4-wire block has been successfully used in large designs with 250 MHz clocks, so I would expect it to run with no problems in your situation. However, since you have an internal need for multiple states (1 valid input = 64 valid outputs), it isn't ideally suited (it would work, but it would not be significantly simpler than what you already have).
A couple of other notes, if you use the rotate right primitive (and feed it back instead), that will have much better timing performance because there will be less mux behavior.
I've attached a VI Snippet with some comments and suggestions.
09-13-2012 11:19 AM
dklipec,
I appreciate your feedback. I have implemented some of your changes.
In the diagram that you sent, the 3 input OR gate connected to the CASE structure will still execute the TRUE case even though "ready for output" is low.
This of course is not desirable because it will send the next BIT from the U64 but the next block downstream from the unloader is not ready to recieve.
It is true that it will not send a "T" output_valid signal, but it will have lost a bit.
I think my current code fixes this problem, however, I am now dropping every third U64 word. It is very strange.
I will attach code soon, I hope.... The attached picture is the beginning of our transmitter FPGA code.
At the top left you will see a right bit shifter. That is our current "hack" to get this code working.
Without that hack I will drop every 3rd U64 word. It is very strange.
I hope to be able to find the bug and post the working code. Feel free to examine.
Thanks again,
-loera
09-27-2012 03:19 PM
Hi Ryan,
I am working with OEM board. It is the PCIe-1473R. Could I use some of the functionality in this tools for this card?
It is not FlexRIO.
Thanks - Amit,
09-27-2012 03:27 PM