ST Comp Mthds Electromagnetic
ST Comp Mthds Electromagnetic ECE 495
Popular in Course
verified elite notetaker
verified elite notetaker
verified elite notetaker
Anika Treutel MD
verified elite notetaker
verified elite notetaker
verified elite notetaker
Popular in Engineering Electrical & Compu
This 51 page Class Notes was uploaded by Roel Green on Wednesday September 23, 2015. The Class Notes belongs to ECE 495 at University of New Mexico taught by James Plusquellic in Fall. Since its upload, it has received 29 views. For similar materials see /class/212156/ece-495-university-of-new-mexico in Engineering Electrical & Compu at University of New Mexico.
Reviews for ST Comp Mthds Electromagnetic
Report this Material
What is Karma?
Karma is the currency of StudySoup.
Date Created: 09/23/15
HOST Hardware Trojans I ECE 495595 rHardware Trojans What is a hardware Trojan A deliberate and malicious change to an IC that adds or removes functionality or reduces reliability The modi cations may be designed to leak sensitive information personal or corpo rate The modi cations may be designed to cause a system to fail at a critical time While operating in mission mode The modi cation may be designed to reduce the reliability of the IC What makes this a challenging problem Adversary makes purposeful discovery highly improbable amp physical inspection is very expensive Trojan circuits are a big concern for US military IC Trust Program initiated to investigate solutions to the problem de ned by a Defense Science Board Task Force report httpwwwacqosdmildsbreports200502HPMSReportFinalpdf ECE UNM l N J 9109 HOST Hardware Trojans I ECE 495595 fHardware Trojan Example N Missile control system Assume a chip receives encrypted commands from an RF channel and stores the value in a register for subsequent decryption 31 Wire in original E Jr 2 o E 3 M1ss11e Chlp ll CO quotquot quot Trojan gates and Wires 0 I T Decryption Engine Adversary transmits quotcodequot that causes activation missile detonates before reaching its target J ECE UNM 2 9109 HOST Hardware Trojans I ECE 495595 fHardware Trojan Example N Adversary may try a stealthier strategy e g a monolithic NAND gate 31 I Wire in g g original design 439 Inserted gate 5 I a j detonator o0 TI OJa 3 activation 1 gt0 quotquotquotquot quot o 321nput Wire 1 o m f o NAND gate 0 Trojan transistors gates and Wires Many other implementations are possible e g passgate versions some better than others at minimizing power supply anomalies J ECE UNM 3 9109 HOST Hardware Trojans I ECE 495595 GC Trust Consider the vulnerabilities in a typical ASIC design ow 1 2 3 4 Trusted Either Untrusted 8 9 f FF it alien ASIC design ow given in the DARPA TRUST BAA process modi cation because these steps include signi cant third party content K ECE UNM 4 Steps 14 and 79 are particularly susceptible to malicious insertions and deliberate J 9 109 HOST Hardware Trojans I ECE 495595 ECE UNM 5 GC Trust ASIC designs may use dozens of EDA tools Whose veri cation of TRUST is formi dable Insertions during the fabrication process steps 79 would produce dice With differ ing properties Without testing each die the assumption of trust based on the test results of sampled dice may be misleading Process modi cations can cause premature aging are particularly dif cult to detect After deployment step 13 the IC is largely defenseless against physical tamper and side channel attacks In general in order to develop a strategy to ensure IC trust it Will be necessary to make assumptions about Which steps are trusted and Which are untrusted The Trojan insertion point eg SoftIP GDS package etc Will determine What detection strategies are possible and What assumptions are necessary J 9109 HOST Hardware Trojans I ECE 495595 rTRUST ASICs vs COTS 9 UN Controlled GD Wafer 1 ory ISe amp Mask amp Fab Package UNControlled UNControlled I Specs V Controlled j De lqy amp Package OHItOI39 Test Controlled K J ECE UNM 6 9109 HOST Hardware Trojans I ECE 495595 rTrojan Scenarios Soft1P Trojans N Adversary can compromise soft1P by inserting extra hidden functionality into the netlist Implications No golden model is available Every IC has the Trojan Detection strategies include Formal veri cation methods Prove that the functionality of the IP is equivalent to some higherlevel more abstract trusted speci cation Unfortunately formal veri cation is a dif cult problem NPcomplete and can only be applied to small Circuits There has been some recent work in this area that offers more attractive solu tions J ECE UNM 7 9109 HOST Hardware Trojans I ECE 495595 N rTrojan Scenarios Hard and Soft1P Trojans Monitoring the IC using a trusted companion IC Trusted companion IC has access to the internal state of the untrusted IC through extra pinsscan Chain Trusted companion IC is programmed such that it knows the legal state space of the untrusted IC and sets off an alarm andor shuts down the IC if violated This technique can be used for a second Class of GDSbased Trojans High security applications would likely use only IP developed inhouse or from trusted sources Following the advice from a old adage quotDoctor doctor it hurts when I do thisquot Doctor replies well then don t do thatquot Hard1P GDS Trojans The insertion point here is the layout GDS We mentioned earlier that several modi cations are possible e g those designed to l disabledestroy 2 to leak information and 3 decrease reliability J ECE UNM 8 9109 HOST Hardware Trojans I ECE 495595 N rTrojan Scenarios Hard1P Trojans Changes to the IC s function can be implemented by Using existing Whitespace places in the layout Where there are no transistors or Where there is a bypass capacitor Nudging gates to make space for the Trojan gates In case you were thinking about adding some type of veri able White space ller to prevent the rst case from occurring Parametric Changes designed to reduce reliability can be implemented by thinning Wires to accelerate EM effects by thinning oxide to accelerate TDDB etc I would like to argue that When direct control is needed by the adversary then func tional modi cations the rst type are more attractive Why do you think this might be the case Let s consider another Trojan parameter the size of the Trojan Trojans can be very small and be effective eg only a couplethree gates For Trojans designed to Change functionality small Trojans are risky Why J ECE UNM 9 9109 HOST Hardware Trojans I ECE 495595 rTrojan Scenarios Hard1P Trojans N Therefore I argue that Trojans designed to Change functionality eg destroydisable enable remote control etc are likely to be larger 10 s to 100 s of gates to prevent discovery Unfortunately the same is not true for information leakage Trojans Since they do not at least in an obvious way Change functionality they can be very small and remain secure against detection Information leakage Trojans can leak information in ways that are not easily detected By broadcasting data as EM radiation By inserting data into a communication Channel that appears as error bits to a valid receiver By inserting data into a communication Channel at a higher frequency eg baud rate than the valid receiver is expecting Lot s of strategies have been proposed all of them dif cult to detect unless you test at a high level eg the protocol level J ECE UNM 10 9109 HOST Hardware Trojans I ECE 495595 rTrojan Scenarios Hard1P Trojans N Unlike manufacturing defects you only need to detect ONE Trojan to yield success For example if a layoutbased Trojan is inserted in EVERY copy of a manufactured IC then alternative test strategies that use MUCH larger test sets can be used Unfortunately layoutbased Trojans can be inserted in only a subset of the ICs unlike softIP Trojans which are by de nition in every copy This makes it more dif cult to develop a testing method to detect them Why Whether the Trojan is selectively inserted or inserted into every copy depends on the application I argue that functionally disruptive Trojans like the missile Trojan are likely to be inserted into every copy of an IC Why I also argue that information leakage Trojans do not need to be inserted into every copy of the IC to be useful Why J ECE UNM 11 9109 HOST Hardware Trojans I ECE 495595 N rTrojan Taxonomy Layout inserted GDS Trojans can take many forms but can be broken into the fol Trojan classi cation Physical Activation Action characteristics characteristics characteristics Condition based I 39 w L0 gic a w odify wanna 3pm Small arge Internal I 39 I quotPower Supply Signal Calibration Techniques for Improving Detection Resolution to Hardware Trojans R M Rad W Xiaoxiao M Tehranipoor J Plusquellic International Conference on Computer Aided Design ICCAD Nov 2008 pp 632 639 lowing categories J ECE UNM 12 9109 HOST Hardware Trojans I ECE 495595 N rLayoutOriented Trojan Detection Strategies Three basic approaches IC Deprocessing and Application of Failure Analysis Methods The most straightforward approach is to deprocess the chip ie remove one layer at a time and compare the wires and transistors with the original layout The comparison can be implemented using image processing methods that com pare microphotographs of IC geometries with layout images Failure analysis FA methods traditionally used for identifying the root cause of failure in IC can also be applied to extract geometries Scanning OpticalElectron Microscopy SOlWSEM PicoSecond Imaging Circuit Analysis PICA and Voltage Contrast Imaging LightInducedChargeInduced Voltage Alternation LIVACIVA Advantages IC Deprocessing and Application of Failure Analysis Methods Potentially highly sensitive to the presence of Trojans Drawbacks IC Deprocessing and Application of Failure Analysis Methods Destructive may miss selectivelyinserted Trojans cost effectiveness in nano J ECE UNM 13 9109 HOST Hardware Trojans I ECE 495595 ECE UNM 14 rLayoutOriented Trojan Detection Strategies N Three basic approaches Functional activation through logic testing Develop an automatic test pattern generation ATPG strategy that generates logic vectors patterns to activate the Trojan Given the connectivity Characteristics of the Trojan to the original Circuit are UNknown ATPG must be based on a heuristic The heuristic Chosen by most researchers is that the adversary is likely to con nect the Trojan to Wires in the original design that are the most dif cult to con trol and observe The rational for this is simple the adversary wants to make accidental discov ery ie through manufacturing test of the Trojan extremely unlikely Therefore many of the proposed functional activation strategies are based on deriving tests for nodes that are randompattern resistant J 9109 HOST Hardware Trojans I ECE 495595 N rLayoutOriented Trojan Detection Strategies Three basic approaches Functional activation through logic testing Randompattern resistant is a term used in the testing community for nodes that have a low probability of being tested using a set of random patterns Controllability and Observability analysis of these nodes indicates that these nodes are controlled andor observed under very speci c conditions These rare conditions ie internal Circuit states are the target of many of the proposed Trojan testing strategies The premise is that the adversary can determine these hardtodetect nodes using standard manufacturing test tools and connect the Trojan to them Advantages Functional activation through logic testing Existing manufacturing test tools can be leveraged The presence of the Trojan can be validated Without deprocessing J ECE UNM 15 9109 HOST Hardware Trojans I ECE 495595 N rLayoutOriented Trojan Detection Strategies Three basic approaches Drawbacks Functional activation through logic testing Only applicable to small functional Trojans least likely information leakage Trojans may not Change the functional behavior of the IC The adversary may guess that the ATPG strategy may be directed at hardt0 detect nodes and can connect some Trojan inputs to easytOdetect nodes Generating test patterns may be extremely time consuming or impossible for some hardtodetect nodes impossible to activate As the number of inputs to the Trojan increases the dif culty of generating Tro jan activation patterns increases dramatically This is true because ATPG must generate patterns that Check all combina tions of hardtodetect nodes not just one node at a time as is true in man ufacturing test for detects J ECE UNM 16 9109 HOST Hardware Trojans I ECE 495595 rLayoutOriented Trojan Detection Strategies N Three basic approaches Parametric Anomaly Detection Strategies A parametric anomaly is a change in the analog characteristics of the IC eg in its power consumption delay characteristics temperature pro le EM radiation characteristics etc As we indicated earlier with the Trojan missile example adding a Trojan ie a set of gates to the layout of an IC changes the analog characteristics of the IC These changes include Increasing the leakage characteristics of the IC Increasing the dynamic power consumption of the IC Increasing the delay of paths that have nodes connected to the Trojan gate inputs Temperature pro le changes in the IC etc Therefore Trojan detection methods can be developed that measure an IC s ana log characteristics signature and compares it against a golden deVice J ECE UNM 17 9109 HOST Hardware Trojans I ECE 495595 N rLayoutOriented Trojan Detection Strategies Three basic approaches Parametric Anomaly Detection Strategies The golden device signature can be generated from models of the IC using sim ulation experiments The challenge in making this approach effective is accounting for the natural variations that occur between chips that are introduced by Test environment variations eg probe card resistance variations Noise sources eg environmental instrumentationrelated onchip sources Process variations Detection of selectivelyinserted Trojans may be possible by comparing responses among chips Advantages Parametric Anomaly Detection Strategies Nondestructive and much more costeffective than FA methods J ECE UNM 18 9109 HOST Hardware Trojans I ECE 495595 N rLayoutOriented Trojan Detection Strategies Three basic approaches Advantages Parametric Anomaly Detection Strategies Can potentially detect ALL types of Trojans including functional information leakage and reliability Trojans Can be extremely sensitive to small anomalies if the appropriate calibration methods are applied to reduce or eliminate test environment and process varia tions Drawbacks Parametric Anomaly Detection Strategies Automatic test equipment ATE instrumentation may need to be customized to make analog measurements eg transient current and path delay Data collection may be time consuming and storage intensive eg multiple strobes of the capture cycle to measure actual path delays J ECE UNM 19 9109 HOST Hardware Trojans I ECE 495595 N rLayoutOriented Trojan Detection Strategies Three basic approaches Drawbacks Parametric Anomaly Detection Strategies Developing an adequate golden device models may be dif cult Models need to include environmental variations and process variations if chip data is not calibrated Number of false alarms may be large if process variations are not accounted for Validation through deprocessing make false alarms very costly J ECE UNM 20 9109 HOST HOST Overview ECE 495595 r HardwareOriented Security and Trust HOST N Instructor Prof Jim Plusquellic Text No Text is available I ll be developing one during this course We will read papers from the workshop I cofounded httpwwwengruconneduHOST and will draw material from cryptography httpCsewebucsdeduusersmihirCse207Class noteshtml where appropriate Supplementary texts TBD Web httpwwweceunmedujimpHOST J ECE UNM 1 82509 HOST HOST Overview ECE 495595 ECE UNM 2 rCourse Goals N To investigate traditional and emerging security and trust issues in all types of hard ware systems at the chip ASICs COTs and FPGAs board and systemlevel Our trek through hardwareoriented security and trust HOST will include Learning established cryptographic hardware algorithms and their implementation details Learning about existing security primitives for systems such as smartcards elec tronic voting machines communications systems etc and the types of attacks that adversaries engage in to break them Exploring the recent research activity in areas such as hardware Trojans physical unclonable functions PUFs IP security IC metering boardlevel security and hardware support of OS implemented security Investigating security and trust concerns in FPGAs and their applications With the objective to make you aware of hardware system vulnerabilities and to get you to think about ways to incorporate HOST primitives into designs as opposed to adding them as afterthoughts J 82509 HOST HOST Overview ECE 495595 N rlmportant Domain Knowledge It is impossible to study hardware security and trust in isolation In order to obtain a broad knowledge of HOST issues and proposed solutions we will cover material in the following areas Cryptography Methods designed to enable privacy and authenticity in the transmissions between communicating entities FPGA amp VLSI Design Tools and Flows Tools to enable designers to build chips and program FPGAs VLSI Testing Algorithms and techniques to develop tests for ICs to ensure they are defectfree and meet performance constraints Misc Hardware platforms security amp trust paradigms TPM and OS support Formal veri cation and analysis methods Probability and statistics J ECE UNM 3 82509 HOST HOST Overview ECE 495595 rHOST Threats N The number of HOST threats continues to expand Secret key security for hardware implemented cryptography algorithms and other applications that require authentication and privacy There are many types of attacks that have been applied to steal keys including simple power analysis differential power analysis fault injection etc Trust in integrated circuits and FPGAs Threat is the insertion of additional functionality hardware Trojans in chips fabricated in untrusted foundries FPGA fabrics and bitstreams are vulnerable to malicious modi cations IP piracy Challenge is preventing adversaries from stealing and reusing intellectual prop erty soft1P IC piracy Threat is the production of eXtra copies of ICs by an untrusted foundry for sale on the black market J ECE UNM 4 82509 HOST HOST Overview ECE 495595 rPublished HOSTrelated Articles N quotThe Hunt for the Kill Switchquot IEEE Spectrum May 2008 Hardware Trojan threat Anecdotal evidence Compromised microprocessors in Syrian radar system enabled Israeli jets to bomb suspected nuclear installation unhampered Inserted kill switch in a microprocessor used by French defense contractor enables French to disable military equipment that falls into enemy hands quotCounterfeit Chips Raise Big Hacking Terror Threats Experts Sayquot Glenn Derene and Joe Pappalardo Popular Mechanics April 2008 Offshore migration of fabrication facilities makes Chip subversion more likely quotFairy Dust Secrets and the Real Worldquot SW Smith Security and Privacy Cryptography depends on the ability to hide secrets in hardware quotPrinceton Professor Finds No Hardware Security In EVoting Machinequot Antone Gonsalves InformationWeek Feb 2007 Chip swapping is easy in electronic voting machines J ECE UNM 5 82509 HOST HOST Overview ECE 495595 ECE UNM 6 rHOST Research Areas N Techniques are evolving to deal with these threats Trojan detection and localization methods in IP and ICs Physical unclonable functions PUFs derived from the random manufacturing vari ations in an IC to produce an exponential number of unique IDs for the IC Remote chip activation protocols to eliminate IC piracy Design obfuscation methods to increase the dif culty of reverse engineering Insertion of hidden state machines into IC designs using CAD tools to enable remote activation and watermarking of IP CAD tools to enable designers to evaluate their designs for security and trust Trusted companion chips that monitor system states of other ICs on the board to detect excursions from activated Trojans IC design techniques to defeat differential power analysis Scanchain encryption to eliminate reverse engineering of hardware ICs FPGAs bitstream encryptiomdecryption schemes to prevent Trojans and IP stealing Boardlevel antitamper methods to detect chip swapping Hardware security modules to prevent cable TV theft and fraud in electronic voting machines to implement digital rights management for protecting musicvideo media to implement user authentication RFID in smart cards etc J 82509 HWSW Codesign W FPGAs Course Intro ECE 495595 r Hardware Software Codesign with FPGAs N Instructors ECE Jim Plusquellic FMAC Craig Kief and Steve Suddarth Reference Texts There does not appear to be a quotgoodquot teXt for this course Material for this course Will be drawn from Schaumont s lecture notes and the following texts Where appropriate quotHardwareSoftware CoDesign Principles and Practicequot J Staunstrup and W Wolf Kluwer Academic Publishers 1997 ISBN 0792380134 quotCoDesign for System Acceleration A Quantitative Approachquot Nadia Nedjah Luiza de Macedo Mourelle 2007 ISBN 978 1 4020 5545 4 quotEmbedded System Design A Uni ed HardwareSoftware Introductionquot Frank Vahid and Tony Givargis 2002 ISBN 978 0 471 38678 0 Web httpwwweceunmedufacultyjimpcodesign J ECE UNM 1 32409 HWSW Codesign w FPGAs Course Intro ECE 495595 N rIntroduction What is HardwareSoftware codesign According to IEEE DASC Codesign Study Group the term codesign can be de ned as following HWSW Codesign is a design methodology supporting the concurrent develop ment of hardware and software cospeci cation codevelopment and coveri ca tion in order to achieve shared functionality and performance goals for a combined system 39 HW SW Codesign means meeting system level objectives by exploiting the syner gism of hardware and software through their concurrent design Giovanni De Micheli and Rajesh Gupta quotHardwareSoftware Codesignquot IEEE Proceedings vol 85 no3 March 1997 pp 349365 Codesign is the concurrent development of hardware and software Codesign is the cooperative design of hardware and software components Codesign is the uni cation of currently separate hardware and software paths J ECE UNM 2 32409 HW SW Codesign W FPGAs Course Intro ECE 495595 rIntroduction Relevant ConferencesSymposia on Codesign N Conference on Formal Methods and Models for Codesign MEMOCODE CODESISSS The premier conference for SystemLevel Design The CODESISSS Conference is the merger of two major international sympo sia on hardwaresoftware codesign and system synthesis DAC Design Automation Conference ASPDAC Asia South Paci c Design Automation Conference Formal Methods and Models for CoDesign MEMOCODE 2004 CASES International Conference on Compilers Architecture and Synthesis for Embedded Systems ICCAD International Conference on Computer Aided Design ECE UNM 3 J 32409 HWSW Codesign w FPGAs Course Intro ECE 495595 rIntroduction N Research on Codesign was intense in the 90 s Why is this topic important for the new generation of Computer Engineers Progress in VLSImicroelectronics has enabled the integration of microproces sors and recon gurable logic on a single chip Recon gurable systems are exible and are key to meeting timetomarket power size performance exibility and cost constraints The integration of heterogeneous components onto a single chip has made it possible to implement very large complex energy optimized systems Energyef ciency requirements preclude softwareonly approaches Effective use of SystemonChip SoC requires designers to be knowledgeable in both hardware and software domains in order to make good design tradeoffs J ECE UNM 4 32409 HWSW Codesign w FPGAs Course Intro ECE 495595 N rOVCI39VieW Of Codesign Source HardwareSoftware CoDesign G De Micheli et al Proc of IEEE March 1997 Most engineering designs can be viewed as systems Collections of several possibly heterogeneous components whose combined operation provides useful services Most systems today are either electronic in nature information processing systems or contain an electronic subsystem plant control Their implementation are often predominantly digitalbased and are programma ble ie consist of both hardware and software components The evolution of 1C technology has motivated new approaches to digital design Smaller mask geometries leads to higher integration but also higher cost of fab rication requiring higher volumes to amortize the cost of hardware design This motivates the use of software to differentiate products that are based on the same hardware platform K J ECE UNM 5 32409 HWSW Codesign w FPGAs Course Intro ECE 495595 N rOverview 0f Codesign The high complexity of hardware and software motivates reuse Standardizing by using a common core or speci c processor enables the lever aging of software ranging from OS to embedded software These hardware cores and software microkernels have large intellectual property value Their availability drives the expansion of the electronic market and the design of increasingly complex systems The emergence of FPGAs have blurred the distinction between hardware and soft ware Traditionally hardware was con gured at manufacturing time and remained invariant while its functions were exercised under the control of a program As we know it is possible to con gure the gatelevel interconnection of hardware in FPGAs after manufacture This opens up new applications and new hardwaresoftware codesign problems J ECE UNM 6 32409 HWSW Codesign w FPGAs Course Intro ECE 495595 N rOverview 0f Codesign For example one or more FPGAs may be con gured onthe y to implement a spe ci c software function with better performances than a microprocessor Subsequently they can be reprogrammed to perform another speci c function At a high level the capabilities of an FPGA are then indistinguishable from that of a microprocessor At a lower level however the programmer s interface to FPGAs and micropro cessors is very different HWSW Codesign is a complex discipline that builds upon advances in software compilation computer architecture and VLSI circuit design Unfortunately the eld is fragmented and contextdependent because most efforts are applied to speci c design problems J ECE UNM 7 32409 HWSW Codesign W FPGAs Course Intro ECE 495595 rClassi cation of Digital Systems N Codesign Application Domains A digital system may provide a service as a selfcontained unit or as part of a larger system A computer is an example of a selfcontained system and a digital control sys tem for a manufacturing plant an example of an embedded system Embedded means being part of a larger unit and providing a dedicated service to that unit Selfcontained l l Embedded systems Information Transport Plant Processing consumer Control Control Networks Computers Appliances Automobiles Manufacturing Emulators Games Trains Chemical giggnhszne Prototyping HiFi ShipsAircraft Power Gen Lumped Locally distributed Global J ECE UNM 32409 HWSW Codesign W FPGAs Course Intro ECE 495595 rClassi cation of Digital Systems N Degree of Programmability Digital systems can be programmed at different levels Application Highest level Where user speci es parameters to the program e g VCR Instruction Most digital systems use components with an Instruction SetArchitecture ISA e g microcontrollers and DSPs For computers the end users can compile programs to execute on the ISA While for embedded systems the ISA is not visible Hardware This level enables users to con gure the hardware through e g micropro gramming the control unit or through recon guration FPGAs The challenge of recon gurability is to provide an ASIC level of performance While enabling hardware exibility to accommodate changes as is true for microprocessors K J ECE UNM 9 32409 HWSW Codesign W FPGAs Course Intro ECE 495595 rClassi cation of Digital Systems N Implementation Features The choice of hardware technology for the system components affects the over all performance and cost and therefore is of great importance Systemlevel eld programmability can be achieved by Storing programs in readwrite memories Exploiting programmable interconnects Systems can be constructed from Components such as ASIC s processor and memories mounted on a board Or as single chips With embedded ASICs processor cores and memories Advantages of higher integration single chip solutions are increased perfor mance and lower power consumption Disadvantages include higher complexity in debugging Read reference paper quotHardwareSoftware Codesignquot Giovanni De Micheli for discussion next time K J ECE UNM 10 32409 HWSW Codesign W FPGAs Course Intro ECE 495595 Challenges of Codesign To reduce design time Microprocessor Core Core1 Cora cflusm a Core Cluster 3 r v Goals to improving the joint development of hardware and software 0 To reduce the cost of modi cations and evolution 0 To optimize the hardwaresoftware partitioning process Target Architectures of Codesign ECE UNM J 32409 N HWSW Codesign W FPGAs Course Intro ECE 495595 rCodesign Examples N Example SystemonChip SOC with IP cores RF Micro RF2173 Pow Amp Memory Processor RF quotI I39EIIISI e eCtIVe 0 0 Analog Devices monochrome O AD7373 backlit display Screen digitizer Pow Amp c0ntl 1 DSP l Agere Motorola IZRSOINE MC1376YF 39 OM baseband proc Dlg Transcelvers Maxim MAX4472 Hynix HY57V64 1629 SDRAM 8MB Motorola O MC68VZ328 FlJltSll DragonBall Proc MBM29D1323 Flash 4MB Philips PDIUBD12 USB Interface I V V MMCfermat Xilinx Maxim Universal memory XCR306 MAX3386 Connector card slot CPLD Transceivers I Interface Manual in w J ECE UNM 12 32409 HWSW Codesign W FPGAs Course Intro ECE 495595 rCodesign Examples N Video Codec H261 Camera Display A A MCC bus quot Diwf fairnmeif LSDD Eine SW Processors HW Processors J ECE UNM 13 32409 HWSW Codesign W FPGAs Course Intro ECE 495595 rEmbedded Systems W Information processing systems embedded in a larger product Embedded system design challenges 0 Increasing application complexity Mixture of event driven and data ow tasks 0 Increasing target system complexity Mixture of different technologies processor types and design styles Distributed system implementations ECE UNM 14 32409 HWSW Codesign w FPGAs Course Intro ECE 495595 N rDrivers for this Course The increasingly higher levels of integration in VLSI e g SOC has driven design complexity through the roof Design complexity requires extensive and early exploration of Codesign design alternatives and veri cation though simulation and emulation Power consumption is a serious constraint on many modern products e g cell phones PDAs GPS etc Energy ef cient implementations of applications that run on these products requires partitioning of the algorithms into software and dedicated hardware components Signi cantly reduced timetomarket schedules of new products require codevelop ment of both the hardware and software components Also the increase in design cost introduced by complexity and implementation in deep submicron processes drives reuse and programmability Programmability enables one design to serve several platforms and reuse lever ages triedandtrue components both reduce timetomarket J ECE UNM 15 32409 HWSW Codesign w FPGAs Course Intro ECE 495595 fHardware and Software Design N As indicated in the paper quotHardwareSoftware Codesignquot the distinction between hardware and software design is becoming blurred Consider the following modern hardware platforms Programming an FPGA is accomplished using a bitstream Once con gured it carries out operations directly in the hardware so in this sense its hardwired But consider programming the FPGA with a softcore microprocessor once con gured it executes instructions and is completely programmable Digital Signal Processors DSPs is a specialized microprocessor that executes instructions but provides special hardware functions to accelerate certain opera tions An ApplicationSpeci c Instructionset Processor ASIP allows the instruction set itself to be customized based on the application The ASIP contains both static logic that implements a minimum ISA and con gurable logic that can be used to design new instructions J ECE UNM 16 32409 HWSW Codesign w FPGAs Course Intro ECE 495595 N rSystemlevel Design Codesign boils down to choosing an underlying xed architecture that supports a set of exable e g software components that run on top of it Application Informal Speci cation Represents a new application Constraints e g a new way of encoding audio I Choose architecture Implemef tation Alternatives Least A I General purpose processors I Most FPGA I Energy ef ciency I DSPmicrocontroller I Flexibility ASIP I Least Most ASIC I v K J ECE UNM 17 32409 HW SW Codesign W FPGAs Course Intro ECE 495595 ECE UNM 18 rSystemlevel Design N To get from application and architecture requires a sequence of steps that are de ned collectively as design methods Design methods are used to convert a speci cation to an implementation and involve processes such as Algorithm transformations Loop unrolling Pipelining Memory transformations and usage optimizations Transformations from oatingpoint to xedpoint arithmetic Design methods are a prede ned sequence of steps that once learned can be applied to the design of other applications These are important skills that you Will walk away With after taking this course quotDesign is mapping of applications onto architectures by means of design methodsquot H De Man J 32409 HWSW Codesign W FPGAs Course Intro ECE 495595 rEnergy Ef ciency vs Performance Criteria N A major driver to the proliferation in the usage of different implementation technolo gies is energy e ciency Consider the energy ef ciency of an AES algorithm on different platforms source Patrick Schaumont s lecture slides 102 A 1 AES exible on 10 39 39 39 39 39 39 39 39 39 39 39 39 39 39 39 39 39 39 39 39 39 the right 100 101 But energy ef c1ent E 10 2 on the left a U 10393 This data shows Why 10394 GHz Pentiums are 5 not likely to show 10 39 39 39 39 39 39 up in cell phones 10396 018 um Vertex2 Asm C Java CMOS FPGA PentiumIII Sparc KVM Sparc Energy ef ciency is independent of Clk freq and can be applied universally Performance on the other hand is not a big driver because the difference is smaller ECE UNM 19 32409 HWSW Codesign W FPGAs Course Intro ECE 495595 Design Flow N classic design codesign HW SW l HW SW HW SW Fixed Processor Arch SWCompilatio Instruction Set SPeCi cation Application Speci c Arch HWSynthesis Estimation Intellectual Prop Code DSPmicrocontrollerASIP follow both paths ECE UNM Intellectual Prop Block Machine Code C Netlists 20 32409 HW SW Codesign W FPGAs Course Intro ECE 495595 Design Flow Traditional Systemlevel Design Flow Informal Speci cation Constraints Implementation K ECE UNM 21 Disadvantages Lack of systemlevel performance evaluation HWSW spec implemented before performanceenergycost veri cation Long systemlevel design times Expensive performanceenergy cost failures N J 32409 HWSW Codesign W FPGAs Course Intro ECE 495595 N Design Flow Systemlevel HWSW Codesign Informal Speci cation Constraints Component pro ling quotquotquot 39 HWSW implementation I Intensive systemlevel innerloop architecture design and veri cation gt Performance eval H Architecture design I Advantages I HWSW spec implemented in a synergistic manner Systemlevel performanceenergy cost failures caught early Optimized design Implementation K J ECE UNM 22 32409 HWSW Codesign W FPGAs Course Intro ECE 495595 rSystemlevel Design N Systemlevel HWSW Codesign starts With an idea that is expanded into a speci ca tion of functionality and constraints Systemlevel Components gt HWSW Codesign HW SW Interconnect and buses HW behaV1or and components SW behavior RTOS Memory hierarchy SChedule policy and mapping and processors Veri cation performed through simulatior emulation J ECE UNM 23 32409 HW SW Codesign w FPGAs Course Intro ECE 495595 fSystemlevel Design HWSW Components SW processors DSP and microcontrollers HW coprocessors ASICs and FPGAs Storage elements cache SRAM DRAM Interconnection elements Buses and arbiters N Interface and 110 units DMA UART DA AD wireless communications Software platform RTOS and scheduling Systemlevel design is a set of complex synthesis tasks Software synthesis and code generation Hardware synthesis Interface and communication synthesis Hardwaresoftware partitioning and component selection Hardwaresoftware scheduling ECE UNM 24 J 32409 HWSW Codesign w FPGAs Course Intro ECE 495595 f0verview 0f the Course N Major components of the process Application speci cation Design space exploration and system optimization timing power and area EstimatiomPerformance analysis timing power and area Major topics of this course include Models for describing hardware and software components speci cation System design hardwaresoftware partitioning interfaces and design space explo ration Performance analysis and estimation techniques We will cover Challenges and approaches in modern system design Useful optimization methods Performance estimation of distributed systems Compiler techniques Current research K J ECE UNM 25 32409