SOURCE ARCHIVE
EXTRACTED CONTENT
36,034 charsUVM-based Verification of a RISC-V Processor Core Using a Golden Predictor Model and a Configuration Layer by Marcela Zachariášová and Luboš Moravec — Codasip Ltd., John Stickley and Shakeel Jeeawoody — Mentor, A Siemens Business
RISC-V is a new ISA (Instruction Set Architecture) in [3][4], the design flow utilized by Codasip is
that introduces high level of flexibility into processor highly automated, see Fig. 1. Codasip describes
architecture design, and enables processor processors at a higher abstraction level using an
implementations tailored for applications in a variety architecture description language called CodAL.
of domains, from embedded systems, IoT, and Each processor is described by two CodAL models,
high-end mobile phones to warehouse-scale cloud the instruction-accurate (IA) model, and the cycle-
computers. The downside of this extent of flexibility accurate (CA) model. The IA model describes the
is the verification effort that must be devoted to all syntax and semantics of the instructions and their
variants of the RISC-V cores. In this article, Codasip functional behavior without any micro-architectural
and Mentor aim to describe their methodology of details. To complement, the CA model describes
effective verification of RISC-V processors, based on micro-architectural details such as pipelines,
a combination of standard techniques, such as UVM decoding, timing, etc. From these two CodAL
and emulation, and new concepts that focus on the models, Codasip tools can automatically generate
specifics of the RISC-V verification, such as configura- SDK tools (assembler, linker, C-compiler, simulators,
tion layer, golden predictor model, and FlexMem profilers, debuggers) together with RTL and UVM
approach. verification environments, as described in [5]. In UVM,
the IA model is used as a golden predictor model,
and the RTL generated from the CA model is used
INTRODUCTION as the Design Under Test (DUT). Such high level of
RISC-V is a free-to-use and open ISA developed at automation allows for very fast exploration of the
the University of California, Berkeley, now officially design space, producing a unique processor IP with
supported by the RISC-V Foundation [1][2]. It was all the software tools in minutes.
originally designed for research and education, but
it is currently being adopted by many commercial This article aims to demonstrate that the flexibility of
implementations similar to ARM cores. The flexibility RISC-V ISA presents benefits as well as challenges,
is reflected in many ISA extensions. In addition to namely in verification. We will show how to overcome
basic Integer (“I”/”E”) ISA, many instruction extensions these challenges with a suitable verification strategy,
are supported, including multiplication and division comprising several stages (described in separate
extension (“M”), compressed instructions extension sections of the article):
(“C”), atomic operations extension (“A”), floating-point 1. Defining a configuration layer for RISC-V design
extension (“F”), floating-point with double-precision and verification to check all possible variants
(“D”), floating-point with quad-precision (“Q”), and 2. Defining a golden predictor model based
others. By their combination, more than 100 viable on an ISA simulator to decrease RTL-simulation
ISAs can be created. overhead
Codasip is a company that delivers RISC-V IP cores, 3. Utilizing emulation environment and FlexMem
internally named Codix Berkelium (Bk). In contrast approach to effectively perform all test suites
to the standard design flow, as defined for example
53
VERIFICATIONHORIZONS Menior
cre 1. The first option
is to place the
configuration
um layer at the
EE beginning of the
eer = Cycle Accurate Simulator, Profiler Cr automation flow. Codasip does so by inserting the Figure 1: Codasip's Flow of Generating SDK, RTL, Reference Models, configuration and UVM Verification Environment. string into the high-level CodAL description; see DEFINING A CONFIGURATION an example of a GUI configuration entry in Codasip LAYER FOR RISC-V DESIGN Studio (the processor development environment) in Fig. 2. As you can see, the configuration text string AND VERIFICATION consists of three parts divided by dashes. The first Considering the possible number of RISC-V core part specifies the name of the processor and the variants, it is not practical to manually implement and number of pipeline stages. The second part contains maintain all corresponding RTL representations and the used ISA extensions, and the last part specifies UVM environments. Automation is advisable, its type optional hardware extensions. depending on the configuration variability of RISC-V a. bk3-32IM-pd: When considering bk3-32IM-pd cores. This article will present three options. configuration string in Codasip Studio (Fig. 2), the For demonstration purposes, we will use two different defined processor model will have three pipeline configurations of Codasip Berkelium processor: stages and 32-bit word-width support. It will con- tain base integer instructions (“I”), instructions for a) bk3-32IM-pd multiplication and division (“M”), and it will have two b) bk3-32IMC-pd hardware extensions – parallel multiplier (“p”) and JTAG debug interface (“d”). Other settings, such as “I”, “M”, and “C” stand for standard RISC-V instruction memory size or caches enabled, can be found in the extensions as defined in Section I, “p” signifies options table. Once the configuration is complete, it enabled hardware parallel multiplier, and “d” is possible to automatically generate RTL and UVM for enabled JTAG debugging. The difference between this specific configuration with a single click. the presence and absence of the multiplication and division extension (“M”) in the Bk processor configuration practically only consists in the number of supported instructions. From the RTL and UVM point of view, this means that the existing RTL tc modules are longer, and the instruction decoder is Options: more complicated. However, when the compressed EET instructions extension (“C”) is enabled, many new logic blocks are added to the RTL together with a new dedicated instructions decoder. This requires | [+] compiling additional RTL files that will describe these | new logic blocks. From the UVM point of view, a new E59 UVM agent for the compressed instructions decoder needs to be compiled and properly connected to the rest of the UVM environment. Figure 2: bk3-32IM-pd Configuration in Codasip Studio.
54
configuring the UVM environment during compilation
before each individual verification run. Furthermore,
it makes for easier extending of the UVM environment
with new ISA or hardware extensions.
Figure 3: bk3-32IMC-pd Configuration in Codasip Studio Example 1: Code snippets with ifdef parts for bk3-32IM-pd configuration:
b. bk3-32IMC-pd: When using the configuration /* Decoder description
layer in Codasip Studio, no overhead is created by * file: codix_berkelium_ca_core_dec_t_decoder.svh
enabling the compressed instructions extension /
(“C”) in the bk3-32IMC-pd configuration (Fig. 3).
The only action needed is rebuilding of the RTL and // enumeration code for every decoded instruction
UVM environments so that they reflect the change in typedef enum {
configuration. add_,
and_,
2. The second option, suitable for manually written ...
} m_instruction;
RTLs and verification environments, is to implement
RTL and UVM that can be configured by ifdef // “M” instructions
constructs and related scripts. With this method, only ifdef EXTENSION_M one RTL and one verification environment for multiple typedef enum RISC-V core variants are needed. { mul_, mulh_, a. bk3-32IM-pd: To compile the source files, we use ... } m_instruction_ext_m; the compiler define options that are common for endif
RTL and UVM, as seen in Fig. 4. Code snippets in
Example 1 show that the configurable extensions / UVM Instructions decoder coverage collection
are enclosed in their specific define parts. For * file: decoder_coverage.sv
example, “M” instructions are enclosed in ifdef */ EXTENSION_M in the decoder.svh file. Only when this file is compiled with +define+EXTENSION_M, the “M” // Covergroup definition instructions will be recognized by the decoder. The covergroup FunctionalCoverage( string inst ); same applies to the part of the example related to cvp_instructions : coverpoint m_transaction_h.m_instruction { coverage. Thus, the principle of this method allows for illegal_bins unknown_instruction = {UNKNOWN}; option.comment = "Coverpoint for decoded instructions. Unknown instruction is considered Compile of configurations as illegal."; +define+EXTENSION_M+EXTENSION_C+ } ifdef EXTENSION_M
cvp_instructions_ext_m : coverpoint m_transaction_h.m_
instruction_ext_m { illegal_bins unknown_instruction =
{UNKNOWN};
UVM Files | option.comment = "Cover-point for decoded instructions
for M extension. Unknown instruction
is considered as illegal.";
}
`endif
Figure 4: Compilation of All Files with Defines
55
ificationHorizonsBlog.c
b. bk3-32IMC-pd: When adding the “C” extension,
it is vital to ensure that an additional agent for the /* Environment registration to UVM configuration database
compressed instructions decoder will be compiled * file: codix_berkelium_ca_env.svh
and connected. As shown in Example 2, ifdef */ EXTENSION_C allows compiling the agent package which contains all agent files for compressed // main sub-components used to collect instruction coverage instructions decoder in compile.tcl file, binding the codix_berkelium_ca_core_dec_t_agent m_codix_berkelium_ agent to the RTL signals of the processor in dut.sv ca_core_dec_t_agent_dut_h; file and registering it into the UVM configuration ifdef EXTENSION_C
database in the UVM environment env.sv file. codix_berkelium_ca_core_decompressor_16b32b_t_agent
m_codix_berkelium_ca_core_decompressor_16b32b_t_
Example 2: Code snippets with ifdef parts for agent_dut_h;
bk3-32IMC-pd configuration: `endif
uvm_config_db #( codix_berkelium_ca_core_dec_t_agent_
/* Compile script config )::set( this,
file: compile.tcl "m_codix_berkelium_ca_core_dec_t_agent_dut_h*",
*/ "codix_berkelium_ca_core_dec_t_agent_config", m_cfg_h.m_codix_berkelium_ca_core_dec_t_agent_
UVM packages, interfaces and probes compilation config_dut_h );
compile_fve_source ${LIBRARY} [list
... m_codix_berkelium_ca_core_dec_t_agent_dut_h =
[file join agents codix_berkelium_ca_core_dec_t_agent codix_berkelium_ca_core_dec_t_agent::type_id::create(
sv_codix_berkelium_ca_core_dec_t_agent_pkg.sv] \ "m_codix_berkelium_ca_core_dec_t_agent_dut_h", this );
# Compilation of compressed instructions decoder ifdef EXTENSION_C ifdef EXTENSION_C uvm_config_db #( codix_berkelium_ca_core_
[file join agents codix_berkelium_ca_core_ decompressor_16b32b_t_agent_config
decompressor_16b32b_t_agent )::set( this,
sv_codix_berkelium_ca_core_decompressor_16b32b_t_ "m_codix_berkelium_ca_core_decompressor_16b32b_t_
agent_pkg.sv] \ agent_dut_h*",
`endif "codix_berkelium_ca_core_decompressor_16b32b_t_
agent_config",
m_cfg_h.m_codix_berkelium_ca_core decompressor_
/* Interconnection of probes and RTL modules 16b32b_t_agent_config_dut_h );
- file: dut.sv */ m_codix_berkelium_ca_core_decompressor_16b32b_t_ agent_dut_h =
bind HDL_DUT_U.codix_berkelium.core.dec codix_berkelium_ca_core_decompressor_16b32b_t_
icodix_berkelium_ca_core_dec_t_probe probe( agent::type_id::create(
.ACT(ACT), "m_codix_berkelium_ca_core_decompressor_16b32b_t_
.codasip_param_0(codasip_param_0) agent_dut_h", this );
); endif // binding of compressed instructions decoder ifdef EXTENSION_C
bind HDL_DUT_U.codix_berkelium.core.decompressor_16b32b
icodix_berkelium_ca_core_decompressor_16b32b_t_probe 3. The third option is to use the standard means
probe( of UVM for configuration (uvm_config_db, see [6]).
.ACT(ACT), This option is similar to using ifdef (second option
); .codasip_param_0(codasip_param_0) presented in this article), but it is limited to the UVM
`endif environment.
a. bk3-32IM-pd: As indicated by the code snippet in
Example 3, enabling of the “M” instruction extension
is reflected by the extension_M parameter which
56
is saved into the UVM configuration database. It is For the comparison of all above-mentioned then possible to obtain its value by calling the get configuration methods, we summarized the function from a specific part of the UVM environment main advantages and disadvantages in Table 1, (the coverage file, for example), and then use it for "Advantages and Disadvantages of the creating new objects. Configuration Methods"
Example 3: Code snippet with uvm_config_db Pros Cons example for bk3-32IM-pd configuration: Configuration set at Easy setting The generated higher abstraction of desired RTL + UVM are /* Decoder agent configuration level and RTL + configuration, dedicated just
- file: codix_berkelium_ca_core_dec_t_agent_config.svh UVM are generated better readability of to one processor */ generated source configuration files, and very fast .
// uvm_config_db configuration and set function void set_decoder_config_params(); Ifdefs for manually Support of Worse readability of //set configuration info written RTL and multiple processor code in source files decoder = new(); UVM files configurations . decoder.extension_M = 1; uvm_config_db Support of Worse readability ... for manually multiple processor of code in source uvm_config_db #(decoder_config)::set( this, "*" , written UVM files configurations in files. Limited only " decoder_config" , decoder ); UVM source files to UVM . endfunction
/* Decoder agent coverage
- file: codix_berkelium_ca_core_dec_t_coverage.svh */ DEFINING A GOLDEN PREDICTOR
// Decoder uvm_config_db get and use example MODEL BASED ON AN decoder_config dec_config; ISA SIMULATOR if( !uvm_config_db #( decoder_config )::get( this , "" , "decoder_ An ISA simulator, or an instruction simulator, is used config" , dec_config ) ) begin to execute the instruction stream. High performance end `uvm_error(...) is achieved by omitting micro-architectural ... implementation details. The simulator is usually cvp_instructions : coverpoint m_transaction_h.m_ implemented in C/C++/SystemC, and represents the instruction{…} reference functionality [7]. if( m_config.extension_M ) begin cvp_instructions_ext_m : coverpoint m_transaction_ Codasip generates an ISA simulator from the high- h.m_instruction_ext_m {…} end level instruction-accurate CodAL model as part of their automation flow. The ISA simulator is also used as a golden predictor model in UVM verification, meaning that the RTL processor model (DUV) b. bk3-32IMC-pd: When we applied the uvm_config_ generated from the high-level cycle-accurate CodAL db procedure to the configuration with “C” extension model is verified against it. There are some obstacles enabled, we encountered difficulties with connecting to this approach, such as the asynchronous nature of the additional agent and compiling the source files. the C++ ISA model (RTL is cycle-accurate), resolved That tells us that this method is suitable for ISA or by memory loaders that can load a program to the hardware extensions that extend the functions of the program memory consistently in RTL and C++ – after processor without additional logic files that need to that, both are running on their own speed. Result be compiled and connected. comparison is handled by buffering the outputs of the faster component: when data is present in both
57
the golden predictor model FIFO and the DUV 1. We started by comparing pure simulation and FIFO in Scoreboard, comparison is executed. pure emulation environment runtimes. This means that we measured time of loading a specific program In the Codasip automation flow, assembling the to the program part of the memory and the runtime UVM verification environment including the golden of evaluating this program on the RISC-V Berkelium predictor model is much faster than in the standard processor in UVM in Questa® RTL simulator, and flow, when all components are written manually. the runtime of evaluating the same program on the Time savings on the verification work are counted Berkelium processor located on the emulator. In in man-months. this case, we used a very simple emulator top-level module which instantiates the Berkelium processor. UTILIZING EMULATION At the beginning, the program is loaded, and by deactivating the processor’s RESET signal it starts ENVIRONMENT AND FLEXMEM processing the program. A simple comparison of APPROACH TO EFFECTIVELY this type clearly indicates the maximum emulation PERFORM TESTS performance for a specific DUV, as no software counterparts are slowing it down. In addition, it is Getting a viable golden predictor model is, however, also possible to estimate the benefits of using the only the first step. The second important criterion emulator for a specific project. For example, we is simulation runtime. Flexibility of the RISC-V ISA estimated that we can achieve at least 100 times allows for implementing tens of viable processor verification acceleration when using the emulator. RISC-V micro-architectures. For example, at Codasip we are currently working with 48 variants of RISC-V. 2. As a second step, we recommend creating two Considering that each of these micro-architecture is top-levels: the emulator top-level module and the verified by at least 10,000 programs of around 500 testbench top-level module. The emulator top- instructions (C-programs, benchmarks, randomly level module instantiates the Berkelium processor, generated assembler programs), the verification and the testbench top-level module contains a runtime is enormous. To handle the effort, we di- simple SystemVerilog class with two pipes to start vided the verification runtime into phases. In the first processing programs and detect the end (it also phase, we run suitable program representatives in initiates comparison of the content of registers to RTL simulation, benefiting from very good debugging the reference content, which is for now done by a capabilities of the simulator. In the second phase, simple diff, so no golden predictor model is used after debugging, we run the rest of the programs in this phase). This approach makes it possible to (mainly random ones) in the emulation environment. run more programs on the processor and detect first bottlenecks. For example, we found out that The main drawback of RTL simulation is the inability processing the programs is very fast, but loading new to perform tasks in parallel. A good solution is to programs is ineffective and decreases the emulation use emulation and exploit inherent parallelism performance 25 times. To eliminate this problem, in real hardware environment. Many papers and we used FlexMem blocks later in the process, as books have already been published that present the described in the next section of this article. possible runtime improvements, for example [8]; our goal in this article is to show how verification of the 3. Finally, it is recommended to connect all UVM RISC-V processors in particular can benefit from the objects you intend to use into the testbench top- emulation environment. level module, as they usually add some additional bottlenecks. We connected SystemVerilog programs Our path of porting quite complex UVM environment loader, Codasip C++ ISA simulator as the reference for Berkelium processors to the Veloce® emulator [9] model, one active UVM agent to drive processor’s was not straightforward; based on our experience, we input ports and read the decoded instructions defined the following recommendations. (important for measuring instruction coverage and instruction sequences coverage), and passive UVM
58
agents for reading the transactions on buses, content We achieved the results shown in Table 2 below,
of architectural registers, and content of memory, "Emulation Performance Results", by employing the
as these are compared to the reference results three mentioned steps. The current version achieves
originating from the reference model. The emulation 25.6x acceleration, but we are working on further
performance decreased so much that we started optimizations including data aggregation on the
with profiling in Questa® as well as in the emulator. testbench and on the emulation side, and measuring
The result was that FlexMem blocks are very effective instruction coverage on the emulator directly.
for loading programs from software to the emulator,
however, we had to implement so-called “transactors” Average runtime Acceleration
[x] for driving processor’s input ports from the active for 1 program achieved
UVM agent, for monitoring decoded instructions in seconds (~100
from the processor, and for detecting the end of the 000 instructions)
program. We also realized that having the golden Pure simulation- 128 (simulation) 100 ×
predictor model and Scoreboard comparison as part based verification | 1.28 (emulation)
of the software testbench is not effective, as moving vs. pure emula-
the content of transactions, registers and memories tion-based
between the emulation top-level and the testbench verification
top-level negatively impacts the performance. Thus Emulation-based 32 4 ×
we decided to locate the predictor outside of the test- verification with
bench top-level and to leave it up to the emulation simple test-bench
and pipes
top-level to trigger the results comparison by the diff Emulation-based 20 25.6x
tool when the end of the program is detected. This verification with
means that the golden predictor model is running in UVM, FlexMem
parallel to the emulation, and we used dumping of and external ISA
DUV as well as reference data resources from both simulator
the golden predictor model and from the processor
located in the emulator. For illustration of the result-
ant environment, see Fig. 5, below.
oe] FlexMem TTT
env Seguin]
codasip_top_level_t module
berkelium_t_env
| \ | DIFF dumping of I ISAsimulator ~~ — ofregisters |
Figure 5: Codasip UVM Ported to the Veloce® Emulator
59
VerificationHorizonsBlog.com
SUMMARY REFERENCES This article covered three topics that result from the flexibility of RISC-V IP cores. The first topic described [1] RISC-V Foundation. (2017, July) RISC-V usage of the configuration layer, and was divided Specifications [Online]. Available: https://riscv.org/ into three sub-parts. The first part introduced the specifications/ automation flow used in the processor development [2] David Patterson and John Hennessy. (2017) environment called Codasip Studio. This flow Computer Organization and Design, RISC-V Edition, enables the user to simply input desired supported Morgan Kaufmann. configuration, and the Studio automatically generates all the tools needed for verification and application [3] John Shen and Mikko Lipasti. (2013) Modern development. Processor Design, Waveland Press. The second part explained the usage of defines in [4] Jari Nurmi. (2007) Processor Design, Springer. RTL and UVM files. This part showed that the user can have multiple configurations implemented in [5] Marcela Zachariášová, Zdeněk Přikryl, et al. (2013) one package of source files. This is possible thanks to “Automated Functional Verification of ASIPs,” in compiler defines allowing to mark parts of the code IFIP Advances in Information and Communication that are specific to individual processor extensions. Technology. Springer Verlag, pp. 128–138. The third part elaborated on the procedure of using [6] Verification Academy. (2017, July) UVM a UVM configuration database. The advantage of Configuration [Online]. Available: https:// this approach is the integrated configuration in UVM verificationacademy.com/cookbook/configuration itself. As it is restricted to UVM files, RTL needs to only [7] Rainer Leupers and Olivier Temam. (2010) include files for one configuration at a time. Processor and System-on-Chip Simulation, Springer We transformed a pure simulation-based UVM [8] Hans van der Schoot and Ahmed Yehia. (2015) environment into an emulation environment “UVM and Emulation: How to Get Your Ultimate employing the best practices, and measured the Testbench Acceleration Speed-up”, DVCon Europe acceleration results. In cooperation with Mentor, 2015. we identified parts of the processor that required specific treatment to exploit the full emulation [9] Veloce emulator [Online]. Available: https://www. performance. Excluding the predictor model from mentor.com/products/fv/emulation-systems/ UVM, implementing transactors, and utilizing diff [10] Janick Bergeron, Alan Hunter, Andy Nightingale, comparison outside the UVM allowed us to remove Eduard Černý. (2006) Verification Methodology a significant part of the DPI layer and decrease the Manual for SystemVerilog. Springer. burden of data transfers between software and the emulation environment. Also, utilizing FlexMem approach when loading programs to the program Note: This paper was originally presented memory proved to be less time-consuming than at DVCon US 2018. using pipes (readmemh and writememh functions) directly with emulator memory.
60
VERIFICATION ACADEMY The Most Comprehensive Resource for Verification Training
32 Video Courses Available Covering
32 Video Courses Available Covering
• UVM Framework
• UVM Framework
• UVM Debug
• UVM Debug
• Portable Stimulus Basics
• Portable Stimulus Basics
• SystemVerilog OOP
• SystemVerilog OOP
• Formal Verification
• Formal Verification
• Metrics in SoC Verification
• Metrics in SoC Verification
• Verification Planning
• Verification Planning
• Introductory, Basic, and Advanced UVM
• Introductory, Basic, and Advanced UVM
• Assertion-Based Verification
• Assertion-Based Verification
• FPGA Verification
• FPGA Verification
• Testbench Acceleration
• Testbench Acceleration
• PowerAware Verification
• PowerAware Verification
• Analog Mixed-Signal Verification
• Analog Mixed-Signal Verification
UVM and Coverage Online Methodology Cookbooks
UVM and Coverage Online Methodology Cookbooks
Discussion Forum with more than 9625 topics
Discussion Forum with more than 9625 topics
Verification Patterns Library
Verification Patterns Library
www.verificationacademy.com
www.verificationacademy.com
Editor:
Tom Fitzpatrick
Program Manager:
Rebecca Granquist
Mentor, A Siemens Business
Worldwide Headquarters
8005 SW Boeckman Rd.
Wilsonville, OR 97070-7777
Phone: 503-685-7000
To subscribe visit:
www.mentor.com/horizons
To view our blog visit:
VERIFICATIONHORIZONSBLOG.COM
Verification Horizons is a publication of Mentor, A Siemens Business ©2018, All rights reserved.