Shared variables in separate Entities?

Why OSVVM™? Forums OSVVM Shared variables in separate Entities?

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #877
    Lyle Swanson
    Member

    Hi,
      In VHDL, is there any way to construct a shared variable that exists in separate entities?  The standard usage is to have the shared variables residing in different processes of the same entity.

     We want to build a DV environment that uses the OS-VVM scoreboard methods; however, we want operations (such as “Push” and “Check”) to exist in separate entities.  

    E.g,  
     In Generator transactor entity:
       UartRxScoreboard.Push( (TxData(31 downto 0), other_data_items) ) ;

      In Monitor/Scoreboard:
       UartRxScoreboard.Check( (RxData(31 downto 0),
    other_data_items
    ) );

    #878
    Jim Lewis
    Member

    Hi Lyle,

    There are a couple of ways to handle this.

    1)  Use a package that is referenced by each entity. 

    This will work well until you have multiple instances of the same BFM/monitor.

    2) Define the scoreboard in the one of the entities, such as the monitor, and then access it using external names in the other entity.  There are examples of doing this in the Memory Modeling section of the class. 

    If the other entity is the main generator (TestCtrl) this works well, but if the other entity is the BFM, then this too has issues when there are multiple instances of the same BFM.

    3)  Warining, this one is on the bleeding edge of tool support.  I tried it with an older version of the tools and it did not work.   Define the scoreboard in a package that has a generic on it (such as an integer constant – the value is irrelevant).  Create a generic instance of the package in the architecture declaration region of the architecture that connects the monitor and BFM.   Pass the instance of the package to both designs via a generic on both the monitor and BFM.

    I think it is time to try this last one out in the tools again.  I think it has promise to implement the entire transaction interface and be an interface construct (maybe even similar to SystemVerilog interfaces). 

    Best Regards,

    Jim

    #880
    Lyle Swanson
    Member

     Thanks Jim.

    I’ll give this a try, starting with suggestion #3 and will let you know what happens.  I am working with Modelsim 10.4 Beta, so hopefully it supports this technique.

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