Re: [sv-bc] Re: [sv-ec] Behaviour of ref port

> Shalom writes in http://www.eda-stds.org/sv-bc/hm/5530.html 

I meant in http://www.eda-stds.org/sv-bc/hm/5528.html 

-- Brad

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Brad
Pierce
Sent: Friday, March 02, 2007 12:35 PM
To: sv-bc@eda-stds.org; sv-ec@eda.org
Subject: Re: [sv-bc] Re: [sv-ec] Behaviour of ref port

Shalom writes in http://www.eda-stds.org/sv-bc/hm/5530.html 

>What seems to come out of this is that you can derive the syntax "ref 
>.port_identifier(expression)", but only by going through net_port_type,

>which is misleading, since it is not a net.

For the reasons in http://www.eda-stds.org/sv-ac/hm/2599.html
this is not just misleading, but is a bug in the BNF.

The variable_port_type in variable_port_header should be optional.

-- Brad

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Wednesday, February 21, 2007 6:46 AM
To: Surya Pratik Saha; Steven Sharp
Cc: sv-bc@eda-stds.org; sv-ec@eda.org; sarani@cal.interrasystems.com
Subject: RE: [sv-bc] Re: [sv-ec] Behaviour of ref port

This is a little confusing.

19.9 is talking about the port declaration syntax
.port_identifier(expression), and says, "The self-determined type of the
port expression becomes the type for the port."

So Y is of the same type as x, which is int.

But it is a little more complex than that.

If you look at the BNF in A.1.3, start with list_of_port_declarations. I
start there because it has Note 25, which says, "The
list_of_port_declarations syntax is explained in 19.8, which also
imposes various semantic restrictions, e.g., a ref port must be of a
variable type and an inout port must not be."

So there is an explicit statement that a ref port must be a variable.

Continuing with the BNF, we have

list_of_port_declarations ::=
  ( [ { attribute_instance} ansi_port_declaration { , 
      { attribute_instance} ansi_port_declaration } ] )


ansi_port_declaration ::=
...
| [ net_port_header | variable_port_header ]
                       . port_identifier ( [ expression ] )

net_port_header ::= [ port_direction ] net_port_type
variable_port_header ::= [ port_direction ] variable_port_type
port_direction ::= input | output | inout | ref

net_port_type ::= [ net_type ] data_type_or_implicit variable_port_type
::= var_data_type var_data_type ::= data_type | var
data_type_or_implicit

data_type_or_implicit ::=
    data_type
  | [ signing ] { packed_dimension }

What seems to come out of this is that you can derive the syntax "ref
.port_identifier(expression)", but only by going through net_port_type,
which is misleading, since it is not a net.

Shalom


> Related to this issue, there is an example in the SV 1800 LRM. See
page
> 339 (section 19.9 List of port expressions)
> 
> module mymod (
>  output .P1(r[3:0]),
> output .P2(r[7:4]),
> ref .Y(x), input bit R );
> logic [7:0] r;
> int x;
> ...
> endmodule
> 
> Which is I think wrong, as ref is used without the data type. This
makes
> lot of confusion.

--
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, and is
believed to be clean.