DOCSLIB.ORG

Sparcle: an Evolutionary Processor Design for Large-Scale Multiprocessors

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Sparcle: an Evolutionary Processor Design for Large-Scale Multiprocessors Sparcle: An Evolutionary Processor Design for Large-scale Multiprocessors Working jointly at MIT, IS1 Logic, and Sun Microsystems, designers created the Sparcle pro- cessing chip by evolving an existing RISC architecture toward a processor suited for large- scale multiprocessors. This chip supports three multiprocessor mechanisms: fast context switching, fast, user-level message handling, and fme-grain synchronization. The Sparcle ef- fort demonstrates that RISC architectures coupled with a communications and memory man- agement unit do not require major architectud changes to support multiprocessing efficiently. Anant Agarwal he Sparcle chip clocks at no more than faults and message arrivals. Current micro- 40 MHz, has no more than 200,000 processor designs do not support a clean com- John Kubiatowicz transistors,does not use the latest tech- munications interface between the processor nologies, and dissipates a paltry 2 and the communications network. Further- David Kranz watts. It has no on-chip cache, no Fancy pads, more, traps and other asynchronous event- and only 207 pins. It does not even support mul- handlers are inefficient on many current Beng-Hong lim tiple-instruction issue. Then why do we think this microprocessors,often requiring tens of cycles chip is interesting? to reach the appropriate trap service routine. Donald Yeung Sparcle is a processor chip designed to sup- port large-scale multiprocessing. We designed its The impetus for the Sparcle chip project was Massachusetts institute of mechanisms and interfaces to provide fast mes- our belief that we could implement a processor Technology sage handling, latency tolerance, and fine-grain that provides interfaces for the above mechanisms synchronization. Specifically, Sparcle implements by making small modifications to an existing mi- Godfrey D'Souza croprocessor. Indeed, we derived Sparcle from Mechanism to tolerate memo y and commu- Sparc' (scalable programmable architecture from LSI Logic nication latencies, as well as spcbmniza- Sun Microsystems), and we integrated it into Ale- tion latencies. Long latencies are inevitable wife,2 a large-scale multiprocessor system being Mike Parkin in large-scale multiprocessors, but current developed at MIT. microprocessor designs are ill-suited to Sparcle tolerates long communication and syn- Sun Microsystems handle such latencies. chronization latencies by rapidly switching to Mechanisms to support fine-grain synchro- other threads of computation. The current imple- nization. Modem microprocessors pay scant mentation of Sparcle can switch to another thread attention to this aspect of multiprocessing, of computation in 14 cycles. Slightly more ag- usually providing just a test-and-set instnic- gressive modifications could reduce this number tion, and in some cases, not even that. to four cycles. Sparcle switches to another thread Mechanisms to initiate communication ac- when a cache miss that requires service over the tions to remoteprocesson- acmss the commu- communications network occurs, or when a syn- nications network, and to respond rapidly to chronization fault occurs. Such a processor re- asyncbmnous euentssuch assynchronization quires a pipelined memory and communications 4% /€€€Micro 0272-1732/93/0600-0048$03.000 1993 IEEE Authorized licensed use limited to: Univ of Calif Berkeley. Downloaded on February 17, 2009 at 09:28 from IEEE Xplore. Restrictions apply. system. In our system. a separate coiiimLinir.ationsancl nieiiioq management chip (CMML;) interfaces to Slxircle to provicle the desired pipelined system intertiice. Our system also pro- vides a software prefetch instruction. For a description of the modifications to a modern RISC microprocessor needed to achieve fast context switching. see our cliscussion under x- chitecture and implementation of Sparcle later in the article. Sparcle supports fine-grain data-level synchronization through the use of fiill/empty bits, ;IS in the HEI-’ computer,’ With fiilVempty bits, a lock and access oftlie data word proteaed by the lock can tx prolxd in one operation. If the synchroniz- tion attempt fails. the synchoni7;ltion trap invokes a fault han- dler. In our system, the external communications chip detects synchronization faults and alerts Sparcle I>y raising a trap line. The system then handles the fault in software trap code. Finally, Sparcle supports a highly streamlined network in- Figure 1. An Alewife node. terface with the ability to launch and receive interconnection network messages. While this design implements the con- liance performance iq increasing parallelism and reduc- niunications interface with the interconnection network in a ing coininmication overhead. This enhancement relieves separate chip, the CMMU, future implementations can inte- the programmer of undue effort in partitioning data and grate this functionality into the processor chip. Sparcle sup- controlling flo\\, into coarser chunks to increase ports rapid response to asynchronous events by streamlining performance. Sparc’strap interface and by supporting rapid dispatch to the Memory latency tolerance. Context switching and data appropriate trap handler. To achieve this, Sparcle provides prefetching can reduce communication overhead intro- two special trap lines for the most common types of events- duced by nethvork delays. For shared-memory programs, cache misses to remote nodes and synchronization faults. the smirch must be very fast and occur automatically Sparcle uses a third trap line for all other types of events. when a remote cache miss occurs. Also, this chip has an increased number of instructions in Efficient message interface. The ability to send and each trap dispatch entry so that vital trap codes can be put in receive messages is needed to support message-passing line at the dispatch points. programs. Such interfacing can also improve the perfor- Sparcle’s design process was unusual in that it did not inance of shared-memory programs in some common involve developing a completely new architecture. Rather, situations. we implemented Sparcle with the help of LSI Logic and Sun Microsystems by slightly modifying the existing Sparc Before we can examine the implementation of these fea- architecture. At MIT, we received working Sparcle chips from tures in Sparcle, we need to consider each of these areas in LSI Logic on March 11, 1992. These chips have already un- turn, and discuss why they are useful for large-scale dergone complete functional testing. We are currently con- multiprocessing. tinuing to implement the Alewife multiprocessor so that we Fine-grain computation. As multiprocessors become can thoroughly evaluate our ideas and subject the Sparcle larger, the grain size of parallel computations decreases to chips to full-speed testing. Figure 1 shows an Alewife node satisfy higher parallelism requirements. Computational grain with the Sparcle chip. size refers to the amount of computation between synchroni- zation operations. Given a fixed problem size, the overhead Mechanisms for multiprocessors of parallel and synchronization operations limits the ability By supporting the widely used shared-memory and mes- to use a larger number of processors to speed up a program. sage-passing programming models, Sparcle eases the Systems supporting fine-grain parallelism and synchroniza- programmer’s job and enhances parallel program perfor- tion attempt to minimize this overhead so that parallel pro- mance. We have implemented programming constructs in grams can achieve better performance. parallel versions of Lisp and C that use these features. Sparcle’s The challenge of supporting fine-grain computation is in features fall into three areas, the first two of which support implementing efficient parallelism and synchronization con- the shared-memory model: structs without incurring extensive hardware cost, and with- out reducing coarse-grain performance. By taking an Fine-grain computation. Efficient support of fine-grain evolutionary approach in designing Sparcle, we have at- expression of parallelism and synchronization can en- tempted to satisfy these requirements. June 1993 49 Authorized licensed use limited to: Univ of Calif Berkeley. Downloaded on February 17, 2009 at 09:28 from IEEE Xplore. Restrictions apply. Larue-scale multiprocessors State Value ment. A synchronizing write stores a value to an empty ele- ment and sets it to f~ill,releasing any waiters. An L-structure 11 I 234982 I thus allows mutually exclusive ;~ccessto each of its elements 11 234233 ]Read n :incl allows multiple nonlocking rcaders. 1 111164 Sparcle supports J- and L-structures, as well as other types 1 111134 Consumer of fine-grain data-level synchronization, with per-word, full/ 1 290267 empt) hits in memory.' Sparcle provides new load/store in- 290012 structions that interact with the full/empty bits. The design 77Read361992 @ also includes an extra synchronous trap line to deliver the fdl/empty trap. This extra line allows Sparcle to immediately Producer (Blocked) identify the trap. - Consumer Coiitrol-letel parallelism. Control-level parallelism niay be expressed by wrappingfuturearound an expression or state- - ment X. Thefuture keyword declares that Xand the continu- ation of the future expression niay be evaluated concurrently. Figure 2. J-structures. Fine-grain support allows the amount of computation needed for evaluating X to be small without severely affecting performance. We can express fine-grain parallelism and synchronization If the compiler or runtime system chooses to create a new
Load more

Recommended publications
  • Efficient Checker Processor Design
    Efficient Checker Processor Design Saugata Chatterjee, Chris Weaver, and Todd Austin Electrical Engineering and Computer Science Department University of Michigan {saugatac,chriswea,austin}@eecs.umich.edu Abstract system works to increase test space coverage by proving a design is correct, either through model equivalence or assertion. The approach is significantly more efficient The design and implementation of a modern micro- than simulation-based testing as a single proof can ver- processor creates many reliability challenges. Design- ify correctness over large portions of a design’s state ers must verify the correctness of large complex systems space. However, complex modern pipelines with impre- and construct implementations that work reliably in var- cise state management, out-of-order execution, and ied (and occasionally adverse) operating conditions. In aggressive speculation are too stateful or incomprehen- our previous work, we proposed a solution to these sible to permit complete formal verification. problems by adding a simple, easily verifiable checker To further complicate verification, new reliability processor at pipeline retirement. Performance analyses challenges are materializing in deep submicron fabrica- of our initial design were promising, overall slowdowns tion technologies (i.e. process technologies with mini- due to checker processor hazards were less than 3%. mum feature sizes below 0.25um). Finer feature sizes However, slowdowns for some outlier programs were are generally characterized by increased complexity, larger. more exposure to noise-related faults, and interference In this paper, we examine closely the operation of the from single event radiation (SER). It appears the current checker processor. We identify the specific reasons why advances in verification (e.g., formal verification, the initial design works well for some programs, but model-based test generation) are not keeping pace with slows others.
    [Show full text]
  • Hardware Realization of an FPGA Processor – Operating System Call Offload and Experiences
    Downloaded from orbit.dtu.dk on: Oct 02, 2021 Hardware Realization of an FPGA Processor – Operating System Call Offload and Experiences Hindborg, Andreas Erik; Schleuniger, Pascal; Jensen, Nicklas Bo; Karlsson, Sven Published in: Proceedings of the 2014 Conference on Design and Architectures for Signal and Image Processing (DASIP) Publication date: 2014 Link back to DTU Orbit Citation (APA): Hindborg, A. E., Schleuniger, P., Jensen, N. B., & Karlsson, S. (2014). Hardware Realization of an FPGA Processor – Operating System Call Offload and Experiences. In A. Morawiec, & J. Hinderscheit (Eds.), Proceedings of the 2014 Conference on Design and Architectures for Signal and Image Processing (DASIP) IEEE. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. Users may download and print one copy of any publication from the public portal for the purpose of private study or research. You may not further distribute the material or use it for any profit-making activity or commercial gain You may freely distribute the URL identifying the publication in the public portal If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. Hardware Realization of an FPGA Processor – Operating System Call Offload and Experiences Andreas Erik Hindborg, Pascal Schleuniger Nicklas Bo Jensen, Sven Karlsson DTU Compute – Technical University of Denmark fahin,pass,nboa,[email protected] Abstract—Field-programmable gate arrays, FPGAs, are at- speedup of up to 64% over a Xilinx MicroBlaze based baseline tractive implementation platforms for low-volume signal and system.
    [Show full text]
  • Three-Dimensional Integrated Circuit Design: EDA, Design And
    Integrated Circuits and Systems Series Editor Anantha Chandrakasan, Massachusetts Institute of Technology Cambridge, Massachusetts For other titles published in this series, go to http://www.springer.com/series/7236 Yuan Xie · Jason Cong · Sachin Sapatnekar Editors Three-Dimensional Integrated Circuit Design EDA, Design and Microarchitectures 123 Editors Yuan Xie Jason Cong Department of Computer Science and Department of Computer Science Engineering University of California, Los Angeles Pennsylvania State University [email protected] [email protected] Sachin Sapatnekar Department of Electrical and Computer Engineering University of Minnesota [email protected] ISBN 978-1-4419-0783-7 e-ISBN 978-1-4419-0784-4 DOI 10.1007/978-1-4419-0784-4 Springer New York Dordrecht Heidelberg London Library of Congress Control Number: 2009939282 © Springer Science+Business Media, LLC 2010 All rights reserved. This work may not be translated or copied in whole or in part without the written permission of the publisher (Springer Science+Business Media, LLC, 233 Spring Street, New York, NY 10013, USA), except for brief excerpts in connection with reviews or scholarly analysis. Use in connection with any form of information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed is forbidden. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. Printed on acid-free paper Springer is part of Springer Science+Business Media (www.springer.com) Foreword We live in a time of great change.
    [Show full text]
  • Understanding Performance Numbers in Integrated Circuit Design Oprecomp Summer School 2019, Perugia Italy 5 September 2019
    Understanding performance numbers in Integrated Circuit Design Oprecomp summer school 2019, Perugia Italy 5 September 2019 Frank K. G¨urkaynak [email protected] Integrated Systems Laboratory Introduction Cost Design Flow Area Speed Area/Speed Trade-offs Power Conclusions 2/74 Who Am I? Born in Istanbul, Turkey Studied and worked at: Istanbul Technical University, Istanbul, Turkey EPFL, Lausanne, Switzerland Worcester Polytechnic Institute, Worcester MA, USA Since 2008: Integrated Systems Laboratory, ETH Zurich Director, Microelectronics Design Center Senior Scientist, group of Prof. Luca Benini Interests: Digital Integrated Circuits Cryptographic Hardware Design Design Flows for Digital Design Processor Design Open Source Hardware Integrated Systems Laboratory Introduction Cost Design Flow Area Speed Area/Speed Trade-offs Power Conclusions 3/74 What Will We Discuss Today? Introduction Cost Structure of Integrated Circuits (ICs) Measuring performance of ICs Why is it difficult? EDA tools should give us a number Area How do people report area? Is that fair? Speed How fast does my circuit actually work? Power These days much more important, but also much harder to get right Integrated Systems Laboratory The performance establishes the solution space Finally the cost sets a limit to what is possible Introduction Cost Design Flow Area Speed Area/Speed Trade-offs Power Conclusions 4/74 System Design Requirements System Requirements Functionality Functionality determines what the system will do Integrated Systems Laboratory Finally the cost sets a limit
    [Show full text]
  • Bringing Virtualization to the X86 Architecture with the Original Vmware Workstation
    12 Bringing Virtualization to the x86 Architecture with the Original VMware Workstation EDOUARD BUGNION, Stanford University SCOTT DEVINE, VMware Inc. MENDEL ROSENBLUM, Stanford University JEREMY SUGERMAN, Talaria Technologies, Inc. EDWARD Y. WANG, Cumulus Networks, Inc. This article describes the historical context, technical challenges, and main implementation techniques used by VMware Workstation to bring virtualization to the x86 architecture in 1999. Although virtual machine monitors (VMMs) had been around for decades, they were traditionally designed as part of monolithic, single-vendor architectures with explicit support for virtualization. In contrast, the x86 architecture lacked virtualization support, and the industry around it had disaggregated into an ecosystem, with different ven- dors controlling the computers, CPUs, peripherals, operating systems, and applications, none of them asking for virtualization. We chose to build our solution independently of these vendors. As a result, VMware Workstation had to deal with new challenges associated with (i) the lack of virtual- ization support in the x86 architecture, (ii) the daunting complexity of the architecture itself, (iii) the need to support a broad combination of peripherals, and (iv) the need to offer a simple user experience within existing environments. These new challenges led us to a novel combination of well-known virtualization techniques, techniques from other domains, and new techniques. VMware Workstation combined a hosted architecture with a VMM. The hosted architecture enabled a simple user experience and offered broad hardware compatibility. Rather than exposing I/O diversity to the virtual machines, VMware Workstation also relied on software emulation of I/O devices. The VMM combined a trap-and-emulate direct execution engine with a system-level dynamic binary translator to ef- ficiently virtualize the x86 architecture and support most commodity operating systems.
    [Show full text]
  • CSE 141L: Design Your Own Processor What You'll
    CSE 141L: Design your own processor What you’ll do: - learn Xilinx toolflow - learn Verilog language - propose new ISA - implement it - optimize it (for FPGA) - compete with other teams Grading 15% lab participation – webboard 85% various parts of the labs CSE 141L: Design your own processor Teams - two people - pick someone with similar goals - you keep them to the end of the class - more on the class website: http://www.cse.ucsd.edu/classes/sp08/cse141L/ Course Staff: 141L Instructor: Michael Taylor Email: [email protected] Office Hours: EBU 3b 4110 Tuesday 11:30-12:20 TA: Saturnino Email: [email protected] ebu 3b b260 Lab Hours: TBA (141 TA: Kwangyoon) Æ occasional cameos in 141L http://www-cse.ucsd.edu/classes/sp08/cse141L/ Class Introductions Stand up & tell us: -Name - How long until graduation - What you want to do when you “hit the big time” - What kind of thing you find intellectually interesting What is an FPGA? Next time: (Tuesday) Start working on Xilinx assignment (due next Tuesday) - should be posted Sat will give a tutorial on Verilog today Check the website regularly for updates: http://www.cse.ucsd.edu/classes/sp08/cse141L/ CSE 141: 0 Computer Architecture Professor: Michael Taylor UCSD Department of Computer Science & Engineering RF http://www.cse.ucsd.edu/classes/sp08/cse141/ Computer Architecture from 10,000 feet foo(int x) Class of { .. } application Physics Computer Architecture from 10,000 feet foo(int x) Class of { .. } application An impossibly large gap! In the olden days: “In 1942, just after the United States entered World War II, hundreds of women were employed around the country as Physics computers...” (source: IEEE) The Great Battles in Computer Architecture Are About How to Refine the Abstraction Layers foo(int x) { .
    [Show full text]
  • Static Fault Attack on Hardware DES Registers
    Static Fault Attack on Hardware DES Registers Philippe Loubet-Moundi, Francis Olivier, and David Vigilant Gemalto, Security Labs, France {philippe.loubet-moundi,david.vigilant,francis.olivier}@gemalto.com http://www.gemalto.com Abstract. In the late nineties, Eli Biham and Adi Shamir published the first paper on Differential Fault Analysis on symmetric key algorithms. More specifically they introduced a fault model where a key bit located in non-volatile memory is forced to 0=1 with a fault injection. In their scenario the fault was permanent, and could lead the attacker to full key recovery with low complexity. In this paper, another fault model is considered: forcing a key bit to 0=1 in the register of a hardware block implementing Data Encryption Stan- dard. Due to the specific location of the fault, the key modification is not permanent in the life of the embedded device, and this leads to apply a powerful safe-error like attack. This paper reports a practical validation of the fault model on two actual circuits, and discusses limitations and efficient countermeasures against this threat. Keywords: Hardware DES, fault attacks, safe-error, register attacks 1 Introduction Fault attacks against embedded systems exploit the disturbed execution of a given program to infer sensitive data, or to execute unauthorized parts of this program. Usually a distinction is made between permanent faults and transient faults.A permanent fault alters the behavior of the device from the moment it is injected, and even if the device is powered off [8]. On the other hand, a transient fault has an effect limited in time, only a few cycles of the process are affected.
    [Show full text]
  • Processor Architecture Design Using 3D Integration Technology
    Processor Architecture Design Using 3D Integration Technology Yuan Xie Pennsylvania State University Computer Science and Engineering Department University Park, PA, 16802, USA [email protected] Abstract (4)Smaller form factor, which results in higher pack- ing density and smaller footprint due to the addition of The emerging three-dimensional (3D) chip architec- a third dimension to the conventional two dimensional tures, with their intrinsic capability of reducing the wire layout, and potentially results in a lower cost design. length, is one of the promising solutions to mitigate This tutorial paper first presents the background on the interconnect problem in modern microprocessor de- 3D integration technology, and then reviews various ap- signs. 3D memory stacking also enables much higher proaches to design future 3D microprocessors, which memory bandwidth for future chip-multiprocessor de- leverage the benefits of fast latency, higher bandwidth, sign, mitigating the “memory wall” problem. In addi- and heterogeneous integration capability that are offered tion, heterogenous integration enabled by 3D technol- by 3D technology. The challenges for future 3D archi- ogy can also result in innovation designs for future mi- tecture design are also discussed in the last section. croprocessors. This paper serves as a survey of various approaches to design future 3D microprocessors, lever- 2. 3D Integration Technology aging the benefits of fast latency, higher bandwidth, and The 3D integration technologies [25,26] can be clas- heterogeneous integration capability that are offered by sified into one of the two following categories. (1) 3D technology. 1 Monolithic approach. This approach involves sequen- tial device process. The frontend processing (to build the 1.
    [Show full text]
  • Processor Design：System-On-Chip Computing For
    Processor Design Processor Design System-on-Chip Computing for ASICs and FPGAs Edited by Jari Nurmi Tampere University of Technology Finland A C.I.P. Catalogue record for this book is available from the Library of Congress. ISBN 978-1-4020-5529-4 (HB) ISBN 978-1-4020-5530-0 (e-book) Published by Springer, P.O. Box 17, 3300 AA Dordrecht, The Netherlands. www.springer.com Printed on acid-free paper All Rights Reserved © 2007 Springer No part of this work may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, microfilming, recording or otherwise, without written permission from the Publisher, with the exception of any material supplied specifically for the purpose of being entered and executed on a computer system, for exclusive use by the purchaser of the work. To Pirjo, Lauri, Eero, and Santeri Preface When I started my computing career by programming a PDP-11 computer as a freshman in the university in early 1980s, I could not have dreamed that one day I’d be able to design a processor. At that time, the freshmen were only allowed to use PDP. Next year I was given the permission to use the famous brand-new VAX-780 computer. Also, my new roommate at the dorm had got one of the first personal computers, a Commodore-64 which we started to explore together. Again, I could not have imagined that hundreds of times the processing power will be available in an everyday embedded device just a quarter of century later.
    [Show full text]
  • Design Software & Development Kit Selector Guide
    ® Design Software & Development Kit Selector Guide April 2004 Table of Contents Quartus II Design Software Leadership ................................ page 2 Selecting a Design Software Product ................................... page 5 System Design Technology Recommended System Configurations ................................. page 8 Altera’s Quartus II software is the industry’s only design Altera Programming Hardware........................................... page 8 environment that supports Intellectual Property (IP)-based Altera Development Kits................................................... page 10 system design—including complete and automated system definition and implementation—without requiring lower- Third-Party Solutions........................................................ page 10 level hardware description language (HDL) or schematics. This capability enables designers to turn their concepts into working systems in minutes. The Quartus II system design tools include: Quartus II Design Software SOPC Builder: A system development tool that automates Leadership adding, parameterizing, and linking IP cores—including Altera’s Quartus® II software leads the embedded processors, co-processors, peripherals, memories, industry as the most comprehensive and user-defined logic—without requiring lower-level HDL environment available for FPGA, CPLD, or schematics. (See Figure 1.) and structured ASIC designs, delivering DSP Builder: Shortens digital signal processing (DSP) design unmatched performance, efficiency, and ease-of-use.
    [Show full text]
  • Validating Register Allocation and Spilling
    Validating Register Allocation and Spilling Silvain Rideau1 and Xavier Leroy2 1 Ecole´ Normale Sup´erieure,45 rue d'Ulm, 75005 Paris, France [email protected] 2 INRIA Paris-Rocquencourt, BP 105, 78153 Le Chesnay, France [email protected] Abstract. Following the translation validation approach to high- assurance compilation, we describe a new algorithm for validating a posteriori the results of a run of register allocation. The algorithm is based on backward dataflow inference of equations between variables, registers and stack locations, and can cope with sophisticated forms of spilling and live range splitting, as well as many architectural irregular- ities such as overlapping registers. The soundness of the algorithm was mechanically proved using the Coq proof assistant. 1 Introduction To generate fast and compact machine code, it is crucial to make effective use of the limited number of registers provided by hardware architectures. Register allocation and its accompanying code transformations (spilling, reloading, coa- lescing, live range splitting, rematerialization, etc) therefore play a prominent role in optimizing compilers. As in the case of any advanced compiler pass, mistakes sometimes happen in the design or implementation of register allocators, possibly causing incorrect machine code to be generated from a correct source program. Such compiler- introduced bugs are uncommon but especially difficult to exhibit and track down. In the context of safety-critical software, they can also invalidate all the safety guarantees obtained by formal verification of the source code, which is a growing concern in the formal methods world. There exist two major approaches to rule out incorrect compilations. Com- piler verification proves, once and for all, the correctness of a compiler or compi- lation pass, preferably using mechanical assistance (proof assistants) to conduct the proof.
    [Show full text]
  • V810 Familytm 32-Bit Microprocessor
    V810 FAMILYTM 32-BIT MICROPROCESSOR ARCHITECTURE V805TM V810TM V820TM V821TM Document No. U10082EJ1V0UM00 (1st edition) Date Published October 1995P © 11995 Printed in Japan NOTES FOR CMOS DEVICES 1 PRECAUTION AGAINST ESD FOR SEMICONDUCTORS Note: Strong electric field, when exposed to a MOS device, can cause destruction of the gate oxide and ultimately degrade the device operation. Steps must be taken to stop generation of static electricity as much as possible, and quickly dissipate it once it has occurred. Environmental control must be adequate. When it is dry, humidifier should be used. It is recommended to avoid using insulators that easily build static electricity. Semiconductor devices must be stored and transported in an anti- static container, static shielding bag or conductive material. All test and measurement tools including work bench and floor should be grounded. The operator should be grounded using wrist strap. Semiconductor devices must not be touched with bare hands. Similar precautions need to be taken for PW boards with semiconductor devices on it. 2 HANDLING OF UNUSED INPUT PINS FOR CMOS Note: No connection for CMOS device inputs can be cause of malfunction. If no connection is provided to the input pins, it is possible that an internal input level may be generated due to noise, etc., hence causing malfunction. CMOS devices behave differently than Bipolar or NMOS devices. Input levels of CMOS devices must be fixed high or low by using a pull-up or pull-down circuitry. Each unused pin should be connected to VDD or GND with a resistor, if it is considered to have a possibility of being an output pin.
    [Show full text]