Functional Verification in 8-bit Microcontrollers: A Case Study

Transcription

1 Functional Verification in 8-bit Microcontrollers: A Case Study Walter Soto Encinas Jr Walter.Encinas@motorola.com César Augusto Dueñas M. Cesar.Duenas@motorola.com Brazil Semiconductor Technology Center (BSTC) - SPS - Motorola Rod. SP-340, Km 129 Jaguariúna - SP - Brazil Abstract This paper overviews the most common functional verification techniques and describes the methodology adopted by BTSC Motorola in verification of 8-bit microcontrollers. We describe some topics in our methodology and highlight how this methodology addresses the particular requirements of this class of ICs, as the integration and reuse of Virtual Components (VC) and the tight design schedules. Presented results show the enormous workload needed by functional verification and how our verification methodology can allow the quick reuse of this work. 1 Introduction Generally speaking, verification is the process of checking if an implementation of a design matches its specification [1]. In the context of integrated circuits (IC) design, there are several specification domains, like functional, timing, electrical and real-estate. Functional specification is one of the most timeconsuming tasks in the design cycle. Nowadays, a complete system can be integrated on a single IC using millions of logic gates. This complexity makes the functional verification to be a bottleneck in the design cycle [2] since it consumes 60% of the human and computing resources in a design [3]. There is a rule-of-thumb which states that two verification engineers are needed for each design engineer. On the other hand, there is a broad range of complexity in digital ICs. Therefore, there is no verification technique that fits all requirements for all classes of digital ICs. Some verification techniques are well suited for very large designs [4], but, due to the inherent complexity of these techniques, they are not effective for simpler designs. 8-bit microcontrollers (MCUs) are a class of digital ICs which implements a system on a chip, but are in a lower complexity class than their 32-bit counterparts. The 8-bit MCU market is very dynamic and places stringent requirements for low cost and short design cycles. Therefore MCU designs are excellent candidates for reuse of blocks that implement functions needed in a broad range of applications, like timers, A-to-D converters, and so on. These blocks should be designed with reuse in mind and are known as IP (intellectual property) blocks, or more recently, VC (virtual components). Therefore a new MCU can be quickly developed by integrating these blocks with a processor core, pads and application specific logic, as shown in Figure 1. These characteristics make MCU verification an interesting case of study for verification techniques. This paper describes the verification methodology adopted by Motorola BSTC in the development of an 8-bit MCU. An overview of verification techniques will be presented in Section 2. Our methodology is described in detail in Section 3. Results are presented in Section 4. Comments and conclusions follow. MCU Proc RAM Pads IP Interface Figure 1: Diagram of an 8-bit MCU 2 Functional Verification Techniques Verification techniques can be broadly divided in 2 large groups [5]: static and dynamic, also know as formal and nonformal (or simulation based) verification techniques. A taxonomy of the techniques discussed next is shown in Figure Static Functional Verification or Formal Verification These techniques use formal mathematical methods to verify the functionality of a design. They are called static verification because these techniques don t require stimulus and simulation to verify the behavior of the design. Verification engineers don t need to develop a testbench or test vectors. On the down side, formal verification still has limitations and cannot completely substitute simulation and it is used to complement it. Formal verification techniques are divided in two classes [5]: the ones that check the design against specification and the ones that check the equivalence between an already verified model (golden model) and the model to be verified. They are called intent verification and equivalence checking respectively Intent Verification Two well known techniques that fall in the intent verification class are Model Checking and Theorem Proving. Model Checking generates all possible inputs to the model under all possible states, and checks if the properties of the model,

2 derived from specification, hold true. Due to exponential growth of complexity, this technique is better suited for verifying small blocks of control logic. This exhaustive approach implies a good coverage, but it depends on a careful construction of the properties. Theorem Proving express the model to be verified and the specification in a formal way, involving axioms, properties and inference rules. Verification is achieved by proving the properties using the axioms and inference rules. Effectiveness of this method depends on the quality of translation of the specification into properties. This method is not limited by the number of inputs or the size of the design state space and is well suited for verifying datapath-oriented designs Equivalence Checking Checks the equivalence of model under verification against a golden model, that is, a model already verified. This technique converts both models to a formal logic representation and check if these representations are the same. There are no properties to be created from specification because the golden model is used instead. Equivalence checking is offered by an increasing number of commercial tools, like Tuxedo [6]. 2.2 Dynamic Verification The design is verified through simulation by applying a pattern set. Design responses are checked with expected ones to assure correctness. This approach needs testbench, stimuli and responses to be created by hand by verification engineers. Dynamic verification also can be divided in Intent Verification and Equivalence Verification Intent Verification Specification is used as reference for the creation of verification patterns. This is a time consuming process as every statement in the specification should be checked by some pattern, and while the number of patterns grows quickly, there is no guarantee that the design is full verified Equivalence Checking Equivalence checking is performed by comparing responses of the model to be verified against responses of a golden model. In this case, pattern coverage can be improved by using pseudo-random stimuli in addition to deterministic ones. This is common practice for covering corner cases in complex blocks like processor cores [4][3]. Sometimes a hardware model of the block is built using FPGAs to speed up random verification [3]. This is known as circuit emulation. Normally equivalence checking is used to verify gate-level designs against a golden model in RTL or higher levels. 3 Case Study Our case study describes the verification in an 8-bit generalpurpose microcontroller upwardly compatible with the Motorola M68HC08 family. The instruction set incorporates all HC08 instructions, as well as additional ones and new addressing modes to improve compiler efficiency. In 48-pin LQFP or 40-pin PDIP packages and running at 40 MHz, this chip has the following blocks: 40 MHz HC08-compatible processor 512 bytes static RAM 16 Kbytes FLASH and 512 bytes EEPROM 34/30 general-purpose I/O pins in 48/40-pin packages Keyboard interrupt port Two SCI modules (asynchronous UART) SPI high-speed synchronous serial I/O 3-channel timer/pwm module 1-channel timer All the blocks were implemented as reusable VCs (virtual components). A VC database includes the logic model described in HDL, verification patterns, full documentation and all the necessary information to support all the tools in the design flow. The design flow is explained in depth in [7]. 3.1 Verification methodology The verification methodology used in this design adopts both static and dynamic verification techniques as appropriate for each VC as well as for the top level integration (a.k.a. SoC level). Intent verification relies on dynamic verification techniques. Verification engineers develop a set of verification patterns based on the specification of each of the VCs and its integration. A technique called spec-tagging helps to make sure that the patterns cover all functionality described in specification. These patterns are coded in assembly language and Verilog HDL [8]. They provide both stimuli and expected results. The patterns compare the later with simulation results indicating a pass or fail. Because of this the patterns are said to be self-checking. The simulation environment uses a testbench that instantiates a Verilog model of the device under verification as well as the Verilog part of the patterns. The assembly language part is compiled into object code and loaded into a behavioral memory model to be executed by the MCU. The verification patterns are simulated against the RTL model to validate its functionality. NC-Verilog was the simulator of choice [9]. The same pattern set runs in a later stage on a post-synthesis or post-layout Verilog netlist with full timing information, and whenever design is modified. This process of simulating the full pattern set, reporting a list of passed and failed patterns is known as regression run [10]. It Functional Verification Static Dynamic Intent Equivalence Intent Equivalence Theorem Proving Model Check Equiv Check Deteministic Deterministic Random Figure 2: Taxonomy of Functional Verification Techniques

3 should be run after modifications in design to check if the changes had the expected effects and didn t affect other blocks. To complement the verification, equivalence checking is used to validate gate-level netlist against the RTL. Depending on block complexity, simulations with random stimuli can be used. Processor cores are good candidates for this technique [2] [10] and it was used in the verification of our core. An ISA (instruction set accurate) model was developed and the same randomly generated instruction stream was fed to both the RTL and ISA model, having their outputs compared. Several million random patterns were run successfully. Shaded boxes in Figure 2 identify the verification techniques used in our methodology. 3.2 Spec-tagging Specification tagging (a.k.a. specification annotation) is the process of labeling (tagging) every sentence in the functional specification related to some testable functional aspect with the name of the functional pattern that tests the described functionality. This systematic approach provides traceability between the functional specification and the verification pattern suite, maximizing the coverage of the functionality described in the specification. The spec-tagging process is aided by an in-house tool that collects all the specification statements with a given tag and creates a header for the pattern with all statements that should be tested. This header outlines the pattern strategy and is used as the starting point for the pattern development. benefits like allowing to easily excluding the drivers/monitors when they are not needed or wanted. Depending on the simulation context, patterns can be classified as being either slave or master mode. module clk_gen(clk); real freq; reg enabled; reg clk; output clk; // Model of clock generator goes here task set_freq(f); task set_value(v); task enable; task disable; endmodule Example 1: Driver structure, in Verilog 3.4 Slave Mode In this mode a driver generates read or write transactions directly on the IP Interface bus, completely bypassing the processor. Other blocks may be present to generate other signals to stimulate the block under test, or may be substituted by drivers performing its role. This is shown in Figure Once dynamic verification is used, testbench development is necessary. The testbench instantiates the block under verification, stimulates the block using drivers and check its responses using monitors as shown in Figure 3. Stimuli, expected results and checks are embedded in the patterns. DUT Bus driver Block Under Verif. DUT IP Interface Figure 3: structure and monitors are verification entities only, not intended for synthesis. and monitors are behavioral models structured in same fashion as software objects, with internal variables storing state of the module (properties) and tasks that control the module (methods). This object-oriented approach allows monitors and drivers to implement tasks that perform full transactions. In this way, low-level details of transactions are hidden from patterns, enhancing its reusability and readability. A simple driver (a clock generator) shown in Example 1 clarifies these ideas. and monitors are not declared or instantiated in the main testbench file. Instead, each monitor or driver is declared in an individual files, which is included and instantiated in the testbench by our simulation environment. This approach brings Figure 4: for Verification in Slave Mode As verification in slave mode can be carried out without any other block besides block under verification, it is useful for preliminary testing of the block. It is desired that verification patterns can also be reused to perform production tests in silicon. Slave-mode verification patterns must drive the IP Interface bus inside the chip. High pin-count devices, like 32- bit MCUs, have enough pins to bring outside the chip these signals (data bus, address bus and other control signals), enabling reuse of slave-mode verification patterns in production test. But this is hardly the case with 8-bit MCUs, generally low pin-count devices. So new patterns should be developed for use in production tests. That s why verification in slave mode was not adopted in our 8-bit MCU verification methodology.

4 3.5 Master Mode Master mode verification simulates the block in a full chip context. All transactions on the IP Interface are driven by the processor, not by drivers. Other blocks may drive other internal signals, if they are instantiated. The testbench only drives external signals and checks the responses of the device. The processor generates the internal stimuli by running a program stored in its memory. External stimuli and response checks are coded in the testbench, as shown in Figure 5. Verification in master mode does a more extensive verification than slave mode because patterns will test not only the functionality of block under verification but also the connections from this block to the IP Interface, pads, and other blocks. Due to this fact, there are fewer conditions to test in integration of these blocks (top-level) and fewer patterns to develop, making patterns developed in master mode more reusable than those in slave mode, regarding VC integration. Likewise, master mode offers better pattern reusability for production tests, since internal signals are all driven by the processor and other blocks, not by the testbench. On the other hand, master mode verification requires that models for the processor and other integration blocks are available and debugged.. Behavioral models can be used while RTL or gatelevel models are not available. 3.6 Stimuli Synchronization Since master mode patterns require codification in two domains (assembler and some HDL, Verilog in our case), these domains must be synchronized. This is illustrated in Example 2, where the value of bit 0 in port B of the MCU must be checked at the correct time. Two possible synchronization methods are: by memory access and by instruction fetch. DUT Proc RAM Block Under Verif. IP Interface Memory Access Synchronization is achieved by monitoring the address bus for some reserved memory addresses. Verilog part of verification pattern waits the assembler part accesses one of these memory addresses. When Verilog part detects it the checks are done. This technique is well suited for processors with large addressing space and large amounts of RAM, because some addresses must be reserved for synchronization purposes and extra instructions are required for each synchronization memory access. Figure 5: for Verification in Master Mode ; Set bit 0 in PORT B BSET 0,PORTB ; Clear bit 0 in PORT B BCLR 0,PORTB Instruction Fetch Synchronization is achieved by monitoring the address bus during instruction fetches. This technique does not require reserved addresses or extra synchronization instructions, but cannot be used in the case of processors with complex pipelines. It is well suited for 8-bit MCUs, which are scarce in address space and RAM, and generally have a simple pipeline structure with constant look-ahead for instruction fetch. Therefore, this is the synchronization technique used in our methodology. Example 3 shows assembler and Verilog parts synchronized using this technique. The addresses of assembler labels can be determined by processing the report file generated by the assembler program. Corresponding Verilog define statements can be created with these information and included in Verilog part of the patterns. But having the pattern distributed in two separate files, PORTB0_PIN_MONITOR.CHECK(1); PORTB0_PIN_MONITOR.CHECK(0); Example 2: Pattern with stimulus in assembler and response checking in Verilog ; Set bit 0 in PORT B BSET 0,PORTB SET_BIT_LABEL: ; Clear bit 0 in PORT B BCLR 0,PORTB CLR_BIT_LABEL: wait (`ADDRESS_BUS == `SET_BIT_LABEL+`CTE_PIPE); PORTB0_PIN_MONITOR.CHECK(1); wait ( ÀDDRESS_BUS == `CLR_BIT_LABEL+`CTE_PIPE); PORTB0_PIN_MONITOR.CHECK(0); Example 3: Synchronized pattern with stimulus in assembler and response checking in Verilog BSET 0,PORTB ; Set bit 0 in PORT B FUNA code_pc,*+cte_pipe & wait ( ÀDDRESS_BUS == code_pc); & PORTB0_PIN_MONITOR.CHECK(1); BCLR 0,PORTB ; Clear bit 0 in PORT B FUNA code_pc,*+cte_pipe & wait ( ÀDDRESS_BUS == code_pc); & PORTB0_PIN_MONITOR.CHECK(0); code_pc = 16 h00a4; // Generated by FUNA wait ( ÀDDRESS_BUS == code_pc); PORTB0_PIN_MONITOR.CHECK(1); code_pc = 16 h00a5; // Generated by FUNA wait ( ÀDDRESS_BUS == code_pc); PORTB0_PIN_MONITOR.CHECK(0); Example 4: Synchronized pattern coded in embedded Verilog and Verilog file after assembler processing

5 assembler and Verilog, is not very convenient Embedded Verilog A more elegant solution for synchronization in master mode was reached by integrating assembler and Verilog in the same file. A commercial assembler program was modified under Motorola specifications to do that. This assembler recognizes all lines starting by & as special comments containing Verilog statements, which are extracted into a file as part of the each of the blocks (behavioral, RTL, gate-level with or without timing, and so on). In master mode, the assembler pattern is translated into object code which is then converted to a format suitable to be read by the $readmemh Verilog system task, that initializes the behavioral RAM model. The file with the extracted embedded Verilog is included in the testbench. After that, simulation can start as shown in Figure 6. All this functionality is encapsulated in a single script, which also allows automation of complete regressions, generating a specification blocks testbench spectag behavioral Verilog RTL Verilog Verilog Netlist Verilog pattern spec statements verification engineer Embedded Verilog asm Collector OBJ Verilog Proc Block Under Test OBJ to Mem PLI RAM IP Mem Figure 6: Structure of verification environment assembly process. Besides that, a new pseudo-instruction FUNA was created. As other pseudo instructions, it does not generate any object code. It generates a Verilog attribution statement and writes this statement to the file along with the other embedded Verilog statements, working like a bridge linking assembler and Verilog domains. Any constant or label in assembler can be passed to the Verilog domain. Example 4 shows FUNA storing the address of the current assembler instruction (plus a constant) to a Verilog variable code_pc. The constant added to the current address circumvents the processor pipeline, which fetches an instruction some cycles before it is really executed. The coding style of assembler with embedded Verilog should be a linear sequence of stimuli and checks, and it is necessary to take care with changes of flow as they may compromise the synchronization. 3.7 Verification Environment Our simulation environment is a set of programs that automate the simulation of a pattern. They collect all the block models needed, as well as desired drivers and monitors, building all the verification infrastructure of the whole MCU, which is then handed to the simulator. A configuration file guides this process, allowing the user to choose which model is used for pass/fail log file. 4 Results The design used for this case study was a completely new design and no blocks were available for reuse. A full suite of verification patterns had to be created for each block as well as for the top-level integration. Table 1 shows the number of patterns as well as the number of simulation runs. This is because some patterns can be configured at run time to test more than one case. It took 33 verification engineers for 6 months to complete the pattern development. 5 Conclusions The results shown make clear the enormous amount of work spent in functional verification. Due to this fact, a verification methodology must consider pattern reuse as is the case with the one presented here. Patterns suites developed for each block are delivered as part of its database for reuse in future designs. Master mode patterns can be also be reused for production tests resulting in even more savings. Other benefit is a relatively modest number of patterns that verify integration, because in master mode patterns verify the block for functionality as well as integration. A new MCU version is now under development, and mostly all of its blocks are being reused. Instead 33

6 verification engineers, verification team now is just one. This shows the importance of reuse in the verification methodology. References [1] Dhodhi, M. et al, Functional Verification of Multimillion Gates ASICs for Designing Communications Networks: Trends, Tools and Techniques, Int. Conference on Microelectronics ICM '99, pp , 1999 [2] Yim, Joon-Seo et al, Verification Methodology of Compatible Microprocessors, Design Automation Conference DAC 97, pp , 1997 [3] Kumar, J.; Pixley, C., Logic and functional verification in a commercial semiconductor environment, Int. Conference on Application of Concurrency to System Design, pp. 8 15, 1998 [4] Glenn, Scott et al, Functional Design Verification for the PowerPC 601 microprocessor, 12 th IEEE VLSI Test Symposium, pp , 1994 [5] VSI Alliance, Taxonomy of Functional Verification for Virtual Component, Jan [6] [7] Oliveira, A., Takiguti, R., Andrade, P. J., Development of an 8-bit Microcontroller Using System-on-a-Chip Methodology, 7 th IBERCHIP, Mar [8] Palnitkar, S., Verilog HDL - A Guide to Digital Design and Synthesis, Prentice Hall, 1996 [9] affirma_nc_verilog_sim.html, 2001 [10] Hu, Eileen et al, A Methodology for Design Verification, 7 th IEEE Int. ASIC Conference and Exhibit, pp , 1994 Block # of Patterns # of Runs Processor RAM 8 13 Flash and EEPROM Ports 6 12 Keyboard and External Interrupts SCI SPI channel Timer channel Timer Integration Total Table 1: Patterns developed for each block of MCU