RE: [sv-cc] concatenations and structure/array constructors

Francoise,

I like the idea. This also helps with the concern I
expressed in Issue #45 about getting the values of
elements of aggregate constants.

Could I suggest vpiAssignmentPattern rather than
vpiAssignPattern?

By the way, I don't see the phrase "assignment pattern"
in the new proposal for Issue 254, nor do I see it in
the P1800/D3.

On the other hand, I do see "array constructors" and
"structure constructors". Would it be better to
follow the language of the LRM and use either
vpiConstructor or a combination of vpiArrayConstructor
and vpiStructureConstructor?

Whatever we decide to call them, the idea is excellent.
We could then create diagrams that allow us to extract
the elements of the constuctors by operations similar
to those for extracting the elements of array variables
and array nets or of structure variables and structure
nets. And that would solve the problems of Issue #45.

I also see that the elements of the constructors are
not necessarily literals, but can be arbitrary expressions.
So getting their elements is really a generalization of
the issue I raised in #45, which concerned itself only
with obtaining the elements of literal constructors.

Regards,
Jim V.

---------------------------------------------------------
James H. Vellenga 978-262-6381
Engineering Director (FAX) 978-262-6636
Cadence Design Systems, Inc. vellenga@cadence.com
270 Billerica Rd
Chelmsford, MA 01824-4179
"We all work with partial information."
----------------------------------------------------------
  
 

] -----Original Message-----
] From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On
] Behalf Of Francoise Martinolle
] Sent: Thursday, February 03, 2005 10:13 AM
] To: sv-cc@eda.org
] Subject: [sv-cc] concatenations and structure/array constructors
]
] I looked at the information model we have for concatenations
] and structure/array constructors.
] We represent such expressions as a vpiConcatOp which has
] operands which can be traversed.
] VPI does not have the possibility today to exactly represent
] how a structure/array constructor
] was written by the user (for example providing the key, index
] or default key).
] This is fine as long as the expression returned is equivalent
] to the expression in the original source.
] Note that this would not be acceptable if VPI were to
] represent information after analysis as the structure/array
] constructors are evaluated in the context of the assignment
] to a lvalue and the type/layout of the lvalue
] must be known in order to do this. But this is not an issue today,
] as the VPI standard model is not certified for supporting pre
] elaboration access. There are plenty of other
] issues of this sort which would need to be fixed in order to
] support VPI pre elaboration.
]
] In any case, the latest development of errata #254
] differentiates syntactically a regular verilog concatenation of
] bits from a structure or array constructor. The latter will
] have the curly brace { preceded with a quote ' . For example:
] '{1:1, default: 0}
] Additionally the terminology has changed and call these
] "assignment patterns".
]
] I think that the only VPI change which is currently required
] to be consistent with the language
] is to add a new vpiOpType constant vpiAssignPatternOp.
] Having a different optype will also facilitate future
] enhancements of VPI to support pre elaboration: for ex,
] access of the assignment pattern expression so that we can
] provide the associations between the keys and the
] expression values associated with the keys.
]
]
] If the proposal of 254 is passed, I recomment to add a new
] vpiOptype value: vpiAssignPattern.
] This is consistent with the reasoning of the BC committee who
] feels that we need to differentiate the
] two language constructs.
]
] Francoise
] '
]
Received on Wed Feb 9 06:59:27 2005