Multiple drivers 
Author Message
 Multiple drivers

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



Mon, 02 Jan 2006 07:50:24 GMT  
 Multiple drivers
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

Quote:

> 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



Mon, 02 Jan 2006 22:20:42 GMT  
 Multiple drivers
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...
Quote:

> 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

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



Tue, 03 Jan 2006 02:50:07 GMT  
 Multiple drivers

Quote:

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



Tue, 03 Jan 2006 03:36:43 GMT  
 Multiple drivers

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

Quote:


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



Tue, 03 Jan 2006 04:53:33 GMT  
 Multiple drivers

Quote:

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



Wed, 04 Jan 2006 02:26:02 GMT  
 Multiple drivers
$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...
Quote:


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



Wed, 04 Jan 2006 06:48:06 GMT  
 Multiple drivers

Quote:

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

It is documented in the IEEE standard as a system task that may not be
available in all implementations.  Verilog-XL provided it, and NC-Verilog
also supports it.  You would have to check in the documentation of any
other implementation you are using.


Wed, 04 Jan 2006 10:23:01 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Multiple drivers

2. question about multiple drivers

3. Problem with multiple drivers

4. Synthesis and multiple drivers

5. Multiple Drivers

6. Multiple Drivers?

7. multiple drivers

8. Where are the multiple drivers?

9. multiple drivers for indexed subelements

10. multiple driver problem? please explain.

11. How to find floating nets and multiple drivers in std_logic??

12. Unexpected "multiple drivers" error; bug?

 

 
Powered by phpBB® Forum Software