constant connected to instance output

[Saurabh Verma]

Hi,
I am cofused with the use of constant at instance output. For
following examples:

suppose there is a module:
---------------
module master(out, in);
output out;
input in;
---------------
If we instantiate the above module in following way:
1.
reg a;
master inst1(1'b1, a);

2.
wire w1,w2;
master inst2(w1, w2);

3.
supply0 s1;
reg r1;
master inst3(s1, r1);


In above cases, '2' is OK, but what is the meaning of cases '1' and
'3', where we connect a constant to the output terminal. VCS doesn't
give any syntax error for this. What is the idea behind supporting
this kind of syntax.

Is it just for doing experiments with smulation, when we don't want to
see the output, but, just see the singal inside module through
hierarchical reference ..


--Thanks and Regards,
saurabh

 

[Steven Sharp]

saurabh_verma78@yahoo.com (Saurabh Verma) wrote in message news:<58c50fc8.0404292317.6f9a10ea@posting.google.com>...

In above cases, '2' is OK, but what is the meaning of cases '1' and
'3', where we connect a constant to the output terminal. VCS doesn't
give any syntax error for this. What is the idea behind supporting
this kind of syntax.

I would consider case 1 to be illegal (and so does Verilog-XL, which
was the first de facto standard for Verilog). However, directionality
of ports in Verilog is not strongly enforced (in fact, in some cases
the standard requires simulators to overrule the declared direction,
or produce a warning if they don't). So VCS may have decided to do
something similar and force the port to be treated as an input instead
of an output. Or they may just have failed to check the port at all.

Case 3 is legal because a supply net is not a constant. It is a net
that already has an implicit driver of supply strength on it. It is
very similar to a tri0 or tri1 net, which are nets that have an implicit
driver of pull strength on them, and those are legal on output ports.

The only difference is that the implicit driver on a supply net is of
supply strength, so it is too powerful for any other driver to overcome.
This makes it effectively a constant for most practical purposes, so
you have started thinking that it is one. There are ways to see that
it is not. You can declare your own driver of supply strength and drive
the opposite value onto the supply net, in which case contention will
cause the value of the supply net to go to X. That clearly shows that
it is not a constant. And if the driver is on the inside of an output
port, that shows how something can drive a value out through the
output port onto the supply net. You can also do an explicit continuous
assignment to a supply net, because it is a net. You can't do that to
a constant.

It is possible that your simulator will not correctly show these
behaviors of a supply net. The implementers may have decided that
this aspect of supply net behavior is not important, and treated it
as a constant to allow better optimization. If so, they are technically
wrong, though it probably doesn't matter to anyone. They might even
have allowed constants on output ports precisely because they wanted to
treat supply nets as constants but had to allow them on output ports.

 

[Saurabh Verma]

sharp@cadence.com (Steven Sharp) wrote in message news:<3a8e124e.0404300939.613975a5@posting.google.com>...

saurabh_verma78@yahoo.com (Saurabh Verma) wrote in message news:<58c50fc8.0404292317.6f9a10ea@posting.google.com>...

In above cases, '2' is OK, but what is the meaning of cases '1' and
'3', where we connect a constant to the output terminal. VCS doesn't
give any syntax error for this. What is the idea behind supporting
this kind of syntax.

I would consider case 1 to be illegal (and so does Verilog-XL, which
was the first de facto standard for Verilog). However, directionality
of ports in Verilog is not strongly enforced (in fact, in some cases
the standard requires simulators to overrule the declared direction,
or produce a warning if they don't). So VCS may have decided to do
something similar and force the port to be treated as an input instead
of an output. Or they may just have failed to check the port at all.

Case 3 is legal because a supply net is not a constant. It is a net
that already has an implicit driver of supply strength on it. It is
very similar to a tri0 or tri1 net, which are nets that have an implicit
driver of pull strength on them, and those are legal on output ports.

The only difference is that the implicit driver on a supply net is of
supply strength, so it is too powerful for any other driver to overcome.
This makes it effectively a constant for most practical purposes, so
you have started thinking that it is one. There are ways to see that
it is not. You can declare your own driver of supply strength and drive
the opposite value onto the supply net, in which case contention will
cause the value of the supply net to go to X. That clearly shows that
it is not a constant. And if the driver is on the inside of an output
port, that shows how something can drive a value out through the
output port onto the supply net. You can also do an explicit continuous
assignment to a supply net, because it is a net. You can't do that to
a constant.

It is possible that your simulator will not correctly show these
behaviors of a supply net. The implementers may have decided that
this aspect of supply net behavior is not important, and treated it
as a constant to allow better optimization. If so, they are technically
wrong, though it probably doesn't matter to anyone. They might even
have allowed constants on output ports precisely because they wanted to
treat supply nets as constants but had to allow them on output ports.

Hi Steven,
Thanks a lot!! Its understandable.
I don't use simulators very often, but whenever get a chance will run
something to see advantage of this feature given to supply net. I mean
in some scenario it should be very helpful than just using a constant
or a wire.

Thanks,
saurabh