Simulating mutiplication of 'X' with '0'

[Morten Leikvoll]

I am simulating multipliers [std_logic_vectors] with one factor containing
'X' and the other has '0's, but the simulation gives me 'X'es as a result
while I expected '0's. Is this a bug/weakness or is there any logical or
technical reason at all for [dont' care]*zero<>zero?
Im working with Altera tools.

 

[Brian Drummond]

On Thu, 24 Feb 2011 10:11:24 +0100, "Morten Leikvoll" <mleikvol@yahoo.nospam>
wrote:

with one factor containing
'X' and the other has '0's, but the simulation gives me 'X'es as a result
while I expected '0's. Is this a bug/weakness or is there any logical or
technical reason at all for [dont' care]*zero<>zero?
Im working with Altera tools.

I suppose it would be possible for the sim model for a multiplier to treat
all bits 0 on one input as a special case, but that adds complexity to the model
for questionable benefit.

"X" is not "don't care", ("-" is), it is "Indeterminate", usually as the result
of a design error. So it is normally good to propagate it when in any doubt,
rather than cover up the error.

- Brian

 

[Morten Leikvoll]

"Brian Drummond" <brian_drummond@btconnect.com> wrote in message
news:1obcm65dqmhc6eaogjnvq6q04sl4a5jqug@4ax.com...

On Thu, 24 Feb 2011 10:11:24 +0100, "Morten Leikvoll"
mleikvol@yahoo.nospam
wrote:

I am simulating multipliers [std_logic_vectors] with one factor containing
'X' and the other has '0's, but the simulation gives me 'X'es as a result
while I expected '0's. Is this a bug/weakness or is there any logical or
technical reason at all for [dont' care]*zero<>zero?
Im working with Altera tools.

I suppose it would be possible for the sim model for a multiplier to treat
all bits 0 on one input as a special case, but that adds complexity to the
model
for questionable benefit.

"X" is not "don't care", ("-" is), it is "Indeterminate", usually as the
result
of a design error. So it is normally good to propagate it when in any
doubt,
rather than cover up the error.

This is an multiplier + accumulator function, and the only way to propagate
it is to add additional conditions to the input wich again adds logic at
implementation stage. I've ended up with a generic input called simulate and
conditional code, wich I don't like at all.

 

[Morten Leikvoll]

"Morten Leikvoll" <mleikvol@yahoo.nospam> wrote in message
news:FuGdnUiJXNslvfvQnZ2dnUVZ8vGdnZ2d@lyse.net...

with one factor containing
'X' and the other has '0's, but the simulation gives me 'X'es as a result
while I expected '0's. Is this a bug/weakness or is there any logical or
technical reason at all for [dont' care]*zero<>zero?
Im working with Altera tools.

The only technological explanation I can think of is that '0' isn't really
zero. It's "low" and "low" multiplied with "dont' care" is undefined. Maybe
if I do integer conversion first, it will work?

 

[RCIngham]

"Morten Leikvoll" <mleikvol@yahoo.nospam> wrote in message
news:FuGdnUiJXNslvfvQnZ2dnUVZ8vGdnZ2d@lyse.net...
I am simulating multipliers [std_logic_vectors] with one facto
containing
'X' and the other has '0's, but the simulation gives me 'X'es as a resul

while I expected '0's. Is this a bug/weakness or is there any logical o

technical reason at all for [dont' care]*zero<>zero?
Im working with Altera tools.

The only technological explanation I can think of is that '0' isn't reall

zero. It's "low" and "low" multiplied with "dont' care" is undefined
Maybe
if I do integer conversion first, it will work?

Why have you got 'X's on one input?

Why do you not want 'X's on the output?

Is this a behavioural model simulation?


---------------------------------------
Posted through http://www.FPGARelated.com

 

[Nial Stewart]

"Morten Leikvoll" <mleikvol@yahoo.nospam> wrote in message
news:FuGdnUiJXNslvfvQnZ2dnUVZ8vGdnZ2d@lyse.net...

with one factor containing 'X' and the other has
'0's, but the simulation gives me 'X'es as a result while I expected '0's. Is this a bug/weakness
or is there any logical or technical reason at all for [dont' care]*zero<>zero?
Im working with Altera tools.

Morton, 'X' is 'don't know' so the simulator doesn't know the result of
multiplying this with another value, forget that the other value is 0.

You need to initialise all your inputs at power on to stop this.


Nial.

 

[Morten Leikvoll]

"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote in
message news:8snf99Fq2uU1@mid.individual.net...

"Morten Leikvoll" <mleikvol@yahoo.nospam> wrote in message
news:FuGdnUiJXNslvfvQnZ2dnUVZ8vGdnZ2d@lyse.net...
I am simulating multipliers [std_logic_vectors] with one factor containing
'X' and the other has '0's, but the simulation gives me 'X'es as a result
while I expected '0's. Is this a bug/weakness or is there any logical or
technical reason at all for [dont' care]*zero<>zero?
Im working with Altera tools.

Morton, 'X' is 'don't know' so the simulator doesn't know the result of
multiplying this with another value, forget that the other value is 0.

The point is, what can 'X' be to make 'X'*0 not equal zero?

 

[Mark Curry]

In article <06CdnZJ_uMNULPvQnZ2dnUVZ8hmdnZ2d@lyse.net>,
Morten Leikvoll <mleikvol@yahoo.nospam> wrote:

"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote in
message news:8snf99Fq2uU1@mid.individual.net...
"Morten Leikvoll" <mleikvol@yahoo.nospam> wrote in message
news:FuGdnUiJXNslvfvQnZ2dnUVZ8vGdnZ2d@lyse.net...
I am simulating multipliers [std_logic_vectors] with one factor containing
'X' and the other has '0's, but the simulation gives me 'X'es as a result
while I expected '0's. Is this a bug/weakness or is there any logical or
technical reason at all for [dont' care]*zero<>zero?
Im working with Altera tools.

Morton, 'X' is 'don't know' so the simulator doesn't know the result of
multiplying this with another value, forget that the other value is 0.

The point is, what can 'X' be to make 'X'*0 not equal zero?

That's interesting that VHDL does this too. In verilog,
'X' AND 0 = 0
'X' OR 1 = 1

However for the multiply, it's as you indicated above:
'X' * 0 = 'X'

Don't know what the language designers chose to do it this
way. Good to know VHDL and verilog at least match.

--Mark

 

[Morten Leikvoll]

"Mark Curry" <gtwrek@sonic.net> wrote in message
news:4d66d8d2$0$10596$742ec2ed@news.sonic.net...

In article <06CdnZJ_uMNULPvQnZ2dnUVZ8hmdnZ2d@lyse.net>,
Morten Leikvoll <mleikvol@yahoo.nospam> wrote:

"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote in
message news:8snf99Fq2uU1@mid.individual.net...
"Morten Leikvoll" <mleikvol@yahoo.nospam> wrote in message
news:FuGdnUiJXNslvfvQnZ2dnUVZ8vGdnZ2d@lyse.net...
I am simulating multipliers [std_logic_vectors] with one factor
containing
'X' and the other has '0's, but the simulation gives me 'X'es as a
result
while I expected '0's. Is this a bug/weakness or is there any logical or
technical reason at all for [dont' care]*zero<>zero?
Im working with Altera tools.

Morton, 'X' is 'don't know' so the simulator doesn't know the result of
multiplying this with another value, forget that the other value is 0.

The point is, what can 'X' be to make 'X'*0 not equal zero?

That's interesting that VHDL does this too. In verilog,
'X' AND 0 = 0
'X' OR 1 = 1

However for the multiply, it's as you indicated above:
'X' * 0 = 'X'

Don't know what the language designers chose to do it this
way. Good to know VHDL and verilog at least match.

I have seen similar weirdness in spreadsheets. For OpenOffice Calc
AND(NA();FALSE()) equals NA() and OR(NA();TRUE()) too, and NA()*0=NA(). I
can understand the last one, since cells can be potential non-numeric in
spreadsheets, but for std_logic_vectors the definition should be straight.

 

[Dom Bannon]

On Thu, 24 Feb 2011 10:11:24 +0100, "Morten Leikvoll"
<mleikvol@yahoo.nospam> wrote:

with one factor containing
'X' and the other has '0's, but the simulation gives me 'X'es as a result
while I expected '0's. Is this a bug/weakness or is there any logical or
technical reason at all for [dont' care]*zero<>zero?
Im working with Altera tools.

You haven't given us enough information. What are you simulating? Is
it a '*' operator, or is it your own implementation of a multiplier?
Do you know where the X's are coming from?

If you are actually simulating a '*' operator, then you need to know
that VHDL doesn't define '*' on std_logic_vectors; it only defines it
on physical types, ints, and reals. For these types, there is no X
input.

The numeric_std package has various signed/unsigned/natural
multiplies, but not std_logic_vector multiplies. As Brian said, the
package writer may have decided to special-case the situation where
one input is all zeros, but why bother? Are you sure that all possible
gate-level hardware implementations of a multiplier propagate a zero
output in this case? Even if you are, there's no sense in hiding X's;
you need X propagation so that you can detect and fix them. It's not
the purpose of a simulation package to provide an exact copy of
whatever simulation results your preferred implementation may end up
with.

Note that the numeric_std multiplies always set the result to all X's
if any input bit is 'X'.

BTW, if you do integer conversion first, as you suggest in another
post, it won't 'work' either. If you use 'TO_01', you'll get a warning
if you try to convert an 'X'. You can convert '0' to integer 0 if you
want to, but that wont affect any of the numeric_std multiplies.

 

[Nial Stewart]

The point is, what can 'X' be to make 'X'*0 not equal zero?

You have to initialise the signal that is 'X' to either '1' or '0'.


Nial

 

[Nial Stewart]

The point is, what can 'X' be to make 'X'*0 not equal zero?

Sorry, I might have mis-understood your question.

It's not a mathematical question, in that zero * anything = 0.

It's a functional simulation problem, the simulator probably parses the
inputs to a function (without considering what the function is), says
it doesn't know what the input is so it can't determine the output.

To stop seeing the X's propogate through a design you have to initialise
them at the start of the simulation.


Nial.

 

[Petter Gustad]

"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
writes:

It's a functional simulation problem, the simulator probably parses the
inputs to a function (without considering what the function is), says
it doesn't know what the input is so it can't determine the output.

This does not take place at parse time.

At run time the simulator will pass the left and right values (which
can be ('U','X','0','1','Z','W','L','H','-') to the function. The
problem is the implementation of the "*" function that Morten (or some
library) has defined for std_logic_vector. This function should check
if one of the arguments are 0 and then return 0. If not the function
could be overloaded it to implement this behaviour.

To stop seeing the X's propogate through a design you have to initialise
them at the start of the simulation.

This is bad practice. X's are your friend. They will let you know
you're using unqualified data. State, control register, qualifiers
(e.g. cache valid bits), etc. should be reset using one or more reset
signals.

//Petter
--
..sig removed by request.

 

[Arlet Ottens]

On 02/25/2011 02:32 PM, Nial Stewart wrote:

The point is, what can 'X' be to make 'X'*0 not equal zero?

Sorry, I might have mis-understood your question.

It's not a mathematical question, in that zero * anything = 0.

It's a functional simulation problem, the simulator probably parses the
inputs to a function (without considering what the function is), says
it doesn't know what the input is so it can't determine the output.

That all depends on the simulation algorithm. There's no reason why it
couldn't return 0 in this case.

To stop seeing the X's propogate through a design you have to initialise
them at the start of the simulation.

It would be better if the simulator would be able to work with 'X'
signals, and return sensible results.

For instance, if you turn a computer on, the RAM memory will be
initialized to a random state, and it will still work correctly every
time it boots up.

It would be nice if you could represent that unknown state by filling
the memory with 'X' during a simulation, and see if the model will still
run correctly. This requires that the simulator knows that X & 0 = 0,
and X | 1 = 1, and as a consequence, that X * 0 = 0.

 

[Morten Leikvoll]

"Dom Bannon" <nospam@nospam.com> wrote in message
news:la1fm6pel35182jhpkd5b19cvus3h28te7@4ax.com...

On Thu, 24 Feb 2011 10:11:24 +0100, "Morten Leikvoll"
mleikvol@yahoo.nospam> wrote:

I am simulating multipliers [std_logic_vectors] with one factor containing
'X' and the other has '0's, but the simulation gives me 'X'es as a result
while I expected '0's. Is this a bug/weakness or is there any logical or
technical reason at all for [dont' care]*zero<>zero?
Im working with Altera tools.

You haven't given us enough information. What are you simulating? Is
it a '*' operator, or is it your own implementation of a multiplier?
Do you know where the X's are coming from?

This is a general builtin multiplying operator on std_logic_vector. The use
has no meaning for this discussion.
I am only using ieee.std_logic_1164 and ieee.std_logic_unsigned packages.

If you are actually simulating a '*' operator, then you need to know
that VHDL doesn't define '*' on std_logic_vectors; it only defines it
on physical types, ints, and reals. For these types, there is no X
input.

In Quartus II (and its Modelsim tools) multiplication is obviously defined.
Quartus infers DSP multipliers, and God knows what Modelsim does, but it
does multiply.
I haven't tried to convert to integer and back, but I believe that would
work (althoug the code layout wouldn't look as nice). This is the
std_logic_vector multiplying discussion.

The numeric_std package has various signed/unsigned/natural
multiplies, but not std_logic_vector multiplies. As Brian said, the
package writer may have decided to special-case the situation where
one input is all zeros, but why bother? Are you sure that all possible
gate-level hardware implementations of a multiplier propagate a zero
output in this case? Even if you are, there's no sense in hiding X's;
you need X propagation so that you can detect and fix them. It's not
the purpose of a simulation package to provide an exact copy of
whatever simulation results your preferred implementation may end up
with.

Note that the numeric_std multiplies always set the result to all X's
if any input bit is 'X'.

That is what makes no (or little) sense. I am asking for any physical 'X' in
the valid std_logic space that would make this 'X'. Not even a metastable
factor would do that as long as the other factor is valid '0's.

BTW, if you do integer conversion first, as you suggest in another
post, it won't 'work' either. If you use 'TO_01', you'll get a warning
if you try to convert an 'X'. You can convert '0' to integer 0 if you
want to, but that wont affect any of the numeric_std multiplies.

A warning I can live with. But I wonder what the invalid result will be..
Since integers cant go 'x' the result may end up with what I need. I prefer
that to conditional simulation code.

 

[Dom Bannon]

On Fri, 25 Feb 2011 14:54:50 +0100, Petter Gustad
<newsmailcomp6@gustad.com> wrote:

At run time the simulator will pass the left and right values (which
can be ('U','X','0','1','Z','W','L','H','-') to the function. The
problem is the implementation of the "*" function that Morten (or some
library) has defined for std_logic_vector. This function should check
if one of the arguments are 0 and then return 0. If not the function
could be overloaded it to implement this behaviour.

Why? What is a 'std_logic_vector'? What does it encode? It could be an
IEEE float, for example. In this case, it's not true that
0*anything==0. 0 times infinity is NAN; 0 times NAN is NAN (according
to some, at least), and what about signed zero? Even some integer
representations (Perl?) include a NAN.

The OP is fixated on 0*anything = 0, but this is an application
problem; it's nothing to do with VHDL. VHDL defines multiply only for
physical, real, and integer types. Anything else is the designer's
problem; it's not VHDL's problem. The numeric_std multiply is not
"wrong". If Morten doesn't like it, he can just roll his own.

 

[Dom Bannon]

On Fri, 25 Feb 2011 16:00:34 +0100, "Morten Leikvoll"
<mleikvol@yahoo.nospam> wrote:

"Dom Bannon" <nospam@nospam.com> wrote in message
news:la1fm6pel35182jhpkd5b19cvus3h28te7@4ax.com...

BTW, if you do integer conversion first, as you suggest in another
post, it won't 'work' either. If you use 'TO_01', you'll get a warning
if you try to convert an 'X'. You can convert '0' to integer 0 if you
want to, but that wont affect any of the numeric_std multiplies.

A warning I can live with. But I wonder what the invalid result will be..
Since integers cant go 'x' the result may end up with what I need. I prefer
that to conditional simulation code.

Integers can't be X, but you've got an X in your circuit somewhere.
You could convert your X's to 0 with the numeric_std to_01
(to_01(my_int, '0')). The default is to set X's to '0' if you leave
out the second parameter.

This is not a smart thing to do, though. You need to get rid of your
X's instead of persuading the simulator to treat them 'correctly'
according to your application.

 

[Petter Gustad]

Dom Bannon <nospam@nospam.com> writes:

Why? What is a 'std_logic_vector'? What does it encode? It could be an
IEEE float, for example. In this case, it's not true that

I made an assumption that he was representing integers, which was
wrong. Like you say, it could as well have been IEEE-754, then 0 times
whatever is not always 0.


//Petter
--
..sig removed by request.

 

[Morten Leikvoll]

"Dom Bannon" <nospam@nospam.com> wrote in message
news:24ifm616e4fahpphnppdh33lf8e7n3og4n@4ax.com...

On Fri, 25 Feb 2011 16:00:34 +0100, "Morten Leikvoll"
mleikvol@yahoo.nospam> wrote:

"Dom Bannon" <nospam@nospam.com> wrote in message
news:la1fm6pel35182jhpkd5b19cvus3h28te7@4ax.com...

BTW, if you do integer conversion first, as you suggest in another
post, it won't 'work' either. If you use 'TO_01', you'll get a warning
if you try to convert an 'X'. You can convert '0' to integer 0 if you
want to, but that wont affect any of the numeric_std multiplies.

A warning I can live with. But I wonder what the invalid result will be..
Since integers cant go 'x' the result may end up with what I need. I
prefer
that to conditional simulation code.

Integers can't be X, but you've got an X in your circuit somewhere.
You could convert your X's to 0 with the numeric_std to_01
(to_01(my_int, '0')). The default is to set X's to '0' if you leave
out the second parameter.

This is not a smart thing to do, though. You need to get rid of your
X's instead of persuading the simulator to treat them 'correctly'
according to your application.

Ive seen some good arguments here why 'X'*zero is not always zero, but they
are all only valid in "theoretical space". When it comes down to the real
implementation there is nothing that can be multiplied with 0 and become
<>0, since my input can not be NaN (at least not in my unsigned fixed point
world), or even infinity in real life. I guess in the negative zero case, it
should go negative zero unless you multiply it with a negative zero? So I
guess I have to work with the model not being a "real life" model. Maybe the
std_logic just doesn't do, and make my own datatype and operators for it.
(or just live with bad conditional code)

 

[Hal Murray]

It would be better if the simulator would be able to work with 'X'
signals, and return sensible results.

For instance, if you turn a computer on, the RAM memory will be
initialized to a random state, and it will still work correctly every
time it boots up.

In the case of RAM, it works because the system stores something
useful into RAM before it reads it.

It would be nice if you could represent that unknown state by filling
the memory with 'X' during a simulation, and see if the model will still
run correctly. This requires that the simulator knows that X & 0 = 0,
and X | 1 = 1, and as a consequence, that X * 0 = 0.

I'd prefer the simulator to give an error/warning if it reads
an X from a RAM.

--
These are my opinions, not necessarily my employer's. I hate spam.