The best of both worlds: Optimizing OCP slave memory behavior

For example, what if verification IP for an OCP master is being used to test an OCP slave and conservatively assumes that the data is not committed to the slave memory until its datahandshake completes. If the real master device assumes differently that data is committed at the beginning of the datahandshake phase and initiates a subsequent read from the same address sooner than the slave was tested for, it could result in a hazard. Both scenarios are valid within the specification, so the verification IP should test both scenarios to ensure that the slave can work with a range of master devices.

The DesignWare Verification IP for OCP did not originally include memory, mainly because the OCP specification does not define memory behavior, and verification IP is intended to model the specification. This left it to the verification engineer to model the type of memory used in the design, which is generally the best approach for realistic verification. However, after several requests, memory was added to the slave VIP: as an example for VMM testbench users and hard-coded into the Verilog interface for Verilog testbenches. VMM users can modify the example to most accurately represent the memory that will be in the RTL.

Any memory implementation must make assumptions about when the data is committed to memory as this affects the responsiveness of the component and its datahandshake phase for the transaction. The initial implementation of the hardcoded memory in the DesignWare slave VIP assumed data was committed to memory at the completion of the datahandshake phase. This has now been modified to allow more flexibility for users, with more control of the attributes for the memory access. This configurability of memory and datahandshaking combines with the controls for modeling back-pressure in the master and slave verification components to give engineers more control to accurately model the components that VIP has replaced in the design.

The most recent release of the VIP includes the notion of optimistic and pessimistic behavior. For example, an optimistic behavior assumes that data is committed to memory when the data is sampled by the slave verification IP at the start of the datahandshake phase when MDataValid is driven high. A pessimistic view would be that the data is committed to memory when the corresponding datahandshake phase is completed with SDataAccept driven high. The slave Verification IP will not start the next response phase for subsequent read requests to overlapping addresses until the data is committed to memory, thus avoiding hazards. It is important to test a master device using both of these scenarios to ensure that it will work with slaves of both types.

The option of whether to be an optimist or pessimist applies to three aspects of memory access. The aforementioned write of data to a slave memory is a configuration parameter for the slave VIP. Two configuration parameters added to the DesignWare master VIP relate to the initiation of the request and datahandshake phases of a transaction.