| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 54
|
| Category | errata
|
| Synopsis | 5.6.6 Port connections - inaccurate description
|
| State | open
|
| Class | errata-discuss
|
| Arrival-Date | Oct 16 2001
|
| Originator | Shalom.Bresticker@motorola.com
|
| Release | 2001b, 5.6.6, 12.3.9.2, 12.3.8
|
| Environment |
|
| Description |
Date: Mon, 15 Oct 2001 15:50:58 +0200 From: Shalom Bresticker <Shalom_Bresticker-R50386@email.mot.com> I have a question: 5.6.6 says that "Ports connect processes through implicit continuous assignment statements or implicit bidirectional connections ... Ports can always be represented as declared objects connected as follows: If an input port, then a continuous assignment from an outside expression to a local (input) net ..." Regarding strengths of continuous assignments, 6.1.4 says, at the end, "If drive strength is not specified, it shall default to (strong1, strong0)." If I put these two sections together, it implies that an input port will always be strong. However, we know and see that this is not so. That is, if I drive a net weakly and connect it to an input port of another module, that input port will also have a weak strength. I attach an example. Explanations ? module qq ; wire rr ; assign (weak1, weak0) rr = 1'b1 ; pp pp (rr ) ; endmodule module pp ( rr ) ; input rr ; initial #10 $display ("%v", rr ) ; endmodule Date: Mon, 15 Oct 2001 15:12:32 +0100 From: Daryl Stewart <Daryl.Stewart@cl.cam.ac.uk> I haven't done much work with wire strengths but I think the answer has something to do with "Port Collapsing". The (antique) verilog LRM (Nov 91) has a section (12.4.6) explaining that "Wherever it is possible, some tools collapse port connections during processing -- that is, the two items become one entity." This was omitted from IEEE standards for some reason, but is still observable. It would seem that in your example, since the port is a simple connection between two similar wires they can be collapsed to one, instead of being represented by a continuous assignment as the new standard claims. I have a draft description of an analysis of port connections at http://www.cl.cam.ac.uk/users/djs1002/verilog.project/papers/combining_signals. ps.gz which hilights some other consequences of port collapsing such as allowing assignments to the "wrong" side of a directional port... I did the work while ignorant of port collapsing, which was brought to my attention by Michael McNamara (I think) It's a pretty old paper - a newer description is in my thesis, currently being examined... There's a similarly old paper about wires which is relevant to errata 48 if you're interested: http://www.cl.cam.ac.uk/users/djs1002/verilog.project/papers/combining_signals. ps.gz Date: Mon, 15 Oct 2001 16:19:08 +0200 From: Shalom Bresticker <Shalom_Bresticker-R50386@email.mot.com> Organization: Motorola Semiconductor Israel, Ltd. (MSIL) Yes, port collapsing is obviously what really happens. It saves the simulator a lot of time and memory. My problem is that it seems to contradict what we wrote in 5.6.6, which does not mention port collapsing. Collapsing is still mentioned in 12.3.10, I see, which I have not read in detail. I fear 5.6.6 is inconsistent with 12.3.10. Thanks for the references. I think I remember your old paper. I think I even read it, although I did not have time to consider it in detail. Date: Mon, 15 Oct 2001 15:33:17 +0100 From: Daryl Stewart <Daryl.Stewart@cl.cam.ac.uk> I agree with your concerns. I agree that 5.6.6 is contradictory wrt 12.3.10 12.3.9.2 Rule 2 is also contradictory in its use of the mandatory "shall": "Each port connection shall be a continuous assignment of source to sink where one connected item shall be a signal source and the other shall be a signal sink. The assignment shall be a continuous assignment from source to sink for input or output ports." I had completely missed the line in 12.3.10! Perhaps a reference to it in 5.6.6? Notice also that if the continuous assignment description is fiddled about by errata 48 then it affects port connections because of the distinctions between net and driver delays it introduces... That's one of the reasons I did the work I mentioned before... Date: Mon, 15 Oct 2001 16:25:06 -0400 (EDT) From: Steven Sharp <sharp@cadence.com> Short answer: the standard is wrong. The 1995 standard was supposed to match XL, but does not describe port collapsing. Note that port collapsing is done at the discretion of the tool. Whether it is done is affected by too many complex and tool-specific factors to be specified in a standard. Perhaps this is why it was omitted. It would have been better to have specified that collapsing is allowed. The standard does make a sort of reference to collapsing. It states that if a port direction has been declared with a direction that does not match the actual direction, it may be coerced to inout. If it is not coerced, a warning must be issued. Coercing to inout is the effective result of port collapsing. This is actually a poor attempt to describe port collapsing. This is in section 12.3.6 in the 1995 standard. -- ************************************************************************** Shalom Bresticker Shalom.Bresticker@motorola.com Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268 P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890 ************************************************************************** |
| Fix |
No detailed solution yet proposed. The DB contains all discussion to date. |
| Audit-Trail |
From: "Brad Pierce" <Brad.Pierce@synopsys.com> To: <etf-bugs@boyd.com> Cc: Subject: Re: errata/54: 5.6.6 Port connections - inaccurate description Date: Tue, 26 Nov 2002 14:05:26 -0800 In the last sentence of its first paragraph, section 5.6.6 says -- "Port connection rules require that a value receiver be a net or a structural net expression." Are there structural net expressions that are not nets? If not, we should remove "a net or" here. According to section 12.3.8, "Examination of the port connection rules described in 12.3.9 will show that the item receiving the value through the port (the internal item for inputs, the external item for outputs) shall be a structural net expression." No "a net or". Is it also true that the external item for inouts shall be a structural net expression? If so, the above parenthetical remark in 12.3.8 should be modified to "(the internal item for inputs, the external item for outputs and inouts)" -- Brad From: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com, Brad.Pierce@synopsys.com Cc: Subject: Re: errata/54: 5.6.6 Port connections - inaccurate description Date: Tue, 26 Nov 2002 18:51:51 -0500 (EST) > In the last sentence of its first paragraph, section 5.6.6 says -- > > "Port connection rules require that a value receiver be > a net or a structural net expression." > > Are there structural net expressions that are not nets? If not, > we should remove "a net or" here. I assume that "structural net expressions" refers to nets, constant-index bit-selects and part-selects of nets, and concatenations of structural net expressions. So you could remove "a net or", unless one assumes that a simple net identifier isn't an expression. > According to section 12.3.8, > > "Examination of the port connection rules described in 12.3.9 > will show that the item receiving the value through the port > (the internal item for inputs, the external item for outputs) > shall be a structural net expression." > > No "a net or". > > Is it also true that the external item for inouts shall be a > structural net expression? If so, the above parenthetical remark > in 12.3.8 should be modified to > > "(the internal item for inputs, the external item for outputs > and inouts)" Both the internal and external items for inouts should be structural net expressions. Steven Sharp sharp@cadence.com From: "Brad Pierce" <Brad.Pierce@synopsys.com> To: <etf-bugs@boyd.com> Cc: Subject: Re: errata/54: 5.6.6 Port connections - inaccurate description Date: Tue, 26 Nov 2002 18:39:14 -0800 In the note at the end of section 12.3.8, the LRM 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." And after issuing the warning, then what? Unless it's intended that the message be a fatal error, something more must still happen. What is the correct behavior if the port is not coerced to inout? Moreover, contrary to the note, directions are not really declared on ports, but instead are declared on the port identifiers within port expressions. If the port expression is a concatenation, but the port identifiers within it are declared with mixed directions, such as half input and half output, what is the direction of the port? module m (.p({a,b})) ; input a; output b; not(b,a); endmodule To me, it seems like either p is being declared here as an inout (no coercion involved) or this is an error. Yet I don't see any place in the standard that speaks to this. And the function acc_fetch_direction() would return "accMixedIo" for port p. According to Table 139, there are four kinds of port direction -- Input only Output only Bidirectional (input and output) A concatenation of input ports and output ports But I don't see this fourth kind of port direction mentioned anywhere else in the LRM. -- Brad From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: etf-bugs@boyd.com Cc: Subject: Re: errata/54: 5.6.6 Port connections - inaccurate description Date: Wed, 27 Nov 2002 08:46:47 +0200 12.3.9.2 says, "A structural net expression is a port expression whose operands can be the following: A scalar net A vector net A constant bit-select of a vector net A part-select of a vector net A concatenation of structural net expressions" so "net" is included in "structural net expression". After we figure out what to do about these problematic "implicit continuous assignments", I think 5.6.6 should just refer to 12.3.8-10. Shalom > > In the last sentence of its first paragraph, section 5.6.6 says -- > > > > "Port connection rules require that a value receiver be > > a net or a structural net expression." > > > > Are there structural net expressions that are not nets? If not, > > we should remove "a net or" here. > > I assume that "structural net expressions" refers to nets, constant-index > bit-selects and part-selects of nets, and concatenations of structural net > expressions. So you could remove "a net or", unless one assumes that a > simple net identifier isn't an expression. > > > According to section 12.3.8, > > > > "Examination of the port connection rules described in 12.3.9 > > will show that the item receiving the value through the port > > (the internal item for inputs, the external item for outputs) > > shall be a structural net expression." > > > > No "a net or". > > > > Is it also true that the external item for inouts shall be a > > structural net expression? If so, the above parenthetical remark > > in 12.3.8 should be modified to > > > > "(the internal item for inputs, the external item for outputs > > and inouts)" > > Both the internal and external items for inouts should be structural > net expressions. > > Steven Sharp > sharp@cadence.com > -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 "The devil is in the details." From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: etf-bugs@boyd.com Cc: Subject: Re: errata/54: 5.6.6 Port connections - inaccurate description Date: Wed, 27 Nov 2002 08:48:57 +0200 Also see issue #198. |
| Unformatted |
|
Hosted by Boyd Technology