(FPGA) Wait on Edge Method Test Bench Implementation with Two FPGAs

[smithd]

Description

Description-Separate-1

Overview

This example deomstrates how communicate between two FPGAs using a LabVIEW Testbench.  The project also shows how to appropriately implement a "Wait on Rising Edge" method in your test bench.

Description

LabVIEW FPGA has the ability to simulate the logic in an FPGA VI using one of three methods:

1. On R-series cards, you can simulate using real I/O from the inputs and outputs on the card. However, this requires the presence of the card.
2. On all FPGA devices, you can simulate using random I/O data without the presence of the device.
3. On all FPGA devices, you can create a test bench which can provide customized inputs and outputs to your VI.

This example uses the third method to simulate the communication between two R-series cards which would be wired together, as shown below:

It accomplishes this using a custom VI for each FPGA target (the VIs are reentrant, so you can use the same custom VI for both FPGA targets, as long as you add a case for every I/O spot as outlined in the test bench tutorial). These custom VIs send data to a global variable, which contains two booleans which represent the state of each wire. It is critical that the global variables are called by the custom VIs and not the FPGA VIs.  These custom VIs run on the development computer, and so are able to use the same copy of the global variable. If the FPGA VI's directly accessed the global variable data, they would each produce their own copy of the global variable and there would be no communication between the two targets, even though the FPGAs are technically being simulated by the development computer.

This VI does its job by emulating SPI ,a common data transfer protocols. In SPI, wire A contains the clock signal and wire B contains the bit to be sent. This example has both signals generated by Target B and received by Target A, but that is not required. A few simple logic changes are required to modify that behavior. TA VI.vi waits for a rising edge on the clock signal generated by TB VI.vi and then stores the bit set on wire A. It then collects the 8 bits sent by TB VI.vi and converts them into the integer value chosen on TB VI.vi. This is NOT intended as an example of any algorithm, simply as a demonstration of how to use custom VIs to implement communication between two FPGAs, as well as the implementation of FPGA methods in this test bench code. See the code comments for more detail.

Steps to Execute Code

Option A:

1. Extract the attached zip file to your c:\ drive, and open the project from there. The paths are currently set up to be accessed from the c:\ drive.
2. Open wait on rising edge.lvproj

Option B:

1. Extract the zip to the folder of your choice and open wait on rising edge.lvproj.
2. Right click on each FPGA target and go to properties.
3. Select the debugging tab.
4. Select the browse button (folder icon).
5. Locate the appropriate custom VI for that target (TargetACustom.vi for Target A, and TargetBCustom.vi for Target B).
6. Select OK.

Both Options:

1. Open TA VI.vi on Target A and TB VI.vi on Target B
2. Change the number in TB VI.vi to the byte you wish to send (allowed values: 0 through 255)
3. Press run on TA VI.vi.
4. Press run on TB VI.vi.
5. The byte should be transmitted from TA VI.vi to TB VI.vi

Requirements

Software

This VI requires LabVIEW FPGA 2010 or later and the compatible NI-RIO driver .

Hardware

No hardware is required to run this example.

Related Links

Importing External IP into LabVIEW FPGA (this Test Bench implementation can only be used with the IP integration node)

Efficient Development and Debugging with LabVIEW FPGA

**This document has been updated to meet the current required format for the NI Code Exchange. **

Description-Separate-2

[AriM]

Off the hook, Daniel. Just remember that if you want to send data on a single wire then just add a start and stop bit. Doing this will ensure that the first high bit, i.e. the start bit (assuming that this is rising edge), will trigger for the rest of the data to pass through. If you wire the "timed out" into a case structure then the false case can read back the data. If the case is true then just keep running in a loop.