Silicon Penguins: Using and verifying an open source processor in a 100% first time right commercial ASIC

Transcription

1 Silicon Penguins: Using and verifying an open source processor in a 100% first time right commercial ASIC Declan Staunton System IC Business Unit Silicon & Software Systems Dublin, Ireland declan.staunton@s3group.com Paul Furlong System IC Business Unit Silicon & Software Systems Dublin, Ireland paul.furlong@s3group.com Abstract Open source software, most notably in the case of the Linux operating system a, is now well established and enjoys widespread use in commercial environments. In the case of hardware however, open source IP has been slow to take off in IC development for very good reasons. Immaturity of designs, lack of support, licensing and warranty concerns would normally ensure open source IP cores are not even considered as solutions. However there are situations, and in the case of the LEON core, there are solutions that warrant consideration for certain types of application. Here we describe our experience in using the LEON processor in a commercial ASIC implemented in a 0.13 µm process and in particular the steps that were taken to verify its functionality. The benefits and drawbacks of using and verifying a LEON based design are described before concluding that LEON was an excellent solution for this design. I. INTRODUCTION This paper will describe our experience in using and verifying the LEON processor in a commercial ASIC. We were contracted for the design of this ASIC from specification through to delivery of timing closed netlist to the foundry. The specification was co-authored with the customer. RTL design and verification was performed by Silicon & Software Systems (S3) while the customer also had a small verification team that wrote C models to reflect their understanding of the specification. The processor choice was made after an analysis of a number of CPU cores by S3. There are a number of considerations to be borne in mind when selecting processors for System on Chip (SoC) developments. In perhaps the majority of cases legacy requirements will dictate the processor, or, at the very least the processor architecture to be used. For this SoC design there were neither software nor hardware legacy requirements. In fact the vast majority (approx 700Kgates) of the logic was designed from scratch. The ASIC was intended a The Linux mascot is a penguin. for use in a high volume embedded system. As can be seen from the block diagram in Fig 1 this was a typical SoC design. The principal CPU requirements were: 1) Performance: The initial performance requirements were relatively low but these grew in time. There were some hard real-time requirements and many firm (meaning the system would not fail but the user could perceive a slowdown) real-time requirements 2) Low or no royalty: As very high volumes were expected this was important in keeping the unit price low 3) Supervisor & User modes: The processor would have to support the execution of third party code with limited access to the chip hardware. Power consumption was not a significant concern and while a synthesizable core was preferable this was primarily due to the unsuitability of the hard cores that were available for the fabrication process used. A number of 16 and 32-bit commercial cores were considered before concluding that the LEON processor offered the best overall solution. Figure 1: Block diagram of the LEON powered SoC

2 II. THE LEON PROCESSOR LEON is a VHDL implementation of the open standard (IEEE1754) SPARC V8 architecture [1]. LEON is a highly configurable, synthesizable, 32-bit core with pre-selectable cache sizes (both I & D), optional floating point unit and hardware acceleration for multiply and divide instructions, debug monitor, AMBA AHB [2] interface and support for a co-processor. Most of the features of LEON can be configured via a simple GUI which produces a VHDL file of constants that is then referenced by the other source files. A screenshot of this GUI showing the configuration options for the Integer Unit is shown in Fig 2. The LEON3 processor is available under the GNU General Public License (GPL) [3] and commercial license arrangements. A GNU Lesser General Public License (LGPL) [4] version (LEON2) is also available. In fact for most of the design phase the LEON2 core was used but a late change to the LEON3 core was made for licensing reasons. Despite occurring late in the design phase, the switchover from LEON2 to LEON3 was not difficult. Sun Microsystems have recently announced plans to open source its 64-bit multi-threaded UltraSPARC T1 processor including the Verilog source code [10]. Such a move is likely to fuel interest and activity in both open source hardware IP and the SPARC architecture. Figure 2: LEON configuration GUI A full software development environment based on the GNU C/C++ compiler is available for LEON. An instruction set simulator (TSIM) is also available although, as this could not co-simulate with RTL, this was only rarely used by the IC development team. The LEON cores and associated IP are available from and supported by Gaisler Research [5]. III. USING LEON The first step in customizing LEON for our application was the identification of the component entities we wished to retain and excising these from the LEON deliverable (which includes bridges, interfaces and peripherals to make it a SoC in its own right). The components of interest were at the heart of the processor the Integer Unit (IU), Cache controllers and AHB interface (there were some 22 VHDL files required to describe these completely). A testbench was created to verify the operation of these components in isolation from the rest of the LEON deliverable. The next step was the creation of a bridge between the LEON AHB interface and the proprietary bus interfaces to the on-chip DRAM and peripherals. While AMBA buses were not used elsewhere on the chip their use was advantageous due to the familiarity of the design team with the standard. With the bridge in place the LEON CPU core could then be integrated with the remainder of the ASIC (or more specifically the portions of it that existed at that time). It was necessary to select and integrate the correct memories and register files for the cache data and tag rams and the IU register file. At a later date the appropriate hardware multiplier and divider circuits were chosen. LEON does support memories and register arrays from a number of foundries (and also FPGA targets) but the foundry for this ASIC was not supported so this step took some work. Simple wrappers were also required for each register array / memory. Familiarization with the LEON design was quite straightforward but could have been accelerated by more complete design documentation and better coding practices. The code itself was written in a consistent style but the signal and variable naming were often not very descriptive and comments were scant. Moreover the extensive use of VHDL records caused problems with some tools and in some cases a record had to be broken out into its constituent signals. IV. MODIFICATIONS In order to fulfill the application requirements some modifications and enhancements were required to the LEON CPU components. All of the LEON related design work was confined to the CPU subsystem level of hierarchy depicted in Fig 3 below and this was performed in parallel with the rest of the ASIC design. Firstly, as the LEON cache controllers refilled the 256-bit wide cache lines by reading 32 bits at a time and the on-chip DRAM produced 256-bit lines for every read, it was highly inefficient to read the same DRAM line 8 times in order to refill a line in the LEON caches. By making a few changes to both the instruction and data cache controllers and cache memories it

3 was possible to refill the entire cache line with the 256 bits yielded by the DRAM read thus reducing the number of DRAM reads required from 8 to 1.! " # $ % & & ' " # $ % & % ( & Figure 3: CPU subsystem block diagram The most significant enhancement was the addition of a Memory Management Unit (MMU). Code is executed on the processor in either supervisor or user mode and the application required strict enforcement of security rules to ensure user mode code was restricted in its operation. The primary function of the MMU was the protection of supervisor mode code and data from user mode accesses. The MMU was simpler than a conventional MMU in that it did not feature a Translation Lookaside Buffer (TLB), although it did implement the memory map for the IC. It is not compatible with the SPARC Reference MMU specification [6]. The MMU allowed the DRAM address space to be split into up to 8 regions with each region having programmable access permissions and start / stop boundaries. The programmable registers controlling the MMU could of course only be accessed when executing code in supervisor mode. Access control for the on-chip peripherals was distributed i.e. the access control signals were propagated to each peripheral and each peripheral could accept or reject an access depending on the permissions of the access and the peripherals settings (this was often determined on a register by register basis). In addition to controlling access to the DRAM and peripherals the MMU also included the AHB to proprietary bus bridges for the DRAM data bus and the CPU peripheral bus, a write buffer and a bus timeout function to avoid possible bus hangs. The purpose of the write buffer was to improve write performance to minimize the impact of register window over / underflows. Register windows are a feature of SPARC processors and can allow fast context switching between tasks. However when a register window over / underflow occurs the worst case context switch time may become prohibitive for real-time applications. A small posted write buffer was added which combined a number of CPU writes into a single write to the wide DRAM. This was found to improve write performance significantly (particularly for the sequential writes that are characteristic of window over / underflow handling) at the cost of complicating the design to ensure data coherency was upheld in all situations. Further modifications were made to the data cache to enforce user / supervisor data security. Extra tag bits and logic were added to the data cache to ensure user mode code could not retrieve supervisor data from the data cache (this was possible with the basic LEON design) and the MMU enforced the security of supervisor mode code and data outside of the caches. After a reset, the processor starts executing code from address # In order to assist with software error handling (e.g. null pointer de-referencing) all accesses to the bottom four word locations (i.e. # to # C) were trapped by the MMU unless they were made by the reset handler. In all there were six different conditions introduced that could be trapped by the MMU to protect the integrity of the system. These customizations were made while preserving all of the existing LEON functionality i.e. no previous LEON functionality was compromised by the enhancements. While this required a little more design and verification effort it offered increased confidence in the modified design. V. ASIC VERIFICATION STRATEGY Figure 4: ASIC Verification Overview The verification strategy for this ASIC was a bottom-up approach. This is illustrated in Figure 4. At all levels the

4 ASIC verification team, in conjunction with the design team, specified a set of functional verification requirements which were required to be tested. The steps in this multilevel approach are outlined below: 1. The blocks in Figure 1 e.g. TIMER, GPIO are exhaustively verified using HDL testbenches at the block level. The requirement here is 100% code coverage and 100% functional coverage of the verification requirements. Bus functional models (BFMs) replace the surrounding blocks e.g. the CPU is replaced by a CPU BFM and CPU read and write tasks are used to verify the functionality of the CPU interfaces of each of the blocks. 2. A small customer team wrote C++ models and testcases for each of the blocks. I/O vectors were captured from the C++ testcases and used to exercise the RTL implementation of each block principally as an independent check that the design specification had been interpreted as intended. 3. The various subsystems of the ASIC, e.g. LEON and all its peripherals, are integrated and the connectivity verified. Extensive use-case testing is used to prove the interaction of the blocks within the subsystems. 4. Finally, the subsystems are integrated, any connectivity remaining to be verified is exercised, and the interaction of the sub-systems is verified to prove the system level functionality. The complete verification approach comprised for block level testing: HDL directed test cases, Randomized test cases, C++ modeling test cases. For subsystem and top-level testing: Processor code test cases. For emulation and early software development: FPGA test cases. The verification approaches are complementary and overlapping. The block-level verification techniques provide very deep functional coverage. Higher level verification added breadth. VI. LEON VERIFICATION STRATEGY We followed the ASIC bottom-up verification approach in the integration and verification of LEON. Since the complexity increases as we go up the levels the amount of functional coverage obtainable is lower. Hence the importance of testing at the module or sub-block level. The verification effort for LEON can be divided into a number of sections: 1. Verification of LEON CPU components: a. Verification of LEON Integer Unit. b. Verification of the CPU MMU. 2. Integration and verification of the complete LEON CPU module of Figure 3 including testing the modifications to the cache controllers. 3. CPU subsystem integration and verification of the LEON CPU block and its peripherals. 4. Top-level integration and verification of the LEON CPU subsystem within the ASIC. 5. FPGA Emulation. All verification of LEON above sub-block level involved cross-compiled C code running on LEON. An Instruction Set Simulator (ISS) which can co-simulate with RTL is not available for LEON so the full VHDL RTL source code was used instead. Running such a large number of use-cases in software on the actual CPU RTL implementation provided a very high level of confidence in the ASIC before tapeout. Additionally, FPGA emulation allowed driver software and application software to be developed and tested in advance of silicon samples. VII. VERIFICATION OF LEON COMPONENTS A. Verification of the LEON Integer Unit One would normally expect an IP core to be delivered with an exhaustive set of testcases designed to provide high functional coverage. The ASIC verification effort would normally then concentrate on verifying any modifications and on integrating the IP core into the ASIC. Unfortunately the LEON processor is delivered with a very limited set of testcases which more checked for correct configuration rather than exhaustively exercising the processor. With this in mind, and since LEON is a relatively new processor, we felt that it was important to do some independent verification of the core LEON Integer Unit (IU). Two approaches were adopted: 1. Independent certification of the IU. 2. Instruction set testing. SPARC International maintains a set of golden SPARC compliance tests which are used to certify that a CPU implementation is SPARC compliant. We therefore arranged for LEON to be certified as SPARC compliant. No issues were found during the compliance testing. The instruction set testing activity was intended as a basic sanity check of each instruction against its specified behavior in the SPARC standard. Errors were found with the implementations of two instructions with this approach. An issue with the swapa instruction (an instruction not normally generated by the compiler) was found and corrected. The swapa instruction is intended to cause a software trap if the effective address is not word-aligned. This problem was not captured by the SPARC vectors as they do not test every possible trap mechanism for every instruction. A second minor issue was found with the mulssc

5 multiply instruction (also not normally generated by the compiler) which was also corrected. B. Verification of the MMU Following the same approach adopted for the rest of the ASIC, the C++ modeling team wrote a pseudo cycleaccurate C++ model and testcases for the MMU with its AHB interface to LEON. Vectors captured from the C++ testcases were used to verify the RTL so as to independently verify that the MMU functionality was interpreted and implemented correctly from the specification. A set of functional verification requirements was written for these testcases. The MMU was also tested as part of the CPU module level tests. VIII. INTEGRATION AND VERIFICATION OF THE COMPLETE CPU MODULE RAM location monitored by the testbench which causes an interrupt to be asserted by the testbench). All testcases were self-checking. A set of functional verification requirements written by the ASIC verification team, in conjunction with the design team, specified what was required to be tested. The combined approach of C code testcases and VHDL testbench with models of external modules provided the controllability and observability needed to achieve 100% functional coverage of the verification requirements and 100% code coverage external to the LEON IP. LEON modules that were customized were subjected to full functional verification (i.e. not just the changes were tested). As the original LEON tests that formed part of the release were not considered rigorous enough for production silicon extra effort was expended to ensure satisfactory verification coverage, particularly of the cache controllers. An issue with diagnostic cache writes to the D cache was found and corrected during CPU module verification. Figure 5: Testbench used to verify CPU module The majority of CPU testing (and in particular the customizations of the LEON components) was done at the complete CPU module level. The first critical test was to boot the CPU from ROM and then transfer instruction execution to DRAM. The verification environment, shown in Figure 5, consisted of all the CPU module components shown in Fig 3, ROM, RAM, DRAM arbiter and a behavioral model for the DRAM. Tests were developed using C and assembly language, compiled using the GNU toolkit available with LEON and then post processed into appropriately formatted ROM and DRAM memory images by perl scripts. The testbench included models of the CPU subsystem peripherals. All of these tests take the form of short C and/or assembly programs that are targeted at the functionality under test. Where a stimulus external to the CPU block (and memory subsystem) is needed it is either supplied by the testbench (e.g. the reset signal) or induced by the testbench in conjunction with the testcode (e.g. code writing to a IX. VERIFICATION OF THE CPU SUBSYSTEM The next step in the verification process is the integration and verification of the complete CPU subsystem i.e. the CPU module with the CPU peripherals. Figure 6 summarizes the verification performed to prove the integration of the CPU subsystem. Most of this verification is concerned with interconnect verification and hardwaresoftware interactions across the CPU subsystem. It is assumed that the individual blocks have already been exhaustively tested at the unit level. Because the CPU peripherals had been verified using a bus functional model of the CPU peripheral bus prior to integration they all worked first time with the real CPU. Figure 6 CPU integration testcases The initial intention of these top-level testcases is 1) To prove the correctness of the top-level CPU peripheral bus system. Randomized back-to-back alternating read and write accesses to the same and different peripherals were used to stress test the CPU sub-system bus. 2) To prove the memory map is correct. 3) To confirm the address map cacheability (only the DRAM contents are cacheable).

6 Once the basic top-level testing was complete the more complex hardware-software interaction verification commenced. Similar to CPU module testing a functional coverage approach was adopted with testing complete when 100% functional coverage on the identified interactions has been achieved. Direct testing of all the hardware-software interactions means confidence in system use-cases which are composed of these interactions can be very high. The top-level CPU testcases required the reuse of a number of hardware/software communication mechanisms developed at CPU sub-system level. These included a communications area between the testbench and software running on LEON. CPU reads and writes to a defined part of the address map are monitored by the testbench and allow the CPU to write data to the testbench and to read back data which the testbench forces onto the processor read bus. The mechanism allows the CPU to wait on testbench events and vice-versa allowing synchronization between events in C- code and testbench events. The CPU-testbench communication mechanism is shown in Figure 7. Figure 7: CPU software/testbench interaction Some of the hardware-software interactions tested at the CPU subsystem level are described in the next sections. A. Interrupt testing The complete hardware/software interrupt handling loop between peripherals, interrupt controller and LEON CPU was exercised. Each possible interrupt source was used to generate an interrupt which the interrupt controller maps to 1 of 16 levels which is flagged to the CPU. The CPU acknowledges the interrupt to the interrupt controller and disables any further interrupts. The interrupt controller captures the source of the interrupt in a status register. When the software interrupt handler executes it will normally read the interrupt controller status register to find out the source of the interrupt before re-enabling interrupts. Back-to-back combinations of the same and different interrupts sources were handled with each mapped to the same and different interrupt levels so as to exercise interrupt queuing and preemption. Block-level verification of the interrupt controller covered all combinations of interrupt sources and priorities. B. Endianness testing One issue that did require particular attention during integration was endianness. SPARC, and therefore LEON, is a big endian architecture but the rest of the system was little endian. Thus, when data was shared between the CPU and other blocks (some of which had DMAs with byte-write capability) careful thought was needed to ensure that bytes were not swapped around incorrectly. These scenarios were subjected to significant directed testing e.g. endianness consistency between the CPU and the USB device block was tested by performing a USB OUT transfer from an external USB host model to the USB device on the ASIC which then streamed the received data into DRAM. The testcase used the CPU to read this data from DRAM which was compared with the data sent by the host model. This was repeated for CPU byte, half-word and word accesses to confirm that the endianness interpretation of the data is consistent with the CPU programming model. Where endianness coherency could not be handled by hardware the need for byte swapping in software was clearly flagged to the software developers. C. Supervisor/user access integrity testing A good example of hardware-software interaction tested at this level is supervisor/user access integrity e.g. whether user mode read access to a particular peripheral is allowed. The access permissions are set in the individual peripherals. The CPU peripheral bus includes a bus error signal from each of the peripherals back to the MMU. A forbidden access to a peripheral will cause the peripheral to assert its bus error signal to the MMU which will flag an exception to the CPU and cause a software trap handler to execute. The source of the exception is recorded by the MMU. Special software functions e.g. the user_read function are used for this testing which specify the expected exception source. int user_read (int *raddr, int *read_data, int expd_excptnsrc_val) If the trap handler executes then the default trap handler will invert the memory location containing the expected trap type. When control returns to the main program the expected trap type is checked to see whether a trap occurred, if it is the correct type, and whether the MMU exception source register records the expected exception source.

7 X. CPU SUBSYSTEM INTEGRATION WITHIN THE ASIC Once the various subsystems on the ASIC had been verified the next step was to verify the interaction of those subsystems at ASIC top-level. The bottom-up verification approach adopted here means the CPU subsystem has already been tested fully and only specific interactions with the other subsystems on the ASIC need to be tested. An example would be ASIC power management e.g. waking up the CPU from power down mode due to activity detected on the external USB interface. The remainder of the testing comprises some basic system use-cases including verifying the system boot modes. Many system use-cases were exercised on the FPGA. XI. FPGA EMULATION A significant software development was required to generate the ROM image and further post-boot downloadable code. While there is an instruction level simulator (TSIM) available for the LEON processor it could not model the modifications made to the LEON modules. FPGA emulation was clearly the best solution especially as it also provided an additional layer of functional verification. An off the shelf third party board based on a Xilinx Virtex-II 6000 FGPA was chosen for its large FPGA and short lead time. Retargeting the LEON modules to the FPGA was straightforward as Xilinx FPGAs were already supported as a target technology in the LEON code. Two additional LEON modules were implemented on the FPGA which would not be present on the ASIC the Debug Support Unit (DSU) and a UART. These were required to facilitate software debug and communication with a host PC. S3 s GNAT (General-purpose Native jtag Tester) [7][8] module was used as part of the FPGA development environment. This module allows access to the FPGA logic (including ROM / RAM and I/Os) via its JTAG port. When used in conjunction with VNC [9] full remote control, even from other sites, of the FPGA board was possible. This allowed the ROM contents to be updated, the processor reset and onboard LEDs and internal registers to be monitored all without having to go to the lab. XII. VERIFICATION RESULTS AND CONCLUSIONS The emphasis on bottom-up testing with 100% code and functional coverage meant that only a handful of bugs were found during subsystem and top-level verification. Metrics such as Bug tracking Code coverage Functional coverage HDL checkin rate were used throughout the project. Code coverage and functional requirements coverage were used to track block level verification closure with 100% required for both metrics. Subsystem and top-level testing progress is tracked by functional coverage. The bug rate at subsystem and top-level was so low that the main metric used to track verification progress to tapeout was the number of testcases remaining and the HDL check-in rate (the RTL was changing primarily due to integration of the final version of the USB PHY core which required changes to the reset and clocking circuits). Directed HDL testing and C modeling is most useful at block-level as it allows high levels of controllability resulting in very high functional coverage. In the case of LEON the SPARC certification and instruction set testing performed on the integer unit were essential in obtaining high levels of functional confidence. Almost all subsystem and top-level testcases are under CPU software control which serves to increase confidence in both the processor and the overall ASIC. FPGA test further increases confidence. The main strength of this verification approach is that exhaustive testing at block-level means that top-level integration tests can be targeted at interconnect testing and on exercising the complex component hardware-software interactions which make up real use-case scenarios. The success of the verification approach is best demonstrated by the fact that the silicon worked first time upon return from the fab without a single bug. Within a few hours the device was booting from on-chip ROM following power-on-reset and downloading further program code and data over its USB device port. Only one very minor feature was found in the ROM code which could easily be resolved in a real application. Extended field testing over a period of several months uncovered no defects. XIII. BENEFITS Outside of the obvious cost savings one of the primary benefits of using LEON was the ease with which its capabilities could be augmented as the requirements grew. This was a significant benefit because, as with all developments, requirements did change. Initially a cacheless integer unit was to be sufficient but this evolved into a final configuration with 1 KB I & D caches with the enhancements referred to earlier and hardware support for the SPARC multiply, multiply and accumulate, and divide instructions. As the entire source code was available for the extra LEON features from the very beginning the new features could be turned on easily and quickly without the need for further dialog (or negotiation) with the supplier. Indeed once the simulation and synthesis environments had been set-up simple what-if analyses could be easily achieved by choosing different configuration options with the GUI referred to earlier and executing our makefile based flow. Access to the source code and the freedom to modify it proved very useful not only in performing the

8 customizations described but also during debug as it was possible to tease out detailed functionality and to obtain a more complete understanding of certain behaviors. Without this freedom to modify the core the same degree of performance improvement would not have been possible. Furthermore if similar functionality was designed into the non-cpu logic its complexity, and the probability of a error, would have been increased. LEON has been designed with direct support for a number of fabrication technologies (including FPGA) and porting it to a new technology was not difficult. The code synthesized cleanly and posed no problems in physical design. The commercial support provided by Gaisler Research [5] for the duration of the development was excellent. We enjoyed a direct interface to the engineers who designed the core and they were always prompt and accurate in their responses. The use of an independent verification team significantly improved the quality of the design by eliminating misinterpretations of the specification and ensuring that each block was verified by more than one person. Since LEON is a relatively new processor, the fact that all verification was performed on the actual RTL implementation provided a strong level of confidence which was borne out by the first-time right results obtained from the manufactured silicon. Extensive testing of all the hardware-software interactions between LEON and the rest of the ASIC, in addition to system use-cases tested both on the ASIC and on the FPGA, added to this pre-tapeout confidence. XIV. DRAWBACKS The coding style used for LEON required some familiarization and the lack of comments and detailed design documentation hampered progress from time to time. The widespread use of records also caused problems for some CAD tools (although these may have been addressed by the tool vendors by now). There were also a number of new releases of the LEON database which fortunately had little effect on our development this was because the modules we were using in our design were only occasionally modified in these new releases. Other embedded applications, especially those with significant real-time requirements, may not find LEON such a good solution as the use of register windows makes context switching times difficult to predict and poor in the worst case. Furthermore the register file for the IU is large a 144 x 32, 3-port register array was required in our implementation which used the standard configuration of eight register windows. While the software support for LEON is increasing all the time (a Linux port is now available) careful consideration should be given to both legacy (as porting may be non-trivial) and new software requirements. This was not a problem in our application. While the LEON code itself has been used and refined many times the testcases that formed part of the releases used in our development were not comprehensive enough for an ASIC tapeout. Supplementary testing was required in our case. Moreover the additional steps to prove the CPU (instruction set verification and SPARC V8 compliance testing) would not have been required with a more mainstream, multiple silicon proven, CPU core. The C++ based approach used by the customer verification team resulted in large vector files which took a long time to debug and run. In fact a significant part of the overall verification effort was expended on converging the vectors with the RTL designs without actually uncovering many bugs. Future designs will leverage the advantages of having a reference model whilst reducing the debug time through co-simulation of C++ with RTL rather than using the cumbersome vector-based approach. XV. CONCLUSION Processor selection is one of the most important decisions to be made in developing an SoC. When faced with a clean-sheet design the LEON core is certainly worthy of serious consideration. While it could be used without any modifications the possibilities for customization are powerful. Access to the source code, and the ability to modify it, allowed us to customize the core to our requirements rather than complicate the logic external to the core. The importance of open-source processor IP will certainly increase following SUN s announcement of its intention [10] to open source the UltraSPARC T1 processor. The bottom-up verification approach together with independent verification teams yielded a better quality, well verified design. The additional measures taken for the CPU, namely instruction set testing and SPARC certification, gave increased confidence in the CPU. The project was vindicated by fully functional silicon with zero defects found even after many months of extensive field testing. XVI. REFERENCES [1] [2] [3] [4] [5] [6] SPARC V8 Architecture Manual, Appendix H [7] [8] g53.htm [9] [10]