Andy,
Consider support for fixed and/or floating point types? I guess a
separate package of functions for those types could be defined that
simply converts to arguments SLV/signed/unsigned and calls this
package's functions. Ideally, I suppose there should be separate
packages for each set of types (std_logic, numeric_std, numeric_bit,
fixed_point, floating_point).
I considered it. There is a road block in that each
package instance creates a new type, and hence, it is not
really possible for general support.
I think there may also be other issues WRT larger (> 62 bits)
numbers. The seeds for uniform are 62 bits. Can a 62 bit
seed generate numbers that are bigger than 62 bit that cover
the entire value set?
Instead of trying to answer this question, I separated out
RandomBasePkg to allow the seeds, the base randomization
(currently uniform) and any customizations (currently
FAVOR_SMALL and FAVOR_BIG) to be easily changed without
having to worry about disturbing the rest of RandomPkg.
Long term, I expect RandomBasePkg to evolve to address
common customizations and maybe to handle an extended
range of numbers (if it does not adversely effect performance).
I was also thinking that RandomSeedType, RandomModeType and
randomize could be passed as package generics to the
package (unless generics get added to protected types/classes
in the future - in which case, add them there).
Given that the range of valid values for the elements of
RandomSeedType is constrained to much less than that of integer, why
did you choose integer_vector as its base type? Seems like a custom
type would be more useful (bounds checking), and less of a hassle
given the current status of integer_vector. Just like we have multiple
standard types of vectors of SL for different purposes, I see no
reason why we should not have different types of vectors of integer,
especially when there are different ranges to be enforced on the
elements.
For the seeds that makes sense. Changing it to a record with
constrained
subtypes of integer would be transparent since an aggregate is used
to
set the seeds.
However, since other things use integer vector (randomizing sparse
sets of numbers and exclude vectors), it does not remove the need for
an integer array type. I thought that long term, using one type for
this application would make it easier to keep general.
Use of capitalization (instead of '_') for word separation in
identifiers is not in keeping with current ieee standard packages. If
this is intended for eventual inclusion in the ieee standard (I think
it should be), will these identifiers require changing? Just one of
my pet peeves, but I do not recommend naming conventions that use
capitalization (especially mixed) in a language that ignores
capitalization in identifiers.
My pinky finger curses the person that put the '_' key in such an
inconvenient place on the key board. Shift key is so much easier.
In being nice to my fingers, I adopted mix cased names for signals,
variables, and subprograms.
This naming convention works well in C and other languages, but
not in VHDL.
I would disagree. VHDL makes things safer by allowing only one
spelling of a name to be visible whether it is mixed or all lower
case with '_'. Whether you use '_' or mixed case in VHDL, it is
nothing more than a visual thing. Sure '_' forces one to make
the subprogram calls more readable, but if this is your only
mechanism to force people to write readable code you are in
real trouble.
Regardless, I believe efforts bound for standardization should
stick to the naming conventions already present in the standard
packages.
While I want to standardize them with IEEE, I do not think they are
a practical solution. To be able to display the contents of VHDL
packages in tools, either the standards WG (which has no money) or
the vendors need to pony up a significant amount of money ($15K -
60K)
to IEEE-SA. As the IEEE VHDL chair, I have already invested time
into looking into this issue and IEEE does not seem to be flexible.
I am thinking that they need to remain open source. That would
allow vendors to distribute them and all to use them and see the
packages and/or documentation.
Perhaps then we need to form a separate organization for peer review.
I have several other packages that I will also be releasing. While
I not too excited about switching naming styles within a large set
of packages and my pinky finger is even less excited, I may be
able to be swayed. However, perhaps this is the difference between
the packages developed by the different organizations.
Note that I also have legacy considerations as we also have been
distributing these packages to students in our training classes
for several years now.
Best,
Jim
P.S.
IEEE is great for working on the base standard and I am hoping
we can add more verification features to the language (such
as classes and declarative class based randomization).
