Re: [sv-cc] Revised 265 uploaded

Hi Bassam,

Along the lines of Francoise's issue, I am not enamored with the
vpi_get_assertion_info() routine. It does not fit the style of VPI.
Let me explain further. VPI provides a minimum set of routines, and
they should be the building blocks that an application uses to write
what it needs. If an application needs all of the static information,
then it could have it's own vpi_get_assertion_info() routine. On the
other hand, if an application only needs one piece of information, say
endLine, it must call a routine that has to go and find a whole bunch
of info that the application doesn't care about. This slows down the
application, and should be prevented if possible.

In a nutshell, everything in the t_vpi_assertion_info structure should
be properties of the different kinds of assertion handles.

Also, I would like to know why you think you need endLine, endColumn,
startLine, and startColumn. Are they of particular value to assertions?
If not, would you want to see these properties on other kinds of objects?
The way these are defined now, they only apply to assertion objects.

One other minor issue, the instance diagram (31.2) needs to be redrawn so
that it is unambiguous as to which arrow the vpiTypedef label applies. Some
of the other diagrams are pretty far off from what's in the rest of the
document, in terms of formatting. I don't think our editor will have a
problem though.

In general, I do agree with Jim and Francoise that this is an improvement
over what is currently in the specification.

   -Chas

Francoise Martinolle wrote:
> Bassam,
>
> I looked over at your new proposal and I like it. This is in line with
> my thinking.
> The only issue I see is in the new diagram 31.2 (instance diagram) where
> you provide both the iterations
> concurrentAssertions and assertions, the later being a superset of the
> former.
> I suggest to only provide the vpiAssertion iteration as one can filter
> the sequenceInst, immediateAssertions and
> propertyInst.
>
> Francoise
> '
>
> ------------------------------------------------------------------------
> From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of
> Bassam Tabbara
> Sent: Tuesday, November 30, 2004 9:08 PM
> To: sv-cc@eda.org
> Subject: [sv-cc] Revised 265 uploaded
>
> Hi All,
>
> I reviewed the discussion we had last meeting (objectively) and then
> evaluated the work/instability involved if we were to remove "type"
> as a compromise (both 31 and 28 would be victims), it seems to me
> the changes are quite localized and in fact touch the same areas of
> the proposal already. That said, in order to ensure unanimity and
> address all the concerns raised I opted to upgrade it to take the
> comments (that Francoise mainly made) last time into account of
> course at the cost of some backward incompatibility with tools
> supporting this API, but probably the code is bloated anyway with
> the 2 needlessly navigation VPI of 31 and the direct data access VPI
> of 28.
>
> Removing type, caused a clash with vpiProperty of course so I added
> Inst on there and then also to sequence for consistency, the result
> is a good deal of the VPI figs (sequence inst/property inst) would
> remain unchanged, and gladly "inst" is back and "property" is gone
> ... now that I've done the work I sorta like it, and as I said the
> instability of making these changes late in the game is fairly
> localized and not as bad as I had initially surmised ! (who cares
> about backward compatible as long as it is "right", right ?? :-)!).
>
> I uploaded the file, called SV_LRM_265_new.pdf . [Why is it of
> larger size even though it is simpler ? I disabled compression
> and/or MS word keeps track of every single thing I ever did !]
>
> ** I also found an extra reference to the attempt info struct in
> sv_vpi_user.h that I incorporated.
>
> ** Please run through this with other sets of eyes and let me know
> if any bugs. In theory this is the best/simplest version, easy to
> digest ...
>
> ** Michael this should make upgrade of 158 a bit easier, look
> through 265 towards the end and see if you can replicate the changes
> as well... I think that's best to avoid races in the fixes ...
>
> Thx.
> -Bassam.
> --
> Dr. Bassam Tabbara
> Architect, R&D
> Novas Software, Inc.
> (408) 467-7893
>
>

-- 
Charles Dawson
Senior Engineering Manager
NC-Verilog Team
Cadence Design Systems, Inc.
270 Billerica Road
Chelmsford, MA  01824
(978) 262 - 6273
chas@cadence.com