FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > Verilog

Verilog comp.lang.verilog newsgroup / usenet

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 04-30-2004, 08:17 AM
Saurabh Verma
Guest
 
Posts: n/a
Default constant connected to instance output

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
Reply With Quote
  #2 (permalink)  
Old 04-30-2004, 06:39 PM
Steven Sharp
Guest
 
Posts: n/a
Default Re: constant connected to instance output

[email protected] (Saurabh Verma) wrote in message news:<[email protected] 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.
Reply With Quote
  #3 (permalink)  
Old 05-06-2004, 12:54 AM
Saurabh Verma
Guest
 
Posts: n/a
Default Re: constant connected to instance output

[email protected] (Steven Sharp) wrote in message news:<[email protected] com>...
> [email protected] (Saurabh Verma) wrote in message news:<[email protected] 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
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: verilog instance name length DSLuser Verilog 0 06-28-2003 05:21 AM


All times are GMT +1. The time now is 07:03 AM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved