The proper way to handle bit manipulation with register containing variable field sizes?

[ShotSimon]

I have a set of registers that contain variable fields of variable sizes.  Field widths are variable since these register are based on FPGA's which allow for very flexible bit packing.  Fields can vary from a field 32 bits wide x 1 register down to a 32 single bits x 1 register and every option in between (see attached).  What is the best way in Labview to operate on this data?  I'm not looking for someone to implement this.  I’m more interested in learning the proper programming technique in Labview.  I realize all the logical operators will work on arrays and I am aware of the data manipulation library.  I'm looking for the fastest implementation similar to bit manipulation operators in C++, or using fields within a structure.  I'm also looking for something flexible, readable, and easy to implement.  SS

[tbd]

Hi SS,

      I've just finished a GUI for testing an FPGA-based device with similar register-bit-packing.  The GUI reads an XLS (once) to obtain a "directory" of signal-names - there's a default value, register index, start-bit and bit-count associated with each signal name (we're lucky that fields don't cross register-boundaries).  One UpdateByName VI serves all register updates.

Doing a signal-name lookup for every update isn't as fast as embedding all the bit packing detail on the diagram as numeric-constants, however it IS "flexible, readable, and easy to implement".

Cheers!

Message Edited by tbd on 02-13-2008 01:07 AM

[ShotSimon]

This sounds excellent...Do you feel like sharing?  SS

[tbd]

Hi SS,

      Sorry for long delay...

Attached is an LLB that implements PackUnpackByName and includes the "Bit Directory.vi", a global, and a typedef.

Note: There's a global "RegisterOffset" that you may not need.  I hope you're like me and inclined to scrutinize "adopted" code!

Here's  a link to an XLS reader VI (basically what I'm using.)

You'll need to initialize the Bit Directory.vi with a directory array, but (assuming you're reading an XLS) our XLS is very awkward and undoubtedly different - our parser wouldn't be of much use.  Also, it's time-consuming to remove proprietary and product-specific detail from this application, so I can't share much more.

Hopefully this will be helpful!

Cheers.

Message Edited by tbd on 02-13-2008 09:30 PM