HDL Verifier Max Bit Width Using System Object

I have a SystemVerilog HDL module that I am trying to test with HDL Verifier. The module takes in a packed 2-D array of 16x32 elements. This means that one of the input ports requires 512 bits, but when I try to send an FI object in that's 512 bits wide using the step function, I get an error that the max fixed point word length is 128 bits.

The only workaround that I know is to fall back to the old method of using raw bit strings and a callback function. But that's not ideal as I hope to be able to use FIL later which appears to exclusively use the System object.

I tried using an unpacked array, but that didn't seem to work with HDL verifier at all.

Is there a way to accomplish this with the System object?

Thank you!

-David

Answer 1

[YP]

Hi David,

Do you mean FIL system object? FIL doesn't support sytem verilog HDL. Can you attach your code and elaborate your workflow?

And I don't understand what you mean by 'old method of using raw bit strings and a callback function' either.

[David]

Yanjie,

Thank you for the reply!

This isn't for FIL, but for cosimulation with ModelSim. So far the constructs that I am using in SystemVerilog seem to be working fine with MATLAB. I totally understand that some/most of the fancy things in SystemVerilog aren't supported. In fact, my modules are written using SystemVerilog, but the testbench is either pure Verilog or just enough SystemVerilog to get the job done.

What I means was using the hdlverifier.HDLCosimulation object [1] vs the matlabtb callback function [2]. The second option being the "old" way. With the HDLCosimulation object I am forced to use fixed point objects which seem to be limited to 128 bits when used with System Objects. The matlabtb callback function method doesn't require fixed point objects and instead just takes in bit strings, so no limitations there. But as I understand it I will not be able to use matlabtb for FIL which I would like to use in the future.

It would be nice if there were a workaround that allowed either longer bit strings with the HDLCosimulation object, or unpacked Verilog arrays such that I was passing in a vector of 16 32-bit fixed point objects.

Thanks!

-David

[1] https://www.mathworks.com/help/hdlverifier/ref/hdlverifier.hdlcosimulation-system-object.html

[2] https://www.mathworks.com/help/hdlverifier/ref/matlabtb.html?searchHighlight=matlabtb&s_tid=srchtitle_matlabtb_1

[Marc Erickson]

Hey David, thanks for the clarifications! You have indeed confirmed the current limitations of the cosimulation interfaces. As you have found, the SystemVerilog support really is the old Verilog subset of port types. The hdlverifier.HDLCosimulation system object under the hood uses the same implementation as the Simulink block. For both, the limit is currently 128bits of packed data. To work-around this limitation will require wrapping the interface such that you can flatten the unpacked dimensions.

[David]

Marc,

Thanks for the info!

In my tests I am using packed arrays which seem to be the issue. If I have something like this:

input wire [15:0] [31:0] input_elements;

Then what I would need to provide the step function would be something like fi(N, 0, 16 * 32, 0) which results in a fixed point object that's 512 bits wide and no good for Simulink.

If instead I use something like

input wire [31:0] input_elements [31:0];

Then I get an error because Verilog does not support unpacked arrays at the ports.

Finally, changing to a completely flat array doesn't help either:

input wire [(16 * 32)-1:0] input_elements;

Because the max bit width of a fixed point value in Simulink is again violated.

Do you know of any ways that I could pass in a vector of fixed point values to a 2-D port? That would solve the problem, but it doesn't look like there is a way to do this. I saw something about "frames" in the documentation, but that looks like a way to send in a bunch of data that will be clocked in vs something that allows me to pass in an array in one clock. Even if it did work, it's going to be marked as deprecated in future releases.

Thanks!!

-David

[Marc Erickson]

The flattening would requiring splitting as well, to something like:

input wire [15:0] [7:0] input_elements_1;
input wire [15:0] [7:0] input_elements_2;

etc.

Frames are what you suspect: they represent a collection of samples over time. We have not deprecated frames, just the use of the property to designate whether it is a frame or a multi-dimensional sample. Unfortunately, this is exactly the differentiation you are looking for.

So, currently the only workaround to supporting N-D signals is to:

1. use Simulink cosim and FIL
2. wrap your Verilog in VHDL

[David]

I was not aware that HDL Verifier supported VHDL arrays in this manner. Do you happen to have some examples of how 2-D (or any multidimensional arrays) can be used with VHDL and cosim without FIL? In the mean time I'll poke around in the HDL Verifier user guide and see if I can find anything.

Thank you very much for the help!

-David