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

From: Feldman, Yulik <yulik.feldman_at_.....>
Date: Fri Oct 19 2007 - 00:07:31 PDT
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, and is
believed to be clean.
Received on Fri Oct 19 00:08:14 2007

This archive was generated by hypermail 2.1.8 : Fri Oct 19 2007 - 00:08:21 PDT