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: Sat Oct 20 2007 - 11:49:23 PDT
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, and is
believed to be clean.
Received on Sat Oct 20 11:51:05 2007

This archive was generated by hypermail 2.1.8 : Sat Oct 20 2007 - 11:51:36 PDT