Efficient packing of data for BlockRAMs, UltraRAMs

Hi,

I have a system where there's four channels of 18-bit data processed simultaneously and written to a RAM as 4096 words x 4 channels of data. HDL Coder seems to want to instantiate four separate RAMs (appears that way in the Verilog), and Vivado shows this too.

I'd like to see the four channels packed into a 72-bit word and written to one location in an UltraRAM. I specified "ultra" for the RAMDirective, and this "works" - the netlist shows four UltraRAMs in use, so at least we've got UltraRAMs.

But how do I get the data packed into a single 72-bit word? Is that something I need to do in the Simulink diagram?

Thanks,

Charles

Answer 1

[Ryan Baird]

The RAM block interprets vectors of data to mean you want separate RAM banks. In order to store and retreive the data as a single value, you currently need to combine the data before writing and separate the data after reading outside of the RAM block. The easiest way I'm aware of to do this is with the Bit Concat and Bit Slice blocks. You could use a Bit Concat block before the RAM block to combine the data, and use Bit Slice blocks after the RAM block to separate the read data back into 4 different values.

[Walter Roberson]

I am just wondering what, within the context of HDL, the consequences are of separated vs combined?

If different chips were being used for different banks I might worry about their rate being different, but that would not seem to be relevant to one unified HDL?

Traditionally multiple banks permitted more parallelism and so higher rates, but on unified HDL the circuits would be operating in parallel anyway so that does not seem relevant.

The only thing I have come up with at the moment is 4x18 would potentially have a disadvantage compared to 1x72 of potentially requiring some control logic to be duplicated 4 times?

Would there be expected to be heat differences?

[Ryan Baird]

It can make a difference for FPGA targets. Since the RAMs available on the target device are of specific sizes, when we split our RAM accesses into 4 banks it will often be synthesized as 4 RAMs instead of 1 RAM, taking up unecessary resources on the FPGA.

[Charles]

My guess was that emitting code that automatically packed vectors most efficiently into a BRAM/URAM might be less platform-independent. So if you want more efficiency, you need to code it yourself, knowing the platform.

At any rate, I've checked this all the way to synthesis, and it works. One "gotcha" is that I now need to work out a way to alternate between running the system with doubles and with fixdt(1, 18, 0). Sounds ugly, but I don't think it's impossible.

[Charles]

A follow-up about constucting a system that can use either fixdt(1, 18, 0) or double in the Bit Concat/Slice operations required to pack four vector elements into a word:

• It doesn't work with doubles, because it would take a 256-bit word, and Simulink doesn't support more than 128 bits
• Casting to single didn't work for me either. I tried various combinations of casting, using Stored Integer instead of Real-World Values (I assume that's like C++ reinterpret_cast<>), but couldn't get the system to work right with double. I gave up because I don't need this optimization that badly
• To be clear, this does work with 18-bit ints, as would be needed for using UltraRAMs, but as I need to be able to run in either configuration for validation/verification, I won't be implementing it.

Thanks,

Charles

[Ryan Baird]

One possibility is that you could concatenate one type and not the other. That might be easier to do with MATLAB Function blocks, e.g.:

function out = concatIfNotDouble(v)
   if(isa(v(1), 'double'))
      out = v;
   else
      % Assumed array of four 18 bit fixpt values
      out = bitconcat(v(4), v(3), v(2), v(1)); 
   end
end

function out = splitIfNotDouble(v)
   if(isa(v(1), 'double'))
       % 4 double values
       out = v;
   else
       % Assumed 72 bit value to be split into four 18 bit values
       out = fi(zeros(1,4), 0, 18, 0);
       for i = 0:3
           start=18*i+1;
           out(i+1) = bitsliceget(v,start+17,start);
       end
   end
end

Answer 2

[Charles]

Hello,

I am getting back to this now, as it does seem like we're going to need to be more efficient with memory use. The idea is workable as a concept, but there are some missing details, and I'm spending a lot of time in the Model Explorer messing with the dimensions of the output of the two functions.

Basically, I can only get this to work if I specify the correct dimensions in the Model Explorer for the output of the two Matlab function blocks. I'm attaching two systems demonstrating this. In the InitFcn you can change the data type to the opposite for each and see the issues I run into.

One thing that would be helpful is to know how to create a data type with either a "real-world value" or as "stored integer". I assume stored integer is the equivalent of a c++ reinterpret_cast<>, and I need it here to eliminate the type cast after splitIfNotDouble(). Also, I could not get bitsliceget() to accept variables as arguments.

Charles

Answer 3

[Charles]

Ok, I figured it out. The "size" field for a given variable in Model Explorer accepts a Matlab expression, so I set it to [1 Nsize], where Nsize = 1 for packed mode and 4 for regular vector mode.

It would be great to get the type conversion done inside splitIfNotDouble(). That might also fix a "Wrap on overflow" warning emanating from this type conversion.

Attached is the working sim.

Charles

[Ryan Baird]

There's a function "typecast" for converting between integer and floating point types, keeping the same underlying data (similar to a c++ reinterpret_cast), and there's a function "reinterpretcast" for converting between integer and fixedpoint types while keeping the same underlying data:

https://www.mathworks.com/help/matlab/ref/typecast.html

https://www.mathworks.com/help/fixedpoint/ref/reinterpretcast.html