fixed-size arrays : Do they not 'support' size()?

[ljepson74]

Do fixed-size arrays not support .size()?

 

Or, am I doing smthg wrong below?

Running irun 13.1, I am told that .size() "is not a valid built in method name for this object".

 

 

If they do not, is this b/c 

 a. the expectation is that someone used a parameter/constant to specify the size of the array and that they can just use it everywhere else they might need it

 b. fixed sizes arrays were part of pre-SystemVerilog Verilog and as such missed this convenient feature.

?

 

Just before publishing, I discovered section "20.7 Array querying functions" in the 1800-2012.pdf, SystemVerilog spec:  $size()

 

module top;
   int farray[10];  //fixed array

   initial begin
//1    for (int jjj=0; jjj<10; jjj++) begin             //works
/*2*/  for (int jjj=0; jjj<farray.size(); jjj++) begin  //doesn't work
//3    for (int jjj=0; jjj<$size(farray); jjj++) begin  //works
          farray[jjj] = $urandom_range(121,0);
       end

      $display("******************************");
      for (int jjj=0; jjj<10; jjj++) begin
         $display("%0d: %0d",jjj,farray[jjj]);
      end
   end
endmodule : top

 

[dave_59]

It is not currently legal. The reason it's not legal is because SystemVerilog was designed by committee. See http://www.eda.org/svdb/view.php?id=2397

[David Black]

First, before I discuss the problems with SystemVerilog, I would like to point out that you are really missing a much simpler solution to your problem:

module top;
   int farray[10];  //fixed array

   initial begin
       foreach (farray[jjj]) begin
          farray[jjj] = $urandom_range(121,0);
       end

      $display("******************************");
      foreach (farray[jjj]) begin
         $display("%0d: %0d",jjj,farray[jjj]);
      end
   end
endmodule : top 

With respect to "how many elements does my container have?", try the following. Note that you may need to comment out a few lines since the EDA vendor simulators don't all agree on whether some of these should work, and to be fair, the standard is not entirely clear...

module top;
  byte   Fixed_array[3];
  byte   Dynamic_array[] = {10, 20, 30};
  string String = "abc";
  byte   Queue[$] = {40,50,60};
  byte   Assoc_array[string] = '{"a":70,"b":80,"c":90};
  initial $display("Fixed_array size     is %0d", $size(Fixed_array)   );
  initial $display("Dynamic_array size   is %0d", Dynamic_array.size() );
  initial $display("String size          is %0d", String.len()         );
  initial $display("Queue size           is %0d", Queue.size()         );
  initial $display("Assoc_array size     is %0d", Assoc_array.num()    );
  // Alternate approach
  initial $display("$size(Fixed_array  ) is %0d", $size(Fixed_array)   );
  initial $display("$size(Dynamic_array) is %0d", $size(Dynamic_array) );
  initial $display("$size(String size  ) is %0d", $size(String)        ); // May not be legal
  initial $display("$size(Queue size   ) is %0d", $size(Queue)         );
  initial $display("$size(Assoc_array  ) is %0d", $size(Assoc_array)   );
  // Yet another approach
  initial $display("$bits(Fixed_array  ) is %0d", $bits(Fixed_array)   );
  initial $display("$bits(Dynamic_array) is %0d", $bits(Dynamic_array) );
  initial $display("$bits(String size  ) is %0d", $bits(String)        );
  initial $display("$bits(Queue size   ) is %0d", $bits(Queue)         );
  initial $display("$bits(Assoc_array  ) is %0d", $bits(Assoc_array)   ); // Strange result
endmodule

The standard attempts to rationalize away this inconsistency at the bottom of page 45 (85 in the PDF) in the IEEE 1800-2012 standard:[/size][/font][/color][/code]

In general, a built-in method is preferred over a system task when a particular functionality applies to all
data types or when it applies to a specific data type. For example:

dynamic_array.size, associative_array.num, and string.len[/size]

These are all similar concepts, but they represent different things. A dynamic array has a size, an associative
array contains a given number of items, and a string has a given length. Using the same system task, such as
$size , for all of them would be less clear and intuitive.

I for one don't entirely agree with this rationalization. The concepts are all closely related and should have been unified to make the coders job easier.

 
Actually, $size() appears to work with most of them.

[ljepson74]

DB,

 I didn't so much have a problem, as a question, but thanks tremendously for putting together that nice comparision code, showing which simulators/data-types support which methods/tasks.

 

(It'd be great to have a public repository of small examples and a public checkmark-style spreadsheet showing which simulator versions support which constructs/code-samples.  But, as far as I understand, the EDA vendors would prohibit such benchmarking.)

 

I agree that unified naming for these methods/tasks would make our lives easier.