Subject: Assertion API comments
From: Francoise Martinolle (fm@cadence.com)
Date: Wed Dec 18 2002 - 15:47:23 PST
First I do like it better defined as a VPI extension. Great work in a small
amount of time.
1. use short names for saving typing. For example prop instead of property.
2. may not be a bad idea to use prop as an infix in the object
types/properties/methods/callbacks
to be able to determine from the name that this is a VPI extension to
assertion language.
You can write for example vpiPropTemp (for temporal property)
and vpiPropCheck (for property check)
3. I already stated this during the meeting.
add a property vpiDirective which value can be vpiPropAssert,
vpiPropAssume,
vpiPropRestrict, vpiPropCover
4. vpi_property_info struct, vpi_source_info:
Adding a new VPI property or relation to an existing "object type"
need not cause backward compatibility problems when they are
individually named and fetched (e.g. vpi_get_str(vpiName, objH)).
But when they are combined into a struct this way, the interface
becomes a lot more 'brittle', because additions to the struct will
break existing compiled code. This is especially troublesome in
an API (like this one) intended for 3rd party integrations.
That may not be much of a concern for the t_vpi_source_info struct,
because that is indeed likely to be quite stable. But the fields
of the t_vpi_property_info struct are much more likely (in my opinion)
to change over time.
Perhaps there should be TWO methods for accessing this info, one using
existing VPI properties like vpiName, vpiType, etc., and one using
this struct. Then the API users can choose their tradeoffs between
backward compatibility and performance.
5. typo PLI_BYTE* should be PLI_BYTE8 *
6. clock expression and failed expression are strings. I would prefer them
to be
VPI handles.
What was the reason for only providing a string? If you had a vpi handle
you can inquire
about the expression and its operand values, can't you ? and further
diagnose why it failed?
7. syntactical information may be needed but we can wait for later defining it
8. vpi_register_property_cb
A handle to the callback may not needed to be returned, you should also
have a flag field which can be used to indicate (vpiReturnCb)whether or not
you want a
callback to be returned. You could combine the event and flags together
in a single integer argument.
9. property step
How do you think users are going to make any sense of a step forward
in the assertion
if they cannot have observable points. Users would have to be
able to differentiate one thread attempt from another.
This archive was generated by hypermail 2b28 : Wed Dec 18 2002 - 15:48:15 PST