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