Schedule Based Verification

By Vishal Patel, Dhaval Shah at Arastu Systems

Introduction

In these highly competent times, the need of the hour is to provide a step higher than just a functionally verified IP. A functionally verified IP is great to begin with, but clubbing it with features such as to maximize system performance and minimize the power utilization is an absolute necessity. In most cases functional verification grabs the limelight while the other prime aspects such as low power consumption, resource optimization to name a few are not taken care by the automated Verification Environment (VE). These features are targeted through certain observations on the design behavior via a set of specifically designed experiments. This is not just extra effort, but tedious too. We, at Arastu, have designed a Verification Component (VC) for our LPDDR4 IP, that aids in improving the overall system performance. Let us take a quick look into this VC, we call it the Scheduler.

More on the Scheduler

As a part of Functional Verification, Design Under Test (DUT) violations are reported immediately. This type of constant monitoring is not done for several aspects such as performance. Conventionally, after the DUT reaches a certain level of maturity, a set of tests are designed and behavior of DUT is observed to extract the performance parameters. If it comes out below the targeted value then a lot of brainstorming is done on the architecture in order to step up the performance. The Scheduler designed at Arastu is a VC that is not just a model to mimic the DUT, but also an independent component which, in addition to the basic DUT functions, has algorithms to suggest the optimized way of bus utilization. This is not a synthesizable component and hence it is free to use a large amount of resources, which in turn aids in climbing up the performance ladder a lot more quicker.

Description

Figure 1 shows the block diagram of the Scheduler. It is plugged to the System Side on one end and hence knows what goes into the LPDDR4 Controller. On the other end it interfaces to the Controller output and hence knows what operations are being issued by Controller to the DRAM. The Scheduler Config Block, as depicted in Figure 1, makes this VC configurable in accordance with the DUT. Parameters such as minimum controller datapath latency and choice of addressing scheme to name a few, can be configured.

Figure 1 : Block Diagram of the Scheduler based Predictor for LPDDR4 Controller

The Scheduler, in addition to the basic functions of DUT, has significant features to improvise performance. These performance targeting components may vary based on which parameter needs to be enhanced. We, at Arastu, have aimed at the following critical ones,

• Out-of-Order execution: Controller can reorder the requests received from system side for the best performance. Similarly, the Scheduler does reordering which fits best and makes suggestions based on it
• Request Merging: If two or more requests in the request queue are targeting the same DRAM address then it is efficient to merge these kind of requests. This avoids DRAM bus activities which are actually redundant
• Multiple Request Queue: Each data operation targets one of the eight banks in the DRAM. The minimum wait time between two successive commands varies based on which bank they are targeting to. Multiple request queues, one for each bank are maintained in order to exploit this aspect. In case of a single request queue, the wait time is calculated based on the next command in the queue, thus ignoring the fact that command targeting to each bank has a different wait time. But if the multiple queues are maintained one can have freedom to choose the minimum amongst all of the wait times. Scheduler reports an error if wait time for any of the request queue is satisfied and no bus activity is observed. These reports help the designer in analyzing weak spots in the scheduling algorithm of DUT for improving the bus utilization
• Latency Counter: Scheduler manages latency count for each of the request starting when it arrived from the system interface. If latency counter for a request crosses a pre-configured threshold value, then it reports an error stating that the particular request has been starving for a long time
• Data Hazard: If multiple requests targeting same address have arrived then they must be served in order. This is a must in order to maintain data accuracy. Since the controller does out of order execution, it might reorder requests for the same address as well which can potentially lead to data hazard. However the Scheduler keeps a strong eye on this kind of behavior
• Power Down Modes: Many components nowadays support various features for power saving. Scheduler makes suggestion for entering and exiting from power saving modes. Scheduler for LPDDR4 considers Clock Stop, Power Down and Self Refresh as the power saving modes. Once the Scheduler notices that no requests are pending, it expects the Controller to put DRAM into any of the three Power Saving mode in the preconfigured amount of time. Similarly, once the Scheduler observes a new request coming from the System, it expects the controller to bring the DRAM out of the Power Saving mode within a preconfigured amount of time

Apart from making various suggestions for better bus utilization, this Scheduler also keeps a track of it. It observes DRAM bus activities, starting from first ‘Refresh’ till the end of the simulation. At the end of simulation, it reports statistical information about DRAM bus utilization. The report contains Read Latency, Write Latency, Transfer Rate and Average bus utilization as depicted in the Figure 2.

About the Authors:

Vishal Patel is a member of technical team at Arastu Systems, a company focused at delivering customized IP products and related services in the memory and networking area. Vishal holds a master’s degree in VLSI from IIT, Delhi and have worked with CISCO before joining Arastu Systems in 2014. He is passionate about technology and likes to stay updated on various Industry happenings.

Dhaval Shah is working as a Tech lead at Arastu Systems. He is in charge of product definition and implementation for Arastu Systems DRAM products. Dhaval has more than 10 years of Industry experience and has completed his masters in VLSI design from Nirma University, Ahmedabad. Along with chipsets, Dhaval likes to travel and is always enthusiastic to explore new places.