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

From: Rich, Dave <Dave_Rich_at_.....>
Date: Fri Nov 13 2009 - 13:25:21 PST
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] 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; 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] On Behalf Of Dhiraj Kumar
Prasad
	Sent: Friday, November 13, 2009 11:35 AM
	To: 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, and is
believed to be clean.
Received on Fri Nov 13 13:27:02 2009

This archive was generated by hypermail 2.1.8 : Fri Nov 13 2009 - 13:27:53 PST