DOCSLIB.ORG

Hardware Architecture Considerations in the WE32100 Chip Set

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Hardware Architecture Considerations in the WE32100 Chip Set FEATURE Hardware Architecture Considerations in the WE32100 Chip Set Michael L. Fuccio AT&T Bell Laboratories Benjamin Ng AT&T Information Systems The interchip communication protocols for the WE32100 microprocessor chip set had to be designed to support several ambitious architectural goals. T he WE32100 series of VLSI chips is an upgrade * support the software architecture of the entire chip set, and addition to the WE32000 (formerly, Bellmac- * retain some compatibility with predecessor chips so 32A) 32-bit microprocessor family. The WE32100 that Bellmac customers desiring higher performance via the family is a CMOS chip set that differs from its predecessor WE32100 chip set would not need to perform wholesale ar- in operating speed as well as in hardware architecture. chitectural changes when upgrading, and Some software architecture modifications of the upward- * allow for easy interfacing to commercial memories and compatible type were also implemented. Here, we discuss peripherals. the WE32100 chip set's interchip protocols as they relate to system hardware architectures. These protocols were de- fined at the same time the WE32100 family was designed. We also examine architectural trade-offs as they pertain to Alternatives investigated the WE32100 chip family. We investigated over a dozen alternatives for an inter- chip communications protocol. They fell into three Goals categories: * asynchronous protocols compatible with the WE32000 A number of goals guided the definition of the hard- (Bellmac-32A) microprocessor module, ware architecture. We wanted to * asynchronous protocols with pipelined memory trans- * provide an interchip protocol that would support com- actions, and petitive performance in a 32-bit microprocessor operating at * fully synchronous protocols with "split-read" memory a prescribed frequency, transactions. * provide a true all-VLSI chip set requiring no SSI The first category included about eight variations on the ''glue,'' theme. The WE32000 module has a four-cycle (zero-wait- * allow for multiple chip set configurations, to permit a state) memory transaction. We felt that a cycle could be system designer to customize the chip set to his needs, eliminated from this access and, further, that excess over- April 1986 0272-1732/86/0400-0029$01.00 © 1986 IEEE 29 WE32100 SERIES head on the WE32000 module could be eliminated. This showed that the occurrence of memory accesses that could alternative and its variations, then, provided an asynchro- be overlapped is relatively small for the WE32100 CPU. nous, three-cycle memory transaction for the CPU and any Furthermore, a write transaction cannot be overlapped. Yet other bus master. another problem, an internal CPU bus conflict, all but We evaluated the possibility of a memory transaction of eliminated "overlappable" transactions. Given these facts, two (or less) clock cycles, and the preliminary timing infor- we abandoned the second class of alternatives. mation we obtained indicated that, for a two-cycle memory At the time of the WE32100 development, our investiga- access, very little memory access time would be available tions of the third class of alternatives were still very ex- for common memory parts. This did not meet our first ploratory. Furthermore, the alternatives in this class did not goal, that is, that the speed be competitive. It was our judg- meet the goal of compatibility with Bellmac chips. Since ment that a two-cycle memory transaction would not be compatibility was very important and since the concepts of usable with common memory well into the foreseeable this class were not well proven, we abandoned it. future. Furthermore, certain functionality would have been Table 1 summarizes how the three classes of protocol lost if the transaction had been made two cycles long. alternatives met our goals. The details of the chip set pro- In sampling asynchronous signals, there is a high cost tocols are described in the WE32100) information manual.l associated with preventing input signal metastability. In the remainder of this article, we will describe some of Avoiding metastability requires a signal input to be doubly the more important issues relating to the realization of a latched. This requires additional latching times (clock hardware architecture for a 32-bit VLSI chip set. edges), which a two-cycle transaction could not have provided. As a result of all these difficulties, we abandoned the Chip set protocol issues two-cycle approach in favor of the three-cycle one. The second class of alternatives also addressed our desire Here, we examine the issues that arose when we sought to reduce the length of a memory transaction to two cycles. to choose a chip set protocol that would meet our goals. In these alternatives, a three-cycle access would overlap, by These issues involved one cycle, the subsequent access. This memory transaction overlap would yield an effective two-cycle transaction. We * choosing asynchronous or synchronous operation, felt that this overlap could occur often, given the instruc- * choosing multiplexed or nonmultiplexed addresses and tion prefetch policy of the CPU and the early availability of data, the next instruction. More careful analysis, however, * implementation of transaction types, including reads, writes, interlocked reads, block fetches, and interrupt- vector number fetches, * exception handling, * bus arbitration, * the implementation of the interface to the memory alternativs me hW3 0 iciett0gas management unit, or MMU, * the handling of support processors, ;Goalf Aleraiv IAterm0itive 2 leraiv * providing for special needs of the chip set architecture, Competitive:l0 :0 * choosing the operating frequency, and * electrical design. Yes YeWs :0Yes0 i't;t- ; perormne?;000 $A;StleL;: :<SEd;.X; Before discussing each of the issues listed above, we tSXllEi;t4;f \y;ti100-050X; should describe, briefly, some of the features of the Glue logic?; 00; N:rn Sm,;'a,,zMoun 0'dsiE^ WE32100 chip set. Additional detail can be found in ;S:t;;00t,-'000^00 ji ;;^^XE several technical papers. 2-5 M:ultipl chip 0i0j0)0 t:;E^:; ftity4^;-;f; - ;,l The WE32100 CPU has a rich instruction set that in- con£;gurations? ';i'.tS;:fE;1ffi:e:az:S cludes operating system support instructions. Two instruc- ;if';f:.:;iE00w<^.000 Yes,;f;0W::' SS: i;; ;it;;<, i;; f;: ftA42 -:.: ;NiC. \,8 tions requiring I/O protocol support are implemented. The ES;;03X'S'S;t:;X:^j8X4j. SSA;SEd^\X:, .. 10000 ^t-LL t;;-0^ :;SH;;,:;:::4:o.S tE; W; dE: Nt;ji,,; 00 ;,:00 first is the SWAPI (swap interlock) instruction and the sec- 2 ,E4 b: ;f;; f. S;X,,75;-k t ;; t;;t;Li; W;; ond is the MVTRW instruction. We will discuss support for a£¢chitecture 00 Yi t:s? GE tE f^. --.^4.zy ?:;;; iAtl.;^;;|Xt:: ^t ;;-Cv; t: t>; ,3t these instructions later. The WE32100 CPU also supports a a,,l! ?2E,f(;;;; :T' t:U: <, rich interrupt structure, including Yes tiEE4-:S: ,40 t;;^ l0040 li4S'40.E '1x;z^ an "autovector" feature. :iS:: ': ;"; -St .;,;; ;.; f f"t1; rNl The WE32100 CPU has an on-board instruction cache t^:?::.iS E: :;;;gS;-: t;. ,;:X;E XK :t^f^--;; that fetches a two-word block on a cache miss. This two- ffiWE32;000-. ^ Y;: 'ties; :1|..S:||^|- (M, ^:^; ^t :;ts :$ '^.!@' word fetch has a hardware protocol support mechanism, 4: ;gl; j? :,; :tiNg:^^:i,,,;- 11 fW:cpantibe? ; ;,,,$;?S b ll;A. ",'i:^ :?;FfE;'..r"'', which we will discuss later. ;S.., :d t:-: ;SA J; iSk; ;;? S4t'S;04^^-' :|.; ;;i'.^:^SS The WE32101 MMU provides typical virtual memory Ea,yS commercial:t ,.;U.. 51, SS*3:_w; atl^0n'S^^= functions-that is, address translation and protection-for the WE32100 chip set. The MMU supports segmentation 30 E'SN''xS;AtS;, IEIEEE MICROIR and paging and, in the paged translation mode, a special entities can only react to bus events, since they cannot be I/O protocol feature called "early RAS." made aware of the activity of other bus entities in a global The WE32106 math accelerator unit, or MAU, complies sense. with Draft 10.0 of the proposed IEEE floating-point Entities on an asynchronous bus typically do not share a arithmetic standard.6 It can be configured as a support clock signal governing bus transactions. Typical VLSI processor (i.e., make use of the WE32100 support pro- devices advance their internal state via a clock signal. This cessor interface) or as a memory-mapped peripheral. causes some difficulty in connecting the asynchronous bus The WE32103 dynamic RAM controller supports up to to the synchronous internals of such devices. Metastability four banks of dynamic memory. The DRAM controller is a problem here. 6-9 To avoid having a sampled asynchro- also supports dual-ported memory and has an interface for nous signal become metastabie, one should be sure the an error detection and correction chip. It is programmable signal is doubly latched. That is, the signal, once sampled, for various speeds of dynamic RAM. should have its sampled value latched some time later to The WE32104 direct memory access controller features a resolve a potential metastability condition. The need to system bus and a peripheral bus. The system bus is a 32-bit- doubly latch an asynchronous signal means that more time wide bus designed for memory-to-memory DMA. The pe- must be dedicated to guaranteeing the state of that signal. ripheral bus is an eight-bit-wide bus optimized for byte- This can mean an overall loss of bandwidth for an asyn- wide peripherals such as UARTs and LAN interfaces. The chronous bus compared to a synchronous bus. DMA controller can perform system-bus-to-peripheral-bus transactions and also allows the CPU to access peripherals, Pseudosynchronous buses. A pseudosynchronous bus has on the peripheral bus, from the system bus. The DMA con- the attributes of both a synchronous and an asynchronous troller is programmable for burst-mode or cycle-steal trans- bus.
Load more

Recommended publications
  • Is Parallel Programming Hard, And, If So, What Can You Do About It?
    Is Parallel Programming Hard, And, If So, What Can You Do About It? Edited by: Paul E. McKenney Linux Technology Center IBM Beaverton [email protected] December 16, 2011 ii Legal Statement This work represents the views of the authors and does not necessarily represent the view of their employers. IBM, zSeries, and Power PC are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. Linux is a registered trademark of Linus Torvalds. i386 is a trademarks of Intel Corporation or its subsidiaries in the United States, other countries, or both. Other company, product, and service names may be trademarks or service marks of such companies. The non-source-code text and images in this doc- ument are provided under the terms of the Creative Commons Attribution-Share Alike 3.0 United States li- cense (http://creativecommons.org/licenses/ by-sa/3.0/us/). In brief, you may use the contents of this document for any purpose, personal, commercial, or otherwise, so long as attribution to the authors is maintained. Likewise, the document may be modified, and derivative works and translations made available, so long as such modifications and derivations are offered to the public on equal terms as the non-source-code text and images in the original document. Source code is covered by various versions of the GPL (http://www.gnu.org/licenses/gpl-2.0.html). Some of this code is GPLv2-only, as it derives from the Linux kernel, while other code is GPLv2-or-later.
    [Show full text]
  • Hardware Architecture
    Hardware Architecture Components Computing Infrastructure Components Servers Clients LAN & WLAN Internet Connectivity Computation Software Storage Backup Integration is the Key ! Security Data Network Management Computer Today’s Computer Computer Model: Von Neumann Architecture Computer Model Input: keyboard, mouse, scanner, punch cards Processing: CPU executes the computer program Output: monitor, printer, fax machine Storage: hard drive, optical media, diskettes, magnetic tape Von Neumann architecture - Wiki Article (15 min YouTube Video) Components Computer Components Components Computer Components CPU Memory Hard Disk Mother Board CD/DVD Drives Adaptors Power Supply Display Keyboard Mouse Network Interface I/O ports CPU CPU CPU – Central Processing Unit (Microprocessor) consists of three parts: Control Unit • Execute programs/instructions: the machine language • Move data from one memory location to another • Communicate between other parts of a PC Arithmetic Logic Unit • Arithmetic operations: add, subtract, multiply, divide • Logic operations: and, or, xor • Floating point operations: real number manipulation Registers CPU Processor Architecture See How the CPU Works In One Lesson (20 min YouTube Video) CPU CPU CPU speed is influenced by several factors: Chip Manufacturing Technology: nm (2002: 130 nm, 2004: 90nm, 2006: 65 nm, 2008: 45nm, 2010:32nm, Latest is 22nm) Clock speed: Gigahertz (Typical : 2 – 3 GHz, Maximum 5.5 GHz) Front Side Bus: MHz (Typical: 1333MHz , 1666MHz) Word size : 32-bit or 64-bit word sizes Cache: Level 1 (64 KB per core), Level 2 (256 KB per core) caches on die. Now Level 3 (2 MB to 8 MB shared) cache also on die Instruction set size: X86 (CISC), RISC Microarchitecture: CPU Internal Architecture (Ivy Bridge, Haswell) Single Core/Multi Core Multi Threading Hyper Threading vs.
    [Show full text]
  • Antipatterns Refactoring Software, Architectures, and Projects in Crisis
    AntiPatterns Refactoring Software, Architectures, and Projects in Crisis William J. Brown Raphael C. Malveau Hays W. McCormick III Thomas J. Mowbray John Wiley & Sons, Inc. Publisher: Robert Ipsen Editor: Theresa Hudson Managing Editor: Micheline Frederick Text Design & Composition: North Market Street Graphics Copyright © 1998 by William J. Brown, Raphael C. Malveau, Hays W. McCormick III, and Thomas J. Mowbray. All rights reserved. Published by John Wiley & Sons, Inc. Published simultaneously in Canada. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per−copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750−8400, fax (978) 750−. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 605 Third Avenue, New York, NY 10158−, (212) 850−, fax (212) 850−, E−Mail: PERMREQ @ WILEY.COM. This publication is designed to provide accurate and authoritative information in regard to the subject matter covered. It is sold with the understanding that the publisher is not engaged in professional services. If professional advice or other expert assistance is required, the services of a competent professional person should be sought. Designations used by companies to distinguish their products are often claimed as trademarks. In all instances where John Wiley & Sons, Inc., is aware of a claim, the product names appear in initial capital or all capital letters.
    [Show full text]
  • Efficient Processing of Deep Neural Networks
    Efficient Processing of Deep Neural Networks Vivienne Sze, Yu-Hsin Chen, Tien-Ju Yang, Joel Emer Massachusetts Institute of Technology Reference: V. Sze, Y.-H.Chen, T.-J. Yang, J. S. Emer, ”Efficient Processing of Deep Neural Networks,” Synthesis Lectures on Computer Architecture, Morgan & Claypool Publishers, 2020 For book updates, sign up for mailing list at http://mailman.mit.edu/mailman/listinfo/eems-news June 15, 2020 Abstract This book provides a structured treatment of the key principles and techniques for enabling efficient process- ing of deep neural networks (DNNs). DNNs are currently widely used for many artificial intelligence (AI) applications, including computer vision, speech recognition, and robotics. While DNNs deliver state-of-the- art accuracy on many AI tasks, it comes at the cost of high computational complexity. Therefore, techniques that enable efficient processing of deep neural networks to improve key metrics—such as energy-efficiency, throughput, and latency—without sacrificing accuracy or increasing hardware costs are critical to enabling the wide deployment of DNNs in AI systems. The book includes background on DNN processing; a description and taxonomy of hardware architectural approaches for designing DNN accelerators; key metrics for evaluating and comparing different designs; features of DNN processing that are amenable to hardware/algorithm co-design to improve energy efficiency and throughput; and opportunities for applying new technologies. Readers will find a structured introduction to the field as well as formalization and organization of key concepts from contemporary work that provide insights that may spark new ideas. 1 Contents Preface 9 I Understanding Deep Neural Networks 13 1 Introduction 14 1.1 Background on Deep Neural Networks .
    [Show full text]
  • Architectural Adaptation for Application-Specific Locality
    Architectural Adaptation for Application-Specific Locality Optimizations y z Xingbin Zhang Ali Dasdan Martin Schulz Rajesh K. Gupta Andrew A. Chien Department of Computer Science yInstitut f¨ur Informatik University of Illinois at Urbana-Champaign Technische Universit¨at M¨unchen g fzhang,dasdan,achien @cs.uiuc.edu [email protected] zInformation and Computer Science, University of California at Irvine [email protected] Abstract without repartitioning hardware and software functionality and reimplementing the co-processing hardware. This re- We propose a machine architecture that integrates pro- targetability problem is an obstacle toward exploiting pro- grammable logic into key components of the system with grammable logic for general purpose computing. the goal of customizing architectural mechanisms and poli- cies to match an application. This approach presents We propose a machine architecture that integrates pro- an improvement over traditional approach of exploiting grammable logic into key components of the system with programmable logic as a separate co-processor by pre- the goal of customizing architectural mechanisms and poli- serving machine usability through software and over tra- cies to match an application. We base our design on the ditional computer architecture by providing application- premise that communication is already critical and getting specific hardware assists. We present two case studies of increasingly so [17], and flexible interconnects can be used architectural customization to enhance latency tolerance to replace static wires at competitive performance [6, 9, 20]. and efficiently utilize network bisection on multiproces- Our approach presents an improvement over co-processing sors for sparse matrix computations. We demonstrate that by preserving machine usability through software and over application-specific hardware assists and policies can pro- traditional computer architecture by providing application- vide substantial improvements in performance on a per ap- specific hardware assists.
    [Show full text]
  • Performance Analyses and Code Transformations for MATLAB Applications Patryk Kiepas
    Performance analyses and code transformations for MATLAB applications Patryk Kiepas To cite this version: Patryk Kiepas. Performance analyses and code transformations for MATLAB applications. Computa- tion and Language [cs.CL]. Université Paris sciences et lettres, 2019. English. NNT : 2019PSLEM063. tel-02516727 HAL Id: tel-02516727 https://pastel.archives-ouvertes.fr/tel-02516727 Submitted on 24 Mar 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Préparée à MINES ParisTech Analyses de performances et transformations de code pour les applications MATLAB Performance analyses and code transformations for MATLAB applications Soutenue par Composition du jury : Patryk KIEPAS Christine EISENBEIS Le 19 decembre 2019 Directrice de recherche, Inria / Paris 11 Présidente du jury João Manuel Paiva CARDOSO Professeur, University of Porto Rapporteur Ecole doctorale n° 621 Erven ROHOU Ingénierie des Systèmes, Directeur de recherche, Inria Rennes Rapporteur Matériaux, Mécanique, Michel BARRETEAU Ingénieur de recherche, THALES Examinateur Énergétique Francois GIERSCH Ingénieur de recherche, THALES Invité Spécialité Claude TADONKI Informatique temps-réel, Chargé de recherche, MINES ParisTech Directeur de thèse robotique et automatique Corinne ANCOURT Maître de recherche, MINES ParisTech Co-directrice de thèse Jarosław KOŹLAK Professeur, AGH UST Co-directeur de thèse 2 Abstract MATLAB is an interactive computing environment with an easy programming language and a vast library of built-in functions.
    [Show full text]
  • Development of a Predictable Hardware Architecture Template and Integration Into an Automated System Design Flow
    Development Secure of Reprogramming a Predictable Hardware of Architecturea Network Template Connected and Device Integration into an Automated System Design Flow Securing programmable logic controllers MARCUS MIKULCAK MUSSIE TESFAYE KTH Information and Communication Technology Masters’ Degree Project Second level, 30.0 HEC Stockholm, Sweden June 2013 TRITA-ICT-EX-2013:138Degree project in Communication Systems Second level, 30.0 HEC Stockholm, Sweden Secure Reprogramming of a Network Connected Device KTH ROYAL INSTITUTE OF TECHNOLOGY Securing programmable logic controllers SCHOOL OF INFORMATION AND COMMUNICATION TECHNOLOGY ELECTRONIC SYSTEMS MUSSIE TESFAYE Development of a Predictable Hardware Architecture TemplateKTH Information and Communication Technology and Integration into an Automated System Design Flow Master of Science Thesis in System-on-Chip Design Stockholm, June 2013 TRITA-ICT-EX-2013:138 Author: Examiner: Marcus Mikulcak Assoc. Prof. Ingo Sander Supervisor: Seyed Hosein Attarzadeh Niaki Degree project in Communication Systems Second level, 30.0 HEC Stockholm, Sweden Abstract The requirements of safety-critical real-time embedded systems pose unique challenges on their design process which cannot be fulfilled with traditional development methods. To ensure their correct timing and functionality, it has been suggested to move the design process to a higher abstraction level, which opens the possibility to utilize automated correct-by-design development flows from a functional specification of the system down to the level of Multiprocessor Systems-on-Chip. ForSyDe, an embedded system design methodology, presents a flow of this kind by basing system development on the theory of Models of Computation and side-effect-free processes, making it possible to separate the timing analysis of computation and communication of process networks.
    [Show full text]
  • Computer Architectures an Overview
    Computer Architectures An Overview PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 25 Feb 2012 22:35:32 UTC Contents Articles Microarchitecture 1 x86 7 PowerPC 23 IBM POWER 33 MIPS architecture 39 SPARC 57 ARM architecture 65 DEC Alpha 80 AlphaStation 92 AlphaServer 95 Very long instruction word 103 Instruction-level parallelism 107 Explicitly parallel instruction computing 108 References Article Sources and Contributors 111 Image Sources, Licenses and Contributors 113 Article Licenses License 114 Microarchitecture 1 Microarchitecture In computer engineering, microarchitecture (sometimes abbreviated to µarch or uarch), also called computer organization, is the way a given instruction set architecture (ISA) is implemented on a processor. A given ISA may be implemented with different microarchitectures.[1] Implementations might vary due to different goals of a given design or due to shifts in technology.[2] Computer architecture is the combination of microarchitecture and instruction set design. Relation to instruction set architecture The ISA is roughly the same as the programming model of a processor as seen by an assembly language programmer or compiler writer. The ISA includes the execution model, processor registers, address and data formats among other things. The Intel Core microarchitecture microarchitecture includes the constituent parts of the processor and how these interconnect and interoperate to implement the ISA. The microarchitecture of a machine is usually represented as (more or less detailed) diagrams that describe the interconnections of the various microarchitectural elements of the machine, which may be everything from single gates and registers, to complete arithmetic logic units (ALU)s and even larger elements.
    [Show full text]
  • Large-Scale Software Architecture
    Large-Scale Software Architecture A Practical Guide using UML Jeff Garland CrystalClear Software Inc. Richard Anthony Object Computing Inc. Large-Scale Software Architecture Large-Scale Software Architecture A Practical Guide using UML Jeff Garland CrystalClear Software Inc. Richard Anthony Object Computing Inc. Copyright # 2003 by John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex PO19 8SQ, England Telephone (+44) 1243 779777 Email (for orders and customer service enquiries): [email protected] Visit our Home Page on www.wileyeurope.com or www.wiley.com All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except under the terms of the Copyright, Designs and Patents Act 1988 or under the terms of a licence issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London W1T 4LP, UK, without the permission in writing of 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 publication. Requests to the Publisher should be addressed to the Permissions Department, John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex PO19 8SQ, England, or emailed to [email protected], or faxed to (+44) 1243 770571. Neither the authors nor John Wiley & Sons, Ltd accept any responsibility or liability for loss or damage occasioned to any person or property through using the material, instructions, methods or ideas contained herein, or acting or freraining from acting as a result of such use.
    [Show full text]
  • Integrated Circuit Technology for Wireless Communications: an Overview Babak Daneshrad Integrated Circuits and Systems Laboratory UCLA Electrical Engineering Dept
    Integrated Circuit Technology for Wireless Communications: An Overview Babak Daneshrad Integrated Circuits and Systems Laboratory UCLA Electrical Engineering Dept. email: [email protected] http://www.ee.ucla.edu/~babak Abstract: Figure 1 shows a block diagram of a typical wireless com- This paper provides a brief overview of present trends in the develop- munication system. Moreover it shows the partitioning of the ment of integrated circuit technology for applications in the wireless receiver into RF, IF, baseband analog and digital components. communications industry. Through advanced circuit, architectural and In this paper we will focus on two main classes of integrated processing technologies, ICs have helped bring about the wireless revo- circuit technologies. The first is ICs for analog and more lution by enabling highly sophisticated, low cost and portable end user importantly RF communications. In general the technologist as terminals. In this paper two broad categories of circuits are highlighted. The first is RF integrated circuits and the second is digital baseband well as the circuit designer’s challenge here is to first, make the processing circuits. In both areas, the paper presents the circuit design transistors operate at higher carrier frequencies, and second, to challenges and options presented to the designer. It also highlights the integrate as many of the components required in the receiver manner in which these technologies have helped advance wireless com- onto the IC. The second class of circuits that we will focus on munications. are digital baseband circuits. Where increased density and I. Introduction reduced power consumption are the key factors for optimiza- tion.
    [Show full text]
  • [0470848499]Large-Scale Software Architecture.Pdf
    Y L F M A E T Team-Fly® Large-Scale Software Architecture A Practical Guide using UML Jeff Garland CrystalClear Software Inc. Richard Anthony Object Computing Inc. Large-Scale Software Architecture Large-Scale Software Architecture A Practical Guide using UML Jeff Garland CrystalClear Software Inc. Richard Anthony Object Computing Inc. Copyright # 2003 by John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex PO19 8SQ, England Telephone (+44) 1243 779777 Email (for orders and customer service enquiries): [email protected] Visit our Home Page on www.wileyeurope.com or www.wiley.com All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except under the terms of the Copyright, Designs and Patents Act 1988 or under the terms of a licence issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London W1T 4LP, UK, without the permission in writing of 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 publication. Requests to the Publisher should be addressed to the Permissions Department, John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex PO19 8SQ, England, or emailed to [email protected], or faxed to (+44) 1243 770571. Neither the authors nor John Wiley & Sons, Ltd accept any responsibility or liability for loss or damage occasioned to any person or property through using the material, instructions, methods or ideas contained herein, or acting or freraining from acting as a result of such use.
    [Show full text]
  • Hybrid Pipeline Hardware Architecture Based on Error Detection and Correction for AES
    sensors Article Hybrid Pipeline Hardware Architecture Based on Error Detection and Correction for AES Ignacio Algredo-Badillo 1,† , Kelsey A. Ramírez-Gutiérrez 1,† , Luis Alberto Morales-Rosales 2,* , Daniel Pacheco Bautista 3,† and Claudia Feregrino-Uribe 4,† 1 CONACYT-Instituto Nacional de Astrofísica, Óptica y Electrónica, Puebla 72840, Mexico; [email protected] (I.A.-B.); [email protected] (K.A.R.-G.) 2 Faculty of Civil Engineering, CONACYT-Universidad Michoacana de San Nicolás de Hidalgo, Morelia 58000, Mexico 3 Departamento de Ingeniería en Computación, Universidad del Istmo, Campus Tehuantepec, Oaxaca 70760, Mexico; [email protected] 4 Instituto Nacional de Astrofísica, Óptica y Electrónica, Puebla 72840, Mexico; [email protected] * Correspondence: [email protected] † These authors contributed equally to this work. Abstract: Currently, cryptographic algorithms are widely applied to communications systems to guarantee data security. For instance, in an emerging automotive environment where connectivity is a core part of autonomous and connected cars, it is essential to guarantee secure communications both inside and outside the vehicle. The AES algorithm has been widely applied to protect communications in onboard networks and outside the vehicle. Hardware implementations use techniques such as iterative, parallel, unrolled, and pipeline architectures. Nevertheless, the use of AES does not Citation: Algredo-Badillo, I.; guarantee secure communication, because previous works have proved that implementations of secret Ramírez-Gutiérrez, K.A.; key cryptosystems, such as AES, in hardware are sensitive to differential fault analysis. Moreover, Morales-Rosales, L.A.; Pacheco it has been demonstrated that even a single fault during encryption or decryption could cause Bautista, D.; Feregrino-Uribe, C.
    [Show full text]