How to choose FPGA Bit-file depending on hardware

[Munchuk]

Good Afternoon All,

3 years ago we developed a system for cycling batteries that we are researching. The system is built around a sbRIO-9607, with the rest of the hardware developed in house over a number of years. The kit has been working pretty well since then. Time has moved on, as so has the battery capacity's that we are developing so over the last year, I have been developing new kit to supply more amps to the cells under test.

The idea was simple, keep everything the same and then only ever have one set of LabVIEW code to keep maintained with the same code running on both systems and the difference in current values dealt with in the results processing.  This was a great plan until someone (me) managed to switch the TX and RX lines in hardware. DOH!!! A simple change to the CLIP definition of the ports sorted out this mistake, but now I have two different bit-files for the FPGA code, one for the old system and one for the new.

In the RT Vi I  am going to select which Bit-File to load to the FPGA depending on which hardware is connect to the sbRIO, but I now have to remember to compile my FPGA code twice to produce the two Bit-Files for the different hardware configurations etc etc.  

Would you do it differently?  Am I missing something that would make my life significantly easier to manage?

I'm looking forward to any suggestions that you might have.

Regards

Mark

[crossrulz]

I would just fix the wiring in the new setup.  But if that is not an option, you need to compile the FPGAs to be allowed to use "Dynamic BitFile" (or something like that, it's been a while since I was heavy in FPGA).  Then you can use the Open Dynamic BitFile Reference to load which FPGA build was chosen.

[James_McN]

That is pretty much what I do.

I have a project where we have two different hardware platforms and I use system config API to detect which is present and then chose which open FPGA reference to call.

It increases build sizes and does require you to use a dynamic reference (this has been default for a while now though I think) but it works well.

The only other thing for your case is if it is just a couple of lines backwards - could you not set a flag to select which configuration rather than a whole new bitfile?

[rolfk]

IF it is just those two lines switched I definitely would follow James advice and just modify the bitfile to switch those two lines in FPGA fabric depending on an additional boolean configuration value on the front panel that you add. Two select nodes (or maybe rather 4, two on the input side and two on the output side) is all that is needed and that for sure won't blow your FPGA resource usage up. 😀

[Munchuk]

Thanks for you suggestions.

I wish I could modify the hardware. The lines that are swapped are the TX/RX lines for 4 extra RS232 ports that have been used.

A couple of questions of a few points that I don't understand.

Currently I am using  "Open FPGA Vi Reference" and then pointing it at the bitfile of the FPGA compilation. Why would i have to use "Open Dynamic BitFile Reference" rather than putting "Open FPGA Vi Reference" into a case statement with different BitFile Paths selected in the different cases?

Whilst it is a few lines backwards (8) I'm not sure I understand how I could modify the bit-file to rectify it. I'm not sure that I would be able to do it. The swapped ports are for the RS 232 ports and its not possible to access those lines within the FPGA Vi using an I/O Node.

Thanks 

Mark

[rolfk]

So what is the hardware that you use to implement those RS-232 ports? It can't really be the 9870 module as you can't really change the assignment of the TX and RX lines on that one. It has to be something you can change from the FPGA side as otherwise the two bitfiles would make no sense. So what hardware are you using?

[Munchuk]

I'm not using any extra hardware. The sbRIO-9607 has the ability to have 5 serial ports used. Serial port 1 is hardwired to a connector on the board and the other 4 can be enabled when defining the pins using sbRIO CLIP Generator and the TX/RX lines mapped to any of the I/O pins available on  the RMC connector. (shown in the picture below)

Regards

Mark

[rolfk]

Ahhh I see, the sbRIO boards. Now I understand. So you basically work with two different CLIPs in an otherwise identical software design. That kind of sucks! 😀

I don't know of any way to change the CLIP definition in such a way, that it can be made dynamically reprogrammable. I don't think this functionality is exposed and the CLIP is indeed hardwired into the bitfile.

Custom implementation of RS-232 seems also not very desirable and would be likely impossible to plug into the NI-VISA infrastructure with the publically documented interfaces.

[Munchuk]

Yep, you've got it, same code but two different CLIPs.

Custom RS-232 implementation is not somewhere that I want to go. The work involved in changing it all and the testing would take far more effort than just have to manage two FPGA Compiles each time a change is made, which in reality is that often anyway (touch wood).

I think I will continue with two different bit-file option and work out the "open dynamic" v "Open FPGA Vi, with bitfile path" conundrum.

Regards

Mark

[James_McN]

Hi Mark,

That makes sense - I hadn't realised it was generated CLIP rather than VHDL.

The last time I looked - loading a bitfile by path required you to use a different API (wrapped around C) which is a lot more complicated.

This is what I have in my code to support two different FPGA cards - the same concept should apply (and excuse the extra case for 160MHz too):

 If everything is identical then the interface cast shouldn't be necessary but it does limit the risk of change further down the road.

The load by path method wasn't an option when I first built this. I would probably still go down the same route anyway so that the required bitfiles are embedded in the exe and don't require separate management.