DSP Builder Advanced Error Messages

[#1]

NCO

Register width must be 32 bits or less

The memory interface registers in the NCO in non-constant mode can only support up to 32-bits currently.

Bus words per register must be either 1 or 2

For the memory interface, the supported format is either one or 2 registers per bus word. This does not apply in Constant mode, when interface is not used

<name> has an unexpected number of dimensions, expected 2 dimensions, found <N>

This error arises when building the memory interface for NCOs. Check that the parameters relating to the memory map are consistent for the highlighted NCO. 

<name> has wrong number of entries (expected 1 or <M>, found <N>)

This error arises when building the memory interface for NCOs. Check that the parameters relating to the memory map are consistent for the highlighted NCO. 

<name> has too many rows, only expecting 1

This error arises when building the memory interface for NCOs. Check that the parameters relating to the memory map are consistent for the highlighted NCO. 

DSPBA_features

Feature <feature name> does not have a {boolean / integer} value

DSPBA_features Media:DSPBA_features.doc is a mechanism to access some internal prameters of the tool by setting of worksapce variables DSPBA_Features.<feature name> = <value>. The values expected change according to the feature - some are integer values, others are boolean. If the wrong type is read, the above error is displayed. Make sure that the value you have specified is correct for the DSPBA_Feature used. Note that DSPBA_Features are subject to change, so are not recommended for general use. 

Floating Point

Cast error in <name> Conversion from <type A> to <type B> not found in table

This is an internal error; contact your Altera representative and submit a Service Request if you see this. The message occurs at the stage the tool casting between internal floating point formats in the optimization of floating point data-paths. It has attempted to cast between type internal floating point formats for which no casts function is supported. Since all legal casting operations should be supported, this should never occur.

Folding

Folded primitive subsystems can only one have {ChannelIn / ChannelOut} block, but {two / none} were found

Folding is a feature for automatically time-division multiplexing (TDMing) primitive subsystems. The feature is specified on the ModelPrim ChannelIn and ChannelOut blocks. For folded subsystems, the subsystem must contain precisely one ChannelIn block and one ChannelOut block. Ensure this is the case, if necessary aggregating all inputs through a single ChannelIn blocks and all outputs through a single ChannelOut block.

Folding parameters must be set to the same values in the ChannelIn and the ChannelOut block of a folded primitive subsystem, but ChannelIn <input block name> has {Number Of Used TDM Slots / Sample Rate} set to <N> and ChannelOut <output block name> has it set to <M>

The parameters for folding - 'Number Of Used TDM Slots' and 'Sample Rate' - are specified both on the input ChannelIn and on the output ChannelOut. These parameterizations currently have to be identical (though in future we may support different input and outputs rates). Check that the folding parameters on the named ChannelIn are the same as those specified on the named ChannelOut.  

Output port <port name> of ChannelIn block <input block name>, which has folding enabled, can only be connected to the same port of a ChannelOut block, but it was connected to input port <port name> of block <block name>

In folded primitive subsystems, the tool uses the valid and channel signals internally to drive sequenced enables in the generated logic. For folding subsystems, these signals cannot therefore be connected to user logic on the data-path within the subsystem, but instead should be routed directly across to the ChannelOut block. The error messge is displayed if the valid of channel signal in the folded subsystem is routed to any other blocks. If you require these signals in your primitive subsystem design, a workaround is to bring additional copies of them in as data signals through the ChannelIn block.

<ChannelIn block name> cannot fold vector input signal when more than one TDM slot is used

When multiple TDM slots are specified in the folding parameters, the data input signal to the ChannelIn cannot be a vector. The restriction of scalar input to a folded ChannelIn arises as the tool re-uses the 1-dimension to add the folding dimension (and the tool currently does not support 'vectors of vectors'). Make sure all inputs to the specified folded ChannelIn block are scalars. 

Enabled Subsystems are currently unsupported when folding is enabled

The Simulink enable block can be used to create a subsystem-wide enable signal when used at the same level as the boundary blocks (ChannelIn/Out, GPIn/Out). [Note: a) the Enable block which denotes and enabled subsystem cannot generally be used in subsystems embedded within a primitive subsystem (accept where the subsystem contains no synthesizable logic). i.e. generally the enable block can only appear at the 'top level' of the primitive subsystem b) using Enabled Subsystems may generate an enable signal with a large fan-out in HDL which can reduce achievable fmax c) sending the enable signal low immediately halts the Simulink simulation for the enabled subsystem - before any outputs are updated - and that includes stopping the generation of the stimulus capture files (STMs) from the primitive boundary blocks for HDL test-benching. The Simulink simulation will therefore not match when running the automated HDL test-benches. Users wishing to try Enabled Primitive subsystems in their design should be aware of these restrictions and use enabled primitive subsystems with caution.] There is a hard restriction however that the Enable block cannot be used in conjuction with Folding. 

HDL Generation and Naming

Sanitised version of <name> is empty. Please rename to include some alphabetical characters

DSP Builder Advanced translates or 'sanitises' all names - blocks, subsystems, etc - into those that are valid VHDL, including the removal of special characters. The error message means that for the given name, once the special characters have been removed no characters are left. Remember that names should be kept short but descriptive and should ideally be restricted to letters and numbers (but not begin with a number). Reserved words in VHDL (the hardware language used for generation) should also be avoided - the tool will replace reserved words with the phrase "_rsrvd_fix" in the generated hardware. The list of reserved words includes:

abs, access, after, alias, and, architecture, array, assert, attribute, begin, block, body, buffer, bus, case, component, configuration, constant, disconnect, downto, else, elsif, end, entity, exit, file, for, function, generate, generic, group, guarded, if, impure, in, inertial, inout, is, label, library, linkage, literal, loop, map, mod, nand, new, next, nor, not, null, of, on, open, or, others, out, package, port, postponed, procedure, process, pure, range, record, register, reject, rem, report, return, rol, ror, select, severity, signal, shared, sla, sll, sra, srl, subtype, then, to, transport, type, unaffected, units, until, use, variable, wait, when, while, with, xnor, xor

Could not convert string data

The name of a block, or parameter could not be read. This can occur if special characters are used, or for names over 200 characters in length. Check that the blocks, subsystems and parameterization variables in your designs have sensible, short but descriptive names.

Irrecoverable name mapping collision <new name>. Please ensure that the alphanumeric parts of block names are unique

This message means that after sanitization two or more names in the same subsystem are now identical - both mapping to the same <new name>. For example If I had two blocks named "blockA$" and "blockA*", these would both be sanitized to just "blockA". As names within a hierarchical level have to be unique, the tool will stop generation until this is resolved by the user renaming the block(s). 

Failed to open <filen name> for {read / write} (<error string>). Filename is longer than 256 characters (<file name length>)

Some operating systems can only cope with file name paths less than 256 characters. It is possible to exceed this if you a) are generating your model to a directory with an already long path name b) you have used long names for the subsystems in your DSPBA design (since the generated HDL is hierarchical). Try choosing an HDL output directory with a short path-name (set on the Control block). Also make sure the subsystem names used in your design are as short as possible while remaining both descriptive and unique within the same level of hierarchy. 

Failed to open <file name> for {read / write}

The tool is attempting to perform the specified read / write operation to the specified file, but is prevented from doing so. This could arise, for example, if you already have the file open in a text editor, do not have the required permissions for the specified directory, or if the output directory cannot be created. 

Pin name <signal name> will not generate a valid HDL identifier [<subsystem name>]

In generating the port list for the specified subsystem, the tool has identified that the specified signal name cannot be generated. The reasons for this can be that a) the first character is not a letter b) the name contains two or more consecutive underscores ("__"), c) the name is not alphanumeric, or d) the name ends in an underscore. Rename the specified signal name to avoid these errors. 

Pin name <signal name> is a reserved word [<subsystem name>]

In generating the port list for the specified subsystem, the tool has identified that the specified signal name cannot be generated as it is a VHDL reserved word. The list of reserved words includes:

abs, access, after, alias, and, architecture, array, assert, attribute, begin, block, body, buffer, bus, case, component, configuration, constant, disconnect, downto, else, elsif, end, entity, exit, file, for, function, generate, generic, group, guarded, if, impure, in, inertial, inout, is, label, library, linkage, literal, loop, map, mod, nand, new, next, nor, not, null, of, on, open, or, others, out, package, port, postponed, procedure, process, pure, range, record, register, reject, rem, report, return, rol, ror, select, severity, signal, shared, sla, sll, sra, srl, subtype, then, to, transport, type, unaffected, units, until, use, variable, wait, when, while, with, xnor, xor. 

Rename the specified signal to somethign other than the words on the list above.

Port identifier <signal name> used more than once in [<subsystem name>]

In generating the port list for the specified subsystem, the tool has identified that the specified signal name occurs more than once. This can arise if a singal name is repeated directly, or if multiple signals map to the same name once sanitized, or if multiple signals map to the same name once vector and complex type unrolling has been done (for example if you have a port a_1 and a vector port A (which would be unrolled to created a list of numbered ports). Note that the detection of name clashes is case-insensitive as VHDL (the output HDL language for generation) is case insensitive. 

Failed to read generation metrics file <XML file name>

DSPBA serializes and caches the design. This is then used to compare against upon re-generation such that only changed subsystems are re-generated. The serialized design is stored as an XML file, and includes all the information required to regenerate - including for example subsystem latencies. The error message is displayed if there is a problem reading this file; perhaps due to some file corruption. A workaround would be to regenerate from scratch - deleting the XML file and the generated RTL directory to force the complete regeneration. 

Block <name> has no Library Reference - cannot synthesise it

The specifed block has no 'ReferenceBlock' or 'AncestorBlock' parameter, so the tool doesn not know what to do with it. Check the block in question is legal. 

Illegal Block Parameters

[<block name>] failed to convert <parameter name> to double

Many of the numeric parameters specified on DSPBA blocks can only be specified using Matlabs default double type. If the parameter data type is not matlab double DSPBA will attempt to convert it, using the Matlab double() command. IF this fails however the error message will be displayed. Resolve by specifying the parameter as a Matble double data-type.  

Parameter <parameter name> must contain an integer

Some parameters can only accept integer values (i.e. whole numbers). The error message is diplayed if the specified parameter value is not an integer. The error can only be resolved by specifying an integer value.

The Index Option specified on Selector block <name> is not currently supported by the Advanced DSP Builder Blockset - hardware cannot be generated for this block

This error is specific to use of the Simulink selector block. Hardware generation for this block is currently restricted to index by dialog, with index by port unsupported.  

Unsupported type for initialization parameter to block <name>

The underlying data-type used to specify an initialization parameter on the block <name> is unsupported. Note that in most cases numeric parameters have to be one of the basic Simulink types, that is: single, int32, uint32, int16, uint16, int8 uint8. Fixed point data-types are generally not supported for parameters.

BitExtract missing initialization parameters <name>

The named BitExtract ModelPrim block has illegal 'Least Significant Bit Position from Input Word' parameter

Unknown loop test: <test>

The ForLoop block allow four different 'end of loop' criteria to be selected: <, <=, >, >= - yet the tool has detected that one not on this list has been selected. If this occurs it is likely that the block has become corrupted - perhaps broken from the library link and edited, and it is suggested that the user chaeck the ForLoop blocks in their design and if necessary delete and replace from the library. 

Fifo needs 3 or 4 parameters in a vector eg. [32 4 16]

A FIFO block has the incorrect number of values specified for the 'FIFO Setup' parameter. Generally three parameters should be specified as a vector: [<depth> <fill threshold> <full period>]. Check the settings on the FIFO blocks in the design.

The Selector block <name> has a non-inherited 'Sample time'. Only inherited sample times are currently supported (-1).

Note that this rule applies generally to other Simulink blocks for which synthesis is supported (such as Muxes and Real-Imag To Complex). These blocks cannot be used to change the SampleTime of the system - as this will not be reflected in the generated hardware. The SampleTime parameters for such blocks must explicitly be set to -1. 

Error in vector of output channels, index <index> is less than zero. Channel vector entries must be in the range [0..Number of Input Channels - 1]

This error is specific to the ModelPrim Demux block, a channel deserializer equivalent to a ModelPrim equivalent of the ChannelViewer block. The channel to be output includes a negative number, which will always be outside the supported range of channel numbers. Check and correct the parameterization of the highlighted demux block to resolve. 

Error in vector of output channels, index <index> is greater than the Number of Input Channels. Channel vector entries must be in the range [0..Number of Input Channels - 1]

This error is specific to the ModelPrim Demux block, a channel deserializer equivalent to a ModelPrim equivalent of the ChannelViewer block. The channel to be output includes a channel number larger than the specified number of input channels. Check and correct the parameterization of the highlighted demux block to resolve. 

Design Rules

Block <name>: No control block found

Found DSPBA block <name> but no top level Control block. DSPBA designs must contain a Control block at the top hiearchical level of the Simulink model.

Block <name> has no enclosing Signals Block - add one

Found DSPBA block <name> but no top level Signals block. DSPBA designs must contain a Signals block at the top hiearchical level of the Simulink model.

Model IP Block [<block name>] has been found in an unexpected place. There may be a redundant Synthesis Info block at this level or in one of the enclosing subsystems.

This error is displayed when a ModelIP block (CIC, FIR, NCO, Scaler, Channel Viewer, etc) is found in a subsystem at the same hierarchical level or lower than a SynthesisInfo ModelPrim block. This usual cause is that the ModelIP block has been placed in a primitive subsystem - which is illegal in DSPBA. Alternatively a SynthesisInfo block could have been placed unnecessarily outside a primitive subsystem alongside the ModelIP block. Check for these to resolve the error.

Nesting of Primitive Subsystems is not supported. <subsystem A> encloses <subsystem B>

This occurs when a hirearchy of subsystems contains multiple SynthesisInfo blocks, or ModelPrim boundary blocks. This is not supported, so check that no such blocks have been placed in <subsystem B> inadvertently.

Input port <N> of <name> is not connected

The Nth input port of block <name> has been left unconnected. All input ports to DSPBA blocks must be conencted for generation and simulation to continue. 

Port <N>(<M>) of block <name> is connected to a block in another subsystem directly. Please add a ChannelIn or GPIn port to that connection

This error is diplayed when a ModelPrim block in one subsystem directly drives a ModelPrim block in another subsystem with no intervening ChannelIn or GPIn. Make sure the input to the driven primitive subsystem goes via a ChannelIn or GPIn block.

GP-In <name>s inputs must be connected to the Simulink port at the same level as the synthesis block with no intermediary logic.

The specified ModelPrim GPIn boundary block must be driven directly from a Simulink subsystem input port block at the same level. Move any logic betweeen the specified block and the subsystem port to after the GPIn. 

GP-Out <name> cannot drive more than one destination. To drive more destination with the same signal use the input to the Channel Out block instead.

The specified ModelPrim GPOut boundary block must directly drive a single Simulink subsystem output port block at the same level. If necessary replicate the GPOut or use a ChannelOut. 

Channel Out <name>s outputs must be connected to the Simulink port at the same level as the synthesis block with no intermediary logic.

Each output of the specified ModelPrim ChannelOut boundary block must directly drive a single Simulink subsystem output port block at the same level. Move any logic betweeen the specified block and the subsystem output port to before the ChannelOut .

Clock rate is too high

DSPBA will attempt to pipeline to achieve the specified clock frequency. However, in this instance it has detected a clock frequency that it knows will be unobtainable for the device and speed grade specified. Note that currently the limit at which this error occurs is optimistic, so this should not be used as a general guide as to the maximum achievable fmax.

Unable to find a Signals block in the design. The Signals blocks should be at same level as the Control block.

Add a Signals block from the Base Blocks library to the top level of the design. This block is required by DSPBA.

Found device block at the top level of the model. Device blocks must be within subsystems.

The Device block specifies the top synthesizable level of the design. This must be a subsystem below the top level of the model - such that the top level of the model contains the non-synthesizable test-bench and all the control and script blocks, such as Control, Signals, Run Quartus and Run ModelSim. Select the synthesizable part of your design and the Device block and create a subsystem with all these in. 

Illegal combination of device blocks found in <subsystem A> and <subsystem B>

Nested subsystems were found with device blocks. A subsystem hierarchy can contain at most one device block. Remove the device block from <subsystem B>.

Bus Interface

Address width specified in control block of <width> is not wide enough. Block <bus sink block> requires address width of at least <required width> to access the last address which is <last address>

The Control block at the top level of the design specifies a 'System Address Width', which is the bit-width to use for the address signal in the generated bus interface This has to be wide enough such that all the bus addresses specified within the synthesizable system (on ModelBus blocks and ModelIP blocks) can be addressed. If any address falls outside of the expressable range - as the start address and or depth is too large with an address signal only <width> bits wide - the error is displayed. To resolve the error check that your start addresses and memory depths are as you expect, and if so increase the 'System Address Width' on the Control block to the <required width>.

Errors in simulation

Error occured executing model <subsystem or ModelIP block>, at time <time>, error: <message>

A run-time error was detected during simulation. 

Testbenches

Unable to find any Channel-{In/Out} or GP-{In/Out} blocks in the design. Either introduce them or disable the automatic testbench.

The automatic testbenches (ATBs) work by recording the Simulink simulation inputs and outputs (STMs) at each ChannelIn, ChannelOut, GPIn, GPOut and at each ModelIP input and output, then using these to drive and compare in a HDL testbench run in ModelSim. If the option to create Automatic testbenches is switched on in the Control block, then there have to be blocks in the design that will be recording the STM files. Follow the suggested action to resolve.

Category: DSP Builder