It means that the data type of a signal cannot be uniquely determined from the word growth and inheritance rules set on the blocks. This can arise in feedback loops with inherit or growth rules or in blocks with unconnected inputs. Consider the following example where the multiplier and the SampleDelay both have ‘Output data type mode’ as “Inherit via internal rule”.
The word growth rule for multipliers is to add the integer and fractional bit widths of the inputs to get the output type. The SampleDelay preserves the input type without change by default. It can be seen here then that the output type of the Mult cannot be determined:
If input A is sfix17_En16, and input B = Mult output type = is sfixP_Q then the output is sfix(17+P)_En(16+Q) under the default inheritance rules, i.e. P=P+17 and Q=Q+16 – which has no solution for P & Q.
We must fix the type in this loop explicitly. This can be done by explicitly setting a type on one of the blocks; by adding a Convert block to set the type, or by using the Simulink “Data Type Prop Duplicate” block from the Simulink fixpt_dtprop library, which copies the type from the signal attached to ‘Ref’ to the signal attached to ‘Prop’.
This method may be favorable as it is flexible to input type, though an alternative approach is to write a flexible Matlab expression that is evaluated to set the type. Note that other simple propagation type blocks can also be used from this library, for example;
In attempting to resolve data-types, the tool has encountered an illegal data width (specified by Simulink as a default unspecified '-1'). The most common cause is that an input to the block has been left unconnected.
The data-width specified is larger than either Simulink or the tool can cope with. If possible reduce the data-width - splitting into separate signals with bit-selects if necessary.
This error is diplayed when a Simulink Complex To Real-Imag Block is driven by a real signal. Although Simulink will support this (and in this case will create a NULL imaginary component) DSPBA hardware generation does not. Make sure the input signal is complex, or do not use the block. Note that this error will only occur if the Simulink Complex To Real-Imag Block specified is part of the synthesizable design. Otherwise a similar, shortened message is given as a warning: "block <name> requires a complex input, but the signal driving it is real"
The block highlighted by the error has complex inputs but only supports real. The workaround is to explicitly split the complex signal into real and imaginary components to cacluate the complex result using the separate components. For example the FIR filters do not support complex data, but a complex FIR can be built from three FIRs in parallel.
This is another error message that can orginate from use of the Simulink Complex To Real-Imag Block with non-complex data input. Follow the suggested action to resolve the error.
This can occur when downstream blocks do not support complex inputs and back-propagate the enforcement of real-only data. Follow the suggested action to resolve the error.
Here the width refers to the vector signal width, rather than the bit width. Where blocks support vector inputs, for example the ModelPrim Mult block, the vector widths of the inputs have to be the same. Check that this is the case for <block name> - in particular that the vector width input at port <port name> is consistent with any earlier vector port input.
<block name> does not support complex data types. A workaround is to use Complex To Real-Imag and Real-Imag To Complex blocks to explicitly break the signal into its real and imaginary components then replicate <block name> for real and imaginary separately.
This error message is specific to Reinterpret Cast blocks. This block reinterprets the data type in the model while inserting no logic in hardware. The recommended use is for output width == input width only. If you require output width < input width, the recommended method is to follow a Reinterpret Cast (with output width == input width) with a Bit Extract block. (Note that if the Reinterpret Cast block is used directly with output width < input width, MSBs will be discarded.)
The specified CORDIC blocks has inputs x and y with differing bit or fractional widths. Only identical bit and fractional widths are allowed. Check the inputs to this block and use Convert blocks if necessary to ensure the input data types match.
Increase the bit-width of the P input signal to the specified CORDIC block.
This error is specific to the ModelPrim Select block and occurs if the signal driving the specified numbered select input is not a single bit signal. Ensure that the signal driving the specified port is a single bit.
This error is specific to the ModelPrim Shift block and occurs if the signal driving the shift amount input b is specified as having fractional bits. This signal must be an integer type.