Verifying a Bidirectional Data Bus

[pete o.]

I have had reasonable success verifying some designs using behavioral
verilog and modelsim.
I seem to have trouble with bidirectional data buses. I have a handful
of verilog books, but none of
their simulation examples use bidirectional buses. Someone told me I
must use a transactor?
If anyone can point me to a text or has any tips it would be
appreciated.

 

[Ralf Hildebrandt]

pete o. schrieb:

I seem to have trouble with bidirectional data buses.

What problems?

assign tri_driver = (tri_enable==1'b1)? tri_value : 1'bZ;

Make sure, that only one driver to a tri-state bus is enabled at a time!

Remember that uninitialized drivers drive X (not 'U' as in VHDL). A
bidirectional port with no driver at one side is treated as
uninitialized. So drive at least with Z.

Ralf

 

Ralf Hildebrandt wrote:

Remember that uninitialized drivers drive X (not 'U' as in VHDL). A
bidirectional port with no driver at one side is treated as
uninitialized. So drive at least with Z.

I don't know what tools you have been using, but a net with no drivers
has no drivers, and should come up Z already. The Verilog LRM says
that a net with no drivers will come up Z (unless it is one of the
special
net types with an implicit driver like the pullup on a tri1).

If there is a driver on one side of a bidirectional port and not on the
other,
then the one driver will set the value for both sides. A driver that
always
drives Z is useless in Verilog, as in real life.

 

pete o. wrote:

I have had reasonable success verifying some designs using behavioral
verilog and modelsim.
I seem to have trouble with bidirectional data buses.

As Ralf says, you will need to drive them from your testbench using a
driver that you can turn off (tristate), so that you can see the value
being
driven back out when the design is supposed to drive it.

There is also nothing in the value to tell you whether it is currently
being
driven by the testbench or by the design. You just see the current
value
and have to keep track of whether the testbench or the design is
driving
that value. EVCD dumps do keep track of which side of a port the value
is being driven from, so tools that work with those will give you that
extra
information.

Working with bus transactions instead of signal values does allow you
to
work at a higher level of abstraction, if you have tools that support
transaction based verification. But that comes in after you have
verified
the logic for performing individual bus cycles.

 

[Ralf Hildebrandt]

sharp@cadence.com wrote:

I don't know what tools you have been using, but a net with no drivers
has no drivers, and should come up Z already. The Verilog LRM says
that a net with no drivers will come up Z (unless it is one of the
special
net types with an implicit driver like the pullup on a tri1).

If there is a driver on one side of a bidirectional port and not on the
other,
then the one driver will set the value for both sides. A driver that
always
drives Z is useless in Verilog, as in real life.

Well .. I have to say that I did not check my statement for Verilog. For
VHDL and Cadence NCsim I have observed this behavior for bidirectional
ports. My fault - I should have checked it for Verilog too.

Ralf

 

[glen herrmannsfeldt]

Ralf Hildebrandt wrote:

pete o. schrieb:

I seem to have trouble with bidirectional data buses.

assign tri_driver = (tri_enable==1'b1)? tri_value : 1'bZ;

Make sure, that only one driver to a tri-state bus is enabled at a time!

As I understand it, in modern (later than XC4000) FPGA's tristate lines
are implemented through multiplexers, which normally can only select
one input. (and most likely go to a known state with no drivers.)

Then again, the OP didn't say what the target logic family was, if any.

-- glen

 

[Rob Dekker]

<sharp@cadence.com> wrote in message news:1168973475.770102.193160@38g2000cwa.googlegroups.com...

Ralf Hildebrandt wrote:

Remember that uninitialized drivers drive X (not 'U' as in VHDL). A
bidirectional port with no driver at one side is treated as
uninitialized. So drive at least with Z.

I don't know what tools you have been using, but a net with no drivers
has no drivers, and should come up Z already. The Verilog LRM says
that a net with no drivers will come up Z (unless it is one of the
special
net types with an implicit driver like the pullup on a tri1).

If there is a driver on one side of a bidirectional port and not on the
other,
then the one driver will set the value for both sides. A driver that
always
drives Z is useless in Verilog, as in real life.

This (initialization of undriven nets/vars) is still confusing to me (and to Ralf also apparently).
This program :

module t (w,r) ;
output wire w ;
output reg r ;
initial $display("r:%b w:%b",r,w) ;
endmodule

Gives the following result :

r:x w:z

So it seems that Verilog initializes nets with Z but variables (reg) with X...
No idea why. Is this mentioned anywhere in the LRM ?

Rob

 

[Stephen Williams]

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

Rob Dekker wrote:

This (initialization of undriven nets/vars) is still confusing to me (and to Ralf also apparently).
This program :

module t (w,r) ;
output wire w ;
output reg r ;
initial $display("r:%b w:%b",r,w) ;
endmodule

Gives the following result :

r:x w:z

So it seems that Verilog initializes nets with Z but variables (reg) with X...
No idea why. Is this mentioned anywhere in the LRM ?

It's simple. "reg" items are variables, and "wire" items are nets.
Nets are (un)driven and variables are (un)initialized. From that,
the choice of undriven value (z) for nets is obvious (and well known).
Variables are not driven, and in fact are normally thought of as
drivers themselves, so 'bx more clearly says "don't know".

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

iD8DBQFFui7erPt1Sc2b3ikRAv+gAKCSs4hAEE/Un4Sjk1LYhWa+CkLGAwCeNXOW
nAy4BGbRmOwcwJHiq0U7IXc=
=iXNG
-----END PGP SIGNATURE-----

 

[Rob Dekker]

"Stephen Williams" <spamtrap@icarus.com> wrote in message news:FdKdnVHyPZt8syfYnZ2dnUVZ_qGjnZ2d@giganews.com...

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

Rob Dekker wrote:

This (initialization of undriven nets/vars) is still confusing to me (and to Ralf also apparently).
This program :

module t (w,r) ;
output wire w ;
output reg r ;
initial $display("r:%b w:%b",r,w) ;
endmodule

Gives the following result :

r:x w:z

So it seems that Verilog initializes nets with Z but variables (reg) with X...
No idea why. Is this mentioned anywhere in the LRM ?

It's simple. "reg" items are variables, and "wire" items are nets.
Nets are (un)driven and variables are (un)initialized. From that,
the choice of undriven value (z) for nets is obvious (and well known).
Variables are not driven, and in fact are normally thought of as
drivers themselves, so 'bx more clearly says "don't know".

Thanks Steve. That kind of makes sense if you are used to Verilog, and simulation terms like 'undriven' and 'uninitialized'.
From a hardware point of view however, you would think that unassigned variables would be just that : unassigned. So they would
create dangling nets, regardless of their type.
In synthesis, we typically tie unassigned nets to either ground or power, to avoid incorrect functioning devices.
Should we leave undriven nets dangling in your opinion, but tie-off variables ?

In 15 years in the business, I have gone back and forth between tieing off or leaving dangling.
Either way we get bug-reports....

Any way, back to Ralf's remark, I think his advice (to always assign a 'Z' to nets that you explicitly want to represent as dangling
(such as a 'bus') makes perfect sense. Maybe not for simulation, but it does for synthesis : At least now we know that the user does
not want to tie-off the net to power or ground.

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

iD8DBQFFui7erPt1Sc2b3ikRAv+gAKCSs4hAEE/Un4Sjk1LYhWa+CkLGAwCeNXOW
nAy4BGbRmOwcwJHiq0U7IXc=
=iXNG
-----END PGP SIGNATURE-----

 

[Ralf Hildebrandt]

Rob Dekker schrieb:

Any way, back to Ralf's remark, I think his advice (to always assign a 'Z' to nets that you explicitly want to represent as dangling
(such as a 'bus') makes perfect sense. Maybe not for simulation, but it does for synthesis : At least now we know that the user does
not want to tie-off the net to power or ground.

Well .. even for simulation I think it can make sense: If you are in the
middle of the design process of your circuit and your testbench it may
happen, that you create a new module / component which will be "empty"
or "incomplete" at the moment, because you just did not finish it, but
you want to have this instance connected to the testbench / circuit.
(Maybe a tri-state bus communication component, for what you have
finished some registes but not the connection to the tri-state bus.) If
you then want to simulate your design with this incomplete module /
component you may get these 1'bX / 'U'. And the reason for it is hard to
find.

Another example is a chain of transfer gates in VHDL. (example at
<http://www.ralf-hildebrandt.de/publication/publication_en.html&gt If you
forget to drive 'Z' in the testbench at the end of the chain you get
'U'. Without verifying I think the same problem (1'bX) arises in Verilog
if the end of the chain is connected to an undriven reg.



I agree - for synthesis the user should have taken care about floating
nets (tie up/down or force 1'bZ). Fortunately simulation shows this
problem with 1'bX / 'U'.

Ralf