How to fit non-standard VCs/interfaces within the OSVVM framework

Why OSVVM™? Forums OSVVM How to fit non-standard VCs/interfaces within the OSVVM framework

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
  • #1954

    Good Afternoon,

    I have a generic question regarding how one goes about interfacing with a DUT given a non-standard bus/interface.

    Say for example I have an extremely simple DUT that uses a bus general reads and writes, lets call it DeviceBus, as well as two single bit wide PRBS_out and PRBS_in ports that are not a part of the DeviceBus protocol.

    In this design PRBS_in is connected to PRBS_out, and I want some logic that insert errors into the bit-stream in the testbench.

    From what I have read and understood about OSVVM, the test flow (in a simplified sense) is as follows:

    1) the test_control architectures are where the reads and writes and test stimulus are generated.

    2) the read/write commands are communicated using a MIT record (in this case the AddressBusRecType).

    3) the VC translates the MIT record to whatever interface the DUT uses (in this case DeviceBus).

    If I have understood that correctly, the only code that isn’t “structural” and that stimulates the DUT are the test_control architectures. In the case of my simple design, where where would I send the control signal for the PRBS error insertion…

    Would I create a specific VC and record type to pass PRBS_in/out up to the test_control and have my test logic there.

    Or maybe forego the new VC/record and just hook them straight up to the test_control and do all changes there.

    I could easily do the latter and run my test successfully but we are trying to leverage OSVVM to standardize testing methodology and so I was wondering how I would approach such a relatively simple issue within the conventional OSVVM architecture. I guess my question boils down to, how to deal with simple signals that are not part of a bigger bus. Do they just get passed to the test_control unit and not have VCs?

    Sorry if the post isn’t clear or if I am missing something obvious.


    Jim Lewis

    Hi Michael,
    One thing you can do is in your verification component create a setting that controls whether PRBS is to be inverted or not. Then use SetModelOptions to change the settings. For AxiStream we have numerous settings and use an abstraction layer on top of SetModelOptions called SetAxiStreamOptions. For AxiStream the abstraction layer is created in the package AxiStreamOptionsPkg.vhd.

    You can make it so the actions take place immediately or they can take place in conjunction with an action on your DeviceBus.

    Best Regards,

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