LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

trouble saving the state of a feedback loop

Highlighted

Picture a simple feedback loop: adder, multiplier, and a feedback node. It's running in a slow while loop on an fpga. I'm going to have a bunch of these things feeding various points in a much faster SCTL. So I thought I'd save a lot of FPGA real estate by saving the state of the register and effectively time sharing the multiplier and adder. So instead of 100 identical loops there's 1 loop with a case statement with 100 cases around the feedback node. I'd still have 100 feedback nodes (1 in each case) but only 1 multiplier and adder. I guess I'm essentially making a nonreentrant vi that saves more than one state. Trouble is, when I wrap a case statement around the feedback node labview balks saying the wire is part of a loop. It thinks there is no delay in the feedback path even though there is (for every case.) I can throw on a feedback node outside the case statement but that screws up the timing of the loop. Is there a way to coerce labview to acknowledge that there is in fact a delay in the feedback path?

0 Kudos
Message 1 of 10
(308 Views)

Could you post code?


Certified LabVIEW Architect, Certified Professional Instructor, LabVIEW FPGA expert
ALE Consultants
LabVIEW Programming (make LV more popular, read this)
0 Kudos
Message 2 of 10
(278 Views)

I can post a screen cap. This is heavily boiled down. The real vi is an IIR filter.

 

0 Kudos
Message 3 of 10
(274 Views)

So you need to hold 100 values?  How about using a 100 element BRAM or a 100 element array (more restricted)


Certified LabVIEW Architect, Certified Professional Instructor, LabVIEW FPGA expert
ALE Consultants
LabVIEW Programming (make LV more popular, read this)
0 Kudos
Message 4 of 10
(269 Views)

@art_ wrote:

I can post a screen cap. This is heavily boiled down. The real vi is an IIR filter.

 


DATAFLOW!!!

 

The case structure cannot start to run until the Multiply is complete. But the Multiply cannot run because it needs data from the Add which first needs data from the case structure. That case structure is a data flow boundary, regardless of what is inside of it.

 

What do you have in your other cases of that case structure?  Posting an actual VI would be the most helpful.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Message 5 of 10
(230 Views)

Would labview accept the delay inherent in bram as a feedback node? The actual application is an IIR filter, so timing is critical. Any feedback nodes outside the case statement would retain values from a previous 'instantiation' that would booger up the response of the immediate 'instantiation'.

0 Kudos
Message 6 of 10
(202 Views)

All cases are identical. Each has just 1 feedback node. I can't post code. That's just the nature of the place. If I put the adds & multiplies inside the case structure will vivado create a separate clone (of the adds & multiplies) for each case (buying me almost nothing) or is it smart enough to reuse the same devices for each case?

0 Kudos
Message 7 of 10
(197 Views)

Why not use an array? You pass the array through the feedback node, index the value that you need, then replace that value with the new one before sending the array back through the feedback node. This is much more scalable than making a new case for every value.

 

A similar option would be to build an Action Engine.

Message 8 of 10
(188 Views)

Depending on how it is configured, BRAM needs a feedback node; see https://zone.ni.com/reference/en-XX/help/371599P-01/lvfpgaconcepts/fpga_memory_items/

 

Is your background in Vivado or LabVIEW?  I ask because you are asking behind the scenes questions.

 

One thing for sure is that 100 cases (in any edition of LabVIEW) is a flag for reworking how a design is being implemented.  This case especially since the 100 cases are the same and just there to hold state.

 

Are you looking to have some kind of circular buffer?


Certified LabVIEW Architect, Certified Professional Instructor, LabVIEW FPGA expert
ALE Consultants
LabVIEW Programming (make LV more popular, read this)
0 Kudos
Message 9 of 10
(171 Views)

Taking your and Johns advice, this is what I came up with. It was easier than I thought and saved me a boatload of real estate. Just wish it ran faster. For 128 channels it takes 1200 40 MHz clock ticks to cycle through the 128 filter operations on the kintex-7 fpga in a USRP 2944R.That's an equivalent sample rate of just 33 kHz. But I can scale it down to 64 inputs and use 2. It's still a big improvement over 128 independent filters.

Capture.PNG

0 Kudos
Message 10 of 10
(119 Views)