RE: [sv-bc] confusion in determining the type of an self determined binary expression during evalution of type operator

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Sun Oct 21 2007 - 03:19:32 PDT
Hi, Yulik.
 
Regarding Table 10-1: That table is legacy from 1364, where what could
appear even on the LHS of a procedural assignment was limited. For
example, although V2K1 added multidimensional arrays, it still did not
allow an entire array or an array slice to be assigned. And of course,
the LHS of a continuous assignment could only be a net, not a variable.
 
Maybe it would be better, instead of trying to list all the
possibilities (though Mantis 2072 contains an attempt to do so), to just
say generally that the LHS of a procedural assignment can be a variable,
select thereof, or a concatenation or assignment pattern of such. And
the LHS of a continuous assignment can be a net or variable, constant
select thereof, or a concatenation or assignment pattern thereof. (Are
those statements correct?)
 
Regarding the list of operands in 11.2: That is another legacy from 1364
that the editor attempted to update. See Mantis 2074.
 
I don't think it is correct to 'add "array slice" at almost every place
where "bit-select" or "part-select" is used'. The reason is that many,
if not most, of those places are where a singular operand is required,
whereas an array slice is an aggregate.
 
One of the reasons for the attempts to specify precisely what constructs
are allowed is that not every type of select is allowed everywhere. For
example, bit-selects are allowed on packed structures, but not on
unpacked structures. 
 
So one has to be careful about generalizing the terminology.
 
Nevertheless, I do agree with much of what you say, for example, that
the description of part-select syntax in 11.5.1 applies as well to array
slice syntax.
 
Regards,
Shalom



________________________________

	From: Feldman, Yulik 
	Sent: Saturday, October 20, 2007 10:35 PM
	To: Feldman, Yulik; Bresticker, Shalom
	Cc: sv-bc@server.eda.org
	Subject: RE: [sv-bc] confusion in determining the type of an
self determined binary expression during evalution of type operator
	
	

	Disregard the part about parameters; I have been thinking about
type parameters for a moment, but they are obviously irrelevant here.

	 

	
________________________________


	From: owner-sv-bc@server.eda.org
[mailto:owner-sv-bc@server.eda.org] On Behalf Of Feldman, Yulik
	Sent: Saturday, October 20, 2007 9:38 PM
	To: Bresticker, Shalom
	Cc: sv-bc@server.eda.org
	Subject: RE: [sv-bc] confusion in determining the type of an
self determined binary expression during evalution of type operator

	 

	What you have mentioned in 2072 is exactly what I meant by an
improper use of the terms. One way to look on it is to say that the
usage of "bit-select" and "part-select" is OK and that the references to
other kinds of selects are just missing (your interpretation), and the
other way to look on it is to say that the terms were misused, and more
general terms should have been used instead (my interpretation). I
believe it would be better if more general terms were used were
appropriate, instead of adding "and array slice" or the like at almost
every place where "bit-select" or "part-select" is used.

	 

	Here are a few quick random additional picks of the
"part-select" term usage in the LRM:

	 

	*         11.2 says "An operand can be one of the following":
"Parameter bit select or part select". What about parameters whose type
is multidimensional array? (BTW, it is unrelated, but I have just
noticed that the list contains "Any net type" twice for some reason ;)).

	*         The same list says "Packed array, structure or union
bit-select, part-select, element or slice". Wouldn't it be much simpler
to use a single general term here? BTW, the whole list could be made
much shorter, if just a general term would be used.

	*         11.2.1 again talks about bit-select and part selects
of parameters, not noticing other kinds of selects.

	*         11.5: slices are not referred to. Aren't they
operands?

	*         11.5.1: doesn't these rules apply to slices?

	*         22.2.2.1: "port reference can be one of the following
...". What about general slices?

	 

	The full list is much longer. I would replace most references to
bit-selects, part-selects, slices and the like to just slices (or
whatever), instead of trying to fix all those references to include the
whole list of various kinds of slices (which makes the text longer, more
complex to understand and more error prone for already made as well as
future language extensions).

	 

	--Yulik.

	 

	
________________________________


	From: Bresticker, Shalom 
	Sent: Saturday, October 20, 2007 8:49 PM
	To: Feldman, Yulik
	Cc: 'sv-bc@server.eda.org'
	Subject: RE: [sv-bc] confusion in determining the type of an
self determined binary expression during evalution of type operator

	 

	I think that in Table 10-1, the usage of 'bit-select' and
'part-select' is clearly with respect to vectors. I am not sure I looked
at the VPI diagrams, but I did look at all the HDL uses of the terms and
did not find a problem. 

	 

	Table 10-1 does have problems and I filed Mantis 2072 a few
weeks ago on them.

	 

	Regards,

	Shalom

		 

		
________________________________


		From: Feldman, Yulik 
		Sent: Saturday, October 20, 2007 9:14 AM
		To: Bresticker, Shalom
		Cc: 'sv-bc@server.eda.org'
		Subject: RE: [sv-bc] confusion in determining the type
of an self determined binary expression during evalution of type
operator

		I'm personally OK with using 'select' as a general term,
but this term has to be defined in the LRM to serve as such.

		 

		I also understand that "bit-selects" and "part-selects",
as they currently defined, have different rules from "array slices", as
they are currently defined. But in many cases, LRM uses the terms
"bit-select" and "part-select" when the intention is actually to refer
to "array slices" as well. There are lots of such examples. One quick
example is Table 10-1 "Legal left-hand forms in assignment statements";
another is the usage of the terms in the VPI diagrams. I didn't do
detailed study, but I have a feeling that these terms more often used to
refer to "vectors" as well as "arrays", than specifically just to
"vectors". This is confusing.

		 

		--Yulik.

		 

		
________________________________


		From: Bresticker, Shalom 
		Sent: Friday, October 19, 2007 9:12 AM
		To: Feldman, Yulik
		Cc: 'sv-bc@server.eda.org'
		Subject: RE: [sv-bc] confusion in determining the type
of an self determined binary expression during evalution of type
operator

		 

		'select' is a general term.

		 

		But there are cases which are different rules. Vector
bit-selects and part-selects have different rules from array slices in
what you can do with them.

		 

		Shalom

			 

			
________________________________


			From: Feldman, Yulik 
			Sent: Friday, October 19, 2007 9:08 AM
			To: Bresticker, Shalom
			Cc: 'sv-bc@server.eda.org'
			Subject: RE: [sv-bc] confusion in determining
the type of an self determined binary expression during evalution of
type operator

			My main issue is that there are too many
different terms, describing special cases of "selects", instead of
having a single general term describing any kind of "select". Even if
the existing terms are used consistently, when they are used, the
variety of the terms and the lack of one general term cause confusion.

			 

			--Yulik.

			 

			
________________________________


			From: Bresticker, Shalom 
			Sent: Thursday, October 18, 2007 10:18 PM
			To: Feldman, Yulik
			Cc: 'sv-bc@server.eda.org'
			Subject: RE: [sv-bc] confusion in determining
the type of an self determined binary expression during evalution of
type operator

			 

			I checked and found that 'part-select' and
'bit-select' are used consistently. 'Slice' seems also used
consistently.

			 

			Shalom 

				 

				
________________________________


				From: Feldman, Yulik 
				Sent: Wednesday, October 17, 2007 5:31
PM
				To: Bresticker, Shalom
				Cc: 'sv-bc@server.eda.org'
				Subject: RE: [sv-bc] confusion in
determining the type of an self determined binary expression during
evalution of type operator

				Yes, and somebody has to clean this
mess. The definitions as they appear right now have little sense and,
not surprisingly, are not used consistently through the LRM. For
example, the 7.4.6 section with its definitions of part-select, slice,
slice name and indexed name, creates such a big confusion that any
further references to these terms leave the reader in complete
prostration. Not surprisingly, the terms like "slice name" are not even
used anywhere aside their definition. The presence of additional related
definitions in other sections makes the situation even worse. The LRM
should have been defined a single term, like "select", or "part select",
or even "slice" to refer universally to any kind of  "select" and then
should have used this term everywhere. Perhaps it would be OK to have a
couple of specialized terms likes "field select" to ease explanation in
certain cases, but in majority of references a single general term
should have been used, to avoid confusion.

				 

				--Yulik.

				 

				
________________________________


				From: Bresticker, Shalom 
				Sent: Wednesday, October 17, 2007 11:40
AM
				To: Feldman, Yulik
				Cc: sv-bc@server.eda.org
				Subject: RE: [sv-bc] confusion in
determining the type of an self determined binary expression during
evalution of type operator

				 

				7.4.6 defines 'part-select' and 'slice'.

				 

				11.5.1 defines 'bit-select' and
'part-select'.

				 

				11.5.3 defines 'field select' and
'indexing select'.

				 

				11.5.3 uses 'array select', but that is
not used elsewhere.

				 

				Table 10-1 use 'Array element select'
but 'element select' is not used elsewhere.

				 

				'member select' is not used anywhere.

				 

				9.2.2.1 uses 'select expression'.

				 

				11.5.3 uses 'select'.

				 

				Shalom

				 

				[Yulik] The problem here is that the LRM
is very confusing on the definition of the related terminology. I have
tried to raise this issue in the past, but it didn't get much attention.
The end result is that I and all my colleagues just use the "part
select" term as a universal term describing any kind of
"select"/"slice"/"part select"/"bit select"/"member select", even that
we know that strictly speaking LRM assigns some other mysterious meaning
to this term. It looks that you're using the term "select" for such a
universal meaning; but I don't think LRM clearly defines it as such
either.

				 

	
---------------------------------------------------------------------
	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 Oct 21 03:20:31 2007

This archive was generated by hypermail 2.1.8 : Sun Oct 21 2007 - 03:21:03 PDT