[sv-bc] FW: Mantis 1465

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Sun Mar 02 2008 - 02:21:37 PST
resend

> ______________________________________________ 
> From: 	Bresticker, Shalom  
> Sent:	Sunday, March 02, 2008 9:39 AM
> To:	sv-bc
> Subject:	Mantis 1465
> 
> Hi,
> 
> Neil said we can work on Mantis 1465, as it is covered by the
> Champions' feedback on Mantis 1340.
> 
> The original description of 1465 is:
> ================================================================
> 19.8 (in 1800-2005, 22.2.2.3 in D4) states,
> 
> "For the first port, if neither a type nor a direction is specified,
> then it shall be assumed to be a member of a port list, and any port
> direction or type declarations must be declared after the port list.
> This is compatible with the Verilog-1995 syntax. If the first port
> kind or data type is specified, but no direction is specified, then
> the port direction shall default to inout. If the first port direction
> is specified, but no port kind or data type is specified, then the
> port shall default to a net of net type wire. This default net type
> can be changed using the `default_nettype compiler directive, as in
> Verilog.
> 
> // Any declarations must follow the port list because first port does
> not
> // have either a direction or type specified; Port directions default
> to inout
> 
> module mh4(x, y);
> wire x;
> tri0 y;
> ...
> endmodule"
> 
> This example and the code comments show a case which is not discussed
> in the text. 
> 
> This example shows a case where neither a type nor a direction is
> specified for the first port. The text only says that "any port
> direction or type direction must be declared after the port list".
> 
> The example shows that the port declarations are omitted completely.
> There are only net declarations. The text does not say that you can do
> this.
> 
> Similarly, the code comment says that in this case, the port
> directions default to inout. The normative text does not say this,
> either. The text only says this for the case where the first port kind
> or data type is specified.
> ================================================================
> 
> Additional information:
> 
> The sentence about compatibility with Verilog-1995 was removed by the
> editor in the merged LRM. 
> 
> The text comes from SV 3.0. The original example was slightly
> different:
> module mh4(x, y);
> int x;
> char y;
> ...
> endmodule
> 
> None of the simulators I tried allowed the example shown in 1800-2005.
> All complained that port declarations were missing.
> 
> Should the LRM continue to allow it? Or should we remove the example?
> Since few, if any, tools seem to support it, I doubt it would be a
> significant back-compatibility problem. I would be happier to remove
> it.
> 
> If it *is* allowed, it should be described in the subclause on
> non-ANSI style port declarations (22.2.2.1 in D4). The following text
> from 22.2.2.1 contradicts the text from 22.2.2.3:
> 
> "Each port_identifier in a port_expression in the list of ports for
> the module declaration shall also be declared in the body of the
> module as one of the following port declarations: input, output, or
> inout (bidirectional). This is in addition to any other data type
> declaration for a particular port."
> 
> This says that there must be a port declaration whereas the example
> says that it can be omitted sometimes and then a default applies. 
> 
> This sentence does need to be updated to include ref ports and
> interface ports.
> 
> If we have consensus, I can write a proposal.
> 
> Thanks,
> Shalom
> 
> Shalom Bresticker
> Intel Jerusalem LAD DA
> +972 2 589-6582
> +972 54 721-1033
> 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Sun Mar 2 17:08:48 2008

This archive was generated by hypermail 2.1.8 : Sun Mar 02 2008 - 17:09:36 PST