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

 
The new proposal is not in draft 3, but will be incorporated
in draft 4.
Constructors was the old name in draft 3, it will
be replaced by assignment pattern in draft 4. See
the latest proposal in the sv database.

Francoise
    '
-----Original Message-----
From: Jim Vellenga [mailto:vellenga]
Sent: Wednesday, February 09, 2005 9:59 AM
To: Francoise Martinolle
Cc: sv-cc@eda.org
Subject: 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 08:56:13 2005