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

Bassam,

Why do we need the column and endColumn for each sub expression of the
assertion?
As I understand when you register an assertion callback you can get the
assertion step
information which basically tells you the path it took through the assertion
expression
before the callback occurs.
I think that all we care about is the column, endcolumn of where we are in
the assertion
sequence expression. The column, endcolumn represents the current state of
the assertion.
I think that this is sufficient.
If you want to get every single step information and the column/endcolumn
for each expression
which is attempted, you need to place an assertionStepSuccess reason
callback. Everytime
the assertion progresses, you get a step callback and you can query the
column/endColumn
information on the assertion handle in the callback user function.

The assertion step info data structure has an array of expression handles
which
represent the matched expressions. We removed the array of source line info,
because that 
current source line info can be available from the assertion handle.

typedef struct t_vpi_assertion_step_info {
PLI_INT32 matched_expression_count;
vpiHandle *matched_exprs; /* array of expressions */
PLI_INT32 stateFrom, stateTo;/* identify transition */
} s_vpi_assertion_step_info, *p_vpi_assertion_step_info;


I do not think we need to "break the convention". I think that the
current mechanism to have vpiColumn and vpiEndColumn on an assertion handle
is fine.

Am I misunderstanding something?

Francoise
    '

-----Original Message-----
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Bassam
Tabbara
Sent: Friday, March 31, 2006 2:31 PM
To: Jim Vellenga; Bassam Tabbara; Francoise Martinolle; sv-cc@eda.org
Subject: RE: [Fwd: RE: [sv-cc] SV-CC Meeting minutes for 02/15/2006 --
vpiColumn et. al.]

Hi Jim,

Of course, as I stated, we are talking about sequence expressions.
Indeed, I agree ideally a reference to sequence_expr akin to (the subset
now) vpiSequenceInst -> vpiSequenceDecl would be best.

However since this issue is exercised now primarily by the assertion
(stepping debug), the "local" solution should suffice. Keep in mind our
intent in the last update was to keep things simple and consolidate from
earlier -- Conceptually for primaries this meant having a "new" handle (same
type) for the instance with line/column. So yes when it comes to assertions
this might be a "break with convention" on interpretation, but little else
makes sense for this functionality. 

Thx.
-Bassam.

--
Dr. Bassam Tabbara
Synopsys, Inc.
(650) 584-1973

-----Original Message-----
From: Jim Vellenga [mailto:vellenga@cadence.com]
Sent: Friday, March 31, 2006 10:51 AM
To: Bassam Tabbara; Francoise Martinolle; sv-cc@eda.org
Subject: RE: [Fwd: RE: [sv-cc] SV-CC Meeting minutes for 02/15/2006 --
vpiColumn et. al.]

So, yes, Bassam, you do want each expr in a sequence_expr to have a separate
handle.  I think both Francoise and I understand that that is what you want.

The difficulty, from an object model point of view, is that we do not
currently have any "most derived" object that can perform that function.
For example, there is no vpiReferenceToADeclaredObject type of object.
If an element of a sequence expression is (in the source code) a reference
to a bit variable, VPI currently has no way to represent that reference
other than to return vpiBitVar itself.  And by convention, that vpiBitVar
represents the declaration rather than the instance.
To change that in general (i.e., outside of sequence
expressions) would cause a great number of existing VPI applications to
fail.

So are you asking for a different object type to take the place of "bit var"
or "logic var" etc. when it occurs within a "sequence_expr"?

Regards,
Jim Vellenga

--------------------------------------------------------- 
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: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com]
] Sent: Friday, March 31, 2006 1:42 PM
] To: Francoise Martinolle; Jim Vellenga; sv-cc@eda.org ] Subject: RE: [Fwd:
RE: [sv-cc] SV-CC Meeting minutes for ] 02/15/2006 -- vpiColumn et. al.] ] ]
Hi Francoise, ] ] See my email earlier today. Again we are talking here
about *sequence ] expressions within SVA* and YES there IS a difference
between ] (the many ] different) instantiation(s) and declaration. 
]
] Ok I see now, my original example had a named sequence "s1". I guess ]
what's bothering you is if I had something like a ##1 a ##1 a, then ] *yes*
the VPI should return a different handle for each "a" -- similar ] to if I
had vpiSequenceInst there instead of a vpiOperation or ] vpiIdentifier
(primary).  
]
] ---> This is the *original intent and function that 3.1a had* albeit ]
there the source info and the expr list were separated so yes -- in ]
implementation terms -- sharing of simple expression handles was ] possible
(never sequence instances). When we killed the extra source ] info in 1800
the idea was to consolidate with VPI and the expr itself ] had line/Column
info. The (top) expr IS the "pointer" to ] where we are in ] evaluation i.e.
this is how you determine where the progress/fail is ] happening ...
]
] ** So yes a unique expression handle of course, how else did ] you expect
] the step/matched expr lists to work ? And the line/column is for the ]
*expression*, nothing else does the original intent justice -- yes the ]
properties were put on wrong diagram.
]
] Thx.
] -Bassam.  
]
] --
] Dr. Bassam Tabbara
] Synopsys, Inc.
] (650) 584-1973
]
] -----Original Message-----
] From: francoise martinolle [mailto:fm@cadence.com] ] Sent: Friday, March
31, 2006 9:30 AM ] To: 'Jim Vellenga'; 'Bassam Tabbara'; 'Francoise
Martinolle'; ] sv-cc@eda.org ] Subject: RE: [Fwd: RE: [sv-cc] SV-CC Meeting
minutes for 02/15/2006 -- ] vpiColumn et. al.] ] ] I do not understand
either.
] I was pointing out that whenever you encounter a verilog expression ]
which contains primaries such as variable references, vpi ] will create a ]
handle to the variable declaration.
] Ex:
] int a;
]
] initial
] #1 a = a + b - a;
]
] The handle to the declaration of a is a vpiReg so are the ] handles to all
] uses of a in the initial statement.
] For each of these handles vpiLineNo returns the line number of the ]
declaration of a (int a); There is no way to access the line number of ]
each occurrence of a in the initial statement.
]
] Francoise
]     '
]
] -----Original Message-----
] From: Jim Vellenga [mailto:vellenga]
] Sent: Friday, March 31, 2006 10:26 AM
] To: Bassam Tabbara; Francoise Martinolle; sv-cc@eda.org ] Subject: RE:
[Fwd: RE: [sv-cc] SV-CC Meeting minutes for 02/15/2006 -- ] vpiColumn et.
al.] ] ] Bassam, my apologies, but I didn't catch what comment your response
is ] addressing.  I.e., what is the "it" in "it does", and what does it do?
]
] Thanks,
] Jim
]
] --------------------------------------------------------- 
] 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
] Bassam Tabbara ] Sent: Thursday, March 30, 2006 7:05 PM ] To: 
] Francoise
] Martinolle; Bassam.Tabbara@synopsys.com; sv-cc@eda.org ] Subject: Re:
] [Fwd: RE: [sv-cc] SV-CC Meeting minutes for ] 02/15/2006 -- vpiColumn ]
et. al.] ] ] Actually it does, see vpisequencedecl vs. Vpisequenceinst ] ...
] ]
] ]
] ] THX. 
] ] -Bassam
] ]
] ] -----Original Message-----
] ] From: francoise martinolle <fm@cadence.com> ] To: 'Bassam Tabbara'
] <Bassam.Tabbara@synopsys.COM>; 'SV-CC' 
] ] <sv-cc@eda.org>
] ] Sent: Wed Mar 29 19:55:11 2006
] ] Subject: RE: [Fwd: RE: [sv-cc] SV-CC Meeting minutes for ] ] 02/15/2006
] -- vpiColumn et. al.] ] ] We cannot put vpiLine, vpiColumn ] etc.. on expr
] class because ] VPI does not create separate handles for expressions ]
which refer ] to declarations.
] ] Ex:
] ] If the expression is a simple variable, the handle to the ] ] expression
] is the same as a handle to the variable ] declaration. The vpiType of ]
the *expression* will be the ] vpiType as if you had accessed the ] variable
declaration itself.
] ] This is for minimizing the number of handles created. Hence ] you ]
cannot get different line information for the variable and ] for an ]
expression which refer to the variable.
] ]
] ] In fact having the column information on the assertion itself ] is ]
good, as you have different properties to access the line ] ] declaration ]
] for the assertion itself and other properties to access the ] ]
"expression state" of the assertion. With combining ] ] assertion_step_info
and the ] column/startline information a user can ] easily determine ] which
part of the assertion failed/was attempted.
] ]
] ]
] ] Francoise
] ]
] ]
] ]
] ] ________________________________
] ] 
] ] 	From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] 
] ] On Behalf Of Bassam Tabbara
] ] 	Sent: Wednesday, March 29, 2006 5:02 PM
] ] 	To: SV-CC
] ] 	Subject: RE: [Fwd: RE: [sv-cc] SV-CC Meeting minutes 
] ] for 02/15/2006 -- vpiColumn et. al.]
] ] 	
] ] 	
] ] 	Hi Francoise,
] ] 	 
] ] 	I think that if my (1), (2) below make sense, then in 
] ] fact (4)'s TODO is a natural conclusion. There would be no ] ] need for
] notes (at least no "elaborate" notes), and the ] Column info would go ]
where it should -- on expressions. 
] ] 	 
] ] 	I fail to see in your writeup:
] ] 	 a) why these would live (as today) on 
] ] assertion/sequence/property def instead of the respective ] ] expression
] that the assertion/... is composed of, please see (b).
] ] 	 b) column info discussion: I suspect you are missing 
] ] that the idea is to report the *expression* and the column of ] that ]
expression is an afterthought. The step report is *not* ] the more ]
primitive column printing you describe dissociated ] from the ] expression,
I think you are misinterpreting 28.3.2, ] the ] idea is indeed ] to return
the expression (and yes the ] correct handle).
] ] 	 c) your comment on vpiLineNo/vpiFile, these exist for 
] ] anything ...
] ] 	 
] ] 	** My previous proposal is much simpler. As far as 
] ] adding the "No" suffix yet that would be consistent with ] ] legacy VPI
] naming albeit with more changes to SV's header ] (and not the "ok"
] change of deleting stuff).
] ] 	 
] ] 	Thx.
] ] 	-Bassam.
] ] 	
] ] 	--
] ] 	Dr. Bassam Tabbara
] ] 	Synopsys, Inc.
] ] 	(650) 584-1973
] ] 	 
] ]
] ] ________________________________
] ] 
] ] 	From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] 
] ] On Behalf Of francoise martinolle
] ] 	Sent: Wednesday, March 29, 2006 1:00 PM
] ] 	To: 'SV-CC'
] ] 	Subject: 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 
] ] <Bassam.Tabbara@synopsys.com> <mailto:Bassam.Tabbara@synopsys.com> 	
] ] 		To: 	SV-CC <sv-cc@eda.org> <mailto: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
] ] 		
] ] 		
] ]
] ]
] ]
]
]