Problems? Suggestions?

Why OSVVM™? Forums OSVVM Problems? Suggestions?

This topic contains 7 replies, has 5 voices, and was last updated by Avatar of Mark Mark 3 years, 1 month ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #51

    Something doesn’t work in OS-VVM? Would you like to add/change something in this methodology?
    Let us know: add reply below or create new topic…

    • This topic was modified 6 years, 12 months ago by Avatar of Jerry Kaczynski Jerry Kaczynski.
    • This topic was modified 6 years, 12 months ago by Avatar of Jerry Kaczynski Jerry Kaczynski. Reason: Changed stickyness
    • This topic was modified 6 years, 12 months ago by Avatar of Jerry Kaczynski Jerry Kaczynski. Reason: Extended text
    • This topic was modified 6 years, 12 months ago by Avatar of Jerry Kaczynski Jerry Kaczynski.
    #453
    Avatar of vio123
    vio123
    Member

    *Hi Jerry,

    why not providing the OS-VVM lib in its own libray, like the IEEE stuf

    -> compile it to OSVVM

    at the moment all stuf is compiled to lib work

    Looking at the CoveragePkg.vhd :

    use work.RandomPkg.all ;               
    use work.RandomBasePkg.all ;

    package CoveragePkg is
    ….

    I expected to see this :

    library OSVVM;

    use OSVVM.RandomPkg.all ;               
    use OSVVM.RandomBasePkg.all ;

    #614

    *Jerry/Jim,

      A rather generic, non-technical remark/observation – this forum is hard to locate from the front/landing page of osvvm.org – it is there as a small link at the bottom of front page.

    How about adding it as a menu item/toolbar – similar to the other links (see below).

    Thanks

    Srini

    #624
    Avatar of Jim Lewis
    Jim Lewis
    Member

    Hi Vio123,

    In VHDL, the logical library name “work” is special.  It actually refers to the current working library (aka:  the library into which this design unit is compiled). 

    As a result, if the packages SortListPkg_int, RandomBasePkg, RandomPkg, and CoveragePkg are all compiled into the osvvm library,  then CoveragePkg may reference RandomPkg as being in either library work or osvvm.  Both are correct. 

    On the other hand, your programs that are not compiled into the osvvm library will need to reference the packages as being in the osvvm library. 

    As we move toward tools including a precompiled osvvm library, this is important.  When I am testing out release candidates, I need to be able to compile the packages into my own private library that does not corrupt the tool build.  Since they reference each other as being in work, the language allows me to put them in a different library name for development.  The only thing that needs to know this different library name is my testbenches.  Then when I release them, they are all set to be put into the osvvm library.

    Best Regards,
    Jim

    P.S. If your training vendor is not teaching you this, you should consider a class from SynthWorks (http://www.synthworks.com)

    • This reply was modified 5 years, 10 months ago by Avatar of Jim Lewis Jim Lewis.
    #626

    *Jim,

      Not sure if I fully understood your problem, but to me it looks like you need a “custom” OSVVM lib while testing release candidates than the tool’s built-in version. If yes, how about simply asking tool to point to your dir? In case of Riviera-Pro for instance:

    osvvm = “../Jim_LATEST_OSVVM//osvvm.lib”

    Then you could use vcom -work osvvm <os_vmm_src.vhdl>

    Or maybe I am missing something in your problem statement?

    Srini

    http://www.cvcblr.com/blog&nbsp;

    #654
    Avatar of Jim Lewis
    Jim Lewis
    Member

    Hi Srini,

    I have no problems.  I was just explaining why it is correct VHDL when I use the library work rather than library osvvm in the CoveragePkg.  This works well for me and it works well for the OSVVM library. 

    OTOH the examples should not be compiled into the same library and should be referring to CoveragePkg and RandomPkg as being in library osvvm.   Jerry will be changing this in a future release.

    Jim

    #1097
    Avatar of Mark
    Mark
    Member

    I’m just starting to use the Affirmations. 

    I think it would be good if this more closely followed the Alerts and provided AffirmEqual and AffirmNotEqual. This would then give some more information in the log/transcript as to what values are being checked and what the result was.

    If I have:

    AffirmIf((packetCount = 10),”Check Packet Count”);

    Then if the affirmation is true and get a log I don’t know what value was tested, and if it isn’t true also don’t know what value caused the error.

    Mark

    #1113
    Avatar of Mark
    Mark
    Member

    When using ReadLogEnables to select what logging is enabled any logs that are enabled descend down the hierarchy. As you can only set not disable logs in a file this means that I can’t enable logging near the top of my hierarchy without this pushing all the way down to the bottom.

    Would it be possible to change the ReadLogEnables so that it only enabled the specified log levels for each ID. Any un-specified log levels would be disabled.

    This would allow a file that listed all the IDs in my design, and I just need to add which logging levels I want for each ID.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.