I have a situation that I hope someone can shed some light on. Currently I have an FPGA design that collect highspeed data does some processing on it and spits out the results over DMA for the host to read out and save to TDMS files. Currently I am reading 4MB worth of I16 data from the DMA every 25-30 ms, the current design is able to keep up with the data rate just fine. My next task is to allow the FPGA to collect the same type of data, with the same processing, only providing the data back in I8 format, which means one of the following design decisions:
1- keep existing FPGA code/FW and cast the data to I8 on the host side.
The downside to the first option, is the high data rate. I did some benchmark testing with a couple of different methods to do the I16 to I8 cast (Number Split, to I8 cast, and Typecast). Needless to say the Typecast was too slow for my operations averaging about 35-40 ms to cast the 4MB worth of I16 data to I8. The number split and to I8 cast both came with an average time of approximatly 15ms but with a max time of 23 ms. These times were obtained with a system with very little load, which will not be the case on the final design.
2- develop/compile a new FPGA VI that does the exact same operations except convert the data to I8 on the FPGA and send it over a DMA defined with I8 datatype.
The downside here is the need to maintane two versions of the FPGA code as well as two versions of the driver code, this is since the DMA used to transfer the data has changed datatype from I16 to I8 which prevents me from using a dynamic refrence when operating with the FPGA. I also am using all the available DMA channels on board so I cannot just declare both I16 and I8 DMAs and read from the appropriate one on the driver side.
My question is, is there a cheap way of doing the cast operation on the host side? It was mentioned that LV FPGA will use U64 to transfer the data internally and only cast it to the required data type at the end, is it possible to leverage this operation to get it to cast to a differnt data type on the driver side, if this is true? Otherwise is there a fourth method of doing the cast that is cheaper? any other ideas are welcome.
Sorry for the long post.
Solved! Go to Solution.
You could just put the raw DMA data into the TDMS file and process it later. Stick a flag in the file that says whether it is I8, I16 or whatever.
The issue here is the data rate we are dealing with, the idea is that we want to reduce the data going through the system down to the TDMS file. A single FPGA will produce three data streams at the exact same data rate. In the final system we have 4 FPGAs on a single PXI, two of these FPGAs need to operate with the reduced data rate, and as such will save a considerable amount of disk space. This will also reduce the amount of data being written to the drives.
Update your FPGA to be configurable to either pack I16s or I8 into its DMA stream, that way you have one FPGA to maintain and you have a reduced stream from the I8 configured FPGAs (i.e. half the number of DMA values should be sent). Send your DMA values to always be some multiple of I16 so you can easily pack and unpack once they are in TDMS files. The host side always receives the same DMA element (e.g. I16) and doesn't really care that in some cases it contains two I8s.
Thanks for the suggestion. This actually resolved a couple of issues for me as I dont need to maintane multiple FW/Driver versions since I am reusing the same DMAs to send the data to the host.