Reply To: Expected failures in custom VC based on AddressBusRecType

Why OSVVM™? Forums OSVVM Expected failures in custom VC based on AddressBusRecType Reply To: Expected failures in custom VC based on AddressBusRecType

#2042
Jim Lewis
Member

Hi Per,
As you have noted, unlike StreamRecType, AddressBusRecType does not have a params field.

What I do in the Axi4Manager VC is use SetModelOptions to set an WB_ERR expected and a WB_RTY expected – sometimes coded together, sometimes coded separately. The AXI4 response codes that need to be checked are BRESP and RRESP. The way we check those is:

-- Write transfer that expects a SLVERR
SetAxi4Options(ManagerRec, BRESP,     SLVERR) ;     
Write(ManagerRec, X"0002_0000", X"0002_0101" ) ;
SetAxi4Options(ManagerRec, BRESP,     OKAY) ;     

-- Read transfer that expects a SLVERR
SetAxi4Options(ManagerRec, RRESP,     SLVERR) ;     
Read(ManagerRec,    X"0004_000C", Data) ;
AffirmIfEqual(Data, X"0004_0404", "Manager Read Data: ") ;
SetAxi4Options(ManagerRec, RRESP,     OKAY) ;

The AddressBus MIT SetModelOptions requires that the values BRESP and RRESP be integer values. Which if you create BRESP and RRESP as integer constants you can easily do. I prefer to use ENUMS instead, so I created SetAxi4Options to do the call:

SetModelOptions(ManagerRec, Axi4OptionsType'POS(BRESP), Axi4RespEnumType'pos(OKAY)) ;

SetAxi4Options is in the package AXI4/common/src/Axi4OptionsPkg.vhd.

StreamRecType has the params field because many streaming interfaces need either error codes or additional information to do every transaction. Long term AddressBusRecType may need this capability too if there is side-band information other than Address and Data that needs to be specified on every call.

Best Regards,
Jim