RE: [sv-bc] Mantis 1573

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Wed Dec 12 2007 - 05:41:37 PST
OK.

I suggest we move 22.3.3.1 (port coercion) to be after 22.3.3.7 (net and
port collapsing).

I think the entire discussion of port coercion can be restricted to
ports declared with type net. If the port were of type variable, then
22.3.3.2 says:

1. If it is an input port, then an assignment to it is illegal. So that
case cannot occur.
2. If it is an output port, then if it is connected to a variable
outside, it is illegal to have assignments to that external variable.
3. If it is an output port, then if it is connected to a net outside,
multiple drivers are allowed on the net. (coercion does not work, but no
warning is issued)
4. A variable cannot be an inout port.

So can we say that coercion may only occur if both sides of the port are
nets?

The examples I wrote were

module top ;
wire in1, out1 ;
m m(in1, out1);
assign out1 = 1'b1;
endmodule

module m (in1, out1) ;
input in1 ;
output out1;        // out1 is driven outside the module and thus used
as an input
assign in1 = 1'b0 ; // in1 is driven within the module and thus used as
an output
endmodule

We can use these as examples (merely examples) of an input net port used
as an output or vice-versa. Beyond that, we won't define what is meant
by "used as an output(input)". But I think we can say it another way,
that the port sink is assigned or written from an additional source,
other than through the port connection.

I understand that port coercion will always occur if the port is
collapsed. If the port is not collapsed, port coercion may or may not
occur. Can we say that?

I understand that if coercion does not occur, the extra assignment to
the net takes place, but the port direction is preserved and the
assignment does not pass through the port connection to the signal
source.

If I can get confirmation on this today and/or corrections to any
mistakes in what I wrote here, then I can rewrite the proposal tomorrow,
and have it ready for review.

Thanks,
Shalom

> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
> Sent: Friday, October 19, 2007 7:32 PM
> To: Steven Sharp
> Cc: Bresticker, Shalom; sv-bc@server.eda.org; Dave_Rich@mentor.com
> Subject: Re: [sv-bc] Mantis 1573
> 
> 
> 
> Steven Sharp wrote:
> [...]
> 
> > This idea that port coercion is a deliberate attempt by the tool to 
> > fix an incorrect port direction was a figment of someone's 
> imagination.
> > What happened is that Verilog-XL collapses ports whenever 
> it can, for 
> > performance reasons.  It does this independently of the declared or 
> > correct port direction.  When it does this, the port 
> becomes an inout.
> 
> I agree -- the view that collapsing can be expressed as "port 
> coercion"
> poses some real issues.  I think that confusion also 
> manifests itself in the modport discussion.  In the past I've 
> also raised issues with force semantics as well if you don't 
> really think about nets as collapsed.
> 
> Gord.
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
> 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Dec 12 12:09:39 2007

This archive was generated by hypermail 2.1.8 : Wed Dec 12 2007 - 12:09:55 PST