Exception Handling in Microprocessors Using Assertion Libraries Fernando Cortez Sica
Claudionor N. Coelho Junior
José Augusto M. Nacif
DCC/UFMG – DECOM/UFOP Av. Antônio Carlos 6.627 Belo Horizonte, Brazil – 31.270-010 +55 31 3499-5860
Federal University of Minas Gerais Av. Antônio Carlos 6.627 Belo Horizonte, Brazil – 31.270-010 +55 31 3499-5860
Federal University of Minas Gerais Av. Antônio Carlos 6.627 Belo Horizonte, Brazil – 31.270-010 +55 31 3499-5860
[email protected]
[email protected] [email protected] Harry Foster Antônio Otávio Fernandes
Jasper Design Automation, Inc. 100 View St #101 Mountain View, CA 94041 +1 650 804 5000
Federal University of Minas Gerais Av. Antônio Carlos 6.627 Belo Horizonte, Brazil – 31.270-010 +55 31 3499-5860
[email protected]
[email protected]
violation [1]. To this date exception handling has been implemented using an ad hoc approach, i.e. as a circuitry intermingled in the design to handle special cases evaluated in a single cycle, such as described in [2]. Designing such circuitry may be a difficult task because exception handling is usually solved in a frequency much slower than the microprocessor speed, requiring solutions that are mixed between hardware and software.
ABSTRACT In complex System-on-a-Chip (SoC) designs, designers often need to add new features into an original processor core, such as to extend the exception handling mechanism to consider exceptions in the remaining portion of the SoC design. We present in this paper a scalable architecture that can be used to add complex exception handling mechanisms in processor cores and how it can be used to extend the fixed set of exceptions found in microprocessor cores. This mechanism is based on the use of assertion libraries linked by an assertion processor to incorporate these new functionalities.
As increased functionality are added to microprocessor baseddesigns in a single chip, it becomes clear that we need to extend exception handling to consider cases not considered by the original designer or microprocessor IP (Intellectual Property) core provider. In systems-on-a-chip (SoC) designs using microprocessor cores, extending exception handling mechanisms may be mandatory to consider the whole circuit where the microprocessor is embedded.
Categories and Subject Descriptors B.8 [Performance and Reliability]: Reliability, Testing, and Fault-Tolerance
General Terms
In this paper, we present a technique to design exception handling mechanisms in an orthogonal way to the design. This technique uses property languages, such as the properties described in Accellera Property Specification Language (PSL) [3] or the Open Verification Library (OVL) [4]. We also present an architecture to extend exception handling mechanisms for SoC designs. This architecture considers the exceptions in the whole circuit, as opposed to the regular microprocessor exceptions. We show that with this architecture we neither need to have access the microprocessor IP source code nor to know the microprocessor internal architecture and its relation to the exception handling implementation.
Management, Design, Reliability, Verification.
Keywords Exceptions Handling, Assertions.
1. INTRODUCTION Exception handling has been employed in microprocessor designs to handle corner cases of the computation, such as floating point exception, illegal instruction execution or memory protection Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SBCCI’04, September 7–11, 2004, Pernambuco, Brazil. Copyright 2004 ACM 1-58113-947-0/04/0009...$5.00.
2. ASSERTION LIBRARIES Assertions monitors are intended to capture the design intent in a verifiable format that can be used to check its implementation. Assertions can be built from hardware description languages [4],
55
from some pragmas of a specific tool such as in [5] or from testbench languages, such as Open Vera [6]. Adding assertions to a design can increase the observability of the design by inserting logical probes that checks for specific conditions. This technique is known as White-Box Verification Approach [5] [7] [8] [9].
components: a) a sea of synthesizable assertions capturing exception and error conditions, based on some assertion language extension or library, such as the Open Verification Library (OVL) [12]; b) an assertion processor, which is a circuit designed to monitor the results of the assertions, taking appropriate action when an assertion fails, being as simple as a circuit that raises an error pin or as complex as an embedded processor that dispatches an error correction routine, resets the chip, or raises a interrupt based exception handling routine; c) and a routing mechanism that routes error and exceptions information from the assertions to the assertion processor.
Assertion libraries have been synthesized in chip designs to perform runtime debugging in [10]. By inserting assertions into the designs, White-Box Verification Technique was extended beyond the simulation/emulation phases of a design. The basic idea of this work is to chain assertions to verify properties in a similar way as the IEEE-1149 Boundary-scan standard [11], which defines test logic that can be included in an integrated circuit for implementation testing. In this paper, the Boundaryscan check approach is used to signal exceptions events, beyond signaling design errors.
Assertion Processor
Figure 1 presents a typical assertion module from modified version with scan-chain architecture. reset_n clk test_expr escen_n esclk esci ei
assert_moduleA
esco eo
Circuit under verification Chained assertions Error signals propagation links
Figure 1. OVL assertion modified with extra pins for scan-chain architecture
Figure 2. Diagram of assertion processor This assertion processor needs to perform at least three tasks: a) scan the assertion chain to detect which assertion has caused the failure or exception; b) encode the possible tasks that must be performed for each assertion in the circuit; c) perform specific tasks to overcome the error or exception condition.
The extended assertion library include the inputs esci, esclk, ei and escen_n, and the outputs eo, esco. Signal eo is the conjunction of all previous (in the chain) possible errors or exceptions and it is the result of an internal event triggered by a failed assertion. Signal escen_n disables the expression evaluation in the assertion, enabling the scan-chain to be exercised. Signals esci, esco and esclk are normal scan input, output and clock signals.
In [13], was used the assertion processor to fix design problems at runtime. In the next section, we further extend this architecture to handle exceptions of microprocessor cores.
A chip's pin interface is enlarged with signals eo, esco, escen_n and esclk. After the chip lowers the event output signal eo, an external monitor starts enquiring which assertion has triggered eo by first enabling the event scan chain (by asserting esce_n). At this time, the first assertion result will appear in the error scan output (esco). At subsequent cycles, by pulsing esclk, a new assertion result will appear at esco until all assertions have been scanned. For a design with n assertions, after n cycles, all assertion violations will appear as 0's in the output of esco. In a similar way to the IEEE-1149 standard, we can add pins ei and esci to the chip's interface to be able to cascade multiple chips in a board design, as well as in a chip design with multiple IP cores. Also, we can embed the assertion processor in a chip design. In the next section, we present the architecture of this monitor.
4. USING ASSERTION PROCESSOR TO HANDLE EXCEPTIONS IN SoC DESIGNS The assertion processor architecture described earlier can detect errors in chip designs and is able to recover from these errors gracefully depending on the implementation of the assertion processor. In this section, we use assertions to capture exception conditions and the assertion processor to solve these error conditions by signaling the processor and surrounding logic. An architecture for SoC with exception handling is depicted in Figure 3. In this figure, the original SoC is composed by a processor core and by an application specific dedicated logic. The assertion processor (AP) is responsible for screening assertions in the scan-chain and dispatching some error handling hardware in case an exception occurs. In some cases, exception handling can be implemented as hardware reset or software interrupt.
3. ASSERTION PROCESSOR An architecture for on-chip verification and exceptions signaling can be found in Figure 2. This architecture is based on three
56
As mentioned before, this approach is especially useful to handle and to extend exceptions in microprocessor IP hard cores; to cascade exception handling mechanisms at board level designs; or even to extend exception handling in new generation of microprocessors in an orthogonal way to the design.
The reader should note that the exceptions from the dedicated logic are chained into the microprocessor core, truly extending exception handling to the whole chip.
Dedicated logic
The chained hardware assertions to exception handling avoid the use of low speed tasks to handle exceptions. These low speed tasks affect the circuit final frequency if the exception treatment is integrated in ad-hoc way.
interrupt signals processor core
AP assertion chain
5. Examples
exception handling hardware
5.1 Scratchpad Selection in Microprocessor Core
Figure 3. A possible SoC architecture with an assertion processor for exception handling
We consider in this example a microprocessor based SoC design using a microprocessor IP hard-core interfacing to a memory block or chip by the pins clk, rst, enable_write, enable, addr, w_data and r_data signals. We assume that this SoC design may use from time to time a portion of the memory as a scratchpad, such as the one described in [7].
Figure 4 presents a skeleton for an assertion processor. For the sake of illustration, it contains four errors and exceptions processing tasks: halting the processor for more serious errors, resetting the entire chip, performing a software interrupt to enable a processor core to perform a specific action, or activating an exception handling circuit.
In our example, since activating the memory scratchpad may involve saving data from the internal RAM memory, components can be activated and de-activated by a mixed hardware and software solution. Inside the memory controller, an exception can be triggered to decide whether the memory block should work as a monolithic component or as a partitioned memory with a portion of the memory devoted to function as a scratchpad. This exception will re-align the buffers inside the microprocessor core.
module AssertionProcessor (...); // SCAN DETECTION always @(posedge clk) begin if (error detection)
begin
Figure 5 shows the design obtained by the inclusion of a new memory system between the processor IP hardcore and the external memory module. The new memory system consists of memory controller modification (by addition of assertions and assertion processor interface) and assertion processor and internal RAM memory incorporation.
count = count + 1; if (esci == 1) ErrorNo = count; ... end end // PRIORITY ENCODING OF ERROR CONDITION assign ErrorNo = ErrorEncoding(ErrorNo);
cpu
// ERROR CORRECTION
core
always @(posedge clk) begin if (error detected)
begin
casex (ErrorPriority)
address signal data signal
Address bus Memory Controller
In/out external data bus In/out internal data bus
4’bxxx1: // HALT INTEG. CIRC. 4’bxx1x: // HW RESET
Assertions chained
4’bx1xx: // SW INTERRUPT 4’b1xxx: // EXCEP.HAND.HARD.
Internal RAM
External RAM
endcase end
Assertion Processor
end endmodule
select signal (assertion priority)
Figure 5. Design with scratch memory based on assertions activation
Figure 4. Assertion Processor Verilog HDL Skeleton
57
Figure 6 shows the memory controller outline, where the bold expressions were added to incorporate the scratch memory system.
Table 1. Absolute values from additional assertion based modules
Parameter
module MemoryController(addr,...);
Slice Flip Flops
input [15:0] addr;
4 Input LUTs Slices IOBs
Overhead employed 24 16 14 42
//memory definitions ExternalRAM_Scratch external(...); InternalRAM_Scratch internal(...);
(1)
//assertion processor definition
(2)
assertion_processor ap(...);
(3) (4)
//external memory initial address parameter init_x_addr=8'b00000100;
(5) (6)
//assertions to activate internal
(7)
//or external memories assert_always active_internal(...,addr < init_x_addr,...);
Legend: (1) (2) (3) (4) (5) (6) (7)
assert_always active_external(...,addr >= init_x_addr,...); endmodule
Figure 6. Verilog HDL outline for memory controller Figure 7 presents the waveforms obtained by simulation to activate the scratchpad memory. In this figure, the assertion priority signal denotes the signal coming from Assertion Processor and used to activate the correct memory bank.
= simulation time (ns) = core clock = data address = core memory enable signal = external memory enable signal = internal memory enable signal = assertion priority Figure 7. Time diagram from simulation
5.2 Sensor Network Microprocessor Core In this example, we consider a SoC based on a microprocessor core to support sensor network applications. A sensor network is an interconnected wireless network in which hundreds or thousands of nodes monitor a specific condition or event, such as the temperature over a large area. Sensor networks are implemented by nodes, which are low power microprocessor cores whose functionality may change over time, depending on several factors, such as power availability or node redundancy [15].
Observing the figure 7, notices that the time is minimum, e.g., the activation occurs in the same clock cycle. Consequently, using assertions to handle this exception is totally compatible with scratch application timing as can be seen by simulation. In figure 7, is supposed an internal memory composed by 2 positions. At first core memory enable signal, the data address bus carry the value 15, enabling the external memory module (assertion priority = 2). At second core memory enable signal, the data address bus carry the value 2. In this way, the assertion processor produces value 1 as assertion priority. In this point, the internal memory module is enabled.
The microprocessor core implementing the node must basically perform cell communication routines. Depending on the current scenario, a node may function as a gateway, as a source of data, or event to shutdown itself. In other words, it may decide to reconfigure the hardware, the software or a combination of both. As a result, this behavior change in a microprocessor core for a sensor network node can be easily implemented using assertion processors.
An important aspect to be mentioned is related with silicon area and operational maximum frequency. Table 1 shows the absolute values from additional modules. In this example, the maximum operational frequency obtained was 322.165 MHz.
In this example, an energy monitor periodically checks the battery level and it decides upon several actions in accordance to the battery level. For example, a node can decrease the hardware operational frequency (Figure 8a), change the basic node functionality (Figure 8b), or even to put itself in idle or sleep
The synthesis was made using Xilinx WebPack 5.2i environment. Xilinx WebPack uses Xilinx Synthesis Technology (XST) [14]. The designs were synthetized and routed for a Virtex XCV300 FPGA using area optimization effort.
58
exception conditions in complex designs. We also presented in this paper an architecture that extends microprocessor exceptions beyond core boundaries. These two techniques can be used to deal with exceptions appearing in complex SoC designs, especially those designs where microprocessor core was surrounded by some application specific logic. The extended exception handling mechanism turned a hard IP core design into a flexible structure, incorporating a low overhead into the original core design. By using a formal method to capture the exception condition along with the extensible architecture, we were able to go beyond traditional exception handling in microprocessors, such as floating point or single cycle exceptions. We presented examples of application specific exceptions that are usually not implemented in the microprocessor core in order to maintain the generality of the core. We are currently designing some applications using this framework, and we are integrating support for a real-time operating system into it.
mode (Figure 8c). The reader should note that all these behaviors are executed while the node performs its basic function. Energy Assertion Monitor Processor
Operating System
Hardware Host Reconfigura-- Processor tion Module
Hardware interrupt - decrease core operational frequency
Soft. Interrupt - Hard. Interrupt call election call reconfiguramechanisms tion mechanisms
Soft. Interrupt call sleep/halt routines
Hard Interrupt - turn core in the sleep/halt mode
(a)
(b)
(c)
7. ACKNOWLEDGMENTS This paper is partially supported by CAPES and CNPq under grant PNM #830107/2002-9.
Exceptions - battery energy level (by assertion approach) Figure 8. Energy consumption management for sensor network node The implementation of the assertion processor can be realized by a series of assertions capturing the energy levels of the sensor network node, as seen in Figure 9, which outlines the Verilog HDL skeleton for an energy monitor. In this skeleton, the interface between the assertion processor, the host processor and the hardware reconfiguration module can be implemented in a similar way to the scratchpad example.
8. REFERENCES [1] J. L. Hennessy, D. A. Patterson. Computer Architecture – A quantitative approach. Morgan Kaufmann, 3rd edition, 2002. [2] T.M Austin. DIVA: A dynamic approach to microprocessor verification. The Journal of Instruction-Level Parallelism Volume 2, 2000. [3] www.accellera.org. [4] www.verificationlib.org [5] 0-In Design Automation, Inc. Black & White assertion-based verification flow. The Verification Monitor, may 2002. [6] Synopsys, Inc. Assertion-based verification, May 2002. [7] P.R.Panda, N. Dutt, A. Nicolau. Memory Issues in Embedded Systems-on-Chip. Kluwer Academic Publishers, 1999. [8] H. Foster, A.C. Krolnik, D.J. Lacey. Assertion based design. Kluwer Academic Publisher, 2003. [9] A. Gupta. Assertion-based verifications turns the corner. IEEE Design & Test of Computers 19, pages 131-132, 2002. [10] J. A. Nacif, F. M. De Paula, H. Foster, C. Coelho, F. C. Sica, D. C. da Silva, and A. O. Fernandes. An Assertion library for on-chip white-box verification at run-time. In Proceedings of Latin American Test WorkShop, 2003. [11] IEEE Standard 1149.1-2001, ISBN 0-7381-2944-5. [12] H. Foster, C. Coelho Jr. Assertions targeting a diverse set of tools. In 10th Annual International HDL Conference Proceedings, 2001. [13] J. A. Nacif, F. M. De Paula, H. Foster, C. Coelho, F. C. Sica, D.C.Silva, A. O. Fernandes. The chip is ready. Am I done? on-chip verification using assertion processor. In Proceedings of VLSI-SOC´03, 2003. [14] www.xilinx.com. [15] J. Hill, R. Szewczyk, A. Woo, D. Culler, S. Hollar, and K. Pister. System architecture directions for networked sensors. In Proceedings of ASPLOS, Nov. 2000.
module EnergyMonitor(...); input [2:0] current_level; . . . //assertions to call the correct exception //treatment assert_never low_clock(cur_level >= LEVEL2 && cur_level < LEVEL3); assert_never ch_function(cur_level >= LEVEL1 && cur_level < LEVEL2); assert_never sleep(cur_level >= 0 && cur_level < LEVEL1); endmodule
Figure 9 - Verilog HDL outline for energy monitor
6. Conclusions and future work In this paper, we showed that assertions that were once used to capture design errors can also be a powerful tool to specify
59
