HDL Coder and Bitstream Programming Insight Needed

I am trying to program the DAC PL-DDR Transmit example ( https://www.mathworks.com/help/hdlcoder/ug/hdl-dac-PL-DDR4-transmit.html ) to my ZCU216 board. I have already asked a question about this a few days ago but will make this one more broad to give it a better chance of being answered.

When generating and programming the bitstream, I ensure that the AXI4 Stream Interface is 128 bits wide. However, when I run the addAXI4StreamInterface() function, a prequisite to writing to the port from MATLAB for testing purposes, I am getting data mismatch errors that can be resolved by changing the inteface width to 64 bits. So, clearly the programmed FPGA is expecting the function to request 64 bits and not 128.

My question is: what kind of troubleshooting steps are aviailable for an issue like this? Trying to explore these functions, you run into .p files quickly, so it's been impossible so far to see what's going on under the hood.

[Umar]

Hi @ Thomas J Kelly,

To address your query regarding, “However, when I run the addAXI4StreamInterface() function, a prequisite to writing to the port from MATLAB for testing purposes, I am getting data mismatch errors that can be resolved by changing the inteface width to 64 bits. So, clearly the programmed FPGA is expecting the function to request 64 bits and not 128.”

Please see my response to your comments below.

After reviewing the documentation of your evaluation kit board ZCU216,

https://docs.amd.com/r/en-US/ug1390-zcu216-eval-bd/PS-DDR4-SODIMM-Socket

I found out that it features features a 64-bit DDR4 SODIMM memory, which implies that many components in the system, including those related to memory interfaces and possibly certain IP cores, are optimized for 64-bit data paths. Also, PL DDR4 I/F consists of two banks of 32-bit components which might influence how data is handled in your design. Furthermore, if the IP core or peripheral you are interfacing with is built to operate at a maximum of 64 bits (i.e., two 32-bit channels), attempting to push 128 bits may lead to mismatches in expected data sizes which aligns clearly with your statement “ programmed FPGA is expecting the function to request 64 bits”.

Now addressing your query about, “My question is: what kind of troubleshooting steps are aviailable for an issue like this? Trying to explore these functions, you run into .p files quickly, so it's been impossible so far to see what's going on under the hood.”

Engage with Xilinx community forums or technical support for insights from others who might have encountered similar issues.

[Thomas J Kelly]

Thanks for the advice @Umar, I will take the steps that you prescribed.

I will say it would be strange if it were impossible to pass 128 bits. The example, which requires 128 bits, has the ZCU216 as one of its default target devices and the workflow advisor has a drop down menu for data width that includes 128. If it's not possible, I guess I will have to figure out how to replicate something close to the desired output while working with only 64 bits.

[Umar]

Hi @ Thomas J Kelly,

While it is indeed strange that a 128-bit operation would be deemed impossible given your context, it is crucial to remember that hardware capabilities often dictate operational limits. In cases where direct use of 128 bits proves unfeasible, consider implementing techniques such as packetization or multiplexing your data streams over multiple channels, if applicable.

Lastly, keep an eye on software updates from Xilinx for MATLAB interfaces, as newer versions may address existing issues or introduce improved functionalities for handling wider data paths.

[Thomas J Kelly]

@Umar thanks for the insight, I'll keep working at it. What I meant by "strange" is that the example is fully worked in the link that I included, and the ZCU216 is explicitly listed as one of two compatible devices. So, I'm still confident that this is supposed to work in a straighforward way, and the issue is somewhere on my end.