mux with inputs of "X" or "Z"...?

A

andersod2

Guest
What happens if I have a module that is a simple 1-bit mux, where the
select line selects A or B, and A is "X", and B is "Z"...? (And let's
say the select line is set to "B")...does this mean the output will
just be "Z" or is there some kind of error condition associated with
this? Under what circumstances would something like this happen (i.e.
how could an "X" and a "Z" possibly get passed into the module)?

Thanks for your help
 
andersod2 <thechrisanderson@gmail.com> wrote:

What happens if I have a module that is a simple 1-bit mux, where the
select line selects A or B, and A is "X", and B is "Z"...?
Click to expand...
What do you mean by "what happens"?

(And let's
say the select line is set to "B")...does this mean the output will
just be "Z" or is there some kind of error condition associated with
this? Under what circumstances would something like this happen (i.e.
how could an "X" and a "Z" possibly get passed into the module)?
Click to expand...
In simulation, you can pass X or Z around all you want.

In synthesis, X will be either 0 or 1, but you don't know which.

Z won't go through most buffers, nor most synthesized MUXes.

-- glen
 
Thanks for your response glen -- what I mean by "what happens" is
what will be the value on the output line from the mux? i.e. if B is
selected, and is equal to Z, does this just mean Z will technically be
the output? (I guess another question would be does how the mux is
implemented affect this, i.e. with an assign statement for the output
wire vs a reg for the output)?

In general I'd like to just know what real-world situations cause X
and Z -- I take it X could be caused by an unconnected pin, or some
random/unstable state, or we use it to just mean we don't use this
wire/don't care. Z is a bit foggier to me as to how this value ends
up on an input to a module.
 
On Thu, 2 Sep 2010 10:24:12 -0700 (PDT), andersod2 wrote:

What happens if I have a module that is a simple 1-bit mux, where the
select line selects A or B, and A is "X", and B is "Z"...? (And let's
say the select line is set to "B")...does this mean the output will
just be "Z" or is there some kind of error condition associated with
this? Under what circumstances would something like this happen (i.e.
how could an "X" and a "Z" possibly get passed into the module)?
Click to expand...
Since this is comp.lang.verilog, I assume you're asking about a mux
coded in Verilog. There are numerous ways to do this, and each
may give a different answer to your question.

If we're thinking about standard synthesisable RTL idioms,
there are basically three ways to write a mux:

(1) using the ?: conditional operator

assign result = selector ? A : B;
OR (almost equivalent)
always @* result = selector ? A : B;

In both cases...
- if "selector" = 1'b0, then the result will
be an exact copy of B (whether it's X, Z or whatever)
- if the selector is 1'bx or 1'bz (unknown) then if
A and B are equal the result will be that value;
otherwise the result will be 1'bx

I think you'll agree that this is a reasonable model
of a hardware mux, except that typical hardware muxes
don't pass Z values (a Z input would cause an X output).

(2) Using an if..else statement
always @*
if (selector)
result = A;
else
result = B;

Once again, if selector is 1'b0 then the result is an
exact copy of B; if selector is 1'b1 then the result is
an exact copy of A; but if selector is unknown, things
get a bit more complicated. The problem here is that
the familiar programming construct "if...else" only
admits of two possibilities, true and false; it has no
notion of "maybe". So the Verilog language has to
make a decision about that, and the official (albeit
arbitrary) decision is: when the condition in an "if"
evaluates to an unknown truth-value, the if...else
statement takes its "else" branch. This is not such
a good model of real hardware, because X really models
"it's a 1 or a 0, but I don't know which"; in this case,
hardware is likely to behave rather in the same way as
version (1), with the output being the same as the inputs
if they're identical, but X if the inputs are different.

(3) Explicit and-or mux:
assign result = (A & selector) | (B & ~selector);

Once again, if selector is well-known (O or 1) then
the output is an exact copy of the selected input,
EXCEPT that a Z input will appear as X on the output,
because in Verilog (rather sensibly)
1'bZ & 1'b1 == 1'bX.

If the selector is unknown, then we get....

A B result
0 0 0 (because 1'b0 & 1'bX == 1'b0)
0 1 X
1 0 X
1 1 X (because 1'b1 & 1'bX == 1'bX)

The last line of that truth table is slightly
surprising, but there you go.
===============================================
Of course, every one of these three idioms will
synthesise to exactly the same hardware: whatever your
chosen technology does to implement a mux. And the
real hardware mux will probably behave most like
the ?: conditional-expression form. But generally
you will have tried to keep X values out of your
simulation, won't you? Yes, of course you did.

And then, of course, you may decide that your real
physical hardware uses pass transistors to implement
a mux. Such a mux really does pass Z values correctly.
You can model that in Verilog too, using tranif primitives,
but it won't be synthesisable.

Amazing how many different answers there are to a
simple question about a three-gate circuit :)
--
Jonathan Bromley
 
andersod2 <thechrisanderson@gmail.com> wrote:

Thanks for your response glen -- what I mean by "what happens" is
what will be the value on the output line from the mux? i.e. if B is
selected, and is equal to Z, does this just mean Z will technically be
the output? (I guess another question would be does how the mux is
implemented affect this, i.e. with an assign statement for the output
wire vs a reg for the output)?
Click to expand...
I usually try to think in terms of real logic gates, where X
doesn't exist, and Z only comes from the outputs of certain gates.

In the case of bus extenders, there are circuits that attempt
to propagate a Z, but in most real logic Z doesn't propagate.

assign vs. reg shouldn't matter. If you use if/then/else
or the conditional operator, you should be able to propagate
one in simulation. If you use AND/OR logic, then you won't
propagate Z.

In general I'd like to just know what real-world situations cause X
and Z -- I take it X could be caused by an unconnected pin, or some
random/unstable state, or we use it to just mean we don't use this
wire/don't care. Z is a bit foggier to me as to how this value ends
up on an input to a module.
Click to expand...
In the real world, you pretty much never have X. For CMOS, I
suppose an unconnected pin could float just right, but that isn't
really a useful X. In real logic, Z can only propagate
through a pass transistor, and you normally don't see them.

Early FPGAs had internal tristate gates, but newer ones don't.

-- glen
 
Ok - thanks. So then if Z doesn't propogate, what is on the actual
output signal if the port with Z on it is selected? X?
 
On Thu, 2 Sep 2010 21:26:19 +0000 (UTC), glen herrmannsfeldt wrote:

You can model that
[pass-transistor mux]
in Verilog too, using tranif primitives,
but it won't be synthesisable.

Again, it might for ASIC, but not likely for any FPGA technology
that I know about. Pass transistors used to be a pretty common
part of MOS logic design.
Click to expand...
Agreed, but I've not yet met _any_ synthesis tool that will
accept "tran" primitives at all. Happy to be proved wrong,
as always.

The synth tools' refusal to parse Verilog "tranif" is
just a matter of the front-end, of course. There is
nothing in the world to stop you having a pass-transistor
mux in your cell library, and then any half-decent ASIC
synth tool can use it to implement your behavioural
mux descriptions using ?:, if-then or whatever.

Which reminds me: there's a fourth mux description that
at least some synth tools will accept, and which comes
very close to the pass-transistor implementation:

assign result = selector ? A : 1'bz;
assign result = ~selector ? B : 1'bz;

Detailed analysis of this design's simulation behaviour
in the presence of X or Z values on any inputs is left
as an exercise for the student (for such I guess the OP
to be). When that's done, the OP can then go off and
find out about alternative mux implementations using
wor and wand nets for the result signal...
--
Jonathan Bromley
 
Jonathan Bromley <spam@oxfordbromley.plus.com> wrote:
On Thu, 2 Sep 2010 10:24:12 -0700 (PDT), andersod2 wrote:

What happens if I have a module that is a simple 1-bit mux, where the
select line selects A or B, and A is "X", and B is "Z"...?
(snip)
Click to expand...

Since this is comp.lang.verilog, I assume you're asking about a mux
coded in Verilog. There are numerous ways to do this, and each
may give a different answer to your question.
(snip)
Click to expand...

assign result = selector ? A : B;
OR (almost equivalent)
always @* result = selector ? A : B;
Click to expand...
(snip)
===============================================
Of course, every one of these three idioms will
synthesise to exactly the same hardware: whatever your
chosen technology does to implement a mux. And the
real hardware mux will probably behave most like
the ?: conditional-expression form. But generally
you will have tried to keep X values out of your
simulation, won't you? Yes, of course you did.

And then, of course, you may decide that your real
physical hardware uses pass transistors to implement
a mux. Such a mux really does pass Z values correctly.
Click to expand...
It won't synthesize for FPGAs, I am not so sure it couldn't
for an ASIC, though. Also, if the synthesis finds that the
select line is constant, it might be able to optimize
out the mux, such that Z would go through.

You can model that in Verilog too, using tranif primitives,
but it won't be synthesisable.
Click to expand...
Again, it might for ASIC, but not likely for any FPGA technology
that I know about. Pass transistors used to be a pretty common
part of MOS logic design. I might still have some books from those
days that describe how to use them.

Amazing how many different answers there are to a
simple question about a three-gate circuit :)
Click to expand...
-- glen
 
Jonathan Bromley <spam@oxfordbromley.plus.com> wrote:
(snip)

Which reminds me: there's a fourth mux description that
at least some synth tools will accept, and which comes
very close to the pass-transistor implementation:

assign result = selector ? A : 1'bz;
assign result = ~selector ? B : 1'bz;
Click to expand...
I believe that the FPGA tools should accept that one.

Older FPGA families, at least XC4K series, have internal
tristate buffers. For back compatability, the tools for
newer families will implement tristate logic as MUX logic.

It may even give better results in the case of distributed
sources, as would be usual for a tristate bus.

-- glen
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top