Patch: Support for random integer_vector

[Trond Danielsen]

Hi, I have created a patch for OS-VVM that adds support for random <code>integer_vector</tt> types. If anyone is interested the code can be found here: http://code.google.com/r/tronddanielsen-open-vhdl-devel/

[Jim Lewis]

Do you think we should add the option of generating Size number of unique integers?  SortListPkg_int has a sort, should we make it visible in RandomPkg?   I can add an alias?  Perhaps also need reverse sort.

Do we need to do the same thing for real_vector?

On my list for the next revision is RandTime.

Jim

[Trond Danielsen]

Are you thinking of a version were each element of the resulting array has individual constraints?

rand_real

should be simple to add. I’ll see if I find the time to push an updated version.

[Jim Lewis]

> Are you thinking of a version were each element of the resulting array has individual constraints?

No.  Just one range specification that never produces the same number more than once.  It is a simple modification that puts the numbers generated into the exclude list.  

[Trond Danielsen]

I pushed a new version to my fork which adds RandRealVector and fixes a couple of syntax error in the RandIntegerVector code.

Exclude does not work for RandRealVector because I haven’t modified SortListPkg_int. I suggest we add one SortListPkg_int and one SortListPkg_real for VHDL-2002 compatibility, and then switch to the generic package by default.

[Jim Lewis]

I suspect we can leave out the exclude for real vectors right now.  Exclude with a real number requires a range rather than a specific value. 

I don’t think generics will support SortListPkg_int yet.  Currently a generic type has no means to know if a type is an array type or not and indexing is not allowed.   The 1076 WG is looking at this issue and hopefully will have a proposal for the next revision.

[Trond Danielsen]

Do you have any additional comments on the RandIntegerVector code? Is the naming acceptable, or do you think I should rename them to RandIntVec?

[Jim Lewis]

Edit note:  12/31  Revised RandIntV unique parameter to be type natural rather than boolean.

I am looking at getting these into the 2013.12 or 2014.01 release.  @Trond, I cannot access your google code repository.  I have written my own versions.  What has me perplexed is how to handle generating a vector vs. a unique vector result.  

My current RandIntV is:

    impure function RandIntV (Min, Max : integer ; Unique : natural ; Size : natural) return integer_vector is
      variable result : integer_vector(1 to Size) ;  
    begin
      -- if Unique = 0, it is more efficient to call RandIntV(Min, Max, Size)
      for i in result'range loop 
        result(i) := RandInt(Min, Max, result(maximum(1, 1 + i - Unique) to Size)) ; 
      end loop ; 
      return result ; 
    end function RandIntV ; 

What bothers me is should it be one function with a parameter (perhaps optional) or should it be two separate functions, like RandIntV and RandIntVU (for unique).  Not really liking either one.
The problem as I see is that we need these for (min,max), (min,max,exclude), (vector) and (vector, exclude):

    impure function RandIntV (Min, Max : integer; Size : natural) return integer_vector ;
    impure function RandIntV (Min, Max : integer; Unique : natural; Size : natural) return integer_vector ;
    impure function RandRealV (Min, Max : real; Size : natural) return real_vector ;

    impure function RandIntV (Min, Max : integer; Exclude : integer_vector ; Size : natural) return integer_vector ;
    impure function RandIntV (Min, Max : integer; Exclude : integer_vector ; Unique : natural; Size : natural) return integer_vector ;
-- no excludes for real vectors 

    impure function RandIntV (A : integer_vector ; Size : natural) return integer_vector ;
    impure function RandIntV (A : integer_vector ; Unique : natural; Size : natural) return integer_vector ;
    impure function RandRealV (A : real_vector ;   Size : natural) return real_vector ;


    impure function RandIntV (A : integer_vector ; Exclude: integer_vector ; Size : natural) return integer_vector ;
    impure function RandIntV (A : integer_vector ; Exclude: integer_vector ; Unique : natural; Size : natural) return integer_vector ;
-- no excludes for real vectors 

Any input appreciated.

Jim

[Andy Jones]

Why is it desired to have, for all of the variants of RandIntV(), size as the last parameter, when it is always required? 

If the additional (optional) parameters were last, then they could be defaulted, while still allowing positional notation, and fewer functions could be defined, thereby reducing maintenance and code bulk.

Unique and exclude could be defaulted to 0 and a null vector, respectively.

Andy

[Jim Lewis]

Andy,

Thanks for the feedback.

My first goal is to be consistent with RandInt, RandUnsigned, and RandSigned.  So that gives us a basic order of (Min, Max, Size), (Min, Max, Exclude, Size), (Set, Size), and (Set, Exclude, Size) where Set and exclude are type integer_vector..  So Unique needs to be in there somewhere.  You could argue to put it at the end.  However, I am not sure I would default it to 0 as I like handling the two cases separately – having the Unique parameter requires adding an exclude vector – which you do not want to do unless you have to.  So I decided to put Size at the end as this seems an easier rule to remember (for all the functions that use size, size is at the end).  Well this is almost true, as with RandTimeV, I did put Unit last and defaulted it to 1 ns.

I sent you an advanced copy of the packages so you can review them and see if you agree or not.  They are done and passing regressions. 

Even if they had defaulted parameters, I still have to test all the variations and the error conditions – and this seems to take as much or more time than writing the functions themselves. 

Jim

[Andy Jones]

Yeah, mentor graphics survey indicates design verification takes more than twice the  effort of design itself (70% of total project)

Just because you have a default parameter does not mean that you can’t have a simple check on the parameter and choose an optimal algorithm base on its value. 

With separate functions you have to test the erstwhile default value case on two different functions (uless you test the value in the larger function and call the smaller function from within the larger one.)

But consistency with precedents is extremely important for usability. Even if defaulted parameters are not in the optimal order to allow simpler use of positional association, they still come in handy for named association. 

Andy

[Author]

Posts