Help with Verilog charge strength

Hello Everyone,
I am facing some issues with verilog charge strengths. Here's what I
want -- the signal a must reflect the charge strength of the signal
which is driving a. Here's my code:
assign (strong1, weak0) d = 1'b0; // d's strength is now We0
initial #2 $display ("%v", d); // this will print "We0"
assign a = d;
initial #4 $display ("%v", a); // this prints "St0" :-(

Can anyone please help solve my problem? All I need is some verilog
code which lets the assigned signal take on the charge strength of the
driving signal.

Thanks and Regards,
Arpan

 

On Jun 11, 2:04 pm, arpan...@gmail.com wrote:

Can anyone please help solve my problem? All I need is some verilog
code which lets the assigned signal take on the charge strength of the
driving signal.

The only way to pass strength values is to use a transistor
primitive. Since you apparently want to pass the value only one
direction, you would use a unidirectional MOS switch primitive. For
example

pmos p1(a, d, 1'b0);

 

Thanks a lot for the response. I came across the following interesting
snippet and thought it is worth sharing with all. consider this code:
pmos (a, c ? p : q, 1'b0);
in this situation what would be the strength of a? will it vary
depending on what the value of c is or should it be set to the greater
of the strengths of p and q? is there any lrm section(s) which
specifically deal with such corner situations?

regards,
arpan

On Jun 11, 11:29 pm, sh...@cadence.com wrote:

On Jun 11, 2:04 pm, arpan...@gmail.com wrote:



Can anyone please help solve my problem? All I need is some verilog
code which lets the assigned signal take on the charge strength of the
driving signal.

The only way to pass strength values is to use a transistor
primitive. Since you apparently want to pass the value only one
direction, you would use a unidirectional MOS switch primitive. For
example

pmos p1(a, d, 1'b0);

 

On Jun 15, 9:13 am, arpan...@gmail.com wrote:

Thanks a lot for the response. I came across the following interesting
snippet and thought it is worth sharing with all. consider this code:
pmos (a, c ? p : q, 1'b0);
in this situation what would be the strength of a? will it vary
depending on what the value of c is or should it be set to the greater
of the strengths of p and q?

It will be completely independent of the strengths of c, p and q. As
soon as you connect an expression to the port, you have created an
implicit continuous assignment that evaluates the expression and
drives the port. The output strength of that implicit continuous
assignment will be Strong.

If you want to pass signal strength through, then the entire path
taken by the signal must be logic that passes strength, which means
transistor primitives. If you want to select between two inputs, you
will have to create your MUX with transistor primitives:

pmos (a, q, c);
nmos (a, p, c);

 

[glen herrmannsfeldt]

sharp@cadence.com wrote:

On Jun 15, 9:13 am, arpan...@gmail.com wrote:
(snip)

pmos (a, c ? p : q, 1'b0);
(no verilog statements were snipped.)

in this situation what would be the strength of a? will it vary
depending on what the value of c is or should it be set to the greater
of the strengths of p and q?

It will be completely independent of the strengths of c, p and q. As
soon as you connect an expression to the port, you have created an
implicit continuous assignment that evaluates the expression and
drives the port. The output strength of that implicit continuous
assignment will be Strong.
(snip)

I am confused by your reply (which doesn't mean it is wrong).

pmos is a verilog primitive. If you can't connect it to
something else, then it doesn't seem to be useful at all.

In addition, if you can't connect two or more wires with
different drive strength to the same input port it would seem
that there wasn't much use for it. I would expect, then,
that drive strength would go through port connections.
It doesn't have to go through continuous assignment, but
it sure would be convenient if it did.

-- glen

 

[Muzaffer Kal]

On Tue, 17 Jun 2008 02:48:21 -0800, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

sharp@cadence.com wrote:
On Jun 15, 9:13 am, arpan...@gmail.com wrote:
(snip)

pmos (a, c ? p : q, 1'b0);
(no verilog statements were snipped.)

in this situation what would be the strength of a? will it vary
depending on what the value of c is or should it be set to the greater
of the strengths of p and q?

It will be completely independent of the strengths of c, p and q. As
soon as you connect an expression to the port, you have created an
implicit continuous assignment that evaluates the expression and
drives the port. The output strength of that implicit continuous
assignment will be Strong.
(snip)

I am confused by your reply (which doesn't mean it is wrong).

pmos is a verilog primitive. If you can't connect it to
something else, then it doesn't seem to be useful at all.

In addition, if you can't connect two or more wires with
different drive strength to the same input port it would seem
that there wasn't much use for it. I would expect, then,
that drive strength would go through port connections.
It doesn't have to go through continuous assignment, but
it sure would be convenient if it did.

I think the issue is with the port connections. In Verilog port
connections are done with a continuous assignment and the default
strength of a conditional assignment when one is not given is
{strong0,strong1} so your pmos instantiation doesn't do what you need.
You can certainly re-write your data expression in a way which would
transfer the strenghts and accomplish what you want.

 

On Jun 17, 6:48 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

sh...@cadence.com wrote:

pmos is a verilog primitive.  If you can't connect it to
something else, then it doesn't seem to be useful at all.

You can connect it to something else. But if you connect the input to
any expression other than a 1-bit wire (more specifically, a 1-bit
structural net expression), then that expression will be evaluated by
an implicit continuous assignment, which will have a strong output.

What would you have expected for something like

pmos (a, b|c, 1'b0);

The data input is effectively connected to the output of an OR-gate.
It will amplify/buffer its inputs b and c, so that the output drive
strength is independent of the input strengths. The same is true of
any other operator you apply, including the conditional operator.
Aside from the oddity that the conditional operator will pass a z
value, you can think of it as a multiplexer. Like an OR-gate, the
output drive strength of a multiplexer is independent of the input
drive strengths (assuming they are adequate to drive the inputs; this
is not an analog simulator).

In addition, if you can't connect two or more wires with
different drive strength to the same input port it would seem
that there wasn't much use for it.   I would expect, then,
that drive strength would go through port connections.

Port connections are formally defined to behave as continuous
assignments, which would not pass strength. However, when both sides
of the connection are nets, implementations are allowed to collapse
the port, making the nets on both sides become the same net. Since it
is the same net, it has the same value, including strength. This also
makes the port act like an inout port, regardless of how it was
declared.

In fact, implementations almost universally do this, and users rely on
it. If they didn't do this, multi-driver resolution wouldn't work
properly when the drivers were in different modules. The only way to
get it to work would be to declare all the ports in between to be
inout, since inout ports do not behave like continuous assignments.
They are defined to behave like non-strength-reducing transistors,
which is a roundabout way of describing the same basic behavior as
port collapsing.

For the transistor primitives, a connection of a data input to a
single-bit wire must not go through a continuous assignment, or they
would not work properly. I vaguely recall someone proposing LRM text
to this effect, but I don't know whether it was added. An implementor
should be able to figure this out anyway. But if you connect the data
input to an expression, you are back to a continuous assignment.

It doesn't have to go through continuous assignment, but
it sure would be convenient if it did.

I don't agree. How would you define the strengths of the output bits
based on the input bits for something like "assign a = b + c;" anyway?

A continuous assignment is an abstraction for a piece of logic. Even
a simple assignment like "assign b = c;" is (approximately) a buffer.
It does not directly connect b and c together as the same wire. If
you connect another driver to b, it has no effect on c in simulation,
which shows that there is unidirectional buffering going on.
Synthesis tools may end up making them the same wire, but that can be
regarded as an optimization that deletes the buffer because it is
unnecessary in most cases.

 

[glen herrmannsfeldt]

sharp@cadence.com wrote:

On Jun 17, 6:48 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
sh...@cadence.com wrote:

pmos is a verilog primitive. If you can't connect it to
something else, then it doesn't seem to be useful at all.

You can connect it to something else. But if you connect the input to
any expression other than a 1-bit wire (more specifically, a 1-bit
structural net expression), then that expression will be evaluated by
an implicit continuous assignment, which will have a strong output.

What would you have expected for something like

pmos (a, b|c, 1'b0);

The data input is effectively connected to the output of an OR-gate.
It will amplify/buffer its inputs b and c, so that the output drive
strength is independent of the input strengths. The same is true of
any other operator you apply, including the conditional operator.
Aside from the oddity that the conditional operator will pass a z
value, you can think of it as a multiplexer. Like an OR-gate, the
output drive strength of a multiplexer is independent of the input
drive strengths (assuming they are adequate to drive the inputs; this
is not an analog simulator).

Yes, I agree with all those.

In addition, if you can't connect two or more wires with
different drive strength to the same input port it would seem
that there wasn't much use for it. I would expect, then,
that drive strength would go through port connections.

Port connections are formally defined to behave as continuous
assignments, which would not pass strength. However, when both sides
of the connection are nets, implementations are allowed to collapse
the port, making the nets on both sides become the same net. Since it
is the same net, it has the same value, including strength. This also
makes the port act like an inout port, regardless of how it was
declared.

I agree it should be inout if you want it to propagate.
In hardware terms, current has to be able to flow both
directions. You could replace continuous assignment
with tranif, but you can't do anything about ports.

In fact, implementations almost universally do this, and users rely on
it. If they didn't do this, multi-driver resolution wouldn't work
properly when the drivers were in different modules. The only way to
get it to work would be to declare all the ports in between to be
inout, since inout ports do not behave like continuous assignments.
They are defined to behave like non-strength-reducing transistors,
which is a roundabout way of describing the same basic behavior as
port collapsing.

For the transistor primitives, a connection of a data input to a
single-bit wire must not go through a continuous assignment, or they
would not work properly. I vaguely recall someone proposing LRM text
to this effect, but I don't know whether it was added. An implementor
should be able to figure this out anyway. But if you connect the data
input to an expression, you are back to a continuous assignment.

It doesn't have to go through continuous assignment, but
it sure would be convenient if it did.

I don't agree. How would you define the strengths of the output bits
based on the input bits for something like "assign a = b + c;" anyway?

Should tristate gates in modules have the tristate signal
propagate out to the top level module? (And to pins in
the hardware implementation.)

Since some FPGAs can adjust drive strength it would be nice
if it could propagate through ports. Again, tranif can
be used instead of continuous assignment.

A continuous assignment is an abstraction for a piece of logic. Even
a simple assignment like "assign b = c;" is (approximately) a buffer.
It does not directly connect b and c together as the same wire. If
you connect another driver to b, it has no effect on c in simulation,
which shows that there is unidirectional buffering going on.
Synthesis tools may end up making them the same wire, but that can be
regarded as an optimization that deletes the buffer because it is
unnecessary in most cases.

It is nice sometimes to use it as a wire connection, though.
Even so, FPGAs will often add buffers where they don't exist
in the design. Even more, it is supposed to be that current
FPGA tools fake tristate signals through logic such that no
actual tristate line exists. As FPGAs get bigger, more
buffering is needed such that you can't really drive a
long tristate line anymore. It is nice, though, if the
tools can propagate it to the output drivers through
ports. I think my main point is that port connections
sometimes are different from continuous assignment,
especially in the case of tristate lines.

-- glen