Jump to content

Recommended Posts

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

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×