Generates and "multiple sources"

Here's a weird one. I have a boolean generic, say FOO, that is
determines how some logic is generated. When analyzing with ModelSim
XE 6.3c, I get a warning that says, "non-resolved signal 'bar' may
have multiple sources."

The idea is that I have a terminal count value, bar, of type natural.
Depending on the value of FOO, bar is assigned either a constant, or
the contents of a register which the user can change. The thinking is
I can save a few gates by making bar a constant in one circumstance.

Here's the skeleton, which gives the idea.

signal bar : natural range 0 to 127;
signal loadthis : natural range 0 to 127;
constant bletch : natural range 0 to 127 := 127;

FOO_Is_True : if (FOO) generate
begin
bar <= bletch;
end generate FOO_Is_True;

FOO_Is_False : if (not FOO) generate
begin
bar <= loadthis;
end generate FOO_Is_False;

I've done this sort of thing before, although with std_logic and not
natural. So obviously bar (of type natural) is not a resolved type
whereas std_logic is, which is why I've never seen this warning
before.

So I guess my question is: is ModelSim right to be this picky? I
suppose it is. When synthesized (or at least elaborated), the generic
(which has a default) will select the right case, and as long as I'm
smart enough not to actually do a multiple assignment, all is well.

Is there a better way to do this?

-a

Andy Peters wrote:
> Here's a weird one. I have a boolean generic, say FOO, that is
> determines how some logic is generated. When analyzing with ModelSim
> XE 6.3c, I get a warning that says, "non-resolved signal 'bar' may
> have multiple sources."
>
> The idea is that I have a terminal count value, bar, of type natural.
> Depending on the value of FOO, bar is assigned either a constant, or
> the contents of a register which the user can change. The thinking is
> I can save a few gates by making bar a constant in one circumstance.
>
> Here's the skeleton, which gives the idea.
>
> signal bar : natural range 0 to 127;
> signal loadthis : natural range 0 to 127;
> constant bletch : natural range 0 to 127 := 127;
>
> FOO_Is_True : if (FOO) generate
> begin
> bar <= bletch;
> end generate FOO_Is_True;
>
> FOO_Is_False : if (not FOO) generate
> begin
> bar <= loadthis;
> end generate FOO_Is_False;
>
> I've done this sort of thing before, although with std_logic and not
> natural. So obviously bar (of type natural) is not a resolved type
> whereas std_logic is, which is why I've never seen this warning
> before.
>
> So I guess my question is: is ModelSim right to be this picky? I
> suppose it is. When synthesized (or at least elaborated), the generic
> (which has a default) will select the right case, and as long as I'm
> smart enough not to actually do a multiple assignment, all is well.
>
> Is there a better way to do this?
>
> -a
This might not be a direct answer, but you can get the same effect
without the generate using what I call parameterizable mux-based
collapsing. A synthesizer will collapse the mux implied by an if-clause
if the condition is a constant. That is, you should get the same
synthesis results with:

if (FOO) then bar <= bletch;
else bar <= loadthis; end

You can check this, but just about any synthesizer is smart enough to
prune out a mux that has the select line tied to a constant. The only
drawback is that simulation speed is slowed somewhat, because the
if-clause is checked during simulation, whereas with a generate the IF
is only checked during compilaton. -Kevin

Kevin Neilson wrote:

> if (FOO) then bar <= bletch;
> else bar <= loadthis; end

I've used both techniques myself, and haven't seen any warnings - at least
none that I've noticed! :O

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

On 31 Jul, 22:43, Andy Peters <goo...@latke.net> wrote:
> Here's a weird one. I have a boolean generic, say FOO, *that is
> determines how some logic is generated. When analyzing with ModelSim
> XE 6.3c, I get a warning that says, "non-resolved signal 'bar' may
> have multiple sources."
>

This has come about because Modelsim has no way of knowing the value
of FOO at compile time, even if it is given a default value. The
problem with generates is that you cannot force them to be mutually
exclusive - ie. they dont support if-then-else. Because of this, the
compiler assumes that both generate statements are possible, and
because it sees bar assigned from 2 sources, it throws a warning.
There will not be a problem when you actually run the simulation or
synthesis because the full implementation of the generates will give
the correct connection. If it did try to connect it to two sources, as
it is non-resolved it would throw an error.

Does what Mark suggested would remove the warning and still work fine,
and should synthesize in the same way.
If FOO was declared as a constant instead of a generic, some compilers
may completly ignore the non-generated portion of code, the the point
where they even ignore syntax errors (I know this was true of
ActiveHDL a couple of years ago. Not true of modelsim now.)

"Andy Peters" <google@latke.net> wrote in message
news:085f445c-2286-47c4-9d23-fe4f0968684b@a2g2000prm.googlegroups.com...
> Here's a weird one. I have a boolean generic, say FOO, that is
> determines how some logic is generated. When analyzing with ModelSim
> XE 6.3c, I get a warning that says, "non-resolved signal 'bar' may
> have multiple sources."
>

The key words here are 'may'...and that it's a 'warning'. Good to question
and peruse all warnings as you're doing, but they will not prevent you from
simulating.

>
> I've done this sort of thing before, although with std_logic and not
> natural. So obviously bar (of type natural) is not a resolved type
> whereas std_logic is, which is why I've never seen this warning
> before.
>

>
> Is there a better way to do this?
>

bar <= sel(FOO, bletch, loadthis);

where 'sel' is a function (that you write) that takes three operators, the
first being some form of 'condition' that selects the second argument or the
third argument. After writing this once for the data types you have, you'll
probably see that providing additional function overrides to handle all of
the usual data types for the second and third arguments (std_logic,
std_logic_vector, real, time, etc.) is also useful...as is being able to use
either a boolean or std_logic type for the first argument.

No errors, no warnings.

KJ

On Aug 3, 9:33*am, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "Andy Peters" <goo...@latke.net> wrote in message
>
> news:085f445c-2286-47c4-9d23-fe4f0968684b@a2g2000prm.googlegroups.com...
>
> > Here's a weird one. I have a boolean generic, say FOO, *that is
> > determines how some logic is generated. When analyzing with ModelSim
> > XE 6.3c, I get a warning that says, "non-resolved signal 'bar' may
> > have multiple sources."
>
> The key words here are 'may'...and that it's a 'warning'. *Good to question
> and peruse all warnings as you're doing, but they will not prevent you from
> simulating.
>
>
>
> > I've done this sort of thing before, although with std_logic and not
> > natural. So obviously bar (of type natural) is not a resolved type
> > whereas std_logic is, which is why I've never seen this warning
> > before.
>
> > Is there a better way to do this?
>
> bar <= sel(FOO, bletch, loadthis);
>
> where 'sel' is a function (that you write) that takes three operators, the
> first being some form of 'condition' that selects the second argument or the
> third argument. *After writing this once for the data types you have, you'll
> probably see that providing additional function overrides to handle all of
> the usual data types for the second and third arguments (std_logic,
> std_logic_vector, real, time, etc.) is also useful...as is being able to use
> either a boolean or std_logic type for the first argument.
>
> No errors, no warnings.
>
> KJ

I like it!

I agree with everyone; the tools should be smart enough to optimize
properly.

-a