il
`
`ThesainaDWarriorS
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 1 of 72
`
`

`

`The Design Warrior’s
`Guide to FPGAs
`
`Devices, Tools and Flows
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 2 of 72
`
`

`

`This book belongs to Lee Bernstein
`
`(rachel.girts@haynesboone.com)
`
`Copyright Elsevier 2023
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 3 of 72
`
`

`

`This book belongs to Lee Bernstein (rachel.girts@haynesboone.com)
`
`Copyright Elsevier 2023
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 4 of 72
`
`

`

`The Design Warrior’s
`Guide to FPGAs
`
`Devices, Tools and Flows
`
`Clive “Max” Maxfield
`
`AMSTERDAM• BOSTON • HEIDELBERG • LONDON
`NEW YORK • OXFORD • PARIS • SAN DIEGO
`SAN FRANCISCO • SINGAPORE • SYDNEY • TOKYO
`Newnes is an imprint of Elsevier
`
`Newnes
`
`This book belongs to Lee Bernstein (rachel.girts@haynesboone.com)
`
`Copyright Elsevier 2023
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 5 of 72
`
`

`

`Newnes is an imprint of Elsevier
`
`200 Wheeler Road, Burlington, MA 01803, USA
`
`Linacre House, Jordan Hill, Oxford OX2 8DP, UK
`
`Copyright © 2004, Mentor Graphics Corporation and Xilinx, Inc.
`All rights reserved.
`
`Illustrations by Clive “Max” Maxfield
`
`No part of this publication may be reproduced, stored in a retrieval system, or trans-
`mitted in any form or by any means, electronic, mechanical, photocopying,
`recording, or otherwise, without the prior written permission of the publisher.
`
`Permissions may be sought directly from Elsevier’s Science & Technology Rights
`Department in Oxford, UK: phone: (+44) 1865 843830, fax: (+44) 1865 853333,
`e-mail: permissions@elsevier.com.uk. You may also complete your request on-line
`via the Elsevier homepage (http://elsevier.com), by selecting “Customer Support”
`and then “Obtaining Permissions.”
`
`Recognizing the importance of preserving what has been written, Elsevier prints its
`books on acid-free paper whenever possible.
`
`Library of Congress Cataloging-in-Publication Data
`
`Application submitted
`
`ISBN: 0-7506-7604-3
`
`British Library Cataloguing-in-Publication Data
`
`A catalogue record for this book is available from the British Library.
`
`For information on all Newnes publications
`
`visit our Web site at www.newnespress.com
`
`04 05 06 07 08 09
`
`10 9 8 7 6 5 4 3 2 1
`
`Printed in the United States of America
`
`This book belongs to Lee Bernstein (rachel.girts@haynesboone.com)
`
`Copyright Elsevier 2023
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 6 of 72
`
`

`

`To my wife Gina—the yummy-scrummy caramel, chocolate fudge,
`and rainbow-colored sprinkles on the ice cream sundae of my life
`
`Also, to my stepson Joseph and my grandchildren Willow, Gaige, Keegan, and Karma,
`all of whom will be tickled pink to see their names in a real book!
`
`This book belongs to Lee Bernstein (rachel.girts@haynesboone.com)
`
`Copyright Elsevier 2023
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 7 of 72
`
`

`

`For your delectation and delight, the CD accompanying this book contains a fully-
`searchable copy of The Design Warrior’s Guide to FPGAs in Adobe® Acrobat®
`(PDF) format. You can copy this PDF to your computer so as to be able to access
`The Design Warrior’s Guide to FPGAs as required (this is particularly useful if you
`travel a lot and use a notebook computer).
`
`The CD also contains a set of Microsoft® PowerPoint® files—one for each chapter
`and appendix—containing copies of the illustrations that are festooned throughout
`the book. This will be of particular interest for educators at colleges and universities
`when it comes to giving lectures or creating handouts based on The Design Warrior’s
`Guide to FPGAs
`
`Last but not least, the CD contains a smorgasbord of datasheets, technical articles,
`and useful web links provided by Mentor and Xilinx.
`
`This book belongs to Lee Bernstein (rachel.girts@haynesboone.com)
`
`Copyright Elsevier 2023
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 8 of 72
`
`

`

`Contents
`
`SRAMs, DRAMs, and
`. . . . 28
`microprocessors. . . . .
`SPLDs and CPLDs . . . . . . . . 28
`ASICs (gate arrays, etc.) . . . . . 42
`FPGAs . . . . . . . . . . . . . . 49
`
`Chapter 4
`Alternative FPGA Architectures 57
`A word of warning . . . . .
`. . . 57
`A little background information . 57
`Antifuse versus SRAM
`versus … . . . . . . . . . . . . 59
`Fine-, medium-, and coarse-grained
`architectures . . . . . . . . . . 66
`MUX- versus LUT-based
`logic blocks . . . . . . . . . . . 68
`CLBs versus LABs versus slices. . 73
`Fast carry chains . . . . . . . . . 77
`Embedded RAMs . . . . . . . . . 78
`Embedded multipliers, adders,
`MACs, etc. . . . . . . . . . . . 79
`Embedded processor cores
`(hard and soft) . . . . . . . . . 80
`Clock trees and clock managers . 84
`General-purpose I/O . . . . . . . 89
`Gigabit transceivers
`. . . . . . . 92
`Hard IP, soft IP, and firm IP . . . 93
`System gates versus real gates
`. . 95
`FPGA years . . . . . . . . . . . . 98
`
`Preface . .
`
`. . .
`
`. .
`
`. . .
`
`. .
`
`. . .
`
`ix
`
`Acknowledgments .
`
`.
`
`. .
`
`. .
`
`. .
`
`. . xi
`
`Chapter 1
`Introduction .
`.
`. .
`. .
`. .
`. . 1
`What are FPGAs? . . . . . . . . . 1
`Why are FPGAs of interest? . . . . 1
`What can FPGAs be used for? . . . 4
`What’s in this book? . . . . . . . . 6
`What’s not in this book?. . . . . . 7
`Who’s this book for? . . . . . . . . 8
`
`Chapter 2
`Fundamental Concepts .
`. . .
`. 9
`The key thing about FPGAs. . . . 9
`A simple programmable function . 9
`Fusible link technologies . . . . . 10
`Antifuse technologies . . . . . . 12
`Mask-programmed devices . . . . 14
`PROMs . . . . . . . . . . . . . . 15
`EPROM-based technologies . . . 17
`EEPROM-based technologies . . 19
`FLASH-based technologies
`. . . 20
`SRAM-based technologies . . . . 21
`Summary . . . . . . . . . . . . . 22
`
`Chapter 3
`The Origin of FPGAs . .
`. .
`. . 25
`Related technologies . . . . . . . 25
`Transistors . . . . . . . . . . . . 26
`Integrated circuits . . . . . . . . 27
`
`This book belongs to Lee Bernstein (rachel.girts@haynesboone.com)
`
`Copyright Elsevier 2023
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 9 of 72
`
`

`

`viii ■ The Design Warrior's Guide to FPGAs
`
`Chapter 5
`Programming (Configuring)
`an FPGA . .
`. .
`. .
`. .
`. . .
`. 99
`Weasel words . . . . . . . . . . . 99
`Configuration files, etc.
`. . . . . 99
`Configuration cells . . . . . . . 100
`Antifuse-based FPGAs . . . . . 101
`SRAM-based FPGAs . . . . . . 102
`Using the configuration port . . 105
`Using the JTAG port . . . . . . 111
`Using an embedded processor. . 113
`
`Chapter 6
`Who Are All the Players? . . . 115
`Introduction. . . . . . . . . . . 115
`FPGA and FPAA vendors . . . 115
`FPNA vendors
`. . . . . . . . . 116
`Full-line EDA vendors . . . . . 116
`FPGA-specialist and independent EDA
`vendors . . . . . . . . . . . . 117
`FPGA design consultants with special
`tools . . . . . . . . . . . . . . 118
`Open-source, free, and low-cost design
`tools . . . . . . . . . . . . . . 118
`
`Chapter 7
`FPGA Versus ASIC
`Design Styles .
`. .
`. .
`.
`. . . 121
`Introduction. . . . . . . . . . . 121
`Coding styles . . . . . . . . . . 122
`Pipelining and levels of logic . . 122
`Asynchronous design practices . 126
`Clock considerations . . . . . . 127
`Register and latch considerations129
`Resource sharing (time-division multi-
`plexing) . . . . . . . . . . . . 130
`State machine encoding . . . . 131
`Test methodologies . . . . . . . 131
`
`Chapter 8
`Schematic-Based Design Flows 133
`In the days of yore. . . . . . . . 133
`The early days of EDA . . . . . 134
`A simple (early) schematic-driven
`ASIC flow. . . . . . . . . . . 141
`A simple (early) schematic-driven
`FPGA flow . . . . . . . . . . 143
`Flat versus hierarchical schematics
`. . . . . . . . . . . . . . . . 148
`Schematic-driven FPGA
`design flows today . . . . . . . 151
`
`Chapter 9
`HDL-Based Design Flows . . . 153
`Schematic-based flows
`grind to a halt . . . . . . . . . 153
`The advent of HDL-based flows 153
`Graphical design entry lives on . 161
`A positive plethora of HDLs . . 163
`Points to ponder. . . . . . . . . 172
`
`Chapter 10
`Silicon Virtual Prototyping
`for FPGAs . . .
`. . . .
`. . . 179
`Just what is an SVP?
`. . . . . . 179
`ASIC-based SVP approaches . . 180
`FPGA-based SVPs
`. . . . . . . 187
`
`Chaper 11
`C/C++ etc.–Based Design Flows
`. . . .
`. . . .
`. . . .
`. .
`. . 193
`Problems with traditional
`HDL-based flows . . . . . . . 193
`C versus C++ and concurrent
`versus sequential
`. . . . . . . 196
`SystemC-based flows . . . . . . 198
`Augmented C/C++-based flows 205
`Pure C/C++-based flows . . . . 209
`Different levels of synthesis
`abstraction . . . . . . . . . . 213
`
`This book belongs to Lee Bernstein (rachel.girts@haynesboone.com)
`
`Copyright Elsevier 2023
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 10 of 72
`
`

`

`Mixed-language design and
`verification environments . . 214
`
`Chapter 12
`DSP-Based Design Flows . . . 217
`Introducing DSP . . . . . . . . 217
`Alternative DSP implementations
`. . . . . . . . . . . . . . . . 218
`FPGA-centric design flows
`for DSPs . . . . . . . . . . . . 225
`Mixed DSP and VHDL/
`Verilog etc. environments . . 236
`
`Chapter 13
`Embedded Processor-Based
`Design Flows .
`.
`. .
`. .
`. .
`. 239
`Introduction. . . . . . . . . . . 239
`Hard versus soft cores . . . . . . 241
`Partitioning a design into its
`hardware and software components
`245
`Hardware versus software views
`of the world . . . . . . . . . . 247
`Using an FPGA as its own
`development environment . . 249
`Improving visibility in
`the design . . . . . . . . . . . 250
`A few coverification alternatives 251
`A rather cunning design
`environment . . . . . . . . . 257
`
`Chapter 14
`Modular and Incremental
`Design .
`.
`. .
`. .
`. .
`. . . . 259
`Handling things as one
`big chunk . . . . . . . . . . . 259
`Partitioning things into
`smaller chunks . . . . . . . . 261
`There’s always another way . . . 264
`
`Contents ■ ix
`
`Chapter 15
`High-Speed Design and Other
`PCB Considerations . .
`. . . 267
`Before we start. . . . . . . . . . 267
`We were all so much younger
`then . . . . . . . . . . .
`. . . 267
`The times they are a-changing . 269
`Other things to think about
`. . 272
`
`Chapter 16
`Observing Internal Nodes in
`an FPGA . . . .
`. . . .
`. . . 277
`Lack of visibility. . . . . . . . . 277
`Multiplexing as a solution . . . 278
`Special debugging circuitry . . . 280
`Virtual logic analyzers. . . . . . 280
`VirtualWires
`. . . . . . . . .
`. 282
`
`Chapter 17
`Intellectual Property . .
`.
`. . 287
`Sources of IP .
`. . . . . . . . . 287
`Handcrafted IP . . . . . . . . . 287
`IP core generators . . . . . . . . 290
`Miscellaneous stuff
`. . . . .
`. . 291
`
`Chapter 18
`Migrating ASIC Designs to FPGAs
`and Vice Versa .
`. . .
`. . .
`. 293
`Alternative design scenarios . . 293
`
`Chapter 19
`Simulation, Synthesis, Verification,
`etc. Design Tools . . .
`. .
`. . 299
`Introduction. . . . . . . . . . . 299
`Simulation (cycle-based,
`event-driven, etc.) . . . . . . 299
`Synthesis (logic/HDL versus
`physically aware) . . . . . . . 314
`Timing analysis (static
`. 319
`versus dynamic) . . . . . . .
`Verification in general
`. . . . . 322
`Formal verification . . . . . . . 326
`
`This book belongs to Lee Bernstein (rachel.girts@haynesboone.com)
`
`Copyright Elsevier 2023
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 11 of 72
`
`

`

`x ■ The Design Warrior's Guide to FPGAs
`
`Miscellaneous . . . . . . . . . . 338
`
`Chapter 20
`Choosing the Right Device .
`. 343
`So many choices
`. . . . . . . . 343
`If only there were a tool. . . . . 343
`Technology . . . . . . . . . . . 345
`Basic resources and packaging . 346
`General-purpose I/O interfaces . 347
`Embedded multipliers,
`RAMs, etc.
`. . . . . . . . . . 348
`Embedded processor cores. . . . 348
`Gigabit I/O capabilities . . . . . 349
`IP availability . . . . . . . . . . 349
`Speed grades. . . . . . . . . . . 350
`On a happier note. . . . . . . . 351
`
`Chapter 21
`Gigabit Transceivers . .
`. .
`. 353
`Introduction. . . . . . . . . . . 353
`Differential pairs
`. . . . . . . . 354
`Multiple standards
`. . . . . . . 357
`8-bit/10-bit encoding, etc.
`. . . 358
`Delving into the transceiver
`blocks . . . . . . . . . . . . . 361
`Ganging multiple transceiver
`blocks together . . . . . . . . 362
`Configurable stuff . . . . . . . . 364
`Clock recovery, jitter, and
`eye diagrams. . . . . . . . . . 367
`
`Chaper 22
`Reconfigurable Computing .
`. 373
`Dynamically reconfigurable logic 373
`Dynamically reconfigurable
`interconnect
`. . . . . . . . . 373
`Reconfigurable computing . . . 374
`
`Chapter 23
`Field-Programmable
`Node Arrays .
`. .
`. .
`
`.
`
`. .
`
`. 381
`
`Introduction. . . . . . . . . . . 381
`Algorithmic evaluation . . . . . 383
`picoChip’s picoArray technology 384
`QuickSilver’s ACM technology 388
`It’s silicon, Jim, but not
`as we know it! . . . . . . . . . 395
`
`Chapter 24
`Independent Design Tools . . 397
`Introduction. . . . . . . . . . . 397
`ParaCore Architect . . . . . . . 397
`The Confluence system
`design language . . . . . . . . 401
`Do you have a tool? . . . . . . . 406
`
`Chapter 25
`Creating an Open-Source-Based
`Design Flow . . . .
`. . . .
`. 407
`How to start an FPGA design
`shop for next to nothing . . . 407
`The development platform: Linux
`. . . . . . . . . . . . . . . . 407
`The verification environment . 411
`Formal verification . . . . . . . 413
`Access to common IP components
`. . . . . . . . . . . . . . . . 416
`Synthesis and implementation
`tools . . . . . . . . . . . . . . 417
`FPGA development boards . . . 418
`Miscellaneous stuff
`. . . . . . . 418
`
`Chapter 26
`Future FPGA Developments . 419
`Be afraid, be very afraid . . . . . 419
`Next-generation architectures
`and technologies . . . . . . . 420
`Don’t forget the design tools . . 426
`Expect the unexpected . . . . . 427
`
`Appendix A:
`Signal Integrity 101 . . .
`. . 429
`Before we start. . . . . . . . . . 429
`
`This book belongs to Lee Bernstein (rachel.girts@haynesboone.com)
`
`Copyright Elsevier 2023
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 12 of 72
`
`

`

`Capacitive and inductive coupling
`(crosstalk) . . . . . . . . . . 430
`Chip-level effects . . . . . . . . 431
`Board-level effects. . . . . . . . 438
`
`Appendix B:
`Deep-Submicron Delay Effects 101
`. . . .
`. .
`. .
`. .
`. .
`. .
`. . 443
`Introduction. . . . . . . . . . . 443
`The evolution of delay
`specifications . . . . . . . . . 443
`A potpourri of definitions. . . . 445
`Alternative interconnect models 449
`DSM delay effects . . . . . . . . 452
`Summary . . . . . . . . . . . . 464
`
`Appendix C:
`Linear Feedback Shift
`Registers 101 .
`.
`. .
`. .
`. . 465
`The Ouroboras . . . . . . . . . 465
`Many-to-one implementations . 465
`
`Contents ■ xi
`
`More taps than you know
`what to do with . . . . . . . . 468
`Seeding an LFSR . . . . . . . . 470
`FIFO applications . . . . . . . . 472
`Modifying LFSRs to sequence
`2n values . . . . . . . . .
`. . . 474
`Accessing the previous value . . 475
`Encryption and decryption
`applications . . . . . . . . . . 476
`Cyclic redundancy check
`applications . . . . . . . . . . 477
`Data compression applications . 479
`Built-in self-test applications . . 480
`Pseudorandom-number-generation
`applications . . . . . . . . . . 482
`Last but not least . . . . . . . . 482
`
`Glossary . . .
`
`. . . .
`
`. . . .
`
`. . . 485
`
`About the Author .
`
`. . .
`
`. .
`
`. . . 525
`
`Index . . . .
`
`. . . .
`
`. . . .
`
`. . . 527
`
`This book belongs to Lee Bernstein (rachel.girts@haynesboone.com)
`
`Copyright Elsevier 2023
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 13 of 72
`
`

`

`This book belongs to Lee Bernstein (rachel.girts@haynesboone.com)
`
`Copyright Elsevier 2023
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 14 of 72
`
`

`

`4
`Alternative FPGA Architectures
`
`Chapter
`
`A word of warning
`
`In this chapter we introduce a plethora of architectural fea-
`tures. Certain options—such as using antifuse versus SRAM
`configuration cells—are mutually exclusive. Some FPGA ven-
`dors specialize in one or the other; others may offer multiple
`device families based on these different technologies. (Unless
`otherwise noted, the majority of these discussions assume
`SRAM-based devices.)
`In the case of embedded blocks such as multipliers, adders,
`memory, and microprocessor cores, different vendors offer
`alternative “flavors” of these blocks with different “recipes” of
`ingredients. (Much like different brands of chocolate chip
`cookies featuring larger or smaller chocolate chips, for exam-
`ple, some FPGA families will have bigger/better/badder
`embedded RAM blocks, while others might feature more mul-
`tipliers, or support more I/O standards, or …)
`The problem is that the features supported by each vendor
`and each family change on an almost daily basis. This means
`that once you’ve decided what features you need, you then
`need to do a little research to see which vendor’s offerings cur-
`rently come closest to satisfying your requirements.
`
`A little background information
`
`Before hurling ourselves into the body of this chapter, we
`need to define a couple of concepts to ensure that we’re all
`marching to the same drumbeat. For example, you’re going to
`see the term fabric used throughout this book. In the context of
`
`The word “fabric” comes
`from the Middle English
`fabryke, meaning “some-
`thing constructed.”
`
`This book belongs to Lee Bernstein (rachel.girts@haynesboone.com)
`
`Copyright Elsevier 2023
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 15 of 72
`
`

`

`58 ■ The Design Warrior's Guide to FPGAs
`
`a silicon chip, this refers to the underlying structure of the
`device (sort of like the phrase “the fabric of civilized society”).
`When you first hear someone using “fabric” in this way, it
`might sound a little snooty or pretentious (in fact, some engi-
`neers regard it as nothing more than yet another marketing
`term promoted by ASIC and FPGA vendors to make their
`devices sound more sophisticated than they really are). Truth
`to tell, however, once you get used to it, this is really quite a
`useful word.
`When we talk about the geometry of an IC, we are refer-
`ring to the size of the individual structures constructed on the
`chip—such as the portion of a field-effect transistor (FET)
`known as its channel. These structures are incredibly small. In
`the early to mid-1980s, devices were based on 3 µm geome-
`tries, which means that their smallest structures were 3
`millionths of a meter in size. (In conversation, we would say,
`“This IC is based on a three-micron technology.”)
`Each new geometry is referred to as a technology node. By
`the 1990s, devices based on 1 µm geometries were starting to
`appear, and feature sizes continued to plummet throughout
`the course of the decade. As we moved into the twenty-first
`century, high-performance ICs had geometries as small as 0.18
`µm. By 2002, this had shrunk to 0.13 µm, and by 2003,
`devices at 0.09 µm were starting to appear.
`Any geometry smaller than around 0.5 µm is referred to as
`deep submicron (DSM). At some point that is not well defined
`(or that has multiple definitions depending on whom one is
`talking to), we move into the ultradeep submicron (UDSM)
`realm.
`Things started to become a little awkward once geometries
`dropped below 1 µm, not the least because it’s a pain to keep
`having to say things like “zero point one three microns.” For
`this reason, when conversing it’s becoming common to talk in
`terms of nano, where one nano (short for nanometer) equates
`to a thousandth of a micron—that is, one thousandth of a
`millionth of a meter. Thus, instead of mumbling, “point zero
`nine microns” (0.09 µm), one can simply proclaim, “ninety
`
`The “µ” symbol stands for
`“micro” from the Greek
`micros, meaning “small”
`(hence the use of “µP” as
`an abbreviation for micro-
`processor.”)
`
`In the metric system, “µ”
`stands for “one millionth
`part of,” so 1 µm repre-
`sents “one millionth of a
`meter.”
`
`DSM is pronounced
`by spelling it out as
`“D-S-M.”
`
`UDSM is pronounced
`by spelling it out as
`“U-D-S-M.”
`
`This book belongs to Lee Bernstein (rachel.girts@haynesboone.com)
`
`Copyright Elsevier 2023
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 16 of 72
`
`

`

`Alternative FPGA Architectures ■ 59
`
`nano” (90 nano) and have done with it. Of course, these both
`mean exactly the same thing, but if you feel moved to regale
`your friends on these topics, it’s best to use the vernacular of
`the day and present yourself as hip and trendy rather than as
`an old fuddy-duddy from the last millennium.
`
`Antifuse versus SRAM versus …
`
`SRAM-based devices
`The majority of FPGAs are based on the use of SRAM
`configuration cells, which means that they can be configured
`over and over again. The main advantages of this technique
`are that new design ideas can be quickly implemented and
`tested, while evolving standards and protocols can be accom-
`modated relatively easily. Furthermore, when the system is first
`powered up, the FPGA can initially be programmed to perform
`one function such as a self-test or board/system test, and it can
`then be reprogrammed to perform its main task.
`Another big advantage of the SRAM-based approach is
`that these devices are at the forefront of technology. FPGA
`vendors can leverage the fact that many other companies spe-
`cializing in memory devices expend tremendous resources on
`research and development (R&D) in this area. Furthermore, the
`SRAM cells are created using exactly the same CMOS tech-
`nologies as the rest of the device, so no special processing steps
`are required in order to create these components.
`In the past, memory devices were often used to qualify the
`manufacturing processes associated with a new technology
`node. More recently, the mixture of size, complexity, and regu-
`larity associated with the latest FPGA generations has resulted
`in these devices being used for this task. One advantage of
`using FPGAs over memory devices to qualify the manufactur-
`ing process is that, if there’s a defect, the structure of FPGAs is
`such that it’s easier to identify and locate the problem (that is,
`figure out what and where it is). For example, when IBM and
`UMC were rolling out their 0.09 µm (90 nano) processes,
`
`R&D is pronounced by
`spelling it out as
`“R-and-D.”
`
`This book belongs to Lee Bernstein (rachel.girts@haynesboone.com)
`
`Copyright Elsevier 2023
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 17 of 72
`
`

`

`60 ■ The Design Warrior's Guide to FPGAs
`
`IP is pronounced by spell-
`ing it out as “I-P.”
`
`FPGAs from Xilinx were the first devices to race out of the
`starting gate.
`Unfortunately, there’s no such thing as a free lunch. One
`downside of SRAM-based devices is that they have to be
`reconfigured every time the system is powered up. This either
`requires the use of a special external memory device (which
`has an associated cost and consumes real estate on the board)
`or of an on-board microprocessor (or some variation of these
`techniques—see also chapter 5).
`
`Security issues and solutions with SRAM-based
`devices
`Another consideration with regard to SRAM-based
`devices is that it can be difficult to protect your intellectual
`property, or IP, in the form of your design. This is because the
`configuration file used to program the device is stored in some
`form of external memory.
`Currently, there are no commercially available tools that
`will read the contents of a configuration file and generate a
`corresponding schematic or netlist representation. Having
`said this, understanding and extracting the logic from the
`configuration file, while not a trivial task, would not be
`beyond the bounds of possibility given the combination of
`clever folks and computing horsepower available today.
`Let’s not forget that there are reverse-engineering compa-
`nies all over the world specializing in the recovery of “design
`IP.” And there are also a number of countries whose govern-
`ments turn a blind eye to IP theft so long as the money keeps
`rolling in (you know who you are). So if a design is a high-
`profit item, you can bet that there are folks out there who are
`ready and eager to replicate it while you’re not looking.
`In reality, the real issue here is not related to someone
`stealing your IP by reverse-engineering the contents of the
`configuration file, but rather their ability to clone your design,
`irrespective of whether they understand how it performs its
`magic. Using readily available technology, it is relatively easy
`
`This book belongs to Lee Bernstein (rachel.girts@haynesboone.com)
`
`Copyright Elsevier 2023
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 18 of 72
`
`

`

`Alternative FPGA Architectures ■ 61
`
`JTAG is pronounced
`“J-TAG”; that is, by spell-
`ing out the ‘J’ followed
`by “tag” to rhyme with
`“bag.”
`
`for someone to take a circuit board, put it on a “bed of nails”
`tester, and quickly extract a complete netlist for the board.
`This netlist can subsequently be used to reproduce the board.
`Now the only task remaining for the nefarious scoundrels is to
`copy your FPGA configuration file from its boot PROM (or
`EPROM, E2PROM, or whatever), and they have a duplicate of
`the entire design.
`On the bright side, some of today’s SRAM-based FPGAs
`support the concept of bitstream encryption. In this case, the
`final configuration data is encrypted before being stored in the
`external memory device. The encryption key itself is loaded
`into a special SRAM-based register in the FPGA via its JTAG
`port (see also Chapter 5). In conjunction with some associated
`logic, this key allows the incoming encrypted configuration
`bitstream to be decrypted as it’s being loaded into the device.
`The command/process of loading an encrypted bitstream
`automatically disables the FPGA’s read-back capability. This
`means that you will typically use unencrypted configuration
`data during development (where you need to use read-back)
`and then start to use encrypted data when you move into pro-
`duction. (You can load an unencrypted bitstream at any time,
`so you can easily load a test configuration and then reload the
`encrypted version.)
`The main downside to this scheme is that you require a
`battery backup on the circuit board to maintain the contents
`of the encryption key register in the FPGA when power is
`removed from the system. This battery will have a lifetime of
`years or decades because it need only maintain a single register
`in the device, but it does add to the size, weight, complexity,
`and cost of the board.
`
`Antifuse-based devices
`Unlike SRAM-based devices, which are programmed while
`resident in the system, antifuse-based devices are programmed
`off-line using a special device programmer.
`The proponents of antifuse-based FPGAs are proud to
`point to an assortment of (not-insignificant) advantages. First
`
`This book belongs to Lee Bernstein (rachel.girts@haynesboone.com)
`
`Copyright Elsevier 2023
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 19 of 72
`
`

`

`62 ■ The Design Warrior's Guide to FPGAs
`
`Radiation can come in
`the form of gamma rays
`(very high-energy pho-
`tons), beta particles
`(high-energy electrons),
`and alpha particles.
`
`It should be noted that
`rad-hard devices are not
`limited to antifuse tech-
`nologies. Other
`components, such as
`those based on SRAM
`architectures, are avail-
`able with special
`rad-hard packaging and
`triple redundancy
`design.
`
`of all, these devices are nonvolatile (their configuration data
`remains when the system is powered down), which means that
`they are immediately available as soon as power is applied to
`the system. Following from their nonvolatility, these devices
`don’t require an external memory chip to store their configu-
`ration data, which saves the cost of an additional component
`and also saves real estate on the board.
`One noteworthy advantage of antifuse-based FPGAs is the
`fact that their interconnect structure is naturally “rad hard,”
`which means they are relatively immune to the effects of
`radiation. This is of particular interest in the case of military
`and aerospace applications because the state of a configura-
`tion cell in an SRAM-based component can be “flipped” if
`that cell is hit by radiation (of which there is a lot in space).
`By comparison, once an antifuse has been programmed, it
`cannot be altered in this way. Having said this, it should also
`be noted that any flip-flops in these devices remain sensitive
`to radiation, so chips intended for radiation-intensive envi-
`ronments must have their flip-flops protected by triple
`redundancy design. This refers to having three copies of each
`register and taking a majority vote (ideally all three registers
`will contain identical values, but if one has been “flipped”
`such that two registers say 0 and the third says 1, then the 0s
`have it, or vice versa if two registers say 1 and the third
`says 0).
`But perhaps the most significant advantage of antifuse-
`based FPGAs is that their configuration data is buried deep
`inside them. By default, it is possible for the device program-
`mer to read this data out because this is actually how the
`programmer works. As each antifuse is being processed, the
`device programmer keeps on testing it to determine when that
`element has been fully programmed; then it moves onto the
`next antifuse. Furthermore, the device programmer can be
`used to automatically verify that the configuration was per-
`formed successfully (this is well worth doing when you’re
`talking about devices containing 50 million plus programma-
`ble elements). In order to do this, the device programmer
`
`This book belongs to Lee Bernstein (rachel.girts@haynesboone.com)
`
`Copyright Elsevier 2023
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 20 of 72
`
`

`

`Alternative FPGA Architectures ■ 63
`
`requires the ability to read the actual states of the antifuses and
`compare them to the required states defined in the configura-
`tion file.
`Once the device has been programmed, however, it is pos-
`sible to set (grow) a special security antifuse that subsequently
`prevents any programming data (in the form of the presence or
`absence of antifuses) from being read out of the device. Even if
`the device is decapped (its top is removed), programmed and
`unprogrammed antifuses appear to be identical, and the fact
`that all of the antifuses are buried in the internal metallization
`layers makes it almost impossible to reverse-engineer the
`design.
`Vendors of antifuse-based FPGAs may also tout a couple of
`other advantages relating to power consumption and speed,
`but if you aren’t careful this can be a case of the quickness of
`the hand deceiving the eye. For example, they might tease you
`with the fact that an antifuse-based device consumes only 20
`percent (approximately) of the standby power of an equivalent
`SRAM-based component, that their operational power con-
`sumption is also significantly lower, and that their
`interconnect-related delays are smaller. Also, they might casu-
`ally mention that an antifuse is much smaller and thus
`occupies much less real estate on the chip than an equivalent
`SRAM cell (although they may neglect to mention that anti-
`fuse devices also require extra programming circuitry,
`including a large, hairy programming transistor for each anti-
`fuse). They will follow this by noting that when you have a
`device containing tens of millions of configuration elements,
`using antifuses means that the rest of the logic can be much
`closer together. This serves to reduce the interconnect delays,
`thereby making these devices faster than their SRAM cousins.
`And both of the above points would be true … if one were
`comparing two devices implemented at the same technology
`node. But therein lies the rub, because antifuse technology
`requires the use of around three additional process steps after
`the main manufacturing process has been qualified. For this
`(and related) reasons, antifuse devices are always at least
`
`It’s worth noting that
`when the MRAM tech-
`nologies introduced in
`Chapter 2 come to frui-
`tion, these may well
`change the FPGA
`landscape.
`
`This is because MRAM
`fuses would be much
`smaller than SRAM cells
`(thereby increasing com-
`ponent density and
`reducing track delays),
`and they would also con-
`sume much less power.
`
`Furthermore,
`MRAM-based devices
`could be prepro-
`grammed like
`antifuse-based devices
`(great for security) and
`reprogrammed like
`SRAM-based components
`(good for prototyping).
`
`This book belongs to Lee Bernstein (rachel.girts@haynesboone.com)
`
`Copyright Elsevier 2023
`
`Ex. 1028
`CISCO SYSTEMS, INC. / Page 21 of 72
`
`

`

`64 ■ The Design Warrior's Guide to FPGAs
`
`1821: England.
`Michael Faraday invents
`the first electric motor.
`
`one—and usually several—generations (technology nodes)
`behind SRAM-based components, which effectively wipes out
`any speed or power consumption advantages that might other-
`wise be of interest.
`Of course, the main disadvantage associated with
`antifuse-based devices is that they are OTP, so once you’ve
`programmed one of these little scallywags, its function is set in
`stone. This makes these components a poor choice for use in a
`development or prototyping environment.
`
`EPROM-based devices
`This section is short and sweet because no one currently
`makes—or has plans to make—EPROM-based FPGAs.
`
`E2PROM/FLASH-based devices
`E2PROM- or FLASH-based FPGAs are similar to their
`SRAM counterparts in that their configuration cells are con-
`nected together in a long shift-register-style chain. These
`devices can be configured off-line using a device programmer.
`Alternatively, some versions are in-system programmable, or
`ISP, but their programming time is about three times that of
`an SRAM-based component.
`Once programmed, the data they contain is nonvolatile,
`so these devices would be “inst