fpga programming practices

[jyang72211]

i am looking at a piecie of FPGA code, and i have the following questions about its accepted coding practices.

On the piecie of FPGA code that I am looking at,

1. It seems that sequence structure is used a lot.  Howcome a state machine is not used instead?  Does using a state machine hurt the performance? 

2. It seems that clusters were used sparingly and more shift registers were created to pass variable.  Does creater too many cluster or nested cluster hurt the performance?

3. It seems like some values are passed to the outside of a sequence structure's frame through its top.  Is there a special application for that or just sloppy coding? 

Please let me know if there are some good material to read on the topic.  Thanks!

[nathand]

Please start by reading the "Getting Started with the FPGA Module" from the LabVIEW help, if you have not already done so.

---

jyang72211 wrote: 

1. It seems that sequence structure is used a lot.  Howcome a state machine is not used instead?  Does using a state machine hurt the performance? 

---

A state machine uses more FPGA resources than a sequence structure.  There are times when a state machine is appropriate on FPGA, but if you simply need to sequence some actions in the same order every time, a sequence structure is more efficent.  See the FPGA Resource Utilization Statistics, and notice that sequence structures are "free" - they consume no resources.

---

jyang72211 wrote:  

2. It seems that clusters were used sparingly and more shift registers were created to pass variable.  Does creater too many cluster or nested cluster hurt the performance?

---

Nesting clusters does not hurt performance.  Again, see the resource utilitization statistics - bundle and unbundle require no resources.  There can be a penalty for using large clusters on the front panel to pass data.

---

jyang72211 wrote:

3. It seems like some values are passed to the outside of a sequence structure's frame through its top.  Is there a special application for that or just sloppy coding?

---

Assuming we're talking about a flat sequences structure here (maybe the same applies to stacked, I don't use them): if you pass data out the top of the frame, then some other function can start working with that data in parallel with the remaining frames.  If you only pass data through the right edge, then the last frame has to complete before the data is available.

[jyang72211]

1. You mentioned that there could be penalty for having large cluster on front panel.  If I create a cluster constant to pass data in the block diagram, I should have no penalty, right?

2. According to your experience, do you prefer putting individual controls or large custer on the front panel on the FPGA VI to communicate with the host VI?  It seems to me using a single shift register to pass a large cluster makes the code more organize than having way too many shift registers to pass individual values.

3. For a control, should I create type def or not?  Would type def penaltize the FPGA?  

4. Is multiple parallel while loop with case structure in each loop, while having a loop timer at the first frame a pretty standard FPGA VI?  Any standard architecture for FPGA VI?

5.  For each frame in 4 above, Is it a good idea to have multiple parallel single-cycle for loop to make the code more efficient?  For each frame, I am thinking about enclosing a few sections of code inside a single frame.  

6. Does making things into subvi penalize the FPGA?  I am planing to put many read/write and memory nodes into subvi to make my real estate smaller.

[nathand]

Have you tried writing an FPGA VI yet?  I have the impression that you're trying to understand everything about it before starting any work.  I think you'll learn it better if you start writing some code, then come back to this forum with questions about your specific code, rather than vague questions about FPGA generally.

1. Correct.

2. Well, neither is ideal.  See "Limiting the Number of Front Panel Objects in FPGA VIs" and "Using Clusters and Arrays in LabVIEW FPGA."  But do whatever makes sense to you first and see if it works.  There's no need to optimize until you start running into timing constraints or running out of FPGA resources.

3. From this question, I think you haven't quite understood how FPGA works.  You're compiling your code into hardware.  It has no idea if a control is a type definition or not; all it sees is data.  If a type defintion makes it easier for you to program, use one.

4. I don't believe there's any standard architecture on FPGA.  Again: you're basically building special-purpose hardware out of limited resources; use those resources in whatever way makes sense to you.  If you need the FPGA to perform several independent tasks, put each one in a separate loop.

5. Single-cycle timed loops are always more efficient than a standard while loop, but again, start simple and optimize only when you run into restrictions.  However, it is often possible to avoid standard while loops and sequence structures entirely.  Put a timed loop, configured as a single-cycle loop, on the block diagram.  Drop a case structure in it, and put an integer shift register on the loop.  Connect the shift register to the case structure selector terminal.  Increment the value in the shift register on each iteration.  You now have a simple state machine.  Let's say the cycle clock is 40mhz and you have three frames of code that you want to execute every 200khz.  In cases 0 through 2, put your code.  Create a case 3..198 that does nothing, and a case 199 that resets the shift register back to 0.

6. See "Using SubVIs on the FPGA."  A single instance of a subVI, and every instance of a reentrant subVI, is basically inlined during compilation, so there's no difference between using a subVI and putting the code directly at the top level.

[jyang72211]

You are correct.  I have not tried writing a FPGA VI from scratch yet.  My current project is to understand the exising code, to upgrade it, and to improve it.  Right now, I am looking at a piece of FPGA code and trying to learn as much as I can.  I don't have a project that would allow me to write FPGA code from scratch :<  Hopefully, in the near future, I will gain enough knowledge on FPGA to come up with my own FPGA project.   

I have one more question at the moment.

Going back to the Configure Open FPGA VI Reference, you have 3 path options: build specification, VI, and Bitfile.  I understand that the bitfile option requires the user to compile the FPGA VI into a bitfile, so that the open FPGA VI Reference node can load the bitfile into the FPGA during run time.  What about the other two options?  For the VI option, does it loads the VI directly into the FPGA without compiling the VI into a bitfile? 

Thanks!

[nathand]

---

jyang72211 wrote:

Going back to the Configure Open FPGA VI Reference, you have 3 path options: build specification, VI, and Bitfile.  I understand that the bitfile option requires the user to compile the FPGA VI into a bitfile, so that the open FPGA VI Reference node can load the bitfile into the FPGA during run time.  What about the other two options?  For the VI option, does it loads the VI directly into the FPGA without compiling the VI into a bitfile?

---

You cannot run anything on the FPGA without a bitfile.  Let me repeat again: you are compiling hardware.  Unlike the CPU in your PC, the FPGA is not a general-purpose processor.  The bitfile is not a series of instructions for the FPGA to process.  The bitfile is a representation of the hardware that is loaded onto the FPGA.

There are two advantages to referencing a VI instead of a bitfile that come to mind:

1) Easier debugging.  You can open the front panel of the FPGA VI while it's running, and you can run the entire VI in simulation and use standard LabVIEW debugging tools.

2) You guarantee that the what is loaded on the FPGA matches the VI.  You'll get an error if the bitfile is out of date.

The "build specification" option is relatively new, and I'm not sure when you would use it nor what the advantages are.

[jyang72211]

So for the referencincg a VI option, it is mainly for debug.  Even though the user is specifying a *.vi file, the asscoiated bitfile is loaded as well.  Since I am specifying the path of the fpga vi only, how does labview knows where is the bitfile?  By using this option to debug, i still need to recompile the bitfile everytime I make changes to the fpga vi, correct?  Doesn't it take a long time?  Is there a better way to debug, so that I don't have to spend time recompling the bitfile everything a change is made? 

[GregFreeman]

---

@jyang72211 wrote:

Since I am specifying the path of the fpga vi only, how does labview knows where is the bitfile?  By using this option to debug, i still need to recompile the bitfile everytime I make changes to the fpga vi, correct?  Doesn't it take a long time?  Is there a better way to debug, so that I don't have to spend time recompling the bitfile everything a change is made? 

---

No, after compiling once, when you run with the "VI" option checked, it looks to see if there is already an up-to-date bitfile matching your VI. If there is it uses that. If there is not, then it will ask you to recompile. If you just point it specifically to a bit file, it will load that specific bitfile to the FPGA no matter how your "FPGA VI" on disk has changed. Does that make sense? WIth one option you are saying, look for a bitfile that matches my VI and if it does use that. If there is not one, prompt me to recompile. With the bitfile option, it will load that specific bitfile to the FPGA to be run no matter what.

[jyang72211]

Are you saying that with either options, LabVIEW is using the bit file anyway?  If that's the case, why two options?  What are their differences?

[GregSands]

One reason it might be helpful to reference a bitfile directly is that you can keep using a known version of your code (say a release version v1.0) while you continue to work on your VI.  That would ensure that any changes made didn't get used until you were happy with them.  But good coding practices should ensure this doesn't happen anyway - though in a multi-programmer environment, anything can happen!!