RE: [sv-bc] RE: Q: [N] array bounds legal for unpacked but not packed arrays?

As a matter of historical accuracy, this feature does not come from
Superlog.  

 

It may have come from Vera, but I cannot check this since the reference
manual seems to have gone off line.

 

I agree that specifying a size rather than a range for packed arrays could
be confusing.

 

Peter

 

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Stuart
Sutherland
Sent: 30 September 2014 23:58
To: sv-bc@eda.org
Subject: RE: [sv-bc] RE: Q: [N] array bounds legal for unpacked but not
packed arrays?

 

The ability to declare an unpacked array by specifying a size instead of a
range comes from the SuperLog language circa 2001, which was the initial
donation that eventually led to SystemVerilog.  As an instructor, I have
found that most verification engineers who come from a software background
prefer the C-like syntax of declaring arrays by specifying a size instead of
a range.  It is us hardware types that tend to prefer the older Verilog
style, in part because storage in hardware can start with a hardwired
address other than 0.  None of this history really matters, of course.  The
C-like unpacked array declaration is in the standard, and it is used.  I am
surprised, though, to learn that some tools accept the C-like size
declaration syntax for packed arrays.  That simply does not make sense for
vector declarations, was never part of SuperLog or the Accellera version of
SystemVerilog.  

 

Stu

~~~~~~~~~~~~~~~~~~~~ 

Stuart Sutherland

Sutherland HDL, Inc.

+1-503-692-0898

 

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Rich,
Dave
Sent: Tuesday, September 30, 2014 1:58 PM
To: Brad Pierce; sv-bc@eda.org
Subject: [sv-bc] RE: Q: [N] array bounds legal for unpacked but not packed
arrays?

 

The current [0:N-1] ordering was chosen to match array index ordering in
C/C++. 

 

IMHO, [N] should never been allowed as a shortcut in a language that already
supported ranges in either order because of the confusion it creates. Erik's
workaround example is proof of that.

 

But it's too late to change the default range order now for an unpacked
array now.

 

Dave

 

 

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Brad
Pierce
Sent: Tuesday, September 30, 2014 1:44 PM
To: sv-bc@eda.org
Subject: [sv-bc] RE: Q: [N] array bounds legal for unpacked but not packed
arrays?

 

[In reply to http://www.eda.org/sv-bc/hm/11620.html .]

 

The current [0:N-1] default for unpacked array dimensions is also
significant (and annoying). With the hardware order [N-1:0] you can
split/merge dimensions fluidly, as in

 

typedef struct {int x, y;} T;

 

module test#(N=2,M=3)

(   output T A_2D[(2**N)-1:0][(2**M)-1:0]

,   output T A_1D[(2**(N+M))-1:0]

);

 

 

logic [N-1:0] idx_N;

logic [M-1:0] idx_M;

 

always_comb begin

   for (int i = 0; i < 2**N; i++) begin

     for (int j = 0; j < 2**M; j++) begin

       idx_N = i;

       idx_M = j;

       A_2D[idx_N][idx_M] = '{i,j};

       A_1D[{idx_N,idx_M}] = '{i,j};

       assert final (A_2D[idx_N][idx_M] == A_1D[{idx_N,idx_M}]);

     end

   end

end

    

endmodule

 

But with the [0:N-1] default you need to flip the order of dimensions in the
indexes, as in

 

typedef struct {int x, y;} T;

 

module test#(N=2,M=3)

(   output T A_2D[0:(2**N)-1][0:(2**M)-1]

,   output T A_1D[0:(2**(N+M))-1]

);

 

logic [N-1:0] idx_N;

logic [M-1:0] idx_M;

 

always_comb begin

   for (int i = 0; i < 2**N; i++) begin

     for (int j = 0; j < 2**M; j++) begin

       idx_N = i;

       idx_M = j;

       A_2D[idx_N][idx_M] = '{i,j};

       A_1D[{idx_M,idx_N}] = '{i,j};

      assert final (A_2D[idx_N][idx_M] == A_1D[{idx_M,idx_N}]);

     end

   end

end

 

endmodule

 

-- Brad

 


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


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


-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> 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.