RE: [sv-cc] errata 373

If I understand you correctly, you're saying that the
information is always there, but that a VPI implementation
can choose not to return it. Is that correct?

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: Francoise Martinolle
] Sent: Thursday, February 10, 2005 12:02 PM
] To: Jim Vellenga; Francoise Martinolle; sv-cc@eda.org
] Subject: RE: [sv-cc] errata 373
]
] Yes you can always determine the type by the context but the context
] can be the type which prefixes the {}
] ex from the 254 proposal:
]
] An assignment pattern can be used to construct a structure or
] array value by
] prefixing the pattern with the name of a data type to form an
] assignment
] pattern expression that yields the value that a variable of
] the data type
] would hold if it were initialized using the assignment pattern.
]
] typedef logic [1:0] [7:0] T;
]
] shortint'({T'{1,2}, T'{3,4}}) // yields 16'sh1234
]
]
] This is the reason why we need to return the typespec of the '{}.
]
] Rewording the sentence
] Does this sounds better:
] The one to one relation to typespec must always be available
] for vpiCastOp
] operations, for simple expressions, and for vpiAssignmentPatternOp or
] vpiMultiAssignmentPatternOp expressions when the curly braces of the
] assignment patterare prefixed by a data type name. For other
] expressions it
] is implementation dependent whether there is any associated typespec.
]
]
] -----Original Message-----
] From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On
] Behalf Of Jim
] Vellenga
] Sent: Thursday, February 10, 2005 11:26 AM
] To: Francoise Martinolle; sv-cc@eda.org
] Subject: RE: [sv-cc] errata 373
]
] A couple more minor comments:
]
] Note 5
] ------
]
] I also have a concern about the revision to note 5 in section 31.46.
] You've added the phrase "which are prefixed by a data type
] name". It seems
] to me, from the description of assignment patterns in the
] proposal for 254,
] that one can always determine the type by context.
] Is that not true?
]
] If it is true, then I would recommend leaving the phrase out.
]
] If it is not true, then we should reword the sentence for
] clarity, because
] the way it reads now, the phrase "which are prefixed by a
] data type name" at
] first seems as if it could apply to one, two, or three of the
] object types
] that precede it in the sentence. A strict analysis of the
] parsing shows
] that it applies to exactly two, but that's not obvious on a
] quick read. I'd
] be happy to suggest a rewording if necessary.
]
] Note 7
] ------
]
] All of the new Note 7 should be in blue.
]
] Overall
] -------
]
] With the amendments noted above, all this looks good,
] workable, and ready to
] go. Thanks for doing it.
]
] 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 10, 2005 10:49 AM
] ] To: sv-cc@eda.org
] ] Cc: Charlie Dawson
] ] Subject: [sv-cc] errata 373
] ]
] ] as everyone had the chance to review the proposal I uploaded
] ] yesterday night?
] ] Please send any comments to the reflector.
] ] We need to agree on this today.
] ]
] ] Francoise
] ] '
] ]
]
]
]
]
Received on Thu Feb 10 10:38:48 2005