[sv-ec] Minutes of Tuesday April 12th, 2005

 I have attached the unapproved minutes of Tuesday's meeting (April
12th, 2005).
 The next meeting is scheduled for Friday April 15th, 2005
 time: 8:00am - 10:00am PST.
 I will place the minutes on the web as well.
- Mehdi


---------------------------------------------------------------
Action items: (4/12/2005)
  1) AI(issue 232  Mantis 652): Dave update the svdb mantis for this
item
  2) AI(issue 235 Mantis 666 ): Gordon to write up the proposal in
mantis with the same proposal 
					  as in the spreadsheet.
  3) AI(issue 236 Mantis 642) : Ray make the changes. Keep proposal A,
get rid of the "...".
	   				  Also close Manti 411.
(duplicate)
  4) AI(issue 238 Mantis ---): Ray  - Create a mantis item and proposal
for 238. - It will 
	   				 be an informative note on the
race.
  5) AI(issue 189 Mantis 596): Arturo place the proposal in the svdb.
  6) AI(issue 240 Mantis ---): Arturo - writeup on issues for 1. region
crossings 2. scope extensions
	  				- also create a mantis entry.  

==============  SUMMARY of and issue resolved/voted ============
 == Approved issues === 
   on April 12, 2005:
    Issues approved:
	232  ( Mantis- 652 ) [approved on 4/12/05]
	236  ( Mantis- 642 ) [approved on 4/12/05]
	189  ( Mantis- 596 ) [approved on 4/12/05]

   on April 11, 2005:
    Issues approved:
	250  ( Mantis- 636 ) [approved on 4/5/05, re-approved 4/11/05]
	252  ( Mantis- 637 ) [approved on 4/5/05, re-approved 4/11/05]
	229  ( Mantis- 644 )
	230  ( Mantis- 646 )
	163  ( Mantis- 554 ) [one abstain -- Neil, (not read)]
    	255  ( Mantis- 641 ) [one abstain -- Neil, (not read)]

   on April 5, 2005:
	 11  ( Mantis- 410 )
	109  ( Mantis- 537 )
	161  ( Mantis- 550 )
	237  ( Mantis- 616 )
	250  ( Mantis- 636 )
	251  ( Mantis- 643 )
	252  ( Mantis- 637 )

	253  ( Mantis- 649 ) [combined with 254 into one Mantis (649)
	254  ( Mantis- 649 )
				[2 abstains: Francoise & Steven, no
knowledge of coverage]

	270  ( Mantis- 638 ) 
	271  ( Mantis- 639 ) [one abstain: Steven, not read the
proposal]
	272  ( Mantis- 640 )
	283  ( Mantis- 615 ) [Votes: 4 yes(Brad,Neil,Dave, Surrendra), &
Mehdi 
				3 abstain:(Ray,Francoise, Steven), and 1
No (cliff)]	

   Issues marked not feasible
	204

   Issues sent to other committees for review:
	125	294	(sv-ac)	 (vpi question)
	229	644	(sv-bc)  (struct initialization)   
[NOTE: here is what sv-ec received on 229 from April 11th sv-bc meeting:
The SV-BC reviewed the proposal to address issue 229 in
its April 11th meeting.  It was not approved.  Here's
the message that the committee agreed to convey
to the EC:

  The SV-BC did not pass the proposed resolution to issue
  229 as captured in Mantis #644.  The motion failed 
  with only abstention.


Those abstaining felt that making such a change so late
in the lifecycle of the LRM was not a good idea.  They
had concerns about issues such as:
 -continuous assignment to variables
 -initializer passed with with Type through parameters
  which is a new paradigm.
--------------------------------------------------------------

===========================================
== Issues not yet resolved/voted on =======
	 
Negative / High
-----Issue # --  Mantis # ------		
	233		
	235	666					
	238 
	240			
		
Positive / High
	281
Negative
	266 (NoTES)			
	 

Positive High
--  Issue #  --- Mantis # ------
	2		
	5		
	7		
	8		
	10		
	13		
	22		
	23		
	24		
	30		
	31	551	
	32	553	
	36	270	
	94	511	
	95	512	
	96	516	
	97	518	
	98	519	
	99	521	
	100	522	
	101	523	  	
		
Positive / Low 
--  Issue # --- Mantis # -------
	122	251	  	
	123	253	
	162	552	 		  		
	171	564	
	187	594	
	188	595	
	190	597	
	199	607	
	200	608	
	201	609	

Issues sent to sv-ec from other committees
	  1	from sv-bc
	244	from sv-bc
--- For issue 244 ---------------------------------------------------
The SV-BC approved the proposal in Mantis issue 632
and believes this resolves ballot issue 244.

The SV-BC also believe that the SV-EC should review
the issue & its resolution in case it conflicts
with SV-EC requirements.

the previous feedback was:

"Currently, the actuals of interface ports are not restricted in terms 
of hierarchical references to interface instantiations. This can cause
problems similar to other circular elaboration dependencies with
generates 
that IEEE-1364 very carefully avoids."


And the proposed addition to the LRM forbids interface port actuals
from being hierarchical references through arrays of intances or
generated
instances:

At the end of 20.2, ADD

If the actual of an interface port connection is a hierarchical
reference to 
an interface or a modport of a hierarchically referenced interface, the
hierarchical 
reference shall refer to an interface instance and shall not resolve
through an arrayed 
instance or a generate block.

The SV-BC thought the SV-EC should know about such a restriction.
Would you please run this by the EC?
------------------------------------------------------	
=============================================================