HDL Coder For Each Subsystem Assertion failed: B:\matlab\​src\cgir_h​dl\pir_tag​s\ForEachD​ataTag.hpp​:178:nativ​eVObj.get(​)

When generating HDL code using the For Each Subsystem and a partitioned mask parameter, the following error message is generated:

Assertion failed: B:\matlab\src\cgir_hdl\pir_tags\ForEachDataTag.hpp:178:nativeVObj.get()

I believe it is related to the fact that in order for a mask parameter to be partioned using the for each subsystem, the parameter must be tunable for some reason. If there was a way to partition a non-tunable parameter I dont think this would not be an issue. However, when making the parameter non-tunable, the parameter partition tab shows the parameter as greyed-out:

Answer 1

[Kiran Kintali]

The error message is not expected. Can you share your model? Either HDL Coder needs to generate code from the model or generate a proper conformance related validation message for any unsupported behaviors..

Here is the related release note for the ForEach mask partition feature.

https://www.mathworks.com/help/hdlcoder/release-notes.html

Starting R2021a release HDL code generation for For Each Subsystem block with 1-D and 2-D partitioning of mask parameters

You can generate HDL code for the For Each Subsystem block with 1-D and 2-D partitions of mask parameter values. To partition the mask parameters, in the Parameter Partition tab of the For Each block, select each mask parameter that you want to partition, and then specify the Partition Dimension and Partition Width.

See Repeat an Algorithm Using a For Each Subsystem.

[Jason Katcha]

Attached is a minimum reproducible example. The system is intended to function as a linear mapping function with initialization code embedded in the PreLoadFcn callback to define the constants. Again I think the issue arrises with the mask parameter being tunable. It seems like HDL coder does not like this and fails the assertion. I don't need this paramenter to be tunable, so it would be nice if the parameter partion of the for each subsystem would still function with non-tunable parameters. Thanks for taking a look!

[Kiran Kintali]

The issue is being analyzed. Preliminary investigations are published here. https://www.mathworks.com/support/bugreports/3210657