IIR Cascaded Second-Order Sections Form II Transposed: FIFO Overflow in Simulation Mod

[andy_3141593]

Hi There,

I've inherited some FPGA code that originated from NI that implements an "IIR Cascaded Second-Order Sections Form II Transposed" filter that one of our customers have used for years as an FPGA personality called by Veristand.  It is very similar to the IIR_SOS_FPGAVI.vi within the "Cascaded Second-Order Sections IIR.lvproj" example in LabVIEW 2016.

We've had a problem bench, and I've been investigating.  I think I have a solution to the problem (waiting for an opportunity to travel to customer site), but since we use this filter a lot, I would like to get this it into a better development environment so that I can tell what is going on with it.

For starters, I would like to run this FPGA code in simulation execution mode.  I've attempted to use the Diagram Disable Structure to poke in some simulated inputs and read some outputs from the front panel.  At some point I had the simulation working right, but now I've got the input FIFO overflowing.  The overflow seems to be related the handshaking in the filter.  Fortunately, one difference between my code and the example is that the filter code is exposed instead of being wrapped up in a VI generated by "IP Builder".  I guess probably because it is older, maybe 2010 vintage.  But unfortunately, the filter is complicated enough that I just can't figure out what it is doing.  I would like to resolve the FIFO overflow issue.

I've contacted my sales person, and he said the original person involved with this filter has left the company.  However, it doesn't seem to be an isolated piece of code but something that has been reused at NI.  The "Cascaded Second-Order Sections IIR.lvproj" example is a case in point.  There are also several NI articles about this, such as this article, and an old user group.  I am hoping to find somebody that knows something about this filter.

[richtian]

Can you post a diagram here about how you make the connection and what modification you made on the generated filter FPGA code? Without any hints from the diagram, no idea of what you are actually doing. 🙂

[andy_3141593]

Rich - Thank you very much for taking my question!!  Hopefully this won't be too much to sort through.  I'll try to keep it simple.  First, I haven't made changes to the filter itself.  I believe it remains as it was originally received from NI many years back.  I have at least some confidence that my predecessors did not change the filter either, but I cannot guarantee.  For reference, here is the filter.  I'm hoping it reflects something you've seen before.

Filter

My problem bench was having noise issues, and as a debugging step, I worked to expose the pre-filter data.  After much development time spent, I believe I have a solution to expose the pre-filter data.  See below.  The modification is in the red box.Change to expose prefilter data

At one point I was able to develop and test this solution with my test target in simulation mode.  See red box below.

Simulation Mode

However, when I went back to the code some days later, I never could reproduce the simulated result.  Perhaps somehow I got lucky.  My solution did prove out in hardware though, so I'm hoping it will work at the customer site.  However, I would like to get this back up an running in simulation mode so I'm ready if this solution doesn't work at the customer site or if something else comes up in the future.  Below is my instrumented version of the same code above and the problem parameter in the red box.  I observe that the To Filter fifo overflows.  That is, the "Number of Elements to Read" property quickly rises to maximum and stays there (1029). 

FIFO overlow

You can see the data below.  "Data in XML order" is my simulated data.  The "loop 3" indicator shows what was loaded into To Filter fifo.  The "loop 2" indicator shows what was read from the To Filter fifo.  When I run this same code in hardware, Number of Elements to Read stays mostly at 0 (sometimes 1) and the data in "loop 2" reflects "Data in XML order").  But here, the Number of Elements to Read is max'ed out and loop 2 data doesn't reflect what was loaded into To Filter fifo.

I would be happy to send my project to you if you like.

[eestone]

richtian and I have worked on IP builder and DFDT quite a few years ago. I would like to check the project if you can send it to me. My email is lei.song@ni.com

[richtian]

There is no throughput guarantee on the DMA transfer in simulation mode. That's to say, in FPGA mode, the DMA can give you several GB/s throughput and FPGA can process the data super fast. While, in simulation mode, both your host VI and FPGA simulation VI are running on CPU using CPU resource so there is no guarantee about the computation speed for the FPGA simulation code. On FPGA, the elapse to get two continuous sample from the DMA is long enough for the filter processing. While in simulation mode, it's not. Hence, to make it work, you need to do some throughput control on the host side. For example, if your DMA depth is 1024, make sure that you don't feed more than 1024 at a time in simulation mode. And I guess that, the reason why you got luck in your ever successful trial is that you didn't feed too many samples through the DMA. 🙂 Hope that this helps.

[andy_3141593]

The DMA fifo doesn't seem to be an issue, but rather the "To Filter" fifo.  Here is the parallel loop that fills the fifo.  You can see I have a very large delay in this loop (.2 sec), and I still see the To Filter fifo filling up.

[richtian]

I don't think the Loop Timer is simulated as the expected behavior on FPGA. One thing you can try to verify is checking the iteration count i of this WhileLoop. See how fast it grows, comparing with the actually filtering loop.

[andy_3141593]

I set up a parallel loop with no delay to chart local variable copies of the iteration counts.  Loop 2 is the filtering loop that unloads "To Filter", loop 3 is the sampling loop that fills "To Filter".

Also I added microsecond tick counter to loops 2 and 3.  Below they are charted.  Both charts are identical, but I've adjusted the y-axis on the top one.  Both iteration counts above and  tick counters below are in the same parallel loop with no delay.

[richtian]

Umm, what I was referring to is the loop count i, but not any time elapse measurement node. Probably it's easier for me to figure it out when I have the test code. But I only have LabVIEW 2016.