RE: [sv-ac] RE: comments on 1722

Hi Lisa and John,
 
As the author of the last major "bind" revamping leading into P1800,
I would say Lisa is correct on all counts, as per our intentions
in SV-BC when we did the work.  (Sorry, I can't remember the Mantis
item for the earlier proposal I did)
 
BTW, I strongly agree bind should be pulled out of the Assertions
clause and inserted into Clause 19.  I think this proposal is actually
a good time to make the switch.  Otherwise, yet more Mantis will
need to be created, managed, voted, etc.
 
Thanks and regards,
Doug Warmke


________________________________

	From: owner-sv-ac@server.eda.org
[mailto:owner-sv-ac@server.eda.org] On Behalf Of Lisa Piper
	Sent: Monday, March 05, 2007 7:25 PM
	To: john.havlicek@freescale.com
	Cc: sv-ac@server.eda-stds.org
	Subject: [sv-ac] RE: comments on 1722
	
	

	Hi John,

	 

	My comments are below.

	 

	Lisa

	 

	-----Original Message-----
	From: John Havlicek [mailto:john.havlicek@freescale.com] 
	Sent: Tuesday, March 06, 2007 12:22 AM
	To: Lisa Piper
	Cc: sv-ac@eda-stds.org
	Subject: comments on 1722

	 

	Hi Lisa:

	 

	I have read the proposal for 1722 and have the comments

	below.

	 

	J.H.

	 

	 

	 

	- Should the bind discussion be moved to Clause 19 as suggested
by 

	  Jonathan Bromley?  This could invite a change in the way the
motivation 

	  is presented.

	[Lisa Piper >>>] I think this makes sense, however, I would
prefer to get this proposal approved first and then transfer it to
Clause 19.  They can further modify the introduction at that time if
desired.  

	 

	- I understand the motivation of attaching verification code to 

	  design code without touching the design.  However, I don't
like the 

	  sentence

	 

	    SystemVerilog provides a bind construct that allows for
instantiating

	    a module, interface, or program block into design code
without touching

	    the design code.

	 

	  because it suggests that only design code targets are allowed.
I prefer

	  something like

	 

	    SystemVerilog provides a bind construct that is used to
specify one or

	    more instantiations of a module, interface, or program block
without modifying

	    the code of the target.

	[Lisa Piper >>>] this is fine. 

	 

	- I see the text you pointed out:

	 

	    It shall be an error for a bind statement to bind a
bind_instantiation

	    underneath the scope of another bind_instantiation.

	 

	  Suppose I have module C that I bind.  Is this saying that it
is illegal to bind 

	and instance module D to target scope C?  

	[Lisa Piper >>>] yes.

	If not, then are we saying that 

	  there are different capabilities for binding to target scope
and target 

	instance when multiple bindings are involved?

	 

	  


	-- 
	This message has been scanned for viruses and 
	dangerous content by MailScanner <http://www.mailscanner.info/>
, and is 
	believed to be clean. 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.