SOURCE ARCHIVE
EXTRACTED CONTENT
35,818 chars Verifying Open Source CPU Cores using Instruction Set Simulators in
OVM Environments
Waqas Ahmed¹, Siegfried Brandstätter² and Mario Huemer³
1Royal Institute of Technology (KTH), Stockholm, Sweden
2 DMCE GmbH & Co KG, Linz, Austria
3Klagenfurt University, Klagenfurt, Austria
WaqasW@kth.se, SiegfriedX.Brandstaetter@intel.com and Mario.Huemer@ieee.org
Abstract for CPU cores because of their complex instruction sets
[6][16]. Another choice is to perform formal verification
This paper deals with a verification methodology and and mathematically prove a given system [7]. Although environment for open source central processing units this approach offers high verification coverage, it is very (CPUs). The aim is to save development time and veri- complex to apply for designs of large size [3]. How- fication effort by (i) implementing a flexible and reusable ever, the functional verification is an essential verification verification environment by means of Open Verification methodology for complex designs [6]. This methodology Methodology (OVM) and (ii) using the instruction set increases the productivity of a SoC design on a higher ab- simulator (ISS) of the CPU core as a golden model. Ap- straction [17]. A coverage-driven constraint random test plying this methodology implements a unified verifica- generation is not only an appropriate functional verifica- tion environment which facilitates a comparative verifi- tion approach for complex designs but also offers high cation of the CPU core and its ISS on a single platform. verification coverage. Therefore, we opted this approach Hence, it significantly saves resources to implement the for the functional verification of the OR1200 core. golden model and to perform the verification of the ISS. The lack of flexibility and reusability in the development Moreover, reusing the ISS as a golden model considerably of verification environments consumes more resources speeds up the CPU design process. We developed a plat- and keeps the verification costs high [15]. Hence, reusing form to verify the open source OpenRISC1200 (OR1200) the verification blocks will significantly reduce the devel- core and its ISS as a benchmark. opment time and effort. It would be of great value if flexi- ble verification environments are developed which employ reconfigurable and reusable verification components. 1 Introduction In this paper, we present a flexible verification environ- ment which is created by means of OVM. This allows the According to [14], the performance of modern proces- users to develop modular and reusable verification compo- sors doubles every 18 months by exploiting several mech- nents and environments by providing a methodology and a anisms like out-of-order execution, on-chip caching, spec- SystemVerilog based supplementary class library [5][11]. ulative execution, prefetching and thread switching. Of Since all components in OVM based verification environ- course, these techniques increase the complexity of the ments interact with each other via standard transaction- processors [10] as well as the complexity of verification. level modeling (TLM) interfaces, such environments are Thus, the verification of processors requires a great en- very easy to build and maintain. gineering effort and time. It consumes 50% to 70% of Although the verification is performed at every abstrac- the design resources (time and effort) and is considered to tion level of a design, the architectural verification of reg- be a bottleneck in the development of modern computing ister transfer level (RTL) is particularly difficult because systems [15]. Hence, a more innovative and practical ap- of the unavailability of a high-level description for the proach is needed to verify complex designs and to keep comparison of the results [4]. There are mainly two ap- expenses within the budget. The basic questions which proaches for this purpose. One is to implement a golden arise for the verification of a hardware design are: (i) what model of the design for the comparison of the simulation is the most effective and appropriate verification method, results. The other one is to write assertions for the entire (ii) how can the reusability of the verification effort be in- design. The latter approach is rather inconvenient because creased and (iii) how can the verification cost (time and well-defined specifications of designs at RTL abstraction effort) be reduced. are mostly not available. Hence, the implementation of a It has been proven that traditional verification methods golden model is mostly needed. As a matter of fact, the of writing directed tests in assembly or in high-level lan- implementation of a CPU core’s golden model is a very guages (C/C++) are insufficient for the verification of complex task. complex designs [16]. The reason is that the results of In this paper, we propose a verification methodology in directed tests need to be known in advance for compar- which the ISS of a CPU core is used as a golden model. ison. Hence, this verification approach is not suitable To follow this methodology, a CPU core and its ISS need
PC
PM Power IMMU
I/F Management
WB Gen PC
I
DB Debug ICache IC
I/F OR1200 Core 8 KB IF
Tick DCache ID Reg file
timer 8 KB
WB ID
D
INT PIC DMMU Operand
I/F muxes
Figure 1. Block diagram of the OR1200 processor. LSU MAC ALU
LS
DC
to be available. Typically, the ISS is implemented before EX the core for performance analysis on the instruction set. Writeback Thereby, the proposed methodology of reusing the ISS as muxes a golden model not only speeds up the implementation and verification process of a CPU core but also saves resources WB for implementing a golden model. In this paper, an OVM based verification environment is Figure 2. Register abstraction of the OR1200 pipeline developed by following the methodology described above. [1]. It performs a coverage-driven constraint random func- tional verification of the OR1200 core (RTL model) where the ISS (Or1ksim 0.3.0) of the core is used as a golden execution units: (i) the load/store unit (LSU), (ii) the arith- model. metic logic unit (ALU) and (iii) the MAC unit. A precise exception-model is implemented in parallel to control the 2 OR1200 Core pipeline. The functional verification of such a deeply pipelined 2.1 Overview CPU core is a challenging task. It is considered to be the most complex and expensive task in the development of We performed the functional verification of the OR1200 modern SoC designs [13]. The verification of the OR1200 core which is the CPU of the OR1200 processor as shown core is even more complex because of its complex instruc- in Figure 1. The OR1200 processor is an open source tion set. There are five instruction formats and two ad- soft-processor under the LGPL license. Along with the dressing modes. The instruction set mainly consists of core, the processor also provides additional utilities in- single- and multi-cycle instructions, jumps and branches cluding a debug unit, a high-resolution hardware timer, an followed by a delay-slot, and MAC instructions. Ac- interrupt controller and a power management unit. The counting the dependencies between these instructions in OR1200 core is a 32-bit scalar RISC core with a Har- the pipeline and the exception handling, the verification vard memory architecture. It has a single-issue 5-stage becomes even more complex. Furthermore, the simula- integer pipeline, virtual memory support and a multiply- tion time to run test sequences and to get a satisfactory accumulate (MAC) unit for basic digital signal process- verification coverage is a matter of high significance, par- ing (DSP) operations. The OR1200 core delivers a sus- ticularly while verifying pipelined cores like the OR1200 tained throughput and supports single-cycle execution for which has a large number of registers and a complex in- most of its instructions. The core is connected to exter- struction set. nal peripherals and memories through two Wishbone in- terfaces, the data interface (DWB) and the instruction in- 3 terface (IWB). Verification Environment 2.2 Instruction Pipeline Architecture 3.1 Overview The OR1200 core implements a 5-stage integer pipeline We used OVM to implement a reconfigurable and as shown in Figure 2. The Instruction Fetch (IF) stage reusable verification environment for the simulation based is the first pipeline stage followed by the Instruction De- verification of the OR1200 core. It implements a con- code (ID), the Execute (EX), the Load/Store (LS) and the strained random generation of verification scenarios and Write-Back (WB) stage. The instructions are fetched from a vibrant coverage model including a scoreboard to as- the memory system and dispatched to the corresponding sess the verification completeness. Figure 3 elaborates the
OR1200 TB Top 3.3 DUV Wrapper
Package Config_file Empty_elf A SystemVerilog based wrapper (OR1200 Wrapper) is
implemented around the OR1200 core for a structural con-
Direct Programming Interface Or1ksim nectivity as shown in Figure 3. This wrapper provides in-
Create_RandSequence upr (ISS) terfaces for instructions, data and the status of the OR1200
core. These interfaces are used to access the IWB inter-
Routines upw face, the DWB interface and the internal signals of the
core, respectively. The status interface of this wrapper
OR1200 TB makes all required internal signals of the DUV available at
upcpustatus its ports. The internal signals include the status registers
svc_or1200 (to be monitored) and the control signals (to control the
monitoring). The status of the OR1200 core is read over
or1200_virtual OpenRISC1200 simulator functions. The wrapper manipulates the internal
_sequencer (DUV) control signals according to the requirements e.g., delay
insn a control signal for two clock cycles. The wrapper also
formats. All components of the verification environment
Test library status performs the translation of the internal signals to usable
data interact with the DUV only through the wrapper’s inter-
Test bench faces.
configuration
clock reset 3.4 Main Test Bench
Figure 3. Verification environment for the OR1200 The main test bench (OR1200 TB) is a reconfigurable
core. and reusable component which is developed by means
of OVM. It interacts with the golden model through its
imported DPI functions and uses its physical interfaces
architecture of the verification environment (OR1200 TB to interact with the DUV wrapper. The main test bench
Top) which includes executes configurable tests generated by the test library.
• the Golden Model, All tests are a constrained random generation of scenar-
ios comprised of OR1200 instructions. Every verification
• the device under verification (DUV) wrapper component at any hierarchical level is reusable and can
(OR1200 Wrapper), be configured by the test bench configuration. For exam-
• the main test bench (OR1200 TB), ple, (i) whether the coverage model or the scoreboard is
implemented or not, (ii) whether an agent component op-
• the global package (Package), erates as a passive component, or (iii) which tests of the
• the Test library and test library are executed. All components interact with
each other through standard TLM interfaces. The main
• the Test bench configuration. test bench implements a layered architecture and is com-
prised of three main components:
3.2 Golden Model • the interface verification component (ivc_or1200),
The ISS of the OR1200 core, which is used as a golden • the system verification component (svc_or1200) and
model, can be compiled as an executable or as a library
[2]. In the verification environment the ISS is used as a • the virtual sequencer (or1200_virtual_sequencer).
library. Since it is not intended to execute an application
program, an empty ELF image is provided to the ISS. By The main test bench first sends an instruction to the
default the ISS library provides two upcalls (upr, upw) to golden model, writes/reads data (if the instruction is a
its public interface to read/write the external peripherals Load or a Store instruction) and receives the ISS status
[8]. These upcalls are modified to feed the ISS with in- once the instruction has been executed. This instruction is
structions and data for load instruction, and to read data then sent to the DUV. Since the DUV is a pipelined imple-
for store instructions. A third upcall (upcpustatus) is im- mentation, the main test bench implements a synchroniza-
plemented to write the ISS status up to SystemC wrapper tion mechanism by examining the control state machine
after the execution of each instruction. The communica- of the DUV along with the data-path and reacting accord-
tion between the ISS and the test bench is synchronized ingly. It copes with the core’s pipeline problems (delays)
by means of SystemC FIFOs. The main test bench, im- by monitoring the control signals of the DUV. It deter-
plemented in SystemVerilog (OVM), accesses these FI- mines the exact time to examine the status of the DUV,
FOs through Direct Programming Interface (DPI) func- which is indicated by the program counter (PC) and the
tions. More details about the DPI can be found in [9]. special purpose registers (SPRs), and the execution results
ivc_or1200
(SystemC Wrapper)
OR1200 Wrapper Golden Model
data_if insn_if (WB) (WB)
Table 1. Malfunctions in the OR1200 core and the ISS.
Instructions Error Description
Extend Byte with Sign (l.extbs) All these instructions are working correctly in the ISS but are not implemented in
Extend Byte with Zero (l.extbz) the OR1200 core. If any of these instructions is sent to the core, another instruction
Extend Half Word with Sign (l.exths) “l.movhi” is executed instead of generating an illegal instruction exception. Hence,
Extend Half Word with Zero (l.exthz) the execution of an unimplemented instruction is not reported and an incorrect result
is calculated.
Since the carry flag is not controlled by the freeze logic in the OR1200 core, a wrong
Add Signed and Carry (l.addc) value is added to the result. Moreover, the carry flag implementation in the ISS is also
erroneous.
According to the specification of both divide instructions the carry flag should be set
Divide Signed (l.div) if the divisor is zero. However, the ISS generates an illegal exception if the divisor is
Divide Unsigned (l.divu) zero. The OR1200 core neither generates an illegal exception nor sets the carry flag.
This is a clear discrepancy between the specification of the divide instructions and their
implementation in the OR1200 core and the ISS.
The instruction is neither implemented in the OR1200 core nor in the ISS. However,
Find Last 1 (l.fl1) when this instruction is sent to the core, another instruction “Find First 1 (l.ff1)” is
executed instead of generating an illegal instruction exception. Hence, the execution
of an unimplemented instruction is not reported and an incorrect result is calculated.
Multiply Immediate Signed and Accumulate (l.maci) The instruction is decoded correctly neither in the OR1200 core nor in the ISS. There-
fore, a wrong immediate value is used in the calculation.
Multiply Immediate Signed (l.muli) The instruction is not working correctly in the OR1200 core. It is a multi-cycle instruc-
tion but not controlled by the freeze logic. Therefore, an incorrect result is selected.
The instruction is neither implemented in the ISS nor in the OR1200 core. According
to the specification, this instruction is compulsory to implement [12]. Despite that,
Multiply Unsigned (l.mulu) when this instruction is sent to the core, a wrong implementation is executed instead of
generating an illegal instruction exception. Hence, the execution of an unimplemented
instruction is not reported and an incorrect result is calculated.
The effective address for both jump instructions is the content of a GPR which can
Jump Register and Link (l.jalr) be an unaligned address. The instruction fetch in the OR1200 core is naturally word-
Jump Register (l.jr) aligned but not in the ISS. Moreover, the ISS does not implement exception handling
in case of an unaligned access to fetch a new instruction.
The instruction is implemented in the OR1200 core but not in the ISS. Although the in-
Add Immediate Signed and Carry (l.addic) struction generates correct results in the OR1200 core for directed tests, its correctness
is not proven since it could not be included in the exhaustive verification test.
The instruction is not working correctly in the ISS. Although the instruction generates
MAC Read and Clear (l.macrc) correct results in the OR1200 core for directed tests, its correctness is not proven since
it could not be included in the exhaustive verification test.
Rotate Right (l.ror) Both instructions are implemented in the OR1200 core but not in the ISS. Although
Rotate Right with Immediate (l.rori) both instructions generate correct results in the OR1200 core for directed tests, their
correctness is not proven since they could not be included in the main verification test.
Move to Special Purpose Registers (l.mtspr) The ISS implementation of both instructions defines a wrong address for accessing the
Move from Special Purpose Registers (l.mfspr) special purpose register. The implementation in the OR1200 core is correct but not
proven because it could not be included in the main verification test.
Unimplemented Overflow Flag (OV) According to the OR1200 architectural manual a number of instructions can drive the
OV flag. However, the OV flag is not implemented in the OR1200 core.
within the general purpose registers (GPRs). Then it com- 4 Verification Results pares the status of the golden model with the DUV status and scoreboards it. The main test bench also implements a coverage model to assess the completeness of the verifi- The verification results of the OR1200 core show that cation. the core has some malfunctions including (i) erroneous instructions, (ii) unimplemented instructions, (iii) design In case of reusing this verification environment for ver- errors and (iv) discrepancies between the specification and ifying further open source CPU core, the main effort will its implementation. Moreover, the OR1200 ISS has some focus on the timing synchronization between the core and implementation errors and unimplemented instructions, its ISS. The rest of the components can be easily reconfig- too. Since these instructions have to be excluded from the ured and employed. verification, it significantly restricts the achievable veri-
Table 2. Coverage results of the OR1200 core.
OR1200 instruction types Total number of Executed number of Achievable coverage Reached coverage (%)
instruction instruction (%)
Insn rD, rA, rB 17 11 64.7 60.2
Insn rA, rB 12 12 100 100
Insn rD, rA, I 13 9 69.2 69.2
Insn rA, I 10 10 100 100
Insn I (rA), rB 4 3 75 75
Insn rD, rA, L 4 3 75 75
Insn N 5 5 100 100
Insn rD, K 1 1 100 100
Insn rD, rA 4 0 0 0
Insn rB 2 0 0 0
Insn rD 1 0 0 0
Insn rB, I 1 0 0 0
Driving carry flag 10 4 40 40
Driving flag 20 20 100 100
fication coverage of the OR1200 core. The verification total number of instructions belonging to a particular in- results are summarized below. struction type along with the number of instructions that could be executed in the main verification test. The results 4.1 Malfunctions in the OR1200 core and the ISS show the verification coverage achieved for each instruc- The Table 1 presents a summery of all errors and faults tion type which is based on the number of executed in- discovered in the OR1200 core and its ISS. structions. The maximum achievable coverage is reached Several benchmark programs were compiled using the for all instruction types except for the instruction type OpenRISC32 C/C++ compiler but it did not generate most “Insn rD, rA, rB”. This is because of its large test space of these erroneous instructions. This means that the com- which is composed of 17 instructions and three GPRs i.e., piler either does not implement these instructions or does 17 × 32 × 32 × 32 combinations. The maximum achiev- not often generate them. This is the reason why the er- able coverage for this instruction type is 64.7% while rors within these instructions stayed unidentified before. only 60.2% could be reached. There are four instructions However, the OR32 assembler is able to assemble these namely l.nop, l.csync, l.msync and l.psync which are sep- instructions. arately verified and working correctly in the core and the ISS. 4.2 Verification Coverage Results The cross coverage of three contiguous instructions in pipeline stages of the OR1200 core is also taken into This section presents the verification coverage of the account to observe the dependencies between instruc- OR1200 core. tions. The maximum achievable cross coverage is 40.7% The main scope of this verification coverage is to show while only 40.0% could be reached because of large test the verification completeness with respect to the decoding space and unreached combinations of the instruction type of instructions within the core. Therefore, the coverage “Insn rD, rA, rB”. matrix corresponds to the instruction decode and pipeline control logic. Verifying the correctness of the execution 5 of instructions with respect to data values is not included Conclusion due to the state explosion problem. No instruction or scenario having a problem either in The verification of processors consumes upto 70% of the ISS or in the OR1200 core is included in this veri- resources (time and effort) and is acknowledged as a fication since the errors have not been corrected. There major bottleneck in the development process, accord- are 78 instructions in the OR1200 instruction set but only ing to a variety of publications. This paper presents an 58 instructions could be included in the verification test OVM based reusable verification environment for cover- because 20 instructions are erroneous or unimplemented age driven constrained random verification of the OR1200 (either in the OR1200 core or in its ISS). Hence, the over- core. Furthermore, a new verification methodology is in- all instruction verification coverage is restricted to 74.3% troduced by using the ISS of the core as a golden model. which was successfully achieved. This methodology is successfully proven because it has The Table 2 shows the verification coverage results of credibly verified not only the OR1200 core but also the the OR1200 core. There are several instruction types in ISS on a single platform. Since the ISS is often imple- the OR1200 instruction set where each OR1200 instruc- mented before the core, it can be easily reused as a golden tion belongs to one of these types. The table shows the model. This will significantly reduce the development
time and the verification effort. Hence, the methodology [8] Embecosm. The Or1ksim Simulator. Embecosm.
is also proven beneficial because it saved resources to ver- ify the ISS and to develop the golden model for the core. [9] Mentor Graphics. ModelSim User’s Manual. Mentor Graphics, May 2008.
6 Acknowledgements [10] D. Haakon, G. Marius, and N. Lasse. Cache write-back schemes for embedded destructive-read dram. In Proceed- This work was funded by the COMET K2 Center “Aus- ings of the 9th International Conference on Architecture of trian Center of Mechatronics (ACCM)”. The COMET Computing Systems (ARCS), pages 145–159. 2006. program is funded by the Austrian government, the fed- [11] S. Imam. Step-by-Step Functional Verification with Sys- eral state of Upper Austria and the scientific partners of temVerilog and OVM. Hansen Brown Publishing Com- ACCM. pany, 2008. References [12] D. Lampart. OpenRISC 1000 Architecture Manual. Open- Cores, April 5 2006.
[1] W. Ahmed. Implementation and verification of a cpu sub- [13] P. Mishra, N. Dutt, and Y. Kashai. Functional verifica- system for multi-mode rf transceivers. Master’s thesis, tion of pipelined processors: A case study. In Proceedings Royal Institute of Technology (KTH), June 2010. of the 2005 IEEE/LEOS Workshop on Fibres and Optical Passive Components, pages 79 – 84, September 2004. [2] J. Bennett. Or1ksim User Guide. Embecosm, 2009. [14] P. P. Ravale and S. S. Apte. Design of a branch prediction [3] J. Bhadra, M.S. Abadir, L.-C. Wang, and S. Ray. A survey unit of a microprocessor based on superscalar architecture of hybrid techniques for functional verification. In Design using vlsi. In 2nd International conference on Computer & Test of Computers, IEEE, volume 24 , issue:2, pages Engineering and Technology (ICCET), pages V3–355 – 112 – 122, June 2007. V3–360, June 17 2010. [4] M. Bose, J. Shin, E.M. Rudnick, T. Dukes, and M. Abadir. [15] A. Sagahyroon, G. Lakkaraju, and M. Karunaratne. A A genetic approach to automatic bias generation for biased functional verification environment. In 48th Midwest Sym- random instruction generation. In Proceedings of the 2001 posium on Circuits and Systems, volume 1, pages 108 – Congress on Evolutionary Computation, volume 1, pages 111, August 2005. 442 – 448, August 2001. [16] F. Vitullo, S. Saponara, E. Petri, M. Casula, L. Fanucci, [5] Cadence. Open Verification Methodology User Guide. G. Maruccia, R. Locatelli, and M. Coppola. A reusable Cadence Design System, version 2.0 edition, September coverage-driven verification environment for network-on- 2008. chip communication in embedded system platforms. In Seventh Workshop on Intelligent solutions in Embedded [6] J. C. Chen. Applying constrained-random verification Systems, pages 71–77, June 2009. to microprocessors. EE Times EDA Designline, October 2007. [17] M.-K. You and G.-Y. Song. Systemverilog-based verifica- tion environment using systemc custom hierarchical chan- [7] D. Deharbe, S. Shankar, and E.M. Clarke. Formal verifi- nel. In Proceedings of the IEEE 8th International Confer- cation of vhdl, the model checker cv. In Proceedings of ence on ASIC, pages 1310 – 1313, October 2009. the XI Brazilian Symposium on Integrated Circuit Design, pages 95 – 98, October 1998.