RE: [sv-bc] RE: SV 2012: Is forward typedef of nettype supported in SV

I share Gordon's concerns about the differences between a nettype and a data type.  During the brief discussion, I proposed the idea of a nettype parameter that was distinct from a type parameter.

Another issue that was briefly discussed was "type introspection" for nettypes.  This could include the ability to declare a net with the same nettype as a given net, perhaps one coming in through an interface port.  And it could include the ability to extract the data type part of a nettype, to declare a variable having the same data type.


From: Gordon Vreugdenhil [mailto:gordonv@model.com]
Sent: Thursday, October 30, 2014 10:23 AM
To: Bresticker, Shalom; Steven Sharp; Datta, Kausik; sv-bc@eda.org
Subject: Re: [sv-bc] RE: SV 2012: Is forward typedef of nettype supported in SV

The concept of "nettype" as a parameter was briefly discussed at the time.  Part of my concern is that "nettype" incorporates both the "net" aspect and the "type" aspect.  So it really isn't a "type".  If "nettype" were a "type",  things like "wire" or "wand" should also be "types".

While we could explore something like that, the implications might be pretty significant.  And it might not really be necessary since I suspect that in most cases where one would really want a parametric "nettype", one might just use an interconnect anyways.  We'll have to explore those options in the next PAR.

I prefer to think about the data "type" and the full "nettype" differently and would, at least for now, want to only permit the data type part in a type parameter.

Gord
On 10/30/14, 12:53 AM, Bresticker, Shalom wrote:
I filed this suggestion now as Mantis 5053.

From: Steven Sharp [mailto:sharp@cadence.com]
Sent: Thursday, October 30, 2014 09:40
To: Bresticker, Shalom; Datta, Kausik; sv-bc@eda.org<mailto:sv-bc@eda.org>
Subject: RE: SV 2012: Is forward typedef of nettype supported in SV

Agreed.

Nor is there any actual need for a forward nettype declaration.  Forward typedefs are only actually needed for declaring mutually recursive data types, such as two classes that each contain a handle of the other class type.  Since there is no way to declare a handle or pointer that refers to a net, there is no way to create such a recursive type that includes a nettype.

I brought up in committee the possibility of nettype parameters.  However, attention was focused on getting the basics of nettypes defined first.


From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org] On Behalf Of Bresticker, Shalom
Sent: Thursday, October 30, 2014 3:30 AM
To: Datta, Kausik; sv-bc@eda.org<mailto:sv-bc@eda.org>
Subject: [sv-bc] RE: SV 2012: Is forward typedef of nettype supported in SV

No.
Both typedefs and type parameters use the data_type BNF, which does not include nettypes.

Shalom

From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org] On Behalf Of Datta, Kausik
Sent: Thursday, October 30, 2014 09:22
To: sv-bc@eda.org<mailto:sv-bc@eda.org>
Subject: [sv-bc] SV 2012: Is forward typedef of nettype supported in SV

Hi,
I have the following queries:


1.      Can NetType be used as forward typedef?

2.      Can NetType be passed in type parameter?

Forward typedef and parameterized type are useful way to declare generic type in SV which can be resolved later. Does this mechanism hold true for NetType also?
Exmaple 1:                                                                                                                                                                      < o:p>
...
typedef T;
T obj;
...
nettype logic T;
...

Example 2:
module bot #(type T1, type T2)
                      (input T1 in, output T2 out);
//...
endmodule

module top();
    typedef logic T2;
    nettype logic T1;

    T1 p;
    T2 q;

    bot #(T1, T2) b1 (p, q);
endmodule

Thanks
Kausik



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

---------------------------------------------------------------------
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<http://www.mailscanner.info/>, and is
believed to be clean.

---------------------------------------------------------------------
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<http://www.mailscanner.info/>, and is
believed to be clean.



--

--------------------------------------------------------------------

Gordon Vreugdenhil                                503-685-0808

Verification Technologies, Mentor Graphics        gordonv@model.com<mailto:gordonv@model.com>

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