Suppressing multiple driver warning where not needed

[filmil]

My compiler (from VisualElite) issues a multiple driver warning for
'some_signal' for the following snippet:

if_true: if some_generic = true generate
begin
some_signal <= '1';
end generate;
if_false: if some_generic = false generate
begin
some_signal <= '0';
end generate;

Of course the compiler cannot know that the 'if_true' and 'if_false'
cannot be valid at the same time; and the 'else' branch is not
supported in if-generate.

But as I have lots of similar constructs in my code, I'd like to
suppress this particular warning, to be able to concentrate to real
issues. How can I do this?

f

 

[filmil]

To clarify, the given snippet is not exactly what I want to do. It is
just a condensed example showing the issue. In reality, depending on
the value of the generic, I instantiate different components that
drive the signal.

f

 

[Pieter Hulshoff]

My compiler (from VisualElite) issues a multiple driver warning for
'some_signal' for the following snippet:

if_true: if some_generic = true generate
begin
some_signal <= '1';
end generate;
if_false: if some_generic = false generate
begin
some_signal <= '0';
end generate;

Of course the compiler cannot know that the 'if_true' and 'if_false'
cannot be valid at the same time; and the 'else' branch is not
supported in if-generate.

But as I have lots of similar constructs in my code, I'd like to
suppress this particular warning, to be able to concentrate to real
issues. How can I do this?

I share your frustration; we usually use:
if_true: if some_generic = true generate
begin
some_signal1 <= '1';
end generate;
if_false: if some_generic = false generate
begin
some_signal2 <= '0';
end generate;

some_signal <= some_signal1 WHEN some_generic ELSE some_signal2;


Regards,

Pieter Hulshoff

 

[pontus.stenstrom]

....

But as I have lots of similar constructs in my code, I'd like to
suppress this particular warning, to be able to concentrate to real
issues. How can I do this?

....

This thing about handling warnings can be a real pain.

In the [compile/simulate/synt/par] flow, each step (even if it fails)
will always (well...) generate a log file.
This can be seen as the "main" output of the tool, and reviewing it
for warnings/errors is the responsability of the designer.
The object-files/transcripts/netlists/bit-files generated in the flow
are a "side effects" of the tools, and only usable if the log files
passes the review.

In the flow I use, a "suppression" script acts on the log file,
allowing whatever
you manually (in the script file) specify to be suppressed.
If anything goes unsuppressed you will see it and may act on the
warning/error etc.
As an example that may be used with synplify: (warning CL111 is some
reg optimisation)
cat top.srr | grep "@W\|@E" | grep -v "CL111" > top.srr.supressed

A makefile runs the flow to produce the .suppressed file.

I use this method for all above log files, and its been an efficient
way of working.

This also allows you to document why you let a warning pass through,
and creates a todo
list of warnings that can be a document in a design review process.

/Pontus