Continuous execution in FPGA Vivado

[A.Daniel01]

Hi, the last day I asked how to generate the VHD files from a LabVIEW FPGA project and now I can simulate. What I tried to do but I don't really know how to do it or how this works is to run the code without stopping. The simulatión has 4 states (start, run, stop, idle), the problem is that right now when I execute the simulation it only run for like 4 uS and 10 uS from the start to the end. Now, if I want to have a while loop where for example I have a counter, I don't know how to keep the FPGA running.

I tried using a While Loop, thinking that the execution would depend on the LabVIEW code,  it didn't work as expected, I also tried using timed structures but the result was the same, changing parameters on the vivado software but I didn't saw anything. What I did and worked is in the test bench file that LabVIEW generates and where I write the values of my LabVIEW controllers, to add a Wait in the end of the running mode, this worked but it's still not a While Loop (and I tried with a While in vivado but didn't worked, probably I did something wrong) and I want to controll the execution from the LabVIEW code, I don't want to change the VHD files every time.

I am using an PXIe-7976R, with the third-party simulation option, but only for testing, it was the first one that I saw thanks to LabVIEW IP Export example.

Thank you for the help.

[Bob_Schor · Accepted solution]

Most of my FPGA code consists of the following:  A Frame Sequence with two Frames, a very narrow first Frame where I initialize any variables that I need in the second Frame, and also do any hand-shaking I need with the Real-Time Code that uses the FPGA, and the second Frame is a series of While Loops, with essentially no Inputs or Outputs, all of which have "False" wired to the Stop Control (so they run "forever" or until the user Pulls the Plug).  You don't "change" the FPGA during run-time -- if you need it to do two different things, you program it "to do two different things" and pass in a variable that is read inside a running While Loop that says "Now do this other thing".  The FPGA is always running ...

[I'm quite prepared for someone who really understands FPGA much better than I do to tell me that I'm wrong about this, but I'm reasonably confident that this is likely to be the "correct answer" in 99% of the cases ...]

Bob (well, sort-of confident) Schor

[A.Daniel01]

Hi Bob,

Thank you for the answer, for the simulation test I used this VI to test how it work and to see the difference between the While loop and the timed one. I think is what you use for your FPGA codes, much more simplified.

The problem is that I create the simulation export, launch the simulation, and it only works for 10 μs, the running for 1 μs. That's why I think there is something about the Vivado software. Probably I need to configure something to keep the simulation alive.

But in theory, if I use it with a real FPGA, it should work the way I want. So that's enough. Thank you for your help.

[Bob_Schor]

For the FPGA code, I do not use a Timed Loop.  The FPGA has very accurate timing functions that run in exact synchrony with the FPGA's clock rate.  Much of the time in FPGA code, you're doing sequential steps, so you use Frame Sequences with timed Waits inside them to control the timing of the various steps.

What you need to remember about the FPGA is that you are programming on a "micro" level, with literally all the code running in parallel. You end up doing a lot of the timing yourself.  For example, here is the code to do a conversion on an A/D Chip, which starts converting when a signal nCNVST_C_00 goes low-to-high, and is done basically when n_nEOCS_active-C_lo_00 goes low (don't blame me for the names -- our Design Engineer made up the names for the circuit boards).  The little hourglasses are the Wait functions, which can use the FPGA "Tick" clock (running at 40 MHz), a µSec clock (see second Wait), or a mSec clock.

Note that the first two Frames are timed (Convert is asserted by pulling it low for 100 ns, then it is pulled high for 2 µs to start the conversion), and then we wait until the Chip asserts nEOC (End-of-Conversion, negative logic).  This starts when the RT Target raises (makes True) the "shared" Boolean "Cvt CB", which it turns off when the Conversion is done (to let the Target know).

Bob Schor