HDL Code Generation Issue – Exceeding IO Pin Count Threshold & MATLAB Freezing

Hello,

I am working with MATLAB R2024a and attempting to generate HDL code from a Simulink model. The HDL Code Generation properties are set as shown in the attached screenshots.

In my model, I have a Simulink block with 10 input ports, each receiving a vector of 60 elements of type uint16 or uint32. When I try to generate the HDL code, I encounter one of the following issues:

1. The process fails with the following error:pgsqlCopiaModificaError: IO Pin Count '17360' exceeds the IO Mapping Threshold '5000'. Consider redesigning the model or use "Frame to Sample" optimizations to reduce IO. To continue to generate code without design changes, consider changing the "Check for DUT pin count exceeding I/O Threshold" diagnostic to "Warning" or "None".

1. If I increase the IO Threshold or set the diagnostic to "None," MATLAB remains in a "busy" state indefinitely while trying to generate the code.

Has anyone encountered a similar issue? Are there recommended approaches to handling this large number of IOs efficiently? Would "Frame to Sample" optimizations be the best solution, or are there alternative strategies to reduce the pin count while maintaining model functionality?

Thanks in advance for any insights

[Tom Richter]

Hi Dario,

I was just created a model with a HDL Subsystem that also has in total 17360 ports. I first got the expected error and switched to warning. After that I could easily generate VHDL.

I suggest contacting Technical Support to help you with this issue/question. If you go to https://www.mathworks.com/support/contact_us.html, you can submit a support request and add example or reproduction files. The page also displays phone contact information based on your location.

We need to understand what version you use, etc. It is not a port issue only as it looks.

Thanks,

Tom

Answer 1

[Kiran Kintali]

If the generated HDL DUT code results in unreasonable IO, it may eventually lead to failure to meet pin constraint during synthesis. Therefore, it's recommended to review the large IO situation carefully and consider converting the error to a warning or even suppress the message if it can be safely ignored.

For example if this check is hit on a DUT that is an internal module within a larger chip then this check does not need to be applied. Similarly, if many of these DUT IO are representing AXI registers or parameters, the check may not be applicable, and converting it to a warning might be appropriate thing to do after careful consideration.

Additionally, it's important to assess the overall dimensions of the signals entering the design. If you are dealing with large matrix dimensions, you might opt to use frame-to-sample workflows. https://www.mathworks.com/help/hdlcoder/io-optimization.html

For large matrices or vectors, in the data/control path generated from HDL Coder the compute involved in the MATLAB code/MATLAB function block logic or with the Simulink blocks that have large input/output dimensions can trigger a lot of unrolled logic resulting in a very large area design. Such codegen process could take a really long time to generate all that hardware. You may need to additionally use Streaming or Sharing optimizations to further reduce the size/complexity of the hardware and improve the micro architecture to make the generated code synthesizable.

Please share your model for additional recommendations or reach out to tech support for guidance.

Answer 2

[Dario]

Thank you all for your responses. Perhaps I am misunderstanding something. I would like to generate an IP core to import it into Quartus Pro and integrate it into my project. Therefore, the interfaces shown in the screenshot I provided should represent the subsystem interfaces, not physical I/O pins to be allocated.

This is similar to what I am doing in the screenshot attached (Quartus II, Stratix board). As you can see, those are the interfaces of the module, not the allocated physical I/O pins.

I hope I have explained myself clearly. Am I making a mistake in my approach? Thank you.

[Kiran Kintali]

Thank you for the followup.

Your quesiton is related to how you wrap the generated code with an IP core and use HDL Coder in built HW/SW workflow for Intel/Altera FPGAs with Quartus Pro. Please see this link for additional guidance.

https://www.mathworks.com/help/hdlcoder/ug/getting-started-with-hardware-software-codesign-workflow-for-quartus-pro-devices.html

[JT Ferrara]

Hi Dario,

Your approach sounds reasonable. As mentioned by Kiran above, this check is primarily meant to avoid pin constraint failures during synthesis. If the DUT I/O are representing AXI registers or IP core external ports, the check may not be applicable, which sounds like your case. As such, converting it to Warning or None is likely the appropriate thing to do. Actually, starting in R2024b, this check is automatically converted to a warning in the IP core generation workflow.

Regarding MATLAB remaining in a "busy" state indefinitely after disabling this check, this may be long code generation time due to the large number of ports. One option that may contribute to code generation time is the "ScalarizePorts" setting. If you have "ScalarizePorts" set to "on", it can lead to longer code generation times. Consider setting it to "DUTLevel" to help speed up code generation time:

hdlset_param(mdlName, 'ScalarizePorts', 'DUTLevel')

If you are still experiencing issues with slow code generation time, I would recommend you reach out to technical support as mentiond above. If you go to https://www.mathworks.com/support/contact_us.html, you can submit a support request with reproduction files.

Thanks,

JT

[Dario]

Hi JT,

I would like to sincerely thank you and the team for the valuable support and clarifications you provided regarding the IP core generation workflow.

Following your suggestions, I tried using MATLAB R2024b, and I can confirm that the issue has been resolved. The code generation process now completes successfully, and I am able to generate the HDL code as expected.

I truly appreciate the detailed explanation about the check behavior and the improvements introduced in R2024b. Your guidance on the "ScalarizePorts" setting was also very helpful.

Thank you once again for your time and support!

Best regards,

Dario