Simulating mutiplication of 'X' with '0'

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.

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.

- Brian

"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" <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.

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?

Hello,
       I am using a custom FPGA board with xC3S250e-vq100 from xilinx and
the PROM XCF04S. I am using Master serial mode configuration and i have
permanently grounded M0,M1 and M2 mode select pins. I am using Platform
Cable USB II for programming the FPGA. My board has 6 pin JTAG header which
i connect to the Platform cable header. I am using Impact 12.4. The FPGA is
programmed properly when the bit file is downloaded directly to the FPGA
and i get the proper output signals on the I/O's.
When PROM is programmed the message on impact says " Program Succeeded " .
Given below is the console message. 
'2': Loading file 'C:/Users/tsrc/Desktop/FPGA Board
Test/fpgaboardtest/test.mcs' ...
done.
INFO:iMPACT - Current time: Sun Feb 13 16:15:37 2011
PROGRESS_START - Starting Operation.
Maximum TCK operating frequency for this device chain: 10000000.
Validating chain...
Boundary-scan chain validated successfully.
'2': Erasing device...
'2': Erasure completed successfully.
'2': Programming device...
done.
'2': Putting device in ISP mode...done.
'2': Putting device in ISP mode...done.
'2': Verifying device...done.
'2': Verification completed successfully.
'2': Calculated checksum matches expected checksum, 00568e386
'2': Putting device in ISP mode...done.
'2': Putting device in ISP mode...done.
'2': Setting user-programmable bits...
done.
'2': Putting device in ISP mode...done.
'2': Starting FPGA Load with Prom Data...INFO:iMPACT:563 - '2':Please
ensure proper connections as specified by the data book ...
'2': Programming completed successfully.
'2': Programming completed successfully.
PROGRESS_END - End Operation.
Elapsed time =     14 sec.

The TCK speed was 6 MHz. Judging from the Console message i am guessing the
PROM is programmed correctly. But when i try to start up or pull down PROG
pin momentarily low the FPGA is not programmed. I do not get any output
signals on the I/O's. I did checked the DIN pin on FPGA using. When Started
up or gave 0 on PROG pin using push button i saw the random bits which i am
guessing is configuration data. I also observed that the CCLK pin on the
FPGA is continuously giving out the clk pusles no matter what when the PROM
is programmed but goes off when only FPGA is programmed.

I have tried to follow the schematics from FPGA precisely but still have no
clue what is wrong.

Please help
Thanks!


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

"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.

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


Nial.

"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?

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

"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.

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?

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.