RE: [sv-bc] Query related with explicit name port declaration.

There is also an apparent inconsistency between the specification of direction for non-ANSI and ANSI ports.
For non-ANSI port style, we have the following example in 23.2.2.1 Example 7:

Example 7-Explicitly named port with mix of input and output directions (non-ANSI style module header)module mixed_direction (.p({a, e}));
input a; // p contains both input and output directions.
output e;

Here the direction is specified for a and e, rather than p, and in fact, a and e have different directions.
23.2.2.2 has the following example for ANSI style port declarations:

module mymod (
output .P1(r[3:0]),
output .P2(r[7:4]),
ref .Y(x),
input R );logic [7:0] r;
int x;
...
endmodule

This at least gives the impression that the direction is declared for P1 and P2, not for r. This in fact would not allow mixed directions within a single port, as in the non-ANSI example, but it does allow half of r to be declared as output and half to be declared as input, which is not possible with the non-ANSI port style.

Shalom

________________________________
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Rich, Dave
Sent: Saturday, November 14, 2009 12:10 AM
To: Greg Jaxon
Cc: Dhiraj Kumar Prasad; sv-bc@server.eda.org
Subject: RE: [sv-bc] Query related with explicit name port declaration.

Greg,

The LRM say this about port expressions:

The self-determined type of the port expression becomes the type for the port.

So the type of P1 is indeed int.



________________________________
From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com]
Sent: Friday, November 13, 2009 1:54 PM
To: Rich, Dave
Cc: Dhiraj Kumar Prasad; sv-bc@eda.org
Subject: Re: [sv-bc] Query related with explicit name port declaration.

So your answer would differ from mine; you'd make q be  output int,  right?

While I can see how the LRM text leads you to that conclusion, it violates a principle of definition-before-use.
Ansi-style declaration is being succinct here by using a grammatical "distribution" trick.
I believe that distribution pattern is interrupted by the (typeless) named port.
The port .P1(r) has not actually introduced int type into the Ansi-style's grammar rule.
int is the type of r, not of P1, which might have as easily been .P1({r,s,t})
It's really made the prevailing type be "unknown" (extended on credit until "int r;" & cetera are parsed).
Under that reading, type inheritance fails and the question would be whether we skip back to "byte"
or revert to "logic" (the usual default).  I've already given my opinion.

Greg

Rich, Dave wrote:
Greg,

I wish we didn't have all these implicit defaults, but we've got them and the rules are straightforward.

For subsequent ports in the port list:
- If the direction, port kind and data type are all omitted, then they shall be inherited from the previous
port..
Otherwise

- If the direction is omitted, it shall be inherited from the previous port.
- If the port kind is omitted, it shall be determined as specified above.
- If the data type is omitted, it shall default to logic.

Therefore P! is an output because its direction was omitted, and its type/kind are taken from r.

Since q's direction, port kind and data type are all omitted, then they are all inherited P1. I agree that's probably not the user's intent, but that's what they get for being LAZY.

Dave

________________________________
From: owner-sv-bc@server.eda.org<mailto:owner-sv-bc@server.eda.org> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Greg Jaxon
Sent: Friday, November 13, 2009 12:18 PM
To: Bresticker, Shalom
Cc: Dhiraj Kumar Prasad; sv-bc@server.eda.org<mailto:sv-bc@server.eda.org>; Surya Pratik Saha
Subject: Re: [sv-bc] Query related with explicit name port declaration.


Shalom, Dhiraj,



   Shalom is right about this syntax being illegal, but he's ducking the real

question about how named ports interact with ansi_port_declaration carryforward

of port_direction and net/variable/interface_port_header specifications.



module mod(output byte character, .P1(r), q);

   int  r;

endmodule



Do we need to specify direction for r?

Is specifying "int" type for r consistent with the "byte" type which seems to reach it?

What is the type of q?  byte, or logic?  Surely not int!


While implementing here recently I came to the opinion that the BNF is suggesting

that type info is lost, but that direction info can be carried through.

That gives the answers 1) NO, 2) YES, 3) output logic to my three questions.


Bresticker, Shalom wrote:

I think this is not legal syntax, to specify a data type with an explicit port declaration:



ansi_port_declaration ::=

  [ net_port_header | interface_port_header ] port_identifier { unpacked_dimension }[ = constant_expression ]

| [ variable_port_header ] port_identifier { variable_dimension } [ = constant_expression ]

| [ port_direction ] . port_identifier ( [ expression ] )



The BNF seems to allow only the port direction.



Shalom







-----Original Message-----

From: owner-sv-bc@server.eda.org<mailto:owner-sv-bc@server.eda.org>

[mailto:owner-sv-bc@server.eda.org] On Behalf Of Dhiraj Kumar Prasad

Sent: Friday, November 13, 2009 11:35 AM

To: sv-bc@server.eda.org<mailto:sv-bc@server.eda.org>

Cc: Surya Pratik Saha

Subject: [sv-bc] Query related with explicit name port declaration.



Hello,



I have a query related with  explicit name port declaration.



For example



module mod(output logic .P1(r));

   int  r;

endmodule



In above testcases once a type is specified with port then is

this(logic

here) will be regarded

as type of  "r" ??



If yes then does the redefinition of variable "r" should be

treated as

illegal as the name

is previously declared.



If not then what is the significance of specifying explicit data

type(logic here) with port .



Different standard tools are behaving in  different way.



Regards,

dhiRAj



---------------------------------------------------------------------

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<http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
---------------------------------------------------------------------
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.