Subject: [sv-bc] Fwd: these are the two messages that were not archived
From: Karen Pieper (Karen.Pieper@synopsys.com)
Date: Mon Dec 08 2003 - 11:23:58 PST
>Date: Mon, 08 Dec 2003 00:34:43 -0800
>From: Dave Rich <David.Rich@synopsys.COM>
>Organization: Synopsys VTG
>User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5)
>Gecko/20031007
>X-Accept-Language: en-us, en
>To: Karen.Pieper@synopsys.COM
>Subject: these are the two messages that were not archived
>
>
>--
>--
>David.Rich@Synopsys.com
>Technical Marketing Consultant
>http://www.SystemVerilog.org
>tele: 650-584-4026
>cell: 510-589-2625
>
>
>
>
>Return-Path: <fm@cadence.com>
>Received: from vaxjo.synopsys.com (localhost [127.0.0.1])
> by mother.synopsys.com (8.9.1/8.9.1) with ESMTP id NAA10970
> for <David.Rich@synopsys.com>; Mon, 1 Dec 2003 13:42:09 -0800 (PST)
>Received: from psmtp.com (exprod6mx40.postini.com [12.158.35.190])
> by vaxjo.synopsys.com (Postfix) with SMTP id 4DBCADAE0
> for <David.Rich@synopsys.com>; Mon, 1 Dec 2003 13:42:08 -0800 (PST)
>Received: from source ([158.140.2.1]) by exprod6mx40.postini.com
>([12.158.35.251]) with SMTP;
> Mon, 01 Dec 2003 13:42:08 PST
>Received: from gda.cadence.com (gda.Cadence.COM [158.140.106.10])
> by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id NAA10500;
> Mon, 1 Dec 2003 13:42:05 -0800 (PST)
>Received: from pc-fm.cadence.com (d158140105178 [158.140.105.178])
> by gda.cadence.com (8.10.1/8.8.5) with ESMTP id hB1Lg4L02809;
> Mon, 1 Dec 2003 16:42:04 -0500 (EST)
>Message-Id: <5.0.2.1.2.20031201163654.02d8b110@phenix.cadence.com>
>X-Sender: fm@phenix.cadence.com
>X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
>Date: Mon, 01 Dec 2003 16:42:04 -0500
>To: Dave Rich <David.Rich@synopsys.COM>
>From: Francoise Martinolle <fm@cadence.com>
>Subject: Re: [sv-bc] issue 14
>Cc: sv-bc@eda.org
>In-Reply-To: <3FC52B9C.4070300@synopsys.com>
>References: <5.0.2.1.2.20031126153247.02de98a8@phenix.cadence.com>
> <5.0.2.1.2.20031126153247.02de98a8@phenix.cadence.com>
>Mime-Version: 1.0
>Content-Type: text/plain; charset="iso-8859-1"; format=flowed
>X-Received: By mailgate.Cadence.COM as NAA10500 at Mon Dec 1 13:42:05 2003
>X-pstn-levels: (S:39.4150 R:95.9108 P:95.9108 M:98.5141 C:79.5348 )
>X-pstn-settings: 3 (1.0000:2.0000) r p m C
>X-pstn-addresses: from <fm@cadence.com> [164/6]
>Content-Transfer-Encoding: 8bit
>X-MIME-Autoconverted: from quoted-printable to 8bit by mother.synopsys.com
>id NAA10970
>
>At 02:39 PM 11/26/2003 -0800, Dave Rich wrote:
>>Françoise,
>>
>>If I say
>>
>>typedef bit node;
>
>This is a definition as I don't have to analyze further what is "bit". The
>type bit is locally known.
>
>
>>Is that a definition or an alias? Isn't an alias a definition also.
>>
>>If you treat an interface more like a type, and less like a module,
>>referring to a type is not a true XMR/OOMR/NID/XREF. Since the interface
>>must be connected to an instance declaration, the resolution is no
>>different than that of a type parameter.
>
>I see, it is a type parameter.
>
>
>>FYI, the reason the typedef is needed at all is syntactical, I am told.
>>
>>Dave
>>
>>Francoise Martinolle wrote:
>>
>>>We talked about this issue at the last meeting and we said that if a
>>>type is defined in an interface and used in a module which passes this
>>>interface as aport, this type must be redefined locally.
>>>
>>>I thought we meant that we needed an actually redefinition of the type
>>>but when I looked at the example given it shows an alias of the type and
>>>not a redefinition.
>>>interface intf_i;
>>> typedef int data_t;
>>>endinterface
>>>
>>>module sub(intf_i_i p)
>>> typedef p.data_t my_data_t;
>>> my_data_t data; //type of 'data'' will be int when connected to
>>> interface above
>>>endmodule
>>>
>>>Instead of typedef p.data my_data_t; This is just creating an alias
>>>without saying anything about the actual type.
>>>
>>>I would have expected to find the typedef REDEFINED in the module as an
>>>int so that we know it is an int without having to elaborate the interface.
>>>
>>>typedef int p.data_t; This is telling me that the type data_t defined in
>>>the interface p is an int.
>>>
>>>Otherwise we still have XMR to typedefs.
>>>
>>>Francoise
>>> '
>>
>>--
>>--
>>David.Rich@Synopsys.com
>>Technical Marketing Consultant
>>http://www.SystemVerilog.org
>>tele: 650-584-4026
>>cell: 510-589-2625
>>
>>
>
>
>
>
>Return-Path: <owner-sv-bc@eda.org>
>Received: from kiruna.synopsys.com (localhost [127.0.0.1])
> by maiden.synopsys.com (8.9.1/8.9.1) with ESMTP id QAA00355;
> Mon, 1 Dec 2003 16:31:13 -0800 (PST)
>Received: from psmtp.com (exprod6mx15.postini.com [12.158.35.155])
> by kiruna.synopsys.com (Postfix) with SMTP
> id DA147F6AF; Mon, 1 Dec 2003 16:31:11 -0800 (PST)
>Received: from source ([171.67.16.117]) by exprod6mx15.postini.com
>([12.158.35.251]) with SMTP;
> Mon, 01 Dec 2003 16:31:11 PST
>Received: from cis.Stanford.EDU (cis.Stanford.EDU [171.64.100.178])
> by smtp3.Stanford.EDU (8.12.10/8.12.10) with ESMTP id hB20UY7m006462;
> Mon, 1 Dec 2003 16:30:35 -0800
>Received: from server.eda.org (eda.ORG [171.64.101.101])
> by cis.Stanford.EDU (Postfix) with ESMTP
> id 2B6DD37925; Mon, 1 Dec 2003 16:30:32 -0800 (PST)
>Received: by server.eda.org (8.12.0.Beta7/8.12.0.Beta7) id hB20TKfB000986;
> Mon, 1 Dec 2003 16:29:20 -0800 (PST)
>Reply-To: <Brad.Pierce@synopsys.COM>
>From: "Brad Pierce" <Brad.Pierce@synopsys.COM>
>To: <sv-bc@eda.org>
>Subject: Re: [sv-bc] Question about proposal for SV-BC Issue 98
>Date: Mon, 1 Dec 2003 16:27:10 -0800
>Message-ID: <HPECIHFPOFICGBKPKCGMMEKEDJAA.bpierce@synopsys.com>
>MIME-Version: 1.0
>Content-Type: text/plain;
> charset="us-ascii"
>Content-Transfer-Encoding: 7bit
>X-Priority: 3 (Normal)
>X-MSMail-Priority: Normal
>X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
>In-Reply-To: <3FC3D643.1060207@bluespec.com>
>Importance: Normal
>Sender: owner-sv-bc@eda.org
>Precedence: bulk
>X-pstn-levels: (S:63.7094 R:95.9108 P:95.9108 M:97.0282 C:79.5348 )
>
>Nikhil,
>
>Yes, that was my intent. Likewise,
>
> parameter_port_list
> #( parameter_port_declaration )
> #( data_type list_of_param_assignments )
> #( real param_assignment , param_assignment )
> ...
> #(real X = 5.0, Y = 6)
>
>vs.
>
> parameter_port_list
> #( parameter_port_declaration , parameter_port_declaration )
> #( data_type list_of_param_assignments , data_type
>list_of_param_assignments )
> #( real param_assignment , real param_assignment )
> ...
> #(real X = 5.0, real Y = 6)
>
>This is similar to
>
> function f ( real X = 5.0, Y = 6 ) ;
>vs.
> function f ( real X = 5.0, real Y = 6 ) ;
>
>-- Brad
>
>-- Brad
>
>-----Original Message-----
>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of
>Rishiyur S. Nikhil
>Sent: Tuesday, November 25, 2003 2:23 PM
>To: sv-bc@eda.org
>Subject: [sv-bc] Question about proposal for SV-BC Issue 98
>
>
>Just trying to understand the implications of our decision
>to allow the 'parameter' keyword to be omitted in parameter port lists
>(SV-BC Issue 98).
>
>Consider the following, in the original syntax:
>
> #(parameter real X = 5.0, parameter Y = 6)
>
>I believe the type of Y becomes an integral type (int? integer?).
>In particular, its type has nothing to do with the earlier param.
>
>But if I simply drop the 'parameter' keywords:
>
> #(real X = 5.0, Y = 6)
>
>then will 'X = 5.0, Y = 6' be parsed as the list_of_param_assignments
>associated with 'real, thereby giving Y the 'real' type with default
>value 6.0?
>
>So, must I now give an explicit type for Y to avoid it being 'captured'
>by the preceding 'real' type?
>(This is probably good style, anyway.)
>
>Nikhil
This archive was generated by hypermail 2b28 : Mon Dec 08 2003 - 11:25:55 PST