Showing results for 
Search instead for 
Did you mean: 

DSP Builder Advanced Error Messages

Data-Types and Data-Type Propagation

Unable to determine data types for some ports, cannot continue

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”. 

8/8b/FAQ4.PNG ( FAQ4.PNG - click here to view image )

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’.

9/91/FAQ4b.PNG ( FAQ4b.PNG - click here to view image )

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; 

5/57/FAQ4c.PNG ( FAQ4c.PNG - click here to view image )

Illegal bit-width <N> found for output <port name> on block <block name> in <subsystem name>. Please check that inputs to this block are properly connected

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.

Illegal wide bit-width <N> found for output <port name> on <block name> in <subsystem name>. The maximum currently supported output width is <MAX DATAWIDTH>

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. 

block <name> requires a complex input, but the signal driving it is real. To generate hardware, remove this block, or create an imaginary signal component

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"

Complex data is not supported

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. 

The Real-Imag To Complex block <name> has unsupported input type. Please use input type 'Real and imag' and create the appropriate constant zero inputs to the block

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.

The Complex To Real-Imag block <name> has unsupported output type. Please use output type 'Real and imag' and connect unwanted outputs to terminator blocks.

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. 

<port name> on block <block name> is not of the expected width:(<vector signal width>). Only combinations of scalar inputs and/or vector inputs of equal width are supported

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. 

<port name> on block <block name> is complex. This port does not support complex data types

<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.

[<block name>] Reinterpret cast failed - output is wider than the input (<output width> > <input width>)

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.)

Cordic block <block name> inputs x & y do not have the same {input data / fractional} width

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. 

Cordic block <block name> inputs P does not have enough integer bits - 3 integer bits are needed to represent PI values properly.

Increase the bit-width of the P input signal to the specified CORDIC block.

<block name> input <port name> should be boolean

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. 

Shift block <name> cannot be driven by fractional data type on input b.

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. 

Version history
Revision #:
1 of 1
Last update:
‎06-25-2019 09:28 PM
Updated by: