RE: [sv-cc] Revised 265 uploaded

Hi Charles/Francoise,

Some comments below with >>>BT.

--
Dr. Bassam Tabbara
Architect, R&D
Novas Software, Inc.
(408) 467-7893
-----Original Message-----
From: Charles Dawson [mailto:chas@cadence.com] 
Sent: Tuesday, November 30, 2004 8:50 PM
To: bassam@novas.com
Cc: sv-cc@eda.org
Subject: 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.
>>>BT: Typically this is called once by app (when getting "static info"),
conceivably this can in fact be faster than other mechanisms. We had
discussed these kinds of issues (pros/cons) in 3.1a, not fresh in my mind
now, needs consideration.
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.
>>>BT: There are varied uses for this info including: identifying unlabeled
assertions, and error reporting.
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.
>>>BT: Charles if you send me the "soft version" I can update quickly the fm
file and we can post that.
In general, I do agree with Jim and Francoise that this is an improvement
over what is currently in the specification.
>>>BT: Great, the first 2 items, i.e. t_vpi_assertion_info is in use, and
it's a little late now anyway to rethink this from scratch, it's hard/unwise
to consider alternatives, and their cost. I already have qualms about
backward compatibility, but as I mentioned I tried to remedy the issues
raised last and find some compromise: #defines can be fixed, info
organization/access is a little harder to justify breaking existing support.
>>>BT: Francoise, for your comment below. I think that's reasonable, and
does not a major burden/issue for backward compat., I can make that change
(solves one of Charles' formatting suggestions, I can cross out concurrent
and "s" :-)!). Charles I can still use the soft version of Chapter 31 if
needed too.
Thx.
-Bassam.
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