RE: [sv-bc] Mantis 1465

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Sun Mar 16 2008 - 02:03:30 PDT
Hi,
 
Yet another revision of the proposal for 1465.
Changes from the previous version are mostly in the examples and a
little in the formatting. I did not change the rules in this version. I
have tried to go by the motto of "Make everything as simple as possible
but no simpler."
 
This proposal defines a new BNF production
implicit_data_type ::= [ signing ] { packed_dimension }

and uses it in data_type_or_implicit and function_data_type_or_implicit.

 [ signing ] { packed_dimension } also appears in 

data_type ::=
    integer_vector_type [ signing ] { packed_dimension }
    ...

enum_base_type ::=
      integer_atom_type [ signing ]
    | integer_vector_type [ signing ] [ packed_dimension ]
    ...

but I had a doubt whether "implicit_data_type" was an appropriate name
there, so I did not use it in those places. If the committee wants it in
those places as well, I have no objections.

Thanks,

Shalom


________________________________

	From: Bresticker, Shalom 
	Sent: Friday, March 14, 2008 3:48 PM
	To: danielm; sv-bc@server.eda.org
	Subject: RE: [sv-bc] Mantis 1465
	
	
	Here is a revised version.
	I made substantial changes in the main section, so you should
review it completely.
	 
	Thanks,
	Shalom


________________________________

		From: owner-sv-bc@server.eda.org
[mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom
		Sent: Friday, March 14, 2008 12:52 PM
		To: danielm; sv-bc@server.eda.org
		Subject: RE: [sv-bc] Mantis 1465
		
		
		Daniel,
		 
		Thanks for your comments.
		 
		Let me try to respond to them.


________________________________

			From: danielm [mailto:danielm@aldec.com.pl] 
			Sent: Friday, March 14, 2008 12:10 PM
			To: Bresticker, Shalom; sv-bc@server.eda.org
			Subject: RE: [sv-bc] Mantis 1465
			
			
			1. There is lot of examples in this proposal,
but they are still not complete. If it it decided to add all those
examples I think that for clearence there should more of them (if they
are ommited user may be confused):
			 
			module mh4(input var x);          // input
variable logic x
			[SB] OK 
			
			module mh4(var x);          // input variable
logic x
			[SB] I think this should be illegal. Direction
defaults to inout, and inout cannot be var. 
			
			module mh4(input var integer x);          //
input variable integer x
			[SB] OK 
			 
			module mh2(var integer x);        // ERROR
			[SB] OK 

			 module mh2(inout var integer x);        //
ERROR
			[SB] OK 

			 

			 

			2.There is :

			"If the port kind is omitted, it shall be
determined as specified below."

			 

			While below we have some examples. IMHO this
should be specified more precise where described rules can be found.
			[SB] This refers to the paragraph beginning, "If
the port kind is omitted and not inherited from the previous port:" 

			 

			 

			3.There is:

			"-          If the direction is present, but the
port kind and data type are omitted, then the port shall default to a
net of default net type."

			 

			Is it true? IE: above rule will cause that y is
a net, IMHO it should be a var. Aboce rule also do no define what happen
with data type

			module mh6(input x, output y);     

			So the rulse should be :

			"-          If the direction is present, but the
port kind and data type are omitted, then the port shall default to
logic type, and kind should be default for defined direction.(as
described .....)"
			[SB] I believe the statement is correct.
"input/output/inout x" should always be a net.

			There is one exception, if the direction is ref,
it should be a variable. I need to fix that.

			The data type is covered by the statement that
appears afterwards, "If the data type is omitted and not inherited from
the previous port, the data type shall default to logic." 

			 

			 

			 

			4. There is:

			"-          If the data type is present, but the
port kind is omitted, then the port kind shall be determined as
specified below."

			Where is below????

		[SB] This refers to the paragraph beginning, "If the
port kind is omitted and not inherited from the previous port:" 

			 

			Summary for subsequent port:

			*	
				direction is always inherited?
				[SB] Unless explicit. 
			*	
				kind is inherited only when all
direction, kind and type are ommitted?
				[SB] I believe so. 
			*	
				type is inherited only when all
direction, kind and type are ommitted?
				[SB] I believe so.

			Thanks for your feedback,
			Shalom 

	
---------------------------------------------------------------------
		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. 

---------------------------------------------------------------------
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 16 02:15:31 2008

This archive was generated by hypermail 2.1.8 : Sun Mar 16 2008 - 02:16:14 PDT