RE: [sv-bc] assignment to input

Yulik says this statement leaves him confused as to the actual meaning,
so based just on that we should clarify the text in the next round.

I fully admit that I am contaminated from years of using and creating
Verilog tools, so I am already well aware of the sad fact that the
'input' and 'output' and to a lesser extent 'inout' are merely advisory,
all equivalent to perhaps 'port' (because you need to use one of them in
order to use the item in a port list :-), and hence when I read 12.3.8 I
understand the issue it refers to.

I will note further that the false economy of using "input (output)" to
imply the reflexiveness of the issue does not decrease the confusion
factor.

One direction for the group to consider is to deprecating the lack of
enforcement of forbidding writing to inputs.

We would have to consider whether to apply this restriction as well to
preventing a force or procedural continuous assign to an input.  

I personally like the ability to read from outputs, and find other
languages that forbid this to be not helpful.  The one clear case where
reading from an output is quite useful is in a $display or $monitor of
the signals in a module.

Another direction is to include Yulik's example, with a statement that
this is legal.  An intermediate point between the two is to include the
example with that statement that this is not illegal, but is allowed due
to legacy reasons.

All opinions expressed herein are mine
mcnamara@cadence.com
 

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Don
Mills
Sent: Tuesday, August 29, 2006 9:44 AM
To: Feldman,Yulik; Brad Pierce; sv-bc@eda-stds.org
Subject: RE: [sv-bc] assignment to input

I believe that the 1364-2005 does specifily note this senerio

12.3.8 Connecting dissimilar ports
...
A port that is declared as input (output) but used as an output (input)
or inout may be coerced to inout. If not coerced to inout, a warning has
to be issued.


I realize that this discussion group is SV but don't we still need to be
consistant unless otherwise noted.

dm

-----Original Message-----
>From: "Feldman, Yulik" <yulik.feldman@intel.com>
>Sent: Aug 29, 2006 8:35 AM
>To: Brad Pierce <Brad.Pierce@synopsys.com>, sv-bc@server.eda-stds.org
>Subject: RE: [sv-bc] assignment to input
>
>I just want to emphasize that the original issue I wanted to raise is 
>that the LRM doesn't specify whether the assignments to inputs are 
>legal, like in:
>
> 
>
>module m(input wire a);
>
>assign a = '0;
>
>endmodule
>
> 
>
>The connection to the port collapsing happened only indirectly, since 
>the only place in LRM that seems to be trying to give an answer to that

>question is within the section that discusses port collapsing. The 
>references to discussions on that subject are interesting, but are not 
>directly related to the original issue.
>
> 
>
>Regarding the original issue, one may argue that such assignments 
>should be considered legal, since LRM doesn't say the opposite. If this

>is the case, it is still not clear what the semantics is. Since the 
>allowance of such assignments is counter-intuitive (at least for the 
>first-time reader), and semantics is questionable, the intention should

>be clearly explained, to avoid confusion.
>
> 
>
>--Yulik.
>
> 
>
>________________________________
>
>From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On

>Behalf Of Brad Pierce
>Sent: Tuesday, August 29, 2006 5:52 PM
>To: sv-bc@server.eda-stds.org
>Subject: RE: [sv-bc] assignment to input
>
> 
>
>This issue seems related to --
>
> 
>
>     http://www.boyd.com/1364_btf/report/full_pr/54.html
>
> 
>
>such as
>
> 
>
>     http://boydtechinc.com/btf/archive/btf_2001/1595.html
>
> 
>
>-- Brad
>
>    
>
> 
>
>________________________________
>
>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of 
>Feldman, Yulik
>Sent: Tuesday, August 29, 2006 5:46 AM
>To: sv-bc@eda-stds.org
>Subject: [sv-bc] assignment to input
>
>I've opened this as 1573. As soon as this mail arrives to the 
>reflector, I'll add a link to it to the ticket.
>
> 
>
>--Yulik.
>
> 
>
>________________________________
>
>From: Bresticker, Shalom
>Sent: Tuesday, August 29, 2006 3:23 PM
>To: Feldman, Yulik
>Cc: Bresticker, Shalom
>Subject: RE: assignment to input
>
> 
>
>I agree that the wording is confusing. One could ask, what does "used 
>as output" mean?
>
> 
>
>However, the well-known (and unfortunate) behavior is that assignments 
>to inputs are allowed. For many tools, the significance of the port 
>direction is limited to the determination of what can be connected to 
>it, whether just net or also reg. The coercion question affects 
>whether, if you assign to an input, is this assignment reflected 
>outside the module as well or just stay inside? A Mantis would be a 
>good idea, I think, both to clear up the ambiguities, and maybe propose

>to not allow this, though it would cause problems with legacy code.
>
> 
>
>Shalom
>
> 
>
>________________________________
>
>From: Feldman, Yulik
>Sent: Tuesday, August 29, 2006 11:25 AM
>To: Bresticker, Shalom
>Subject: assignment to input
>
> 
>
>Hi Shalom,
>
> 
>
>What do you think, should the assignments to input ports be allowed, or

>not? The only relevant reference to that in LRM that I know is in
>1364-2005 Section 12.3.8 "Connecting dissimilar ports", which says: "A 
>port that is declared as input (output) but used as an output (input) 
>or inout may be coerced to inout. If not coerced to inout, a warning 
>has to be issued". However, it is not clear whether this section talks 
>about connections between pairs of ports or about the general usages of

>ports in any other constructs, like in continuous assignments. So, it 
>is quite confusing. Do you think there is a need to open Mantis on this

>ambiguity, or I'm missing something?
>
> 
>
>Thanks,
>
>            Yulik.
>
> 
>


==========================================================
Don Mills
LCDM Engineering     (Logic, Coding, & Design Methodology) 
mills@lcdm-eng.com                        www.lcdm-eng.com
==========================================================