Interchangeable FPGA code blocks without recompilation

[cbutcher]

Is it possible to write multiple different implementations of some 'interface' (concept, not necessarily LabVIEW interface) that can be compiled for FPGA and then switched between at run-time?

I know a complete bitfile can be changed fairly quickly, but if (for example) I have three steps in a process and each step has two possible implementations, I'd end up needing 8 bitfiles (each of which would need recompilation if any one step/implementation changed). This only gets worse as the number of options or steps increases...

Can I use CLIP, the IP Integration Node, or some other available tool to solve this more easily? Ideally I'd prefer to write LabVIEW (FPGA) code, but VHDL could be fine if that's the only/better option. I'd like to be able to add implementations for a given step without recompiling all of the others, subject to the limitation that I use the same inputs/outputs and timing restrictions as the existing implementations for that step.

I'd like the FPGA VI to be able to be compiled individually of the steps.

Use of the FPGA I/O might be useful (prohibiting the IPIN), but isn't currently critical to my thought experiment (so if the IPIN is nicer than CLIP, please explain why I should prefer that! 🙂 )

[Terry_ALE · Accepted solution]

Partial reconfiguration is supported by tools such as Vivado https://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_1/ug909-vivado-partial-reconfigur... but NI does not support that feature.

CLIP vs IPIN really depends on the IP being integrated.  IPIN supports simulation so I prefer it but CLIP is more flexible with clocking options.  That may be a rabbit hole in this case.

I would take a step back and see what kind of configurations you need to have.  Is the logic or are the parameters different?

I would consider using Conditional Disable diagrams to set different builds.  In other words, the problem may be solvable at a higher level.  I have never had that many configurations but this is a first cut at it.  OOP may also be a consideration.  Have you seen how NI implements the DRAM IDL?  It is supports different memory configurations that get pulled in based on the target.

[cbutcher]

Hi Terry,

Thanks for the link - I'll take a look!

Good to know that neither CLIP nor IPIN will necessarily help in this case.

My plan was to consider different implementations (perhaps, for example, image kernels/equations for calculations) but the same inputs/outputs (e.g. an image pixel by pixel, producing an array of vectors with perhaps the same size as the image resolution).

I haven't coded (or even really planned to code) any of this yet, but I'm trying to work out what might be possible.

OOP and dynamic dispatch solves this problem neatly - I could easily switch between implementations - but not at runtime. Since the classes have to be statically resolved, I can only compile one combination per bitfile. I suppose I could probably script generation of each combination and then submit them all to a server for compilation, but it's not my preferred approach (it may be the only one, though...)

I'll take a look at the DRAM IDL. I've never looked at it before.

[Terry_ALE]

Definitely not dynamic on the OOP on LabVIEW FPGA.

[Intaris]

---

@Terry_ALE wrote:

Definitely not dynamic on the OOP on LabVIEW FPGA.

---

I use a lot of dynamic dispatch on FPGA. What's wrong with it?

I don't think it's necessarily going to solve the problem as listed, but apart from that, nothing wrong with it. Works really well actually.

[Intaris]

---

@cbutcher wrote:

Hi Terry,

Thanks for the link - I'll take a look!

Good to know that neither CLIP nor IPIN will necessarily help in this case.

My plan was to consider different implementations (perhaps, for example, image kernels/equations for calculations) but the same inputs/outputs (e.g. an image pixel by pixel, producing an array of vectors with perhaps the same size as the image resolution).

I haven't coded (or even really planned to code) any of this yet, but I'm trying to work out what might be possible.

OOP and dynamic dispatch solves this problem neatly - I could easily switch between implementations - but not at runtime. Since the classes have to be statically resolved, I can only compile one combination per bitfile. I suppose I could probably script generation of each combination and then submit them all to a server for compilation, but it's not my preferred approach (it may be the only one, though...)

I'll take a look at the DRAM IDL. I've never looked at it before.

---

I'm not perfectly clear where your problem lies. Is your code too big to fit multiple "methods" on the same FPGA target? Are you coding in SCTLs or not?

What you cannot do with FPGA is have true DD behaviour. As you know, each class gets folded down to static calls during compilation. So if you need 8 different code paths, you need 8 different implementations in FPGA. Perhaps some of the methods can be parametrised, so that they use the same core but with different parameters?

Of course, easiest way would be to pack all 8 methods on the FPGA and switch between them on-the-fly. Either that or changing object at run-time includes re-deploying a Bitfile.....

Where OOP helps is defining which kernel you use in your SOURCE CODE only. Run-time DD is (obviously when you consider it for a moment) not supported. So OOP can helo with house-keeping source code but don't expect any of the fancy dynamic swapping to be available after you press the "compile" button.

[Terry_ALE]

---

@Intaris wrote:

---

@Terry_ALE wrote:

Definitely not dynamic on the OOP on LabVIEW FPGA.

---

I use a lot of dynamic dispatch on FPGA. What's wrong with it?

I don't think it's necessarily going to solve the problem as listed, but apart from that, nothing wrong with it. Works really well actually.

---

Sorry, I am incorrect here, you are correct.  The DRAM IDLs use dynamic dispatch and I use those.  What I meant was the dynamic loading of a function at runtime which I think you clarify further down on this thread.

[cbutcher]

Thanks for the link Terry - the partial reconfiguration is exactly what I'm trying to do. It's unfortunate (but not really surprising) that it isn't supported in LabVIEW, but it gives me a nice-ish fallback option.

---

@Intaris wrote:

I'm not perfectly clear where your problem lies. Is your code too big to fit multiple "methods" on the same FPGA target? Are you coding in SCTLs or not?

What you cannot do with FPGA is have true DD behaviour. As you know, each class gets folded down to static calls during compilation. So if you need 8 different code paths, you need 8 different implementations in FPGA. Perhaps some of the methods can be parametrised, so that they use the same core but with different parameters?

Of course, easiest way would be to pack all 8 methods on the FPGA and switch between them on-the-fly. Either that or changing object at run-time includes re-deploying a Bitfile.....

I'm not currently writing any of this code, but I expect it will be in SCTLs. I suspect (especially if I considered moving from cRIO to PXI) that multiple methods could be implemented and selected between via e.g. enum, but this leaves (potentially sizeable) chunks of the FPGA unused but with the resources required for currently unused methods.

I also imagine that given some hypothetical finite FPGA space, if I want to increase throughput (of course, there's an upper limit to the needed throughput, but I don't know how likely I am to reach it) then using more space for parallelization is a good option. If I need each 'function' to be implemented several times (one for each option) then that will reduce my available space for implementation by the same factor.

Maybe this is a case of premature optimization, and everything (including at-that-time-unchosen-options) will fit with more than enough throughput. But I'm doubtful 🙂

Regarding parameterisation - yes, probably some would be possible to use a single 'core' implementation with parameterized variations. I had imagined problems with perhaps changing the size of various arrays, but I suppose I could allocate a maximum size and allow a variable value less than that maximum without needing to implement the entire section repeatedly. I'll keep this in mind when/if I get into more detail planning this out.

---

@Intaris wrote:

Where OOP helps is defining which kernel you use in your SOURCE CODE only. Run-time DD is (obviously when you consider it for a moment) not supported. So OOP can helo with house-keeping source code but don't expect any of the fancy dynamic swapping to be available after you press the "compile" button.

---

Yeah - its clear why this doesn't (can't?) work but it does mean it can't be easily used to solve this problem/issue. As you say, it's still useful for changes that can be made at compile-time only.

Edit: Actually, whilst I think it's clear why it doesn't work, it's not so clear why it can't. Isn't the partial reconfiguration essentially a possible solution for this? I suppose managing to find the necessary restrictions on a class in order to indicate the required size(/width?) at intermediate file generation would be a horrible problem though... but is that basically the idea here?: https://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Run-Time-Dynamic-Dispatch-Support/idi-p/2896184

[Intaris]

That idea refers to a pre-defined set of dynamic methods which, when you analyse it, essentially boils down to my "throw it all on a single target and select one" option.

It's just syntactical sugar for that option, plus some other IDE niceties.