Multiple drivers

[Paul Richardson]

Is there a relatively easy way to determine that more than one driver is
driving a net/wire (of any strength) and if so, drive an 'X' onto the net.

Thanks in advance

Paul Richardson

 

[Paul Richardson]

I was hoping to do this from with rtl, that is, check to make sure that
no one onese is driving the net, if so then guarantee that an X is
present even if multiple drivers are driving the same state onto the net...

Andrew Paule wrote:

Hi Paul:

it depends -
if you are talking about a board with multiple chips that can drive a
bus, then only an examination of the design will do, but most schematic
editors have this DRC built in

if you are inside an array - then things can get hairy depending on the
routing software and your code, but most packages have DRC checking in
them, and this feature can be switched on.

Andrew Paule
Paul Richardson wrote:

Is there a relatively easy way to determine that more than one driver
is driving a net/wire (of any strength) and if so, drive an 'X' onto
the net.

Thanks in advance

Paul Richardson

 

[Andrew Paule]

Oh no don't do that -

let's say that we have two 2mA drivers (internal - sink and source) -
when one goes high and the other goes low, the bus will pull towards one
or the other (the 2mA is a manufacturing "desire" - there is variation
across even a chip), and whoever is stronger will win, and eventually
the "loosing' driver will fail completely. Planning this is a good
recipe for failure.

Andrew Paule

Steven Sharp wrote:

Paul Richardson <paulrichardson@sbcglobal.net> wrote in message news:<4xlRa.11$wU3.1@newssvr24.news.prodigy.com>...


Is there a relatively easy way to determine that more than one driver is
driving a net/wire (of any strength) and if so, drive an 'X' onto the net.



No, there isn't. The resolution functions are all predefined, and are
based on a model of reality in which a stronger driver always overcomes
a weaker one. Contention only occurs for non-matching values with
matching strengths (and not even then for wor and wand net types).

If you made sure that all your drivers had the same strength, then
you would get an X any time two drivers drove different values. If
you wanted an X any time there were two drivers even if they drove
the same value, then you are out of luck. That doesn't match the
model of physical reality used by the simulator.

You could devise your own mechanism by using $countdrivers and then
add extra logic to get your X result, but I wouldn't consider that
to be "relatively easy". It would also be inefficient to simulate.

Because users sometimes want to have contention detectors (and float
detectors), and this is difficult for them to do efficiently in the
existing Verilog, Cadence is considering proposing a language extension
for this. It would look pretty much like a new timing check.

 

[Steven Sharp]

Andrew Paule <lsboogy@qwest.net> wrote in message news:<e_DRa.60$6L4.39254@news.uswest.net>...

Oh no don't do that -

let's say that we have two 2mA drivers (internal - sink and source) -
when one goes high and the other goes low, the bus will pull towards one
or the other (the 2mA is a manufacturing "desire" - there is variation
across even a chip), and whoever is stronger will win, and eventually
the "loosing' driver will fail completely. Planning this is a good
recipe for failure.

It is not clear what you are objecting to here. Nobody is proposing
that it is a good idea to have driver contention. In fact, the
discussion is about how to detect contention during simulation by
producing X values.

The problem is that the original question was about detecting
multiple drivers in situations that are not considered to be
contention. For example, trying to consider two drivers of
different Verilog strengths to be in contention. One would only
use different strengths to model situations where one would
deliberately and safely have two drivers active at once,
typically with orders of magnitude difference in output
impedance. Examples would include tristate busses with pullups,
and wired-logic such as open-collector and ECL. For any other
situation, one would use the default strength (i.e. strong)
and multiple drivers of different values would automatically
result in X values.

The other situation is two drivers driving the same value.
While this might cause problems like switching transients,
this is not technically contention, and the simulator will
not produce X in this situation. Note that this situation
may be designed deliberately also, as in wired-logic, or
using multiple buffer cells wired in parallel to get the
effect of a stronger buffer.

In adding some kind of explicit contention checker to the
language, multiple drivers of any sort would probably be
treated as an error condition. One would not attach such a
contention checker to the kind of signal that would deliberately
have multiple drivers.

 

[Paul Richardson]

$countdrivers, is this a canned (read available in modelsim, vcs) system
task call ? If so I can probably do something along the lines of what
you suggest below...

Steven Sharp wrote:

Paul Richardson <paulrichardson@sbcglobal.net> wrote in message news:<4xlRa.11$wU3.1@newssvr24.news.prodigy.com>...

Is there a relatively easy way to determine that more than one driver is
driving a net/wire (of any strength) and if so, drive an 'X' onto the net.


No, there isn't. The resolution functions are all predefined, and are
based on a model of reality in which a stronger driver always overcomes
a weaker one. Contention only occurs for non-matching values with
matching strengths (and not even then for wor and wand net types).

If you made sure that all your drivers had the same strength, then
you would get an X any time two drivers drove different values. If
you wanted an X any time there were two drivers even if they drove
the same value, then you are out of luck. That doesn't match the
model of physical reality used by the simulator.

You could devise your own mechanism by using $countdrivers and then
add extra logic to get your X result, but I wouldn't consider that
to be "relatively easy". It would also be inefficient to simulate.

Because users sometimes want to have contention detectors (and float
detectors), and this is difficult for them to do efficiently in the
existing Verilog, Cadence is considering proposing a language extension
for this. It would look pretty much like a new timing check.