LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FPGA - Effects of updating FPGA front panel controls continously?

Hello All.....
 
I have a few questions concerning FPGA controls, update rates, etc.....
 
1) In my FPGA application, I have a single-cycle timed loop (SCTL) running at 25ns/tick (it is set up as a state machine).  I update an FPGA FP Boolean with TRUE on each tick as it is running.  When running the FPGA VI FP, does this generate any more "update" traffic to the host?  Or are all front panel controls continuously refreshed at an asynchronous rate.  That is, does the actual assignment of the value to the control cause the update, or are they all updated (to the FP) asynchronously?
 
2) If 1) above creates more traffic (to the host PC), then what about when the FPGA is run from a Host VI?  I assume then it would not, since in a host VI we need to do a read / write control......
 
3) I have some controls that are only updated during specific states of the SCTL.  I also have other controls (Shift registers that get set and stay set if a FIFO Overflow occurs) that update the FIFO OVERFLOW FP indicators every tick.  I could make it so the FIFO OVERFLOW controls only update during those states that a FIFO write occurs.....  In terms of the FPGA logic, is it actually more FPGA -resource intensive to have the extra logic to do this?
 
I am setting up two boolean indicators on the FPGA FP VI, EXECUTING and EXEC COMPLETE.  Before I run any states (Read info, acquire, etc) both indicators are off.  When any state set is executing, the EXECUTING boolean is set TRUE.  Now, my state lengths (ie set of states chained together) can run from 50 ns total to forever (continuous acquire).  When the SCTL stops looping, I set EXEC COMPLETE to true. 
 
So, from my host VI, if I examine the indicators:
EXECUTING      EXEC COMPLETE
False, False = Never ran
True, False = Running
True, True = Completed Running
 
Then my Host VI will set both indicators to FALSE in preparation for the next run.
 
I had just the EXECUTING indicator, but since the control updates appear to be asynchronous and some of my states can run so fast I was afraid that if I started the state, then examine the indicator I could possibly miss the indicator going TRUE.
 
Is there a better way for the host VI to ensure that the state has run?  I looked into using interrupts but it appears that there are issues running multiple interrupts and I think I may need to use them later on in another part of my application.......
 
Whew.... Sorry for being so verbose but thanks for the input!
 
Howard
0 Kudos
Message 1 of 6
(6,125 Views)
Hi Howard,
1) The FPGA front panel is updated asynchronously, in another word, it's lossy updates.
2) The read/write method reads/writes from the buffer that the host uses to communicate with the FPGA, and it does not generate more traffic.
3) Yes, it's more resource intensive to have extra logic in the FPGA.
If the host is suppose to be the middle man and it's the only one responsible setting the booleans back to FALSE, then your current solution should be fine, because that would make it a synchronous operation.  If all your host is doing is monitoring the boolean, you should not be reading the front panel controls, you should use a DMA FIFO.
Hope this helps.

Yi Y.
Applications Engineer
National Instruments
http://www.ni.com/support
0 Kudos
Message 2 of 6
(5,989 Views)


@Yi Y wrote:

........ If all your host is doing is monitoring the boolean, you should not be reading the front panel controls, you should use a DMA FIFO.
Hope this helps.

Yi Y.
Applications Engineer
National Instruments
http://www.ni.com/support


Hello Yi Y,

Could you expand on this a little further?  I am currently using all three DMA channels for passing data, so this may not work for me, but you are saying that the preferred way to monitor a control is through a DMA channel?  Unless I was reading many controls, wouldn't this be wasteful, at least in terms of overhead?  Or is this method much more deterministic?

 

Thanks!

Howard

0 Kudos
Message 3 of 6
(5,972 Views)
Hi Howard,
If you actually want every cycle worth of data and can't miss a cycle you will have to use a FIFO.  If it's not important that you get every cycle worth of data, then you can use the host interface and read the controls.  It's not necessarily the prefered way depending on your application. It is more overhead to use the FIFO, the software on the host side has to receive the data and you'll have to use a hardware channel for DMA and allocate a buffer for it.  However, that's the way to get every data point your controls output.
So do you just want to monitor the states or are you controlling your FPGA from your host?

Yi Y.
Applications Engineer
National Instruments
http://www.ni.com/support
0 Kudos
Message 4 of 6
(5,846 Views)
Yes,  The data I need to acquire with no gaps are going through the FIFOs.  I just use the controls to monitor the status of the FPGA execution, hence why the FPGA sets the EXEC COMPLETE indicator and the only way to clear it is to use a Read/write node from the Host or reset the FPGA.  On my host I have sub vis (Wait For FPGA IDLE and Wait for FPGA IDLE AND EXEC COMPLETE) that monitor the booleans every 5 ms, and returns when the conditions are met or they time out.....
 
So, in your reply previously to 3), it is correct that it is better to update the indicator during every cycle of the single cycle timed loop, rather than have code to only update the control only when the value changes, since it is hardware, if the hardware is in place to do it once it is actully MORE code (resources) to determine when not to do it? 
 
Thanks!
0 Kudos
Message 5 of 6
(5,833 Views)
Hi Howard,
Yes, it s actually more code/resources to program the FPGA with the logic to determine when to update and when not to update rather than having a SCTL that updates constantly.  Since it is hardware, if you don't use a piece, i.e. the indicator register, it just sits there and takes up space. It doesn't inflict extra overhead to update the booleans constantly if the code is already in place to do it.

Yi Y.
Applications Engineer
National Instruments
http://www.ni.com/support
0 Kudos
Message 6 of 6
(5,580 Views)