Constrained Random Verification with VHDL

Discussion in 'VHDL' started by JimLewis, Apr 10, 2009.

  1. JimLewis

    JimLewis Guest

    I have just released the packages we use for doing constrained random
    verification with VHDL at
    http://www.synthworks.com/downloads/index.htm

    You will also find the slides from the webiniar I did with Aldec which
    will give you ideas at how to apply them.

    The package uses VHDL-2002 protected types and work with any simulator
    that supports them. I have tested them with Active-HDL, Riviera, and
    ModelSim.

    There are places where the procedures need to be able to work with
    variable sized sets of integer values. To do this I used an
    unconstrained integer array input to the subprograms. Since there is a
    type named integer_vector that does this in VHDL-2008, I decided to
    leverage that. So for a short time, there will be two sets of packages
    - one that references package ieee_proposed.standard_additions and
    another that requires one to use the VHDL-2008 switch on your
    compiler.

    Cheers,
    Jim
    SynthWorks VHDL Training
     
    JimLewis, Apr 10, 2009
    #1
    1. Advertisements

  2. Mike Treseler, Apr 11, 2009
    #2
    1. Advertisements

  3. JimLewis

    Andy Guest

    Jim,

    Nice work!

    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).

    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.

    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. This naming convention works well in C
    and other languages, but not in VHDL. Regardless, I believe efforts
    bound for standardization should stick to the naming conventions
    already present in the standard packages.

    Andy
     
    Andy, Apr 13, 2009
    #3
  4. JimLewis

    JimLewis Guest

    Andy,
    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).

    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.

    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.
    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.
    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).
     
    JimLewis, Apr 13, 2009
    #4
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.