Patch: Support for random integer_vector
Why OSVVM™? › Forums › OSVVM › Patch: Support for random integer_vector
 This topic has 10 replies, 3 voices, and was last updated 7 years ago by Andy Jones.

AuthorPosts

May 24, 2013 at 03:48 #628Trond DanielsenMember
Hi, I have created a patch for OSVVM 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/tronddanielsenopenvhdldevel/
May 26, 2013 at 11:54 #642Jim LewisMemberDo 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
May 31, 2013 at 02:16 #652Trond DanielsenMemberAre 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.
May 31, 2013 at 07:08 #653Jim LewisMember> 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.
June 13, 2013 at 01:15 #665Trond DanielsenMemberI pushed a new version to my fork which adds
RandRealVector
and fixes a couple of syntax error in theRandIntegerVector
code.Exclude does not work for
RandRealVector
because I haven’t modifiedSortListPkg_int
. I suggest we add oneSortListPkg_int
and oneSortListPkg_real
for VHDL2002 compatibility, and then switch to the generic package by default.June 13, 2013 at 10:39 #666Jim LewisMemberI 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.
July 10, 2013 at 23:10 #690Trond DanielsenMemberDo you have any additional comments on the
RandIntegerVector
code? Is the naming acceptable, or do you think I should rename them toRandIntVec
?December 23, 2013 at 10:57 #730Jim LewisMemberEdit 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
January 16, 2014 at 21:19 #735Andy JonesMemberWhy 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
January 16, 2014 at 22:47 #736Jim LewisMemberAndy,
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
January 18, 2014 at 08:50 #739Andy JonesMemberYeah, 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

AuthorPosts
 You must be logged in to reply to this topic.