# Unknown signal resolution in NCsim and Modelsim

Discussion in 'VHDL' started by vrangan@qualcomm.com, Dec 16, 2003.

1. ### Guest

In sims using either Modelsim/NCsim, the following logic always
results in an 'X' output, regardless of the reset state, due to the
scope of analysis being too small:

z = (a AND b) OR c
c = NOT a

b = reset
a = 'X'
(and thus c = NOT X, still X but the opposite state of a)

When reset = '1', the output should always be forced to '1'.
Substitution of values shows that the logic above is correct, with the
value of input a not mattering if b = '1'. Using equation
substitution, the logic reduces to:

z = (a AND b) OR (a')
= (a OR a') AND (b OR a')
= (1) AND (b OR a')
= b OR a'

Where if b = '1', z = '1' (even if a' = 'X')

But the sim tools don't see things this way. Their scope doesn't
appear to be large enough to see that there is a relationship between
c and a, and therefore z is always 'X' no matter what the state of
input b.

How do we get around this?
Thank you,

, Dec 16, 2003

2. ### Mike TreselerGuest

wrote:
> In sims using either Modelsim/NCsim, the following logic always
> results in an 'X' output, regardless of the reset state, due to the
> scope of analysis being too small:
>
> z = (a AND b) OR c
> c = NOT a
>
> b = reset
> a = 'X'
> (and thus c = NOT X, still X but the opposite state of a)

Post the actual code you are simulating.
Can't tell if you mean signals or variables,
single process or concurrent statements.

-- Mike Treseler

Mike Treseler, Dec 16, 2003

3. ### Jim LewisGuest

It is a simulators job to exectute the
code you write.

Is this code you wrote or code that was synthesized?
If it is code you wrote, post it and someone can
suggest a way to re-write it to give you
the results you want.

If it is the output of Synopsys, you may get some
benefit from setting the preserve_synchronous_resets
to true (note, they like changing names frequently,
so it may be something new). Another way to convey
this information is to put a tight timing delay on
reset so the results will be required to put reset
up front.

Cheers,
Jim

wrote:

> In sims using either Modelsim/NCsim, the following logic always
> results in an 'X' output, regardless of the reset state, due to the
> scope of analysis being too small:
>
> z = (a AND b) OR c
> c = NOT a
>
> b = reset
> a = 'X'
> (and thus c = NOT X, still X but the opposite state of a)
>
> When reset = '1', the output should always be forced to '1'.
> Substitution of values shows that the logic above is correct, with the
> value of input a not mattering if b = '1'. Using equation
> substitution, the logic reduces to:
>
> z = (a AND b) OR (a')
> = (a OR a') AND (b OR a')
> = (1) AND (b OR a')
> = b OR a'
>
> Where if b = '1', z = '1' (even if a' = 'X')
>
> But the sim tools don't see things this way. Their scope doesn't
> appear to be large enough to see that there is a relationship between
> c and a, and therefore z is always 'X' no matter what the state of
> input b.
>
> How do we get around this?
> Thank you,

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Jim Lewis, Dec 16, 2003
4. ### feGuest

> z = (a AND b) OR (a')
> = (a OR a') AND (b OR a')
> = (1) AND (b OR a')
> = b OR a'
>

Sorry, it's wrong.
(a AND b) OR (a') <> (a OR a') AND (b OR a')
a*b - a <> (a - a) * (b - a)
3*5 - 3 = 12
(3-3) * (5 - 3) = 0

Simulator doesn't do optimization.
z = (a AND b) OR NOT a

So, from ieee.std_logic_1164:
if b is '1' and a is 'x' then
not 'x' is 'x'
'x' and '1' is 'x'
'x' or 'x' is 'x'

if b is '0' and a is 'x' then
not 'x' is 'x'
'x' and '0' is '0'
'0' or 'x' is 'x'

z is always 'x'

You can simplify your equation to :
Z = a NAND (NOT b)

So, from ieee.std_logic_1164:
if b is '1' and a is 'x' then
not '1' is '0'
'x' and '0' is '0'
not '0' is '1'
z ='1'

if b is '0' and a is 'x' then
not '0' is '1'
'x' and '1' is 'x'
not 'x' is 'x'
z= 'x'

regards
Pat

fe, Dec 17, 2003