FPGA matrix-vector express VI

[JF-NRAO]

Hi all.

We're trying to put a Kalman estimator in the feedback path of our control system, running at about 10-20 KHz.  We're using it mainly to estimate the velocities of the system,

We've run into trouble fitting the system in.  We have a 4 matrix-vector express VIs we're wanting to put in, one is 5 rows x 5 columns, one is 5 rows by 4 columns, one is 4 rows by 5 columns, and one is 4 rows by 4 columns.

We run out of multipliers, at 106% full.

Are there tweaks we can do to make things smaller?  We already set the # multipliers to 1. 

Some of our matrix elements are zero.  I was wondering if the VI is smart enough not to generate code for zero elements.  If not, we can maybe write our own code to do the 4 multiplications.

Thanks for any tips!

John

[Zach-H]

My First thought would be to try and build some of your code into non-reentrant subVI's. 

You'll find that this won't allow you to run your code in true parallel, but you will get to share the physical resources on the board.  

I'd say if there are any large add or multiplication functions in your code, they would be good candidates to be shared and reduce the number of multipliers you're using.

Try to look for ones that will be running at different times anyway, such as before and after an analog read or write.  

[JF-NRAO]

Thanks for the reply.  The only sort of heavy math functions in our application  are in the 4 matrix-vector express VIs.  I might be able to build my own matrix-vector block that accepts both a matrix and a vector as inputs instead of hard-coding the matrix. 

John

[Zach-H]

The overall idea was to reduce the number of multipliers your code requires.

If you're adding or multiplying anywhere more than once outside of those matrix-vector express VI's you could reduce the number of multipliers being use in your code by sharing them with the implementation of a non non reentrant subVI.

I just mentioned large math operations as good candidates for places to start.  

[JF-NRAO]

Hi Zach.  I'm slightly clueless about hoe to properly organize the labview code for best sharing.  Most of our code is not in separate VIs, but is in one VI, with the math functions explictly drawn.  I'll study up a bit more on it and see if I can make some parts shared by sticking them into VIs.  for instance, we do some scaling of input parameters with multiplication blocks.  Those operations don't need to run every cycle, so I suppose I could take that outside the loop. (Or better, I suppose I could scale it in the RT processor...)

John

[Zach-H]

Moving things to the Real-Time side of things would certainly help reducing the number of multipliers you're using. 

Compartmentalizing your code would be the way to start sharing it. Start looking at areas where you carry out similar functions. It could be as simple as any where you multiply two numbers of the same data type as you do later in your code. 

[JF-NRAO]

Thanks.  This is helpful.  Labview seems simple, but it's not.  🙂

John