Proceedings of the 2017 IEEE 21st International Conference on Computer Supported Cooperative Work in Design
Extendable Generic Base Verification Architecture for Flash Memory Controllers Based on UVM Khaled Khalifa Verification and Emulation Consultant Mentor Graphics Cairo, Egypt
[email protected] methodology such as UVM is advantageous in terms of better communication among engineers and reusability of functional verification environment [4] as it is composed of reusable Verification Components (VCs). This paper introduces UVM from a user perspective and presents the experience gained of its fundamental aspects by its application in the verification of different Flash memory controllers. We studied different Flash Memory controller protocols to create the common VCs of a generic base verification architecture for them all. We are also planning to extend this verification architecture to support DRAM memory core which has special operations require special organization and arrangement of the verification architecture. Through a comprehensive study [5] with many Flash memory controller protocols such as: eMMC [6], SD [7], ONFI [8], One-NAND [9] and UFS [10], we created a base verification architecture with these key contributions: 1) It is an extendable, generic and configurable abstraction layer to be extended to verify Flash memory controller designs by specifying the memory controller behavior in certain places of the base verification architecture. 2) It integrates the essential UVM VCs, defines the functionalities of the VCs, and connects them in a generic and dynamic approach. 3) It implements some needed and common base functions and tasks for any Flash memory controller verification environment. 4) It provides the implementation of the UVM phases’ functions and tasks. 5) Its configuration mechanism supports the verification of multiple memory controllers and other peripherals. The rest of paper is organized as follows. In Section II, some of the related published work is discussed. In Section III, The base verification architecture is explained. Case study of a universal memory controller is explained in Section IV. Experimental results are introduced in Section V. Conclusion and future work are given in Section VI.
Abstract˰˰˰˰˰ This paper introduces an extendable and generic base architecture built on Universal Verification Methodology (UVM) for verifying Flash memory controller designs. The base architecture aims to create a generic and configurable abstraction verification environment for Flash memory controller designs. It integrates the essential UVM Verification Components (VCs), defines the functionalities of the VCs, and connects them in a generic and dynamic approach. It also implements some base functions and tasks for Flash memory controller verification environment. In addition, it provides the implementation of the UVM phases’ functions and tasks. The configuration mechanism of the base architecture supports the verification of multiple memory controllers and other peripherals. This paper guides the verifier where and how to put the behavior of Flash memory controller in its correct and suitable place in the base architecture to serve the idea of reusability which the UVM originally is built on. This paper introduces a case study of the base verification architecture and provides its experimental result. This paper also introduces a lot of UVM knowledge to make the verifier efficiently exploit this base architecture and reuse it in many other verification projects.
Keywords—UVM; SystemVerilog; Functional Verification; Testbench; Environment; Coverage; Constrained Random; BFM; Flash Memory Controller; eMMC; SD; ONFI; One-NAND; UFS. I.
INTRODUCTION
Microprocessors communicate with memory cores through memory controllers. Since the task of memory controller is to manage these devices to unload low-level memory management from the host processor and freeing up resources, memory controllers become more complex and larger than ever before. As large and complex is the memory controller, more are the chances of bugs in the design which requires extensive and diverse verification. This verification cycle is the most critical phase in the design cycle and nearly 70% of design cycle time is consumed by the verification process [1]. Consequently, there is a wide industrial need to create generic base verification architecture to be the extendable base architecture to verify any memory controller protocol. It significantly reduces the development time and effort of creating the verification architecture from scratch. The verification environments developed through SystemVerilog [2] may be different depending upon the implementer; while verification environments built using the Universal Verification Methodology (UVM) [3] remains the same for different vendors such as it can be reused for different vendors IPs. We can say that the use of a particular verification
978-1-5090-6199-0/17/$31.00 ©2017 IEEE
II.
RELATED WORK
The concept of creating a reusable verification environment has already been introduced for multiple IPs. In [11], the authors proposed a UVM methodology as an efficient solution for processor verification and the same in [12] for image signal processing IPs. To our knowledge, the work of proposing a UVM verification environment for memory controllers is introduced by only one paper [13] that is introducing a generic
584
memory controller architecture IP with its UVM environment. We generalize a base verification architecture by integrating and connecting the needed VCs, implementing some needed and common base methods and providing the implementation of the UVM phases’ methods for verifying any Flash memory controller design. We also use the same generic memory controller IP which is introduced in [14] to show how to configure and set related parameters of the memory controller in the base architecture which is introduced in Section IV. The existing UVM architecture in [13] has major drawbacks which affect the reusability, performance and modularity of the architecture. TABLE I illustrates the drawbacks of the existing UVM architecture and their enhancement in the base architecture. In addition to these enhancements, the base architecture defines some base methods which are commonly needed to verify any Flash memory controller. III.
TOP TEST
Environment_Configuration
ENVIRONMENT
Agent_Configuration
AGENT Sequencer
Scoreboard Controller Ref Model
Sequences
Command_FIFO
Command_item
s
Driver
Command_Monitor
Response_Monitor
BFM
BFM
BFM
Bus Functional Model (BFM)
THE BASE VERIFICATION ARCHITECTURE
Coverage Command_FIFO
Design Under Verification (DUV)
Fig. 1. The extendable generic base verification architecture for Flash memory controllers based on UVM
In this section, we divided the base architecture as shown in Fig.1 to connected components or units. Each component is explained separately with its implementation criteria.
• send_receive task: It describes the protocol behavior to: a) Send a valid command with its data. b) Receive the suitable response of the transmitted command with its data. It takes a command and its associated data as input arguments, and the response and its associated data as output arguments. It is accessed by the driver. The BFM also detects commands, responses and data on the DUV pins, then passes them to the monitors which encapsulate them in transactions. Therefore, we will declare a handle of both command_monitor and response_monitor components to add some functionality to the BFM. • command_collector Always Block: It will always be triggered when any activity happens on the command bus signals. It collects both the valid command on the command bus and its associated data on the data bus. Then, it calls a call_monitor() method of the command_monitor.
A. Bus Functional Model (BFM) It handles all the signal-level stimulus issues so that the rest of the testbench can ignore these issues. All the protocol level behavior can be modified in one place; a fix here gets propagated throughout the testbench. It is declared as SystemVerilog Interface which contains several methods to handle the protocol level behavior. These methods are accessed by both driver and the two monitors. The BFM contains five methods which are: • reset_DUV task: It describes the protocol behavior on the DUV’s pins to reset the DUV. It is accessed by the driver. • Clock Generator.
TABLE I. DRAWBACKS OF THE EXISTING UVM ARCHITECTURE VERSUS THE ENHANCEMENTS OF THE BASE VERIFICATION ARCHITECTURE Drawbacks of The Existing UVM Architecture [13] I. The "driver" is controlling two different interfaces ("DUV interface" and "REF Model interface").
II. "Monitor Expected"component is monitoring the "REF Model interface".
III. Monitors and driver have their own signal level methods (functions and/or tasks). IV. No coverage component.
V. The architecture is not configurable. VI. There is no synchronization topology between the commands and their responses.
Enhancements of The Base Verification Architecture I. As the driver is responsible for mapping the transaction to the signal level format required by the "DUV interface", therefore it is a redundancy load on the driver to control the "REF interface". Besides, the "Ref Model" must operate on transaction. Consequently, the base architecture removes "REF interface" and moves "REF model" inside the "Scoreboard". II. It is the complementary operation (monitoring the "REF interface") of the original operation of driving the "REF interface" where driving the "REF interface" is redundant. Consequently, the base architecture removes "Monitor Expected" and only drive/monitor the flow to/from the DUV. III. The base architecture proposes an only one component (BFM) which handles all the signal level stimulus issues so that the rest of the base architecture can ignore these issues through accessing the BFM through the UVM configuration database. IV. The base architecture integrates the coverage component to cover the command, data and response items to establish a complete verification environment. V. The base architecture adds two levels of configuration (Agent and Environment configuration levels) to be easily used and configured to the intended behavior. In addition to support the verification of multiple memory controllers and other peripherals in one testbench. VI. The base architecture uses the FIFO element and the uvm_subscriber to synchronize between commands and their responses.
585
• response_collector Always Block: The same as the command_collector always block, but response_collector collects response and its associated data. It calls a call_monitor() method of the response_monitor.
The end_of_elaboration_phase() method copies the sequencer from the agent by using uvm_top.find() method. Now any test that extends the base_test class will have a handle to the sequencer. Besides, this base_test class extends uvm_test to provide the ability to select which test to execute using the UVM_TESTNAME command line. The test classes extend base_test class and then register the test class with the UVM factory. In the run_phase() method of the test class, four actions are done as shown in Listing 2: • Instantiate sequences. • Raise an objection. • Call the start() method of the sequence. It may take an uvm_sequencer as an argument and returns once the sequence has completed, or it may receive null to launch virtual sequences. • Drop the objection.
B. Command Item It encapsulates command, response, data signals and all the operations we can do with that data. These operations include the following: • Providing a string with the data values in it (convert2string). • Copying another transaction of the same class into this transaction (do_copy). • Creating a second copy of this transaction using the do_copy() method (clone_command). • Comparing this transaction to another of the same class (do_compare). • Randomizing the command and its associated data fields (using SystemVerilog's built-in randomize method). It extends uvm_sequence_item as the uvm_sequence_item carries data from uvm_sequences through the uvm_sequencer to a uvm_driver. C. Response Transaction
Listing 2. The run phase of test component
The same as command_item except for two things: • It extends uvm_transaction as it is treated as a data transaction not as a sequence item connected to the sequencer. • It declares response and out_data signals only.
E. Environment Component It extends uvm_env. In the build_phase() method, it gets the environment configuration object from the Configuration Database and configures the agent configuration object, which is introduced in Listing 3, with the following parameters: • The UVM_ACTIVE or UVM_PASSIVE parameter. • The proper BFM interface. It also sets the agent configuration object to the Configuration Database and instantiates the agent component.
D. Test Component All the tests in the proposed testbench architecture share the same build_phase() and end_of_elaboration_phase() methods [15], therefore this architecture creates a base class with those methods and extends it to create our tests. In the base_test class shown in Listing 1, the build_phase() method creates the environment component and gets the BFM interface from the Configuration Database where the Top module registers this interface into the configuration database in order to allow the class based testbench to connect to the DUV. Besides, it configures the environment configuration object with the proper interfaces which are needed by the used agent. Finally, it sets the environment configuration object in the Configuration Database.
Listing 3. The build phase of environment component
F. Agent Component The agent component extends uvm_agent as it provides the is_active data member and the get_is_active() method. The is_active data member is a variable of type uvm_active_passive_enum. This enumerated type can take one of two values: UVM_ACTIVE or UVM_PASSIVE. Since it is expected to instantiate multiple agents, a way is needed to pass them the handle to the BFM and the value of the is_active variable which is already done by using agent_config class. In the build_phase(), the agent configuration object is checked whatever the agent is active or passive. Active agents will
Listing 1. The build_phase and the end_of_elaboration_phase of the base test
586
instantiate both sequencer and driver. Passive agents will only instantiate monitors and analysis components (Coverage component and Scoreboard component) [16] as shown in Listing 4.
Listing 5. The run phase of driver component
H. Sequence Component The sequence extends uvm_sequence and is parameterized to the command_item to inherit three actions that allow sequence to feed data to a sequencer which are: • m_sequencer: This data member holds a handle to the sequencer that takes our command_items. • body() task: The UVM launches this task when it starts our sequence as shown in Listing 6. • start_item() / finish_item() method pair: These two methods get control of the sequencer and send it a command_item as shown in Listing 6. Listing 4. The build phase and the connect phase of agent component
The connect_phase() checks whatever the agent is active or passive, to connect the driver to the sequencer. Finally, it connects monitors with coverage and scoreboard as shown in Listing 4. G. Driver and Sequencer Components
Listing 6. The body method of the sequence
It extends uvm_driver and is parameterized to work with command_item. When the driver extends uvm_driver, it inherits the seq_item_port object and all its functionality. The run_phase() method calls the get_next_item() method on the seq_item_port object as shown in Listing 5. This method blocks until the sequencer puts data into the port and then gives a command_item object in the command object. Once the driver has the command, Send_OP method is called in the BFM and the response and data are returned. Then, the response and its associated data are stored back in the command object. The driver does this to return the response and data to whoever called it. It assumes that the code that passed the command still has a handle to it and that by storing the response and data in the command the driver is returning it to the caller. Finally, the driver calls the item_done() method on the seq_item_port object to tell the sequencer that it can send another command_item. This architecture defines the sequencer component to be a uvm_sequencer class which is parameterized to accept the command_items. Using a typedef to set the parameterization on a class makes it easy to use that class name later in the design. In some cases, some of memory controllers need multiple drivers, not only one driver. Therefore, the verifier creates a separate driver classes and integrate them into the driver component of the proposed base architecture.
I.
Command Monitor Component
Command_monitor captures any signal activity on the command bus and encapsulates this activity in a command transaction (command_item) which is passed through the analysis port to the analysis components. command_monitor extends uvm_monitor to distinguish the monitor component from the other components. Command_monitor contains: • An analysis port that is parameterized to a command_item to send it back to scoreboard and coverage components. • Virtual BFM to point to the handle of the command_monitor declared in the BFM as introduced in Listing 7. • call_monitor method which is called inside the BFM. It performs two operations; first it encapsulates its input arguments into the command_item. Second, it calls the write() method of the analysis port as shown in Listing 7. • Assertions coverage groups to capture assertion coverage [17] for command activity and its associated input data.
587
IV.
In this section, we present a case study to show how to configure and set related parameters when verifying different Flash memory controller designs. For different memory controllers, the protocol related VCs will be modified according to the definition of the protocol methods (functions or tasks) in the base architecture. The proposed base architecture is extended to be applied on the universal memory controller IP presented in [13]-[14]. This section provides a sample of the configured methods of BFM as in Listing 9, and command_item as in Lisiting 10.
Listing 7. The connect phase and the call_monitor method of the command monitor
J.
CASE STUDY: UNIVERSAL MEMORY CONTROLLER IP
Response Monitor Component
The same as the command_monitor component, but the difference is that the response_monitor operates on the response_transaction instead of command_item. K. Scoreboard Component Scoreboard component is located inside the Agent component as it is used for protocol specific checking, not for the system checking. It extends uvm_subscriber and is parameterized to the response_transaction to allow the scoreboard component to subscribe to the analysis port which handles the receiving of the response_transaction. As a result, the scoreboard needs to subscribe to two different analysis ports. Therefore, it instantiates an uvm_tlm_analysis_fifo object to subscribe to the command_item analysis port. Scoreboard contains: • uvm_tlm_analysis_fifo object which accepts command_items as shown in Listing 8. • controller_ref_model which predicts the expected output response and output data of the memory controller. • write() method which calls the controller_ref_model and uses the fifo’s try_get() method to get the command_item. It also uses the compare feature described in the response_transaction to compare the actual data with the expected reference data as shown in Listing 8.
Listing 8. The declaration of the scoreboard component, the command FIFO and the write method of the scoreboard
L. Coverage Component The same as the scoreboard component, but the difference is that the coverage component has the declaration of the coverage croups for command, in_data, response and out_data to capture the functional coverage [17].
Listing 9. Some methods of the BFM class of the universal memory controller
588
VI.
CONCLUSION AND FUTUER WORK
This paper presents a generic, dynamic, complete and extendable base verification architecture for Flash memory controllers. The base architecture is created using SystemVerilog constructors and UVM base classes [18]. The Environment and agent components of the base architecture are created to be configured by configuration objects to verify multiple memory controllers and other peripherals through it. Scoreboard and coverage components extend uvm_subscriber and use uvm_tlm_analysis_fifo to subscribe to two different analysis ports. This base architecture modularizes the whole functionality of the testbench to create smaller and simpler design units. This approach delivers adaptable code that makes this base testbench stronger as it grows and can be reused in future projects. Moreover, this approach also facilitates the debugging process. In our future work, we plan to extend the base architecture to support DRAM memory core which has special operations and require special organization and arrangement of the verification testbench architecture. REFERENCES [1]
[2] [3] [4] [5]
Listing 10. Some methods of the command_item of the universal memory controller
V.
A. Kokrady, R. Mehrotra, T. J. Powell, and S. Ramakrishnan, "Reducing design verification cycle time through testbench redundancy," 19th International Conference on VLSI Design held jointly with 5th International Conference on Embedded Systems Design (VLSID’06), 2006. C. Spear, SystemVerilog for Verification, Second Edition: A Guide to Learning the Testbench Language Features, 2nd ed. Springer Publishing Company, Incorporated, 2008. Accellera, UVM 1.1 User Guide, 2011. A. Piziali, Functional Verification Coverage Measurement and Analysis, 1st ed. Springer Publishing Company, Incorporated, 2007. K. Khalifa, H. Fawzy, S. El-Ashry, and K. Salah, "Memory controller architectures: A comparative study," 2013 8th IEEE Design and Test Symposium, Dec. 2013. eMMC Standard (4.51 Device), JED84-B451, June 2012. SD Specifications (Version 4.10), August 2012. www.onfi.org.
[6] [7] [8] [9] Flex-OneNAND, Revision No 1.1, Aug.14, 2008. [10] UFS Standard (V.2.0), JESD220B, Sep 2013. [11] A. Bhojak and T. Prasad, "A UVM Based Methodology for Processor Verification," in DVCON, 2015. [12] A. Jain, G. Bonanno, H. Gupta and A. Goyal, "Generic System Verilog Universal Verification Methodology based reusable verification environmentfor efficient verification of image signal processing IPs/SOCs,” International Journal of VLSI design & Communication Systems (VLSICS), vol. 3, no. 6 (2012). [13] K. Khalifa and K. Salah, "Implementation and verification of a generic universal memory controller based on UVM," 2015 10th International Conference on Design & Technology of Integrated Systems in Nanoscale Era (DTIS), Apr. 2015. [14] K. Khalifa, H. Fawzy, S. El-Ashry, and K. Salah, "A novel memory controller architecture," 2014 11th International Conference on Electrical Engineering/Electronics, Computer, Telecommunications and Information Technology (ECTI-CON), May 2014. [15] R. Salemi, The Uvm Primer: A step-by-step introduction to the universal verification methodology. United States: Boston Light Press, 2013. [16] S. Rosenberg and K. Meade, A practical guide to adopting the universal verification methodology (UVM) Second edition. United Kingdom: Lulu.com, 2013. [17] A. B. Mehta, SystemVerilog assertions and functional coverage: Guide to language, methodology and applications. United States: Springer-Verlag New York, 2013. [18] Accellera, UVM 1.1 Class Reference, 2011.
EXPERIMENTAL RESULTS
The total verification time for the universal memory controller IP is consumed only in extending and configuring the proposed base architecture itself which is very small time and effort compared to the development time consumed in creating the testbench verification architecture from scratch, implementing the essential base methods and UVM phases, finding the best connections between VCs to correctly verify the design, and most important to be reusable in the future projects. Depending on the proposed base architecture, the total verification time for the universal IP was 2 man weeks. More than 1K functional coverage bins were created to test the essential operations of (read, write, erase,..) commands. Typically between 2K to 4K random test runs were required to achieve 100% functional and code coverage to get to the confidence according to the targeted operations (read, write, erase,..). 25 odd bugs were found in both design and reference model during verification cycle. During the verification time, debugging time and effort significantly decreased because of the modularity of the extended base architecture.
589
