FW: [sv-cc] assignment pattern expressions information model efficiency

Hi Francoise/all,
 
This is the "keying" mechanism -- I'm all for this one, the way VPI is
today converts a sparse notation into a very dense one and is a bad idea
as in the pathological case cited below.
 
** Francoise, in relation to my other email just now, at some point I
was thinking to add a "vpiStructKey" to handle nested struct but I think
just keep this simple (and separate issue) add mechanism in case
patterns to indicate need to iterate. 
 
Thx.
-Bassam.

 

________________________________

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of
Chuck Berking
Sent: Wednesday, April 26, 2006 10:44 AM
To: Francoise Martinolle; SV-CC
Subject: RE: [sv-cc] assignment pattern expressions information model
efficiency

 

I like it !   I would perhaps choose to name 'vpiAssocExpr' as
'vpiAssignPatternKey' or

something that links it more directly with it's use here- unless it
would have other

similar applications elsewhere.

-Chuck

	 

	
________________________________


	From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf
Of francoise martinolle
	Sent: Tuesday, April 25, 2006 11:50 PM
	To: 'SV-CC'
	Subject: [sv-cc] assignment pattern expressions information
model efficiency

	When we defined the information model for assignment pattern
expressions we decided that it 

	would be represented as an operation which operands would be the
expressions inside the assignment pattern

	expression of an equivalent assignment pattern expression using
the positional notation.

	See note 6 of diagram 27.39.

	 

	This is problematic when we have a default assignment pattern
expression assigned to a very large

	array:

	Ex:

	 

	int ARR [100][100] = '{default :0};

	There would be 10,000 operands returned for the iteration each
representing the value 0.

	 

	Same issue arises with the type key:

	 

	int ARR [100][100] = '{int: 0};

	 

	Perhaps we should define a more efficient (compact) model to
represent values assigned to multiple elements in assignment patterns.

	 

	An idea would be to represent the index, type, member and
default value as associations.

	For example,  I would introduce a new expression of type
vpiAssocExpr which could be returned as an operand of the 

	vpiAssignPatternOp operation. From a vpiAssocExpr, one can
access the property vpiKey which would 

	return either vpiDefault, vpiIndex, vpiMember or vpiType,
Additionally the expression associated with the association 

	can also be obtained with a vpiExpr method. The key itself can
be obtained with a vpiKeyExpr method

	 

	vpiOperation ---vpiOperand-->> vpiAssocExpr                 

	                                                 vpiKey
(vpiDefaultKey, vpiIndexKey, vpiTypeKey, vpiMemberKey)

	                                                 ------->
vpiKeyExpr

	                                                 -------->
vpiExpr 

	 

	 

	In the example above, vpiOperand would only return an operand of
type vpiAssocExpr. The vpiExpr applied

	to the vpiAssocExpr would return the constant 0, the vpiKey
property would return vpiDefault, the vpiKeyExpr would return NULL.

	 

	Ex:

	 

	int arr [1000] = '{0: 1, 100: 3, int:2}

	For this example, we would only get 3 operands for the
iteration, 

	   vpiAssocExpr 

	             vpiKey = vpiIndexKey

	             vpiKeyExpr = vpiConstant for 0

	             vpiExpr = vpiConstant 1

	 

	   vpiAssocExpr 

	             vpiKey = vpiIndexKey

	             vpiKeyExpr = vpiConstant for 100

	             vpiExpr = vpiConstant 1

	 

	  

	   vpiAssocExpr 

	             vpiKey = vpiTypeKey

	             vpiKeyExpr = vpiTypespec for "int"

	             vpiExpr = vpiConstant 2

	 

	 

	We would not require that assignmentPattern expressions be
represented with assoc expressions. We could still leave the possibility

	for an implementation to represent an assignment pattern
expression as a full expanded positional assignment pattern. 

	Comments?

	 

	Francoise

	       '