I am testing the FFT function of our target with specific data. I have a waveform that I generated with LabVIEW as our mock data (it's very specific). There are two main goals: 1) use this data as our input 2) run this FPGA VI in a simulation mode and avoid having to compile/synthesize. It is worth noting that I have tested this FPGA FFT funciton by simply copying and pasting it into a host type of a VI for functionality. Next step is seeing the behavior when this code is on the actual FPGA target.
FPGA loop image is the code that I have on my FPGA. (The FPGA target is in a Simulated I/O mode.)
Next, I wanted to create a testbench on my host where I will use my waveform generator as an input to AI 0. I started by creating a desktop execution node. In host vi image, you can see the IO options I am able to add. Here is issue one, the desktop doesn't allow me to connect to AI 0 as an input. Why is that?
In an example on how to write a host test bench, I saw that they were able to use the I/O target resources (images goal and goal2).
To recap: I would like to be able to create my own input for this FPGA AI 0 and run it in a simulation mode, avoiding compilation. I'm not sure what exactly is going on. I know that since the card we are using isn't like a RIO with its own IP address, it's under the MyComputer hierarchy, but I'm kind of stuck from here on. Any help is appreciated.
After some brainstorming, I got one idea. Do I need to use Host to Target DMA FIFO to write the data to the FPGA and then read them into the FPGA input?
Please see the detailed example of how I used Desktop Execution Node to simulate the FPGA VIs. This is a discussion with examples.
The basic idea is that you have a few files involved in the simulation.
1. Your FPGA VI DUT (usually does not contain an SCTL or while loop).
2. Your FPGA VI simulation model (copied and pasted your source code into a SCTL). This should replace any board/FPGA IO or DMA FIFOs with controls/indicators - I use Conditional Disable blocks, attached to the FPGA Execution Mode environment variable to alternate between my hardware and simulation implementations.
3. Your testbench host VI.
If your DUT already has an SCTL, then item 2 isn't necessary. However, if you're testing subVIs and want to see their cycle-accurate behavior, item 2 is necessary.
The testbench host VI performs at least 2 functions, possibly 3.
1. Generate stimulus to a desktop execution node. The DEN is configured to point to your simulation model (item 2), and using the expected clock frequency. In my example, I'm creating test vector arrays. You can set up a stimulus generation VI to do constrained random inputs if you want.
2. Place the DEN into a for loop, with iteration count appropriate for your test vector. For instance, if your system requires 8 cycles of latency, then you'd have iterations = input test vector array length + 8.
3. Mark the for-loop as a Sampling Probe source, and each input and output from your FPGA as sampling probes.
Run the host VI and review your results in the Sampling Probe waveform window.
If you have the capability to do so, I recommend making a software-optimized bit-accurate model, and comparing the FPGA model results against the bit-accurate model results. If you need more visibility into the design for debug, then simply add more controls/indicators to your DUT so that they are exposed in your host VI and add them as sampling probes.