Jonathan, You're right. My attempted example was LRM-illegal. >the current LRM does not appear to permit >the creation of a type parameter that is an unpacked array type Yes, also right -- the data_type of A.2.2.1 cannot denote an unpacked array type, except as a type_identifier or type_reference, for example, typedef int T1[16]; localparam type T2 = T1; var int v[16]; localparam type T3 = type(v); class C#(parameter type PT = logic, parameter N = 0); typedef PT T[N]; endclass:C localparam type T4 = C#(int,16)::T; -- Brad -----Original Message----- From: Jonathan Bromley [mailto:jonathan.bromley@doulos.com] Sent: Saturday, June 09, 2007 10:49 AM To: Brad Pierce; sv-bc@eda-stds.org Subject: RE: [sv-bc] Proposal for 1134: Localparam in parameter_port_list Brad, > Your proposal would not allow > > module test#( > parameter N = 16, > localparam lgN = $clog2(N), > parameter type T1 [lgN], > parameter type T2 [lgN]) Indeed so. If it is the consensus of sv-bc that we should permit arbitrary interleaving of parameter and localparam in the port list then I'm willing to rewrite the proposal, although personally I'm opposed to it. I can't find any authority in the LRM (draft 3a) for your syntax parameter type T [N] Is this the subject of a sv-bc Mantis item that I've missed? Certainly there is an issue that the current LRM does not appear to permit the creation of a type parameter that is an unpacked array type. I had assumed that this was intentional, to avoid any possibility of a parameter override changing the unpacked dimensionality of a data item. -- 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.Received on Sat Jun 9 22:38:19 2007
This archive was generated by hypermail 2.1.8 : Sat Jun 09 2007 - 22:38:46 PDT