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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...