Understanding FIDL examples: Why are 4xI16 samples packed into 1xU128, and not 1xU64?

[JKSH]

Hello,

I was studying the pre-built examples in FIDL 1.3, and was puzzled by one implementation detail. Acquisition Engine - Facade.lvlib: Packer.vi takes 4x I16 samples and packs them into a U128 value. Doesn't this waste 50% of the bits? Why doesn't it pack the data into a U64 instead?

In case it's important, I'm mainly interested in Acq Engine on 5734 PXIe-7962R.lvproj. (Packer.vi looks like a generic VI that's shared across different projects though)

[BauerPower · Accepted solution]

Hi!

I would take a look at the White Paper titled Three Steps to Using DRAM Effectively in NI FlexRIO. To summarize, different DRAM configurations have different "Access Size," which is the number of bits per memory address. If access size=128bits and you try to write 64-bits to one memory address, the other 64-bits are assigned an arbitrary value by the memory controller in a less-than-ideal fashion.

In order to maximize throughput across the DRAM interface, it is recommended that you write a number of bits equal to the access size. For the PXIe-796x FPGA modules, the access size is 128-bits so it makes sense that we are packing 4xI16 values into 1xU128!

Let me know if you have any questions.

[David-A · Accepted solution]

Like Rob mentioned, the DRAM on the 796x targets makes reads and writes using 128 bit words (look at the properties of  DRAM memory item in the project and go to the Data Type category to see this). Writing or reading less than that will waste bandwidth, so an efficient interaction with DRAM will pack the data up into a 128 bit word.

The packer VI prevents us from wasting bandwidth because it uses feedback nodes to hold on to the last set of valid 4xI16s until another set of 4xI16s are available. It then packs the 8xI16s into a "U128". Packing data like this allows the MultiRecord API to interact effeciently with the DRAM. The image below is from the block diagram of the packer VI in question.

If you're wondering why it creates an array of 16xU8 instead of just 8xI16, the U8 format provides greater flexibility when working with other FAMs. The packer VI and the MultiRecord API are re-used in the example projects we've provided for all the digitizer FAMs. 

[JKSH]

Ah, that's clever!

Thank you Rob and David for your explanations.