Custom Synthesis Error Generation

[French]

Hi,

Does anybody know how I can generate custom error during synthesis
(and not during runtime) inside my vhdl code.

For example, I have defined an entity feature two generics and I would
like to generate a specific error during the synthesis of the current
block is a forbidden combination of my generic parameters occurs.

i.e:

entity test is
generic
( param1 : integer := 23;
param2 : integer := 24); -- always works but when both param1 and
param2 are equal to 32
....

it would be very helpfull to detect missuses of some component defined
in libraries that would not be explicitely reported otherwhise.

I have found some ways to do it during simulation using assert
commands with severity parameters but, as assert must be used in a
sequential process it cannot work during synthesis

 

[Sean Durkin]

I have found some ways to do it during simulation using assert
commands with severity parameters but, as assert must be used in a
sequential process it cannot work during synthesis

Many synthesis tools do in fact evaluate assertions. All the ones I've
seen at least issue a warning, some even halt synthesis when the
severity level is "error" or "failure".

I know it works with XST, and for Mentor's Precision there's a
command-line switch that enables this behaviour:

setup_design -var "rtl_extra_options=-allow_assert_error"

Not sure how it is with Quartus or Synplify.

In some cases there's the possibility to do something similar with range
constraints. Example: You have a generic that should only have valid
values from 1 to 12. Now you could create an integer subtype with range
1 to 12 and make the generic of that type. That way, when someone sets
the generic to an invalid value, the synthesis tool will halt with an
"out of range" error. This definitely should work with any synthesis tool.

But this only works in simple cases, obviously, and you can't customize
the error message that is generated.

HTH,
Sean

 

[Matthieu]

Hi,

Does anybody know how I can generate custom error during synthesis
(and not during runtime) inside my vhdl code.

For example, I have defined an entity feature two generics and I would
like to generate a specific error during the synthesis of the current
block is a forbidden combination of my generic parameters occurs.

Hey French


You may want to take a closer look at the "assert" statement: The
assert statement isn't required to be called within a sequential
process, as a matter of fact, it can also be used as a concurrent
statement as well.

Usually I would place these assert statements just before the end of
the architecture implementation. The following code snippet is
correctly interpreted by the Xilinx design flow and Modelsim.
-------
(...)
ARG_CHECK: assert (MUST_ALWAYS_BE_TRUE_GENERIC = true)
report "Invalid argument: MUST_ALWAYS_BE_TRUE_GENERIC boolean is
not tru.e"
severity failure;
end architecture RTL;

 

[Tricky]

There has been some discussion about this previously:

http://groups.google.co.uk/group/co...5598c92bfe80b1d?tvc=1&q=generics+assert&fwc=1

Overall conclusions:

Synplify and Synopsis DC = Completly ignored it
Precision = Threw a warning and carried on even for ERROR and FAILURE
states
XST and Quartus = Handled them correctly.

Hope this helps.

 

[French]

Thanks to all of you for the very quick answer,

it made my day.

 

[smurfjavel]

Creating synthesis error depending on generic values.

At least Synplify Pro sets a Synthesis error if you generate a process with a wait statement.

I tried this which works both for synthesis and for simulation, might be helpful if you would like to force synthesis error depending on a specific combination of generics. In the case below the generic type is string (with no range).

-- Check generic
b_generic_check: if g_mode /= "non-dest" and
g_mode /= "dest" and
g_mode /= "off" generate
process
begin
assert false
report "Generic is set to an invalid value."
severity failure;
wait for 1 us;
wait;
end process;
end generate b_generic_check;

Synplify pro gave the error
@E: CD443 ... Wait with no wakeup condition is not supported except at end of process