Why OSVVM™? Forums OSVVM RandTime

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
  • #731
    Jim Lewis

    For the next release I am looking at adding RandTime.  In some ways it is just a short hand for:

    RV.RandInt(…) * 1 ns

    Maybe this is the best way.  What I see for the interface of RandTime is:

      impure function RandTime (Min, Max : time) return time ;
      impure function RandTime (Min, Max : time ; Unit : in time) return time ;

    What is of concern is when units are not specified (or we use a default) should the default be ns, similar to write or should the default be the current simulation resolution? If you want direct control, you can use the overloading and specify the units.

    I think I am leaning toward “ns” as default. Mainly for stability of testbenches since many RTL simulations use a simulator resolution of ns while gate level simulation use a resolution of ps. If we use simulator resolution, then testbenches will run differently when someone changes the defaults.

    Once the above is resolved, I plan on adding overloading for:

      -- shown using ns as default rather than sim_resolution
      impure function RandTime (Min, Max : time ; Exclude: time_vector ; Unit: in time := ns) return integer ;
      -- these do not require units
      impure function RandTime (A: time_vector) return time ;
      impure function RandTime (A, Exclude: time_vector) return time ;


    Andy Jones

    I think 1 ns is a reasonable default unit.

    If you default the exclude parameter to a null time_vector, then do you need versions without exclude? Same for units?

    If you wanted no excludes but ms units, you’d have to use named association for the units param.


    Jim Lewis

    Thanks for the feedback. 

    In the current code, the functions that have the Unit parameter, default it to 1 ns and put it last.  The functions without the Unit parameter don’t need it since they use a set rather than a time value.

    The exclude parameter could be defaulted, however, from a code execution point of view, it is a little more efficient to provide two separate functions.

    Again, I think the final package will help you see what was implemented.   If you think you see a cleaner or simpler implementation, let me know. 


Viewing 3 posts - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.