RE: [sv-bc] Are modport port directions enforced?

From: Francoise Martinolle <fm_at_.....>
Date: Thu Mar 01 2007 - 13:59:24 PST
I agree with you. I was just trying to tell Jonathan that there are visible differences 
in a ref versus an output port.
 
In summary, modport port directions for variables should be enforced by a simulator.
modport port directions for nets are not enforced.
 
Francoise
       '.


________________________________

	From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Rich, Dave
	Sent: Thursday, March 01, 2007 4:52 PM
	To: sv-bc@eda.org
	Subject: RE: [sv-bc] Are modport port directions enforced?
	
	

	Françoise,

	I think we are starting to go in circles.

	I believe the intent and answer to your question on Monday <http://www.eda-stds.org/sv-bc/hm/5549.html>  is yes and I also believe the LRM supports that regardless of the secondary issue of whether an interface port creates continuous assignments.

	I do think we need take up another issue to resolve the subtleties of propagation and forces created by an implied continuous assignment. (Rather. IS there an implied continuous assignment?)

	Dave

	

	> -----Original Message-----

	> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@servçer.eda.org] On

	> Behalf Of Francoise Martinolle

	> Sent: Thursday, March 01, 2007 12:54 PM

	> To: sv-bc@server.eda.org

	> Subject: FW: [sv-bc] Are modport port directions enforced?

	> 

	> 

	> 

	> -----Original Message-----

	> From: Francoise Martinolle

	> Sent: Thursday, March 01, 2007 12:33 PM

	> To: 'Jonathan Bromley'; sv-bc@eda-stds.org

	> Subject: RE: [sv-bc] Are modport port directions enforced?

	> 

	> I think that there are differences, subtle but visible.

	> 

	> When you write to an output the write has to propagate up to the object

	> connected in the parent module instance. when you write to a ref port,

	> you are writing to the original object and that write is immediately

	> visible. Because there is a continuous assignment from the output port

	> to the connected object, there may or may not be an extra cycle

	> (depending if the continuous assignment for propagation is inlined with

	> the write operation or not).

	> If you write the output with a force statement, I think that only that

	> output is forced but not the object connected to it. That is not the

	> case for the ref port, the original object would be forced.

	> 

	> Francoise

	>     '

	> 

	> -----Original Message-----

	> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of

	> Jonathan Bromley

	> Sent: Thursday, March 01, 2007 8:54 AM

	> To: sv-bc@eda-stds.org

	> Subject: RE: [sv-bc] Are modport port directions enforced?

	> 

	> [Shalom]

	> 

	> > According to this interpretation, variables are passed as ref ports,

	> > which really do reference the original, and one could look at nets as

	> > using port collapsing. Does that make sense?

	> 

	> Not to me.  If it is that way, what is the difference between "ref" and

	> "output" in a modport, given that port mode "output"

	> has never stopped us reading things?

	> --

	> Jonathan Bromley, Consultant

	> 

	> DOULOS - Developing Design Know-how

	> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

	> 

	> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24

	> 1AW, UK

	> Tel: +44 (0)1425 471223                   Email:

	> jonathan.bromley@doulos.com

	> Fax: +44 (0)1425 471573                           Web:

	> http://www.doulos.com

	> 

	> The contents of this message may contain personal views which are not

	> the views of Doulos Ltd., unless specifically stated.

	> 

	> --

	> This message has been scanned for viruses and dangerous content by

	> MailScanner, and is believed to be clean.

	> 

	> 

	> 

	> --

	> This message has been scanned for viruses and

	> dangerous content by MailScanner, and is

	> believed to be clean.

	> 

	


	-- 
	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.
Received on Thu Mar 1 14:00:04 2007

This archive was generated by hypermail 2.1.8 : Thu Mar 01 2007 - 14:00:21 PST