Why do I get this error when using AXI4-Stream: "Error using fpgaio.int​erface.AXI​4Stream/wr​iteFrame Invalid argument at position 2. Value must be numeric."

I am using the HDL Coder's IP Core generation feature to implement an algorithm I made on my Zedboard. Since my algorithm operates on frames of data I chose to use the AXI4-Stream interface for the input and output data ('data' and 'PHYFrame_out' respectively). Matlab generated the following AX4-Stresam configuration which accepts logical data (as intended based on my alogorithm):

However, when I attempt to send data logical data to this function (boolean(zeros[1024,1]) for testing purposes) it specifies that the data be numeric despite the configurations requiring logical data (as shown above). Out of curiosity I tried sending numeric data (zeros(1024,1)) to see if the error will go away however it repeats the same thing which is strange as zeros(1024,1) is considered numeric by the isnumeric() function.

I would appreciate any insights in resolving this issue, thank you in advance.

[Walter Roberson]

Experiment with

writePort(hFPGA, 'data', false(1024,1))

R2024a does give examples using strings for the port name, but just maybe it is failing to process string objects.

Also, try

which -all writePort
which writePort(hFPGA, "data", false(1024,1))

to see whether possibly the wrong writePort is being invoked.

[Justin]

Thank you for the response, unfortunately the same error occurs when using writePort(hFPGA, 'data', false(1024,1)).

I tried locating the functions associated with writePort and I got these:

I also verfied that writePort(hFPGA, 'data', false(1024,1)) and writePort(hFPGA, "data", false(1024,1)) were using the same writePort method as shown below.

[Walter Roberson]

Hmmm, I might have guessed that the which of the exact call might have shown the AXI4Stream.p version.

But still, FPGA.p should not be misbehaving like that.

Hmmmmm...

Try

restoredefaultpath; rehash toolboxcache

and try the call again. If it works then that would indicate that you normally have some third-party function on your path that is shadowing the Mathworks function. For example if you have a third-party "height.m" on your path then that can cause odd error messages.

[Justin]

I tried it, when I execute the call again it now says the following:

>> writePort(hFPGA, 'data', false(1024,1));
Method 'writePort' is not defined for class 'fpgaio.FPGA' or is removed from MATLAB's search path.

I was not too sure how to proceed after getting message, but from the looks of it, do I have to locate the .m file for writePort function and add it my search path?

[Walter Roberson]

After you restoredefaultpath you might need to recreate the variables.

(Well, not exactly. The real problem is that potentially restoredefaultpath might clear class definitions, and the link between class names and method names depends upon the class being loaded. If you have some other way of loading the class, such as calling a static method of the class, or creating a dummy variable from the class, then that should restore the link between method names and class names.)

Answer 1

[JT Ferrara]

Hi Justin,

This appears to be a bug in the product. I apologize for the inconvenience, and we will work on fixing this for a future release of the product.

In the meantime, you can work around this by manually changing the data type from logical to a numeric data type in the generated file gs_<modelName>_setup.m as follows:

DUTPort_data = hdlcoder.DUTPort("data", ...
    "Direction", "IN", ...
    "DataType", "uint32", ... % Change this line
    "IsComplex", false, ...
    "Dimension", [1 1], ...
    "IOInterface", "AXI4-Stream");

DUTPort_PHYFrame_out = hdlcoder.DUTPort("PHYFrame_out", ...
    "Direction", "OUT", ...
    "DataType", "uint32", ... % Change this line
    "IsComplex", false, ...
    "Dimension", [1 1], ...
    "IOInterface", "AXI4-Stream");

With this change, you can still provide a frame of logical data as input to writePort, for example:

writePort(hFPGA, "data", true([1024 1]))

The data that you provide to writePort will first get cast to the port's data type, which is now uint32, and will therefore bypass the Value must be numeric error. The data is then cast to the AXI4-Stream interface bitwidth (in this case 32 bits) before being written to hardware. The IP core will receive 32-bit data over AXI4-Stream, and convert it back to boolean as input to your algorithm. Therefore, the hardware should receive the expected data.

Please let me know if you run into any issues, or have further questions. Sorry again for the inconvenience!

[Justin]

Thank you for clearing this up, I really appreciate it.