DesignWare Technical Bulletin Article

Search Tools


Beating the Odds on OCP Slave Memory Behavior

How DesignWare VIP for OCP helps you test the spread of best-case, worst case memory response

Verification IP for OCP is generally used to achieve one of two main verification objectives; at the module level to test OCP components and their interfaces; or at the bus fabric level when some or all of the components may be replaced by the verification IP to test the behavior of a system. In either case the VIP behavior used in verification will ultimately be replaced with a real component or interface, and so it is important that the verification IP can represent the behavior of the real component or components; even better to represent a spread of components that might be used in conjunction with the design being tested. The real slave components in an OCP design will have memory of one form or another and so accurately modeling the behavior of the memory in the verification IP can be critical to understanding system performance and identifying potential hazards.

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 a 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.

The first of these sets the prerequisites for the master to initiate its datahandshake phase. The optimistic view is that it can begin as soon as the request has been initiated, while the pessimist can set it to wait until the request is accepted. If there is a previous READ transfer with an overlapping address it also changes the behavior of the master and it will wait until the response phase is started (Optimist) or accepted (Pessimist). Why would you choose one over the other? You would typically do both to see how the slave responsiveness affects overall system performance and also to ensure that the slave does not have hazard problems with an overly optimistic master.

The second parameter for the VIP master sets the prerequisite for initiating the request phase for configurations which don't use datahandshake, or that use reqdata_together; it applies when write requests have a previous READ transaction with overlapping address that hasn't yet completed its response phase. The difference here is that the optimist will allow the master to start the request phase if the previous response phase has started, and the pessimist allows the master to start the request phase only after the response phase is accepted. The risk here is that if the write takes place before the response phase is completed there could be hazard on the read data. Again it depends very much on the characteristics of the slave device and only the project team can fully understand that.

Another interesting feature added to the VIP also plays into the realm of trying to mimic the characteristics of a component that has been replaced by the VIP. It provides the ability to set different types of backpressure in the master and slave VIP which then use MThreadBusy and SThreadBusy signals to convey that they are backed up with queued transactions. This feature creates a semi-randomized behavior that will stop the VIP from initiating or accepting more requests until their queue is back below a user defined level.

The Slave has three ways to do this. It can use a FIFO method that increments a user-defined amount on each request and decrements on each clock. If the total crosses a user-defined threshold it will asserts SThreadBusy. The other two methods for the slave compare the accepted requests with completed handshakes or responses. The idea of all these methods is to create a threshold at which point the slave asserts the SThreadBusy signal.

The Master VIP has a single method to mimic backpressure. This is similar to the Slave FIFO method; it increments a user defined amount on each response and then decrements the FIFO by one on each clock. When the FIFO is above a certain level it will assert MThreadBusy until the clock decrements the count back below a user defined lower level.

These features are all now included with the DesignWare Verification IP for OCP to give verification engineers more knobs to turn when verifying their OCP designs, and leading to more complete verification. DesignWare Verification IP for OCP is included in the DesignWare Library and VCS Verification Library. It is included with CoreCreator, available from OCP-IP.