RE: [Fwd: RE: [sv-cc] SV-CC Meeting minutes for 02/15/2006 -- vpiColumn et. al.]

I read Bassam's email. I do understand why we have this property on an
assertion handle but I do not
agree with what Bassam says to do (see TODO list).
 
All the "location" properties should remain on the assertion class. They are
properties you can query when an assertion fails or
succeeds to get the "state" of the assertion step.
These properties are in addition to the vpiLineNo and vpiFile properties
which exists for an assertion and 
which provide the assertion declaration line and file information.
 
I think we need to add a couple of notes to describe what vpiColumn and
vpiEndColumn values represent.
This is not obvious.
vpiColumn returnsthe column offset to the vpiStartLine
vpiEndColumn returns the column offset from the vpiEndLine
 
(if the expression which rerpesents the current state f the assertion
attempt spans over a line, vpiStartLine and vpiEndline
return different values.) 
 
I would also propose to chaneg the name of vpiStartLine and vpioEndLine to
be more consistent with vpiLineNo
(Basically add "No" at the end). Given that both of them (as well as
vpiColumn and vpiEndColumn) are missing from the header file, 
we can change them.
 
In my opinion the only things to do are:
  - add a couple of notes to describe vpiColumn and vpiEndColumn
  - change the names of vpiStartLine to vpiStartLineNo, vpiEndLine to
vpiEndLineNo
 - add vpiColumn, vpiEndColumn, vpiStartLineNo, vpiEndLineNo to the header
file.
 
Comments?
 
Should I enter a mantis item and make a proposal?
 
Francoise
       '


  _____  

From: Michael Rohleder [mailto:michael.rohleder@freescale.com] 
Sent: Wednesday, March 29, 2006 12:08 PM
To: fm
Subject: [Fwd: RE: [sv-cc] SV-CC Meeting minutes for 02/15/2006 -- vpiColumn
et. al.]




-------- Original Message -------- 
Subject: 	RE: [sv-cc] SV-CC Meeting minutes for 02/15/2006 --
vpiColumn et. al.	
Date: 	Thu, 16 Feb 2006 14:23:17 -0800	
From: 	Bassam Tabbara  <mailto:Bassam.Tabbara@synopsys.com>
<Bassam.Tabbara@synopsys.com>	
To: 	SV-CC  <mailto:sv-cc@eda.org> <sv-cc@eda.org>	


Hi all, 



About the following:

===

   - vpiEndColumn and vpiColumn issue brought up by Francoise



     Chas recalls us discussing this during balloting, and that Bassam

     thought it was important that they remain.  Michael thinks these

     are to help figure out what caused the state change.  Abby doesn't

     think that it matches the other way things are done.  This needs

     to be looked at more carefully.  At the very least, these need

     to be added to the include file. Michael will provide Francoise

     an example.  Francoise will file a Mantis item and work with

     Michael on a solution.

===



I reviewed this a bit now. I think Michael is right about the reasoning

-- it is about knowing the detailed expression progress (that caused

fail say), a very basic debug (printing) capability. For details see the

"step" portion of the Assertion API. 



1) For example:



property p;

  @clk s1 ##1 s1;  // <<<< when we report that "s1" did not match, which

s1 do we mean ? Need column (for printing say) ...

endproperty



A: assert property(p);



2) For the "history" of issue you can refer to LRM 3.1a and look at:



typedef struct t_vpi_assertion_step_info {



>>>>>p_vpi_source_info<<<< *exprs_source_info; /* array of source info

*/



} s_vpi_assertion_step_info, *p_vpi_assertion_step_info;



Now in P1800 revision we killed the source_info bit and opted to offer

the data in more of VPI form, hence the vpiColumn et. al., but seems

forgot to upgrade the include file.



3) Bug in LRM: I think the "location" block was meant to be for

expressions (see the "step" part...) i.e. should be at 27.36 "Sequence

expression" (to cover expr/sequence_inst  ...). The assertion/cover/....

Do not really need this we already can get this info from the

declaration (vpiDefFile/Line ... Note no column... Well assuming

reasonable user indentation :)!).



** BTW, I do not think there is a need to add this "location" to 27.34

as well (for property_expr), the original intent for sequence level is

good enough and still holds true given today's property composition

constructs, adding this makes little sense.



4) TODO:

 - Copy "location" block to 27.36

 - Remove from 27.31

 - Change all occurrence of vpiDefLineNo to vpiLineNo

 - Change all occurrence of vpiDefFile to vpiFile

 - Add the "location" items (except vpiFile) to sv_vpi_user.h Annex I.



Thx.

-Bassam.



--

Dr. Bassam Tabbara

Synopsys, Inc.

(650) 584-1973