Verilog LRM bufif*

[Yottameter]

In the LRM it mentions that the bufif0 and bufif1 elements:

"model three-state drivers. In addition to values of 1 and 0, these
gates output Z."

which would imply to me that X is not an output of that driver, but my
sims show that X does come out of the bufif0 and bufif1 primitives. It
even goes on to describe in the LRM about delays and the X state, so how
is it claimed that the gate is a three state device?

What am I not understanding here?

 

[Stephen Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yottameter wrote:

In the LRM it mentions that the bufif0 and bufif1 elements:

"model three-state drivers. In addition to values of 1 and 0, these
gates output Z."

which would imply to me that X is not an output of that driver, but my
sims show that X does come out of the bufif0 and bufif1 primitives. It
even goes on to describe in the LRM about delays and the X state, so how
is it claimed that the gate is a three state device?

Not only can it output 0, 1, X and Z, they can also output H and L.

X is an unknown between 1 and 0,
H is an unknown between 1 and Z,
L is an unknown between 0 and Z.

What am I not understanding here?

That X (and H and L) are not output values but *unknown* outputs
that reflect the unknown possibilities. There are generic rules
that cover all gate types' handling of X/Z inputs including the
bufif* gates, and there are explicit rules for bufif* gates that
say how to handle X inputs to the enable port. (The latter is
where the H/L values come from.)


- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFH++yjrPt1Sc2b3ikRAvMHAJ9hGIUqe2hexCiQCCogu11s3KwQUQCgvnX3
ijTXNmOZkCMzOTtClVI/LYM=
=oPgH
-----END PGP SIGNATURE-----

 

On Apr 8, 5:33 pm, Yottameter <yottame...@yahoo.com> wrote:

In the LRM it mentions that the bufif0 and bufif1 elements:

"model three-state drivers. In addition to values of 1 and 0, these
gates output Z."

which would imply to me that X is not an output of that driver, but my
sims show that X does come out of the bufif0 and bufif1 primitives. It
even goes on to describe in the LRM about delays and the X state, so how
is it claimed that the gate is a three state device?

I think you are interpreting the term "three state" as if it were an
alternative to 2-state and 4-state values used in simulation. In
fact, the output of a bufif* is a 4-state value, as are all Verilog
values besides reals. The output of a bufif* can be X, like most
primitives. The output can also be Z, which most primitive outputs
cannot. In the same sense, logic primitives have two state outputs.
The simulator uses an additional X state to represent situations where
it is uncertain which of the two states the output is in.

The term "three-state driver" is being used as an alternative to
saying "tristate driver". I believe that the term "tristate" was
trademarked by one particular semiconductor company, so that everyone
else in the industry has had to come up with variant terms.