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 9 years, 4 months ago by Andy Jones.
May 24, 2013 at 03:48 #628
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/May 26, 2013 at 11:54 #642
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.
JimMay 31, 2013 at 02:16 #652
Are you thinking of a version were each element of the resulting array has individual constraints?
should be simple to add. I’ll see if I find the time to push an updated version.May 31, 2013 at 07:08 #653
> 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 #665
I pushed a new version to my fork which adds
RandRealVectorand fixes a couple of syntax error in the
Exclude does not work for
RandRealVectorbecause I haven’t modified
SortListPkg_int. I suggest we add one
SortListPkg_realfor VHDL-2002 compatibility, and then switch to the generic package by default.June 13, 2013 at 10:39 #666
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.July 10, 2013 at 23:10 #690
Do you have any additional comments on the
RandIntegerVectorcode? Is the naming acceptable, or do you think I should rename them to
RandIntVec?December 23, 2013 at 10:57 #730
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.
JimJanuary 16, 2014 at 21:19 #735Andy JonesMember
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.
AndyJanuary 16, 2014 at 22:47 #736
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.
JimJanuary 18, 2014 at 08:50 #739Andy JonesMember
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.
- You must be logged in to reply to this topic.