05-25-2013 06:17 PM
Hi ni
I have connect host vi that executed on computer with fpga vi that executed on the fpga target
the problem is that the process of moving data form host to fpga and inverse totally unclear
like
1- did labview use buffer memory or anything during this process
2-did lv move data from ram of PC then to USB bus then to internal signal of fpga or another method ??
3-did this proces of connecting two vi take a FPA silicon ??? how much!!!
I wish if NI have answer to these thing and put it in knowledge base as flow chart
best regards
05-28-2013
01:25 PM
- last edited on
04-28-2025
06:02 PM
by
Content Cleaner
Are the VI's you are using example programs shipped with LabVIEW or downloaded from ni.com/code? I am not sure that I am understanding your question fully. The following links may be of some use for you:
-Transferrring Data between the FPGA and Host (FPGA Module)
-Transferring Data between Devices or Structures Using FIFOS (FPGA Module)
05-28-2013
04:44 PM
- last edited on
04-28-2025
06:02 PM
by
Content Cleaner
@Dan_the_Man wrote:
Are the VI's you are using example programs shipped with LabVIEW or downloaded from ni.com/code? I am not sure that I am understanding your question fully. The following links may be of some use for you:
-Transferrring Data between the FPGA and Host (FPGA Module)
-Transferring Data between Devices or Structures Using FIFOS (FPGA Module)
thank you
i have read this toturail before
i mean explaination in in depth how the process happen
the problem that allwayes suffer with working with labview i and labview fpga is that everything is simple
just one block vi do everything
some time we need in depth informatin about how the opration done
this is what i mean
regards
05-29-2013 06:00 PM
Are you wondering how the data is actually physically transferred from host to the FPGA target? This is proprietary information. If the actual physical process of how we specifically do it with our hardware was public knowledge, then anyone would be able to copy the process. I apologize if this causes you an inconvenience.
If I am not understanding this correctly, please let me know and I will do my best to answer your specific question.
05-29-2013 09:06 PM
@Dan_the_Man wrote:
Are you wondering how the data is actually physically transferred from host to the FPGA target? This is proprietary information. If the actual physical process of how we specifically do it with our hardware was public knowledge, then anyone would be able to copy the process. I apologize if this causes you an inconvenience.
If I am not understanding this correctly, please let me know and I will do my best to answer your specific question.
Dear
Are you wondering how the data is actually physically transferred from host to the FPGA target?
Yes Dan this is what I want
I know its Copyright but may be some information (flow chart) related to the transmitting operation may be help in understand the operation
not in depth at clock level information but at medium level
please if have any information related to the transmitting process in somehow I will appreciate that
09-30-2013
04:03 PM
- last edited on
04-28-2025
06:05 PM
by
Content Cleaner
At a "medium" level as you say, there are generally three main entities that must interact with the data as it moves through the system: the two end targets (the host and the fpga in this case) and the communication layer (e.g. the pxi bus).
Each of these targets requires the data to be formed in certain ways to maximize performance. The host utilizes large blocks of memory. The FPGA generally has smaller buffers that operate on the data at higher rates. The communication layers generally see things in packets composed of some number of 16, 32, or 64 bit chunks.
This means that when you want to transfer data from the host to the FPGA. The data must first be buffered so the communication layer can send smaller packets (might require a copy of the data). The bus then ships these packets out through the network (whatever that may be) which may involve other buffers at various switches along the way. Eventually these packets make it to the FPGA. The FPGA layer must unpack that data (possibly another copy of the data) and put it in the correct buffer.
The key variants here are which form of "transportation" you are using. Registers (like controls and indicators) generally utilize more CPU time as each operation is atomicly guaranteed between the targets. DMA can hand a lot of this work off to more efficient hardware subsystems.
The "secret sauce" as was pointed out earlier is how these transfers can be optimized such that they require fewer copies of the data, utilize the bus more efficiently, require less CPU intervention, etc. These things are constantly in flux and can change between releases as new and better ways of dealing with data are implemented and new networks/features are supported.
Sometimes these features are exposed to the user as is the case with the Data Value Reference access directly into the memory space of the DMA FIFO on the host size. In general, LabVIEW tries to optimize performance such that 90+% of applications cannot be easily written to perform better than what LabVIEW does automatically. So feel good knowing that you don't have to worry about dealing with these issues in most cases : )