Designus Maximus Unleashed!

Designus Maximus Unleashed! (Unabridged & Unexpurgated) By Clive "Max" Maxfield Newnes Boston Oxford Johannesburg Me...

Author: Clive Maxfield

47 downloads 1042 Views 32MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Designus Maximus Unleashed! (Unabridged & Unexpurgated)

By Clive "Max" Maxfield

Newnes Boston Oxford

Johannesburg Melbourne

New Dehli

Singapore

Newnes is an imprint of Butterworth-Heinemann. Copyright 9 1998 by Butterworth-Heinemann -@

A member of the Reed Elsevier group

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, or otherwise, without the prior written permission of the publisher.

|

Recognizing the importance of preserving what has been written, ButterworthHeinemann prints its books on acid-free paper whenever possible. Butterworth-Heinemann supports the efforts of American Forests and the Global ReLeaf program in its campaign for the betterment of trees, forests, and our environment. ISBN: 0-7506-9089-5 With regards to the book: All of the technical illustrations were created by Clive "Max" Maxfield. The caricatures in Chapter 26 are copyright Maxfield & Montrose Interactive Inc., Madison, AL. With regards to the CD-ROM: The Beboputer Virtual Computer is copyright Maxfield & Montrose Interactive Inc., Madison, AL, USA (http://ro.com/maxmon). The BOOL Logic Synthesizer is copyright Alon Kfir, CA, USA. The MMLogic MultiMedia Logic Design System is copyright Softronics Inc., Northboro, MA, USA (www.softronix.com). The Analog Magic demo and all related files and datasheets are copyright IMP, Inc., San Jose, CA, USA (www.impweb.com).

The publisher offers special discounts on bulk orders of this book. For information, please contact: Manager of Special Sales Butterworth-Heinemann 225 Wildwood Avenue Wobum, MA 01801-2041 Tel: 781-904-2500 Fax: 781-904-2620 For information on all Newnes electronics publications available, contact our World Wide Web home page at: http://www.bh.com 1098765432

1

Printed in the United States of America

To my "little" brother Andrew James, one of the genuinely nice people who make the world a better place for the rest of us.

iv

Designus Maximus Unleashed!

flbout the

luthor

Clive " M a x " Maxfield is 6'1" tall, outrageously handsome, English and proud of it. In addition to being a hero, trend setter, and leader of fashion, he is widely regarded as an expert in all aspects of electronics (at least by his mother). After receiving his B.Sc. in Control Engineering in 1980 from Sheffield Polytechnic (now Sheffield Hallam University), England, Max began his career as a designer of central processing units for mainframe computers. To cut a long stow short, Max now finds himself a Member of the Technical Staff (MTS) at Intergraph Computer Systems, Huntsville, Alabama, USA, where he gets to play with their high-performance 3D graphics workstations. In his s p a r e t i m e (Ha[), Max is a contributing editor to Electronic Design News (EDN) magazine and a member of the advisory board to the Computer History Association of California (CHAC). In addition to numerous technical articles and papers appearing in magazines and at conferences around the world, Max is also the author of the outstandingly successful Bebop to the Boolean Boogie (An Unconventional Guide to Electronics), and the co-author of Bebop

BYTES Back (An Unconventional Guide to Computers). O n t h e off-chance that you're still not impressed, Max was once referred to as an "industry notable" and a "semiconductor design expert" by someone famous who wasn't prompted, coerced, or remunerated in any way!

cknowledgment$

Introduction

Just before we leap into the fray, I would like to take a few moments to thank my staunch friend and good companion Alvin for his help, support, and encouragement in this project, and I'd like to thank Alvin's wife Sue for letting him come round to play at my house, l'd also like to thank Sue for her many kindnesses (including, but not limited to, punishing her kids by making them weed my garden whilst I sat chained to the computer). Thanks also go to my ex-wife Steph for the long hours she spent proof-reading the final manuscript (any remaining errors are mine own). While a large part of this book is devoted to my musings on miscellaneous topics, a key element is the accompanying CD-ROM, whose contents I hope you'll enjoy experimenting with for years to come. So my grateful appreciation goes to Maxfield & Montrose Interactive Inc., Madison, AL, USA (http://ro.com/maxmon) for letting me present a demo copy of the BeboputerTM Virtual Computer, Alon Kfir, CA, USA, for allowing me to showcase his BOOL Logic Synthesizer; George Mills of Softronics Inc., Northboto, MA, USA (www.softronix.com) for allowing me to feature his MMLogic MultiMedia Logic Design System; and Dave Gillooly of IMP, Inc., San Jose, CA, USA (www.impweb.com) for providing the material on Analog Magic and related datasheets. Many of the topics presented in this book have previously appeared in a condensed and edited form as magazine articles, so l'd like to thank the following magazines for allowing me to reprint these articles in their original form: Electronic Design News (EDN) magazine (www.ednmag.com), Electronic Design (ED) magazine (www.penton.com/ed), and Electronic Design & Technology Network (EDTN) magazine (www.edtn.com). Last but certainly not least, my thanks to HighText Publications, Solana Beach, CA (www.hightext-publications.com) and to Doone Publications, Madison, AL (www.doone.com) for kindly permitting me to abstract and expand on certain topics from my earlier works.

V

vi


(

ontents

Section 1" Capriciously Cunning Software Chapter 1: Who was that Masked Man? ....................................................................................... 3 Chapter 2: The

BeboputerTM Virtual

Computer ................................................................ 15

Chapter 3: B O O L Logic Synthesis .................................................................................................. 27

Chapter 4: MMLogic Multimedia Logic Design System ........................................... 33

Section 2- Design Capture, Synthesis, and Simulation Chapter 5: Capturing and Synthesizing a Design ............................................................ 39 Chapter 6: Digital Logic Simulation ................................................................................................ 57 Chapter 7: Static and Dynamic Timing Analysis .............................................................. 73 Chapter 8: Digital Fault Simulation ................................................................................................. 85 Chapter 9: Digital Simulation Logic Value Systems ...................................................... 97 Chapter 10: Unknown X Values ...................................................................................................... 107 Chapter 11: Analog and Mixed-Signal Simulation ....................................................... 119

Section 3: Binary Arithmetic Chapter 12: A minus B = A + NOT(B) + 1 ......................................................................... 135 Chapter 13: Binary Multiplication .................................................................................................. 155 Chapter 14: Binary Division ................................................................................................................. 167

Section 4: Design Musings Chapter 15: State Machines ................................................................................................................. 183

Chapter 16: Asynchronous Design ............................................................................................... 199 Chapter 17: Linear Feedback Shift Registers .................................................................... 219 Chapter 18: Designing a Three-Phase Clock .................................................................... 233 Chapter 19: Field Programmable Devices ........................................................................... 245 Chapter 20: Library of Parameterized Modules ............................................................. 275

Introduction

Section 5: Miscellaneous Musings Chapter 21: Reconfigurable Logic ................................................................................................287 Chapter 22: Genetic Algorithms ......................................................................................................297 Chapter 23: Reed MUller Logic .........................................................................................................307 Chapter 24: Testing RAMs and ROMs ......................................................................................317 Chapter 25: Deep Submicron Delay Effects ......................................................................331 Chapter 26: Logic Diagrams and Machines ........................................................................353 Chapter 27: Transistors of the Future ........................................................................................361 Chapter 28: Protein-Based Switches and Nanotechnology .............................. 371 Chapter 29: Interrupts and Interrupt Handling ............................................................... 381 Chapter 30: A Letter from America .............................................................................................401

Appendix A: Installing your B e b o p u t e r .............................................................................417 Appendix B: B e b o p u t e r Addressing Modes and Instruction Set ....... 421 Index ............................................................................................................................................................................... 429

vii

viii

Designus Maximus Unleashed! The EDN Series for Design Engineers A. Kularatna Power Electronics Design Handbook: Low-Power Components and Applications EDN Design Ideas (CD-ROM) C. Sehroeder Printed Circuit Board Design Using AutoCAD J. Lenk Simplified Design of Voltage-Frequency Converters J. Lenk Simplified Design of Data Converters F. Imdad-Haque Inside PC Card: CardBus and PCMCIA Design C. Schroeder Inside OrCAD J. Lenk Simplified Design of lC Amplifiers J. Lenk Simplified Design of Micropower and Battery Circuits J. Williams The Art and Science of Analog Circuit Design J. Lenk Simplified Design of Switching Power Supplies V. Lakshminarayanan Electronic Circuit Design Ideas J. Lenk Simplified Design of Linear Power Supplies M. Brown Power Supply Cookbook B. Travis and I Hickman EDN Designer's Companion J. Dostal Operational Amplifiers, Second Edition T. Williams Circuit Designer's Companion R. Marston Electronic Circuits Pocket Book: Passive and Discrete Circuits (Vol. 2) N. Dye and H. Granberg Radio Frequency Transistors: Principles and Practical Applications Gates Energy Products Rechargeable Batteries: Applications Handbook T. Williams EMC for Product Designers J. Williams Analog Circuit Design: Art, Science, and Personalities R. Pease Troubleshooting Analog Circuits I. Hickman Electronic Circuits, Systems and Standards R. Marston Electronic Circuits Pocket Book: Linear ICs (Vol. 1) R. Marston Integrated Circuit and Waveform Generator Handbook I. Sinclair Passive Components: A User's Guide

This Page Intentionally Left Blank

Chapter 1:

Who was that Masked Man? "And now m y friends, the show that never ends, In this chapter you will discover: It's a Funny O l d World ........................................................................................................................4 It all S e e m e d Rather Pointless Really ....................................................................... 4 B e w a r e t h e J a b e r w o c k m y Son ....................................................................................... 5 I n t e r n a t i o n a l C o m p u t e r s : Shifters/Rotators ................................................... 6 Cirrus Designs: Test a n d Simulation .............................................................................. 8 I n t e r g r a p h C o r p o r a t i o n ' EDA a n d B a c k t o C o m p u t e r s ..... 10 Articles, C o n f e r e n c e s , a n d Books ............................................................................. 11 So Here We Are ..........................................................................................................................................14

4

DesignusMaximusUnleashed! ~t's a 3unng Old World It really is a funny old world when you come to think about it. Deep in the mists of time when I was but a junior engineer, I occasionally thought that it would be really cool to write technical articles and have them published in electronics magazines. Only two things stood in my way: a) I didn't know anything worth writing about. b) Magazines weren't interested in me because I hadn't written anything before. Over the years l've come to realize that point (a) doesn't necessarily hold you back as much as one might think, but point (b) is certainly something of a show-stopper. As time passed I began to have the odd article published (and some of them were really odd), until one day it appeared as though l'd crossed some undocumented article-producing threshold known only to magazine editors. Instead of being obliged to grovel with editors to have an article published, I suddenly found myself having to beat them off with a stick. Now they call me pleading for an article on "xyz," and happily ignore any protestations on my part that I know nothing whatsoever about the subject in hand. Why should this be? I don't know. That's just the way it is.

~ t a l l S e e m e d I ~ a t h e r P o i n t l e s s i~eallg When I started the English equivalent of High School at the tender age of 11 (Abbydale Grange Grammar School, Millhouses, Sheffield, England, on the off-chance anyone is interested) I wasn't very good at English football (what the Americans would call soccer). In addition to my seeming to have two left feet, no one ever bothered to explain the rules to me. So whenever I actually gained comrfland of the ball, the referee would shout something like "You're offside you dingbat," and then they took the ball away from me again. It all seemed rather pointless really. On the bright side, one of my friends (who also didn't like football) was really rather clever. Even for a precocious 11-year old, Carl Clements, I~l for that was his name, knew an awful lot about electronics So while our compatriots were making life miserable for the old pig's bladder, Carl would be explaining how to make an audio amplifier using just one transistor (not a high-fidelity unit you understand), describing the role of the bias voltage and drawing circuit diagrams in the playground dust.

ICarl, long time no see. If you happen to read this, drop me an email at [email protected].

Chapter I CapriciouslyCunningSoftware The years rolled by and we moved on to more esoteric topics such as bio-feedback. By the age of 14 we were huddled in our corner of the playground designing brainwave amplifiers that could filter out alpha waves, amplify them, and feed them back into headphones as pink-noise. 121Sad to relate, these devices never actually worked. The theory was sound, but we didn't have any test equipment (in fact we didn't have much more than a soldering iron between us) and we didn't have any training in testing circuits and resolving faults. Still later we migrated into simple digital logic and then progressed to creating rudimentary robots that rolled around the house and plugged themselves into power outlets (on occasion they even managed to do this without vaporizing every fuse in the house). Looking back I guess all of this might seem pretty weird. If I were to observe two 11-year olds of today sketching circuit diagrams in the playground while their friends played games, l'd probably pause to ponder what cruel quirk of fate had dealt them such a pathetic existence. But we actually had a great deal of "fun in the sun," and it all seemed perfectly normal at the time.

~eware

the ~aberwock

my Son

In my last year at High School I was s u m m o n e d into the august presence of the Careers Officer, who loomed over the top of his desk and spake unto me thusly: "Do you have the faintest clue what y o u want to be w h e n y o u grow up y o u sniveling little toad?" (Truth to tell, this master of the polyester fashion statement didn't actually voice the words "you sniveling little toad," but it was certainly implied in his sneer and his demeanor.)I31 When I replied: "I'm going to be an electronics engineer," he responded with the following carefully considered gems of advice, which I still treasure to this day: "Good .... y o u can go n o w .... s e n d in the next o n e on your way out." And so it was that I meandered my way into the electronics course at Sheffield Polytechnic (Now Sheffield Hallam University). I hated it. We seemed to spend an inordinate amount of time calculating the angular m o m e n t u m of electrons and listening to lecturers spout forth on similar apparently meaningless drivel. Not that I have anything against electrons having angular m o m e n t u m you understand, or even that I particularly dislike calculating what it is. But once you've calculated one electron's angular m o m e n t u m you've done the lot as far as l'm concerned, so this sort of thing became somewhat tiresome after the third week. 2"Pink Noise" is sort of like "White Noise," but it's a bit more colorful (pun intended). For example, the sound of falling rain might be equated to white noise, while the "churl ... churl ... chuff' of an old fashioned steam train would be a form of pink noise. 3One gets to be more charitable over the years .... perhaps his surly disposition was caused by his underwear riding up or some similar such happenstance.

5

6

DesignusMaximusUnleashed! Knowing that there are a lot of electrons in the universe, 141and with a growing certainty that I would be required to calculate the angular momentum for each and every one of them, I began to desperately search for a way out. After a little rooting around I was amazed to discover that the "Electrical & Electronics" course was one of the last places you wanted to be if you actually wanted to build electronic devices and (dare we say it) have a bit of fun during the process. So after my first year I transferred to a 4-year degree course in Control Engineering, which turned out to be just what I'd wanted to do all along. The Control Engineering course was based on a core of mathematics and control theory, with surrounding subjects in electronics, mechanics, and hydraulics and fluids. The entire course was geared up to building things and controlling them, from factory systems to robots to fly-by-wire aircraft. Also, along the way we were introduced to computers. Of course, in those days we wrote programs in the FORTRAN language (ugggg, arrggghhh), entered them on punched cards, walked through wind, rain, and sleet to the computer building, waited a week to get the results (which were invariably along the lines of "Syntax error on line 2, missing comma."), and then started the whole process again. In fact when you finally got a program to work, you usually couldn't remember what had prompted you to write it in the first place!

~nternational

eomputer$: Shiftersll~otators

After graduating with a B.Sc. in Control Engineering in the Summer of 1980, my first position ("Look Morn, a real job!") was with International Computers Limited (ICL) in Manchester, England. At that time ICL made honking big mainframe computers (they probably still do as far as I know), and I was hired as a member of one of their Central Processing Unit (CPU) design teams. It didn't take me long to discover that little of what l'd studied at college had much bearing on my new job. Isl I also quickly realized that subjects which had appeared easy in the classroom (when the lecturer was doing the bulk of the work) were somewhat trickier when you had to do them in earnest. Fortunately, ICL had a really good policy whereby junior woodchucks like myself were partnered with more experienced team leaders. I was lucky in this regard to be assigned to one Dave Potts, who taught me far more than l'm sure he ever realized. Working under Dave was somewhat frustrating, however, in that he would never answer even the simplest question directly; for example: 4Unless there's only one electron that moves around jolly quickly and pops in and out of existence hither and thither, as was once postulated by the legendary physicist Richard Feynman. 5To be fair, almost everything I learned at college has subsequently come in handy at one time or another.

Chapter I Capriciously Cunning Software

Max:

Hey Dave, what time is it?

Dave: Where is the sun in the sky, which way is the wind blowing, what side of the tree does the moss grow, how ......

To cut a long story short, Dave's policy was to lead you through a series of questions, thereby guiding you to discover the answers to life, the universe, and everything for yourself. In many ways this proved to be a superb learning experience (but you quickly learned not to ask Dave for the time). My first task at ICL was to design a 128-bit barrel shifter and rotator; that is, a unit that could shift or rotate the contents of a 128-bit bus by any amount from 1 to 128 bits in a single clock cycle. Dave informed me that the project called for this unit to be implemented using eight Application-Specific Integrated Circuits (ASICs), each of which would handle a 16-bit chunk of the data bus. Furthermore, all of the ASICs were to be functionally identical in order to keep the project within budget. Initially my task didn't appear to be particularly strenuous. The only tricky details involved inserting the appropriate values into the most- and least-significant bits for right and left shifts, respectively (and handling logical versus arithmetic shifts of course). The solution was to employ two of the pins on each ASIC to act as a device ID; that is, these two pins could be presented with one of four binary patterns (OO, O1, 10, and 11), thereby instructing the device as to its position in the chain. For example, the six devices forming the middle of the chain could have these two pins driven to OO, the device on the left-hand end of the chain could have its pins driven to O1, and the device on the right could be driven to 10. When l'd completed this part of the exercise, Dave deigned to inform me that he'd neglected one slight detail, which was that in addition to shifting all 128 bits, the shifter/rotator also had to be capable of shifting only the least-significant 64 bits or the least-significant 32 bits. OK, my task had just become a tad trickier, but it still wasn't all that bad and a few days later I returned with my latest offering. "Ah, Fla!" said Dave, "now we're getting there, but in addition to binary

shifts, this device also has to be able to handle Binary-Coded Decimal (BCD) data!" And so it went. Every time I finished a problem another feature would be added to my portion of the project. In reality, of course, the specification already contained all of these details, but if l'd been presented with the full requirements on my first day, my brains would have leaked out of my ears and I would have been reduced to a gibbering wreak. These days engineers have access to some very sophisticated tools, such as schematic capture (Chapter 5), logic simulation (Chapter 6), timing analysis (Chapter 7), and so forth. But in those days of yore, the best one could hope for

7

8


was a good data book, a sharp pencil, a lot of paper, and a pocket calculator (if you were lucky). The project specifications called for a certain clock frequency, from which one could derive the maximum permitted delays across my devices. My next task was to calculate the input-to-output delays by hand, then juggle the logic gates inside the device until l'd achieved my target. Last but not least, each device could only accommodate a certain number of logic gates and registers, and I was dreadfully over budget. Unfortunately, we didn't have access to anything like today's logic synthesis technology (Chapters 3 & 5), but we had something far better! One of the members of our team was a 30-year old Chinese engineer, whose forte was logic minimization and optimization, l'm sad to say that I no longer remember the lad's name, but this guy was incredible ~ a grand master of logic ~ and I'd put him up against today's automatic tools without any hesitation at all.

e i r r u s Designs: ~ e s t a n d Simulation My mother was delighted when I was accepted by ICL, because she could see a steady progression through the corporate hierarchy, yay even unto the highest pinnacles of power (my mother had remarkably good eyesight in those days). So you can only imagine her surprise and delight when, after just one year, I departed ICL to join a start-up company called Cirrus Designs. Upon discovering that my new employer had only been incorporated for a few days, my mother became full of doom and despondency (and she wasn't one to suffer quietly or alone ~ sorry Dad). Strange to relate, she now claims that this was the best move she ever told me to make, and when I question her recollection of events she stridently informs me that: "A mother remembers these things!" and who amongst us can argue with that. ~6~ I was the sixth person to join Cirrus Designs, and the other five told me that I was a lucky swine because I'd joined the day after the desks and chairs had arrived. Our sole computer facilities comprised a PDP 11-23, with two terminals and keyboards between us. The hard disk only had a single directory that we all had to share, 171and each of us was allocated only 2000 blocks of disk space (where each block held 1024 characters). It seemed like a lot at the time! When Cirrus Designs commenced operations, we used to have a weekly "state of the company" meeting to see how well we were doing. Unfortunately, I think the founders had assumed that when you did some work for somebody they would pay you for it immediately, so it came as something of a shock to discover that it 6My mother's memory is so acute that she can remember things that haven't even happened yet! 7The last character of a file name indicated its owner. My letter was "M", so any file called xxxM.xxx was one of mine.

. . . . .

._

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

-


. . . . . . . . . . . . . . . . . . . . . . .

.

.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

- . . . . . . . . . . .

- - .

.............

was common to wait for 90 days before you smelled any cash. Thus, week by week the company funds headed ever South, until at one point we were asked to provide our own pencils and paper. Then suddenly the graph flattened out ...... a little later it even began to rise ...... and ...... by golly we'd made it! l've been very fortunate in my career to have been exposed to many aspects of electronics, but perhaps the most fortuitous was learning how to write test programs. The main service provided by Cirrus Designs in the early years (circa 1981 to 1984) was to write functional test programs for circuit boards designed by other companies. These programs were developed using GenRad's 2225 testers, into which one plugged the board to be tested, tS~A test program consisted of driving a pattern of logic Os and logic l s into the board's inputs, waiting for their effect to propagate through the board, and checking that the corresponding pattern of logic 0s and logic l s on the board's outputs matched an expected response. 191Each pattern applied to the inputs was called a test vector, and a test program could consist of thousands (or tens of thousands) of such vectors. My personal view is that l've never received better training than learning to write these test programs. To understand why this should be so, you have to realize that all one was provided with was a "good" circuit board (which often wasn't), and a set of "good" schematics (which often weren't). It wasn't unknown (he said with a wry grin) for the schematics to actually correspond to an earlier or later version of the board, which made life interesting to say the least. First you had to look at the schematics and try to decide exactly what it was that the board was intended to do, then you had to write a test program. Next you ran the test program while applying a fault to the board (such as shorting a device's output pin to ground) in order to ensure that the program could detect and resolve the fault, and you repeated this for every possible fault that could occur on the board. So in addition to reverse-engineering someone else's logic (which is an educational experience in itself), you also discovered portions of the design that were effectively untestable, and you did this to boards designed for myriad applications by different engineers in diverse companies using widely different design styles. As I said, this was the best training in digital logic one could hope to receive. After a few years of test programming, I wandered into my boss's office to find him pondering a request to write some digital simulation models. The problem was that none of us had actually seen a digital logic simulator "in the flesh," but the remuneration (for the company) was particularly attractive. I remarked that 8Cirrus Designs subsequently became a wholly owned subsidiary of GenRad, Concord, MA, USA. 91fthe board contained register elements or memory devices, then a pattern appearing on the board's outputs didn't necessarily correspond to the current pattern on its inputs, but was instead a function of one or more preceding patterns.

9

10


this project looked like it could be fun, and he promptly told me that l'd got the job. I firmly believe that everyone is really good at something, but some people wander through life without ever discovering any of their particular callings. In my case, one of my vocations turned out to be digital simulation, which I took to like a duck to water. Over the next few years I wrote simulation models for everything from ASIC cell libraries to microprocessors, and I also started to pen white papers specifying possible enhancements to the logic, timing, and fault simulators. From there I branched out into giving advanced simulation modeling classes all over Europe, Asia, and America. This served to place me in contact with integrated circuit manufacturers, from whom I collected all sorts of useful nuggets of knowledge about exotic low-level delay effects (Chapter 25).

~Intergraph eorporation: ED~ and ~ a c k to eomputers After nine years with Cirrus Designs (the latter two of which were spent on the South coast of England with our sister company, Cirrus Computers, who specialized in simulation technology), I accepted a position with the electronics division of Intergraph Corporation, Huntsville, AL, USA. I spent a happy first year plunging myself into myriad aspects of electronic design capture, and also writing specifications for a futuristic digital simulation language and simulator. Sad to say this language and simulator were never to see the light of day, because Verilog and VHDL were fast becoming industry standards, and it soon became apparent that the last thing the world needed was "Yet another language and simulator," irrespective of how good they may have been. However, it was during this time that I came into contact with Alon Kfir (the creator of the BOOL Logic Synthesis utility presented in Chapter 3). Alon, who is an expert in many aspects of electronics and mathematics, was based in California, so we ended up spending countless hours on the phone debating fine points of logic value systems (Chapter 9) and simulation algorithms. Following this first year, my life took yet another turn. Recognizing my expertise in digital simulation, those who strode the corridors of power and donned the undergarments of authority at Intergraph Electronics resolved that I was destined to become the analog and mixed-signal marketing manager, so I was thrust into a whole new ball game (life is never boring as long as you're learning something

FleW). After five years with the electronics division (which subsequently became known as VeriBest Inc.), I was given the opportunity to join Intergraph Computer


Systems (ICS), where I remain to this day. Computers have sure come a long way since my days designing mainframes and life is pretty exciting at ICS, because we specialize in making state-of-the art single and multiple Pentium | Pro and Pentium ll| systems running the Windows | 95 and Windows NT | operating systems. Furthermore, Intergraph's RealiZm graphics cards are acknowledged as providing the fastest and most powerful 3D graphics available on IntelAJVindows NT platforms. These cards are employed for the highestperformance 3D simulations and virtual reality visualizations (and I get to play with them!). As I pen these words I find it difficult to believe that l've now spent seven years at Intergraph, because it really seems as though I arrived in America only a few weeks ago. TM

~qrticle$~ eonference$~ and ~oolc~ At some stage after commencing employment with Intergraph, I was fortunate enough to have an article accepted by a magazine (I forget which one now), followed by another, and another, and ..... suddenly the flood gates opened, and I was being published in one magazine or another almost every month. The combination of these articles and my job responsibilities also caused me to be invited to present papers at conferences, first in America with the Printed Circuit Design and the Analog and Mixed-Signal Design conferences, and subsequently in Korea, Taiwan, and China (~~ with the Electronics Design Automation & Test (EDA&T) conference, of which I also served as a member of the technical advisory board for two years. And then there are my books. It's strange really, because I had no conception as to what life had in store for me on this front. This all came about when I was lying in bed planning a trip down to a local bookstore one Saturday morning in the autumn of 1992. For reasons unknown I decided that it would be really cool to walk into a bookshop and see a book l'd written on the shelf ...... so I wrote one. (It sounds easy if you say it quickly, but it actually took two years of evenings and weekends.) I called my first book Bebop to The Boolean Boogie (An Unconventional Guide to Electronics), I~l because it was my book and I could call it what I liked! It's safe to say that Bebop is somewhat unusual, because it starts at ground zero with "What is an atom and what is an electron," and ends up with such esoteric topics as holographic optical interconnects and nanotechnology. Along the way we explore subjects like the secrets behind ~~ got to see the Forbidden City in Beijing and walk on the Great Wall of China, both of which are really, truly amazing. ~HighText Publications (www.hightext-publications.com), ISBN 1-878707-22-1, and for your shopping convenience there's an order form for Bebop to the Boolean Boogie in the back of this book, (if I might make so bold).

11

12

DesignusMaximus Unleashed!

musical socks (the ones that your aunts buy you for Christmas that play an immediately annoying tune when you squeeze them ~ the socks, not the aunts), and there's a rather spicy recipe for a "No-Holds-Barred Seafood Gumbo" (this isn't your mother's electronics book). Once I'd penned the words "The End," I started to think about looking for a publisher. I'd heard some horror stories about this part of the process, but it turned out to be less of a problem than I'd feared. A magazine editor friend of mine suggested I call HighText Publications in Solana Beach, California, because he'd been hearing good things about them. So I called Carol Lewis, the president of HighText, who said "Send the contents list and a couple of example chapters." I posted them on Tuesday, they arrived Thursday morning, and I got a call Thursday lunchtime saying: "We're sending you a draft contract." So there we were. Carol later told me that prospective American authors typically approach a publisher saying: "I've got a great idea for a book, how much of an advance will you give me to write it?", while Europeans almost invariably write their books first and then approach the publisher saying: "I've written this book, would you like to publish it?"

Bebop hit the streets in February 1995. As soon as our local bookstore (Madison Books and Computers on Old Madison Pike ~ a great store, highly recommended) got some copies in, they called me and I rushed down with my daughter, Lucie. We stood there for a while looking at my books on the shelf, then we went to McDonalds for a burger and some fries. So that was that; I'd done what I set out to do and it was all over ...... or so I thought. What I didn't know was that this book was to open all sort of doors to future adventures, such as Electronics Design News (EDN) offering me a regular column, and eventually making me a contributing editor. (~2) Writing Bebop was just about the hardest thing l'd ever done up to that time (Ah, the loneliness of the long-distance writer), and I swore that I'd never attempt another book in my life. Plus I'd hardly seen any television for two years, so I prepared to put some hours in as a couch potato. Have you watched television recently? The vast majority of it is absolute dross! After a couple of weeks I began to fear for my sanity, not the least that I could hear the computer calling plaintively to me from my study. Also l'd had some ideas for a new project, but I didn't want to suffer through the writing of another book alone (suffering loves company). So I approached a chum of mine called Alvin and tempted him with tall tales of how much fun writing a book could be (he's older and wiser now ...... I should bill him for the education).

12Contrary to popular belief, being a "Contributing Editor" doesn't imply a salaried position. It's really an honorary title, but it has made my mother v~ry proud, so that's all right!

Chapter I Capriciously Cunning Software Two and a half years later we finished Bebop B YTE S Back (An Unconventional Guide To Computers). I~31One of the cunning things a b o u t this book is that it's accompanied by a CD-ROM (for Windows 95) containing the fully-functional Beboputer T M Virtual Computer. In fact the Beboputer is the topic of the next chapter, and a d e m o copy of the Beboputer is included on the CD-ROM accompanying this book. Once we'd h a n d e d Bebop BYTES Back over to the publisher, c~4~I was prepared to take life easy for a while, by which I m e a n l'd put in my ten hours a day at Intergraph and spend my evenings reading books and doing not much of anything at all. Sadly this was not to be, because the opportunity came my way to collect a n u m b e r of my magazine articles and miscellaneous musings together into the tome you're reading as we speak. The really tempting aspect about this third book was that I could present my articles in their original form. One of the problems with magazines is that they each have an internal style, which typically excludes h u m o r and the use of first person pronouns. For example, an article I submit to a magazine might c o m m e n c e as follows:

"When we were younger we thought we knew everything there was to know about binary arithmetic, but as the years roll by we've c o m e to realize that we haven't got a clue." The idea l'm trying to convey here is that l'm "one of the lads," in the trenches, up to my armpits in mud, standing side-by-side with the reader. But the way this reemerges after editing is quite likely to be along the lines of the following: "When you were younger you thought you knew everything there was to know about binary arithmetic, but as the years roll by y o u ' v e c o m e to realize that you haven't got a clue." As you can see, this presents the s o m e w h a t different impression that l'm stood on top of the pitcher's m o u n d pontificating furiously and talking d o w n to everyone. This isn't to say that l'm against editing in general ...... I just don't like it being done to me! So the chance to be able to write a book in my own words without fear of having them mutate into another form while my back was turned was just too tempting to resist. 13Doone Publications (www.doone.com), ISBN 0-9651934-0-3. Also, it may not surprise you to learn that there's an order form for Bebop BYTES Back in the back of this book. 14The publisher of Bebop BYTES Back is Doone Publications, but this is no reflection whatsoever on HighText who published Bebop to the Boolean Boogie. Doone is owned by friends of ours who live in the immediate vicinity, and HighText have been strongly supportive and offered invaluable advise throughout.

13

14


So H e r e We Fire If I were a betting man, I'd take a stab in the dark and guess that you think l'm at the beginning of this project as I write these words. Ah, the innocence of youth. In fact l've already finished the rest of the book (that is, the other twenty-nine chapters, two appendices, acknowledgments, and suchlike), and as soon as I pen these final words l'm going to stick the whole thing in the post to the publisher, then wander out to a purveyor of fine refreshments to blow the froth off a few beers with some friends. So why have I left the first chapter until last? Well for one thing I find the technical stuff easier to write than my life story. But perhaps more importantly, one of the capriciously cunning pieces of software I was going to feature in this first section turned out to be not quite so capriciously cunning as l'd first thought, so I decided to chuck it out. But that left me with the problem that the other chapters reference each other, and there's no way I could face going through the whole thing changing all of these references again (plus thirty chapters seemed to be an awfully nice round number ~ much better than twenty-nine). So I decided to lose the Preface and to write this chapter instead (hey ~ it's an engineering solution, OK?). And that's all there is to it really. Of course l've condensed the tale somewhat, omitting the wild parties, the dancing girls, the walrus, the trips to exotic lands, and the months where nothing much happened at all (where this latter state of affairs was more common than not). I've also tended to "accentuate the positive and eliminate the negative," as they say; for example, I haven't once mentioned the fact that the only consistent way l've found of dismounting the unicycle in the house is to slam headfirst into the pantry door, then slide down the wall getting splinters up my nose (Ooops, you tricked it out of me). So I'II close right here and now before we get maudlin, and leave you free to root through the rest of my meandering musings to your heart's content. With my very best wishes Clive "Max" Maxfield (April 1st 1 9 9 7 - J u n e 30th 1997).

Chapter 2:

The Bebopu~er TM

Virtual Computer "When is a computer not a computer?" In this chapter you will discover: P e d a g o g i c a l a n d F a n t a s m a g o r i c a l .....................................................................16 For Your D e l e c t a t i o n a n d D e l i g h t ..............................................................................17 It's A l m o s t Time to Rock a n d Roll ...............................................................................17 The Switch Panel ......................................................................................................................................18 The Hex K e y p a d a n d M e m o r y Walker Display .................................. 21 The CPU Register Display ...........................................................................................................24 M u l t i m e d i a I n t r o d u c t i o n s a n d t h e W e b .........................................................24 O t h e r C o o l Stuff ......................................................................................................................................... 25

16


Pedagogical and 3antasmagoricai In November 1994, my chum Alvin agreed to collaborate with me on a book on computers. We told Alvin's wife, Sue, that it would only take about a year and that it wouldn't occupy our every waking moment (the frightening thing is that we believed this to be true!). Two and a half years later, after spending almost every evening and weekend I~ slaving over hot computer keyboards, we staggered out of our respective studies with stooped shoulders and the finished manuscript clutched firmly in our shaking hands. That book, Bebop BYTES Back (An Unconventional Guide to Computers), was one of the most demanding projects l've ever undertaken, but l'm forced to admit that it's also a project of which l'm inordinately proud. To complement the book, we created what came to be known as "The pedagogical and

fantasmagorica! Beboputer(TM) Virtual Computer." To cut a long store short, we designed a simple microprocessor with an easily understood instruction set. Next we designed and implemented a computer based on our microprocessor, and we christened this system the Beboputer (pronounced "Bee-bop-you-ter"). Now comes the capriciously cunning part of our tale, because instead of constructing the Beboputer in hardware (out of silicon chips), we implemented it as a virtual machine in software. To a large extent we treated the Beboputer as a hardware project. We'd have regular design review meetings in which we'd define new devices to be plugged into the Beboputer's input or output ports. For example, in the case of our virtual QWERTY keyboard, we created a complete specification describing the way in which the keyboard would capture key codes in an internal latch, how this latch would be automatically cleared when the Beboputer read it's contents via an input port, what would happen when the key was pressed (on our virtual keyboard), and so forth. Then Alvin would wander off into the depths of his study to create the virtual device, while I commenced to document the first typewriter patent, 121and then proceeded to describe the evolution of these devices via printing telegraphs and teleprinters into the computer keyboards of today. It sounds easy if you say it quickly!

iWe both have full-timejobs in the day. 2The first patent for a typewriter was granted by the grace of Queen Anne to the English engineer Henry Millin 1714.

Chapter 2 The B e b o p u t e r TM Virtual Computer

3or gour Delectation and Delight It's important to note that the Beboputer is to all intents and respects a real computer, for which one can create and run programs. Furthermore, in addition to a wealth of virtual input and output devices, the Beboputer is equipped with a smorgasbord of useful utilities, such as the CPU Register Display which lets you see the current contents of the registers and status flags within the CPU. In addition to describing where computers came from and how they work (including an in-depth investigation of the design of our virtual Central Processing Unit (CPU)), Bebop BYTES Back documents a series of step-by-step interactive laboratories to be performed on the Beboputer. But I can tell that your excitement is beginning to run wild and adrenaline is beginning to flood your nervous system, so I'II cut to the chase. For your delectation and delight l've included a demo copy of the Beboputer on the CD-ROM accompanying this book. Throughout the remainder of this chapter I'II walk you through a quick demonstration, then I'II leave you free to experiment with the little rascal to your heart's desire.

~It's ~ l l m o s t ~ i m e to l~ock a n d I~oll If you haven't already installed your Beboputer from the CD-ROM accompanying this book, do so now by following the instructions in Appendix A. (Note that the Beboputer is only certified for use with Microsoft Windows 95. Also note that your screen resolution should be 800 x 600 or higher.) Should you have any problems with the installation process, check out the Frequently Asked Questions (FAQ) section of our Beboputer-specific web pages at:

ht,t,p'.//ro.comlmaxmonlb~e~Iby~s, htm If during the installation you receive a message saying something like "Can't

install xxx.dll because this file is a/ready in use," just select Ignore because if the

file is already in use you have already got it and you don't need to load it. Once you've completed the installation, ensure that the CD is still in the appropriate drive in your computer, then use S t a r t - > Programs-> Bebopui;er ->13eboput,er Computer to invoke your yew own pedagogical and fantasmagorica] Beboputer Virtual Computer. OK, you're now in the Beboputer's main project window. When you know what you're doing you can just kick off from here invoking whichever tools and utilities you wish, but to save time we've already created a project for you. Use the File - > Open Project command to invoke the project called ~iemoprj, which will hurl a number of devices onto your screen.

17

18


~ h e Switch P a n e l One of the more prominent devices is called the switch panel (Figure 2-1). In ye olden tymes computers didn't have typewriter-style keyboards, and the switch panel was one of the main methods for the operator to instruct the computer as to which operations it was to perform.

Figure 2-I: The Beboputer's switch panel Running along the upper half of the switch panel are sixteen switches which correspond to the signals forming the Beboputer's 16-bit address bus. Similarly, the lower left hand side of the switch panel contains eight switches which correspond to the Beboputer's 8-bit data bus. In the bottom right-hand corner is the main ON/OFF switch, which is used to power-up the Beboputer (we'll look at the other buttons in due course). Use your mouse to click the ON/OFF switch on the switch panel. The switch toggles, the display lights flash, and, if your home computer is equipped with a sound board, you'll hear the cooling fans begin to roar into action (if you didn't shell out the extra lucre for a sound board ...... we bet you're sorry now). In addition to the main switch panel, there are a number of other devices on the screen, including an 8-bit switch input device (Figure 2-2). This device is plugged into one of the Beboputer's input ports at address $F000 (dollar "$" characters are used to indicate hexadecimal values). A switch in the down position corresponds to a logic O, while a switch in the up position corresponds to a

logic 1. Corresponds to Input bit 7

Figure 2-2: A simple 8-bit switch input device

Corresponds

to Input bit 0

Chapter 2 The Beboputerr~ Virtual Computer

Similarly, we've plugged a dual decoded 7-segment LED display into one of the

Beboputer's output ports at address $F023 (Figure 2-3). The most-significant 4 bits of the output port are used to drive the lefthand digit, while the least-significant 4 bits drive the right-hand digit. (Note that the device on your screen won't be displaying any numbers at this stage, because we haven't actually written any data to this output port. ) What we're going to do is to enter a program that Figure 2-3: A dual decoded will perform an endless loop, reading the state of 7-segment display the switches on the 8-bit input device and writing this state to the dual 7-segment display. The flowchart for this program, along with its associated opcodes and data bytes, is shown in Figure 2-4.

.....................

9

.....................

s 4001 ooo ~I....~~ ~............lIi $91 =

to by the following two ~ s $4oo2 [...........~,~ .......|.... (which are SPO and $00 = SFO00)

$40 o4 I ........~:~:~.....| pointed to !:5/the following two bytes $ 4 0 0 5 iii ~~ ............!| ((which ~ , h i : h are ~ _~1=/') ~ 9 ~ -SFO a~m,,'l n d 4$23 = ~1r/'~"2'~'% $F023) $4006

..................... "1~

Load accumulator from the address

................................................................ pointed

$4007

$40o8

.....~.... ......./.....$C1 = Jump back to the addrees ..........~

..........|..

(which are $40 and $00 = $4000)

Figure 2-4: A simple "load and store" program Note that the Beboputer's ROM occupies addresses $0000 through $3FFF, while its RAM occupies addresses $4000 through $EFFF (addresses higher than this are used for input/output ports and suchlike), so this program happens to commence at the first location in the RAM. From the flowchart we see that the first action is to load the accumulator with whatever value is represented by the 8-bit switch input device. In this flavor of a load, the $91 opcode at address $4000 instructs the CPU to load the accumulator with the contents of the memory location which is pointed to by the following two bytes. Also note that the Beboputer's designers (Alvin and myself) decided that addresses would be stored in memory with the most-significant byte first. Thus, the contents of the two bytes stored at addresses $4001 and $4002 ($F0 and $00, respectively) are understood by the CPU to represent the address $F000.

19

20


However, we're going to trick the CPU, because although it thinks it's reading from memory, the address we're using actually points to the input port into which we've connected the 8-bit switch device. Similarly, the $99 opcode at address $4003 instructs the CPU to copy the contents of its accumulator into memory location $F023 as specified by the address contained in the following two bytes (this is the address of the output port that drives the dual 7-segment display). Finally, the $C1 opcode at address $4006 instructs the CPU to jump back to the memory location specified by the address contained in the following two bytes. In the case of this program, we've decided that the jump instruction should cause the CPU to return to address $4000, which is both the beginning of the program and the beginning of the loop. Just to get the feel of how painful programming a computer used to be, we (well you actually) are going to employ the main switch panel to load this program as shown in the following sequence of illustrations.

.

.

.

l

.

.

l

1

.

l

l

i

l

.

l

.

.

.

.

.

.

.

.

l

l

l

l

l

l

l

l

l

l

1

~l~l~l~H~l~I=l~/ I

i

l

l

I

l

l

l

lil~lili~il~t~t~/~t~l~l~~ .

.

.

.

.

.

.

.

.

.

.

.

.

i~l~l~/ilit~l~/=lilili/~l~il'.~i www

lltilmti/

Set up the addreee anti data ewitchee ae ehown to the left then click on the Enter button. Thle ioacle $91 into aeldreee $ 4 0 0 0

$ ooo

Set up the aclclreee anti data ewitchee ae ehown to the left then click on the Enter button. Thle loade $FO into a~ldreee $4001

$~ooz $4002

$4001

$4000

Set up the acicireee and data ewitchee ae shown to the left then click on the Enter button. Thle loa~le $00 Into a~l~re~e $4002

$4002 $4oo

Set up the acldreee and data switchee as shown to the left then click on the Enter button. Thle loacls $99 into acl~iress $ 4 0 0 3

$4002 $4003 $4004

Set up the address and data ewl'r,ehee as

s4oo3

button. Thle ioacle $FO into addrese $ 4 0 0 4

$400 s

l........

......!.........

!

$4 oo1

!

Chapter 2 The BeboputerT M Virtual Computer ~

t

~

I

~

~

. . . . . . . . . . . . .

-- . . . .

~~l~~I~l~l~~ ~~l~l~i ..... n

~ i

-

a m

i

l

i

m

i

n

l

m

~ i

m

l

i

i

i

m

a

m

n

m

Set up the a~ldre~s and data switches as shown t o the left, then click on the Enter button. This loads $23 into address $4005

$4004 $r $4006

Set up the address and data switches as shown to the left then click on the Enter

s4oos I....~ ..........] , 4 o o 6 t!iii!~i~~ii ~ o o ~ ~..,.:..:.:i~i.i]i!ii.i!.!

button. This ioacle $C1 into actctreee ~ 0 6

i

i

i

~

i

Set up the address and data switches as

shown t o the left, then click on the Enter

....!iiil

s4 o o 6 liii!iiii!i@~i~! 4 o o ; I~!il ii!ii!iiil

button. This loads $40 into address $4007

~4oo8 li

5st up the address anti data switches ae shown t o the left then click on the Enter

$4007 $r

button. This loa~ls $00 into admirers $ 4 0 0 8

]iii!]

I

$4009

Don't forget that you can always correct any errors by overwriting a location's contents with new data. Once you've entered the program and you're happy that all is as it should be, return the address switches to the program's start address of $4000 (Figure 2-5), then _ __ _ _ _ _ _ _ _ _ _ _ _ _ click the Run button to let the Beboputer rip. Figure 2-5: Start address Now although not a lot seems to be happening, the Beboputer is actually working furiously, reading the values of the switches on the 8-bit input device and writing what it finds there to the 7-segment displays. Play around for a while toggling the switches on the 8-bit input device and watching the 7-segment displays respond.

~he Hex Keypnd and ;~lemory Walker Displny Now we could continue to experiment with the switch panel, but we've still got a lot of other things to do, so once your adrenaline rush has spent it's course, click the ON~OFFswitch to power down the Beboputer, then click the clismi~s button in the switch panel's upper right-hand corner. As you've discovered, entering programs using a switch panel is somewhat tedious. The next stage in home computing was to replace the switch panel with a simple keypad device. In the case of the Beboputer, we've supplied you with a hexadecimal keypad (Figure 2-6).

21

22

DesignusMaximus Unleashed! On = 0n/Off Use Setup - > Hcx K~dpad to invoke this AD = Aaare~e device on your screen. Use your mouse to drag the hex keypad by its title bar to Da = Data CIr = Clear a clear area on your screen. Now use Rst = Reset Ent = Enter 5 t p = Step Ku = Run

Display - > Memory Walker to access a rather useful utility that let's us v i e w the contents of the Beboputer's m e m o r y (Figure 2-7).

Once again, use your mouse to drag the memory walker by its title bar to a clear area of your screen. Note that the memory walker on your screen is grayed out, thereby indicating that the Beboputer isn't powered up yet. By default, the

Figure 2-6: The Beboputer's hex keypad

m e m o r y w a l k e r starts at address $ 4 0 0 0 , w h i c h is

the first location in the Beboputer's RAM. Use your mouse to drag the bottom edge of the memory walker down such that you can see locations $4000 through $400A as illustrated in Figure 2-7. Now click the ON switch on the hex keypad to power the Beboputer up again, and observe that the memory walker display clears to white to indicate that the Beboputer is ready for action. Note the $XX data values in the memory walker, which indicate that the contents of these RAM locations currently contain random, $4ooo SXX I ... unknown values.

$4001

$XX iiiiii.,

$4002 $XX OK, we're going to need a small program .............. $4003 $XX ~ to play with, such as the one we entered with the switch panel, which consisted of .............. $4005 $XX just nine bytes: $91 $F0, $00, $99, $F0, i~:i $4006 sxx iiiiiiiiiiiiii, $23, $C1, $40, and $00. If we wished, we $4oo7 sxx !i!i!i!!i!i!i!~, ~: $4oo8 sxx ]i~ ' ii~,'i~"i~i~,i,'i could use the hex keypad for this purpose ~:.~::: $4009 $XX ,~:~,i~!~::;,~ i ,i~,i~,;i (it would be one heck of a lot easier than :~:.~ : $400A $XX i~i~ii was the switch panel). To start this process, ............... all we would have to do would be to click Figure 2-7: The Beboputer's memory the keypad's Ad (Address) button and walker display enter the start address of $4000, then click the Da ( D a t a ) button and enter the first byte of data, which was $91. If we now clicked the Ent (Enter) button, this would load the $91 data into address $4000, automatically increment the address field to point to address $4001, and leave

,4OO4 ,XX:

................

. . . . . . . . . . . . . . . .

Chapter 2 The BeboputerT M Virtual Computer

the data field active, thereby allowing us to alternate between entering data and clicking the Ent (Enter) button. Alternatively, we could use the memory walker display to enter this data directly by simply double-clicking on whichever data field we wish to edit. But both of these techniques would be boring. Instead, you're going to load this program from a virtual paper tape that we prepared for you while you weren't looking (Figure 2-8).

Tape in~

Tape ~ t

Figure 2-8: The Beboputer's paper tape reader/writer This is a top-down view of the paper tape reader/writer's mechanism. Click the hex keypad's Ad (Address) button to make the address field active and enter address $0050. This is the address of the paper tape reader subroutine in our monitor program which is stored in the Beboputer's ROM. Now click the keypad's Ru (Run) button to initiate the subroutine. In the real world each paper tape would have a hand-written label, and it would be up to the operator to locate the tape from a rack (or the bottom of someone's desk drawer). In our virtual world, you're presented with a dialog asking you to select a tape. In fact your only choice in this demo is to select the item called demotape and then click the Open button, which will cause the contents of this tape to be loaded into the Beboputer's memory. Note that the memory walker updates to reflect the fact that the program from the paper tape has now been loaded into the Beboputer. Now click the hex keypad's Ad (Address) button again, enter our program's start address of $4000, click the Ru (Run) button to initiate the program, and play with the 8-bit switches for a while to convince yourself that the program still works. Note that the act of running the program caused the memory walker to gray out again, to indicate that it's contents are not guaranteed to be valid while the Beboputer is in it's Run mode. Now click the keypad's Stp (Step) button, which causes the Beboputer to transition into its Step mode. The memory walker returns to white, and a chevron (arrow) character appears in its "Step" column to indicate the next opcode to be executed (note that you can't predict the opcode at which the Beboputer will pause, because this depends on whatever it happens to be doing when you enter the Step mode). Click the Stp (Step) button a few more times and watch what happens in the memory walker, then proceed to the next section.

23

24

DesignusMaximusUnleashed! ~ h e e P l / I i~egister D i s p l a y The memory walker display has a variety of uses that we haven't considered, such as setting and clearing breakpoints, but once again we need to move onwards and upwards. Dismiss the memory walker by clicking the dismiss button in the upper right-hand corner of its title bar, then use Dlsplay-> CPU F,.eglst~rs to activate the CPU register display (Figure 2-9).

Figure 2-9: The Beboputer's CPU

register display

As its name might suggest, this tool is used to display the contents of the Beboputer's internal registers. Click the hex keypad's 5tp (St~p) button a few times to see the program counter and instruction register change. Note that the "program counter" shows the address of the next instruction to be executed, while the "instruction register" field reflects the last instruction to be executed.

Now click the F-,u (le,un) button to let the Beboputer run wild and free, and watch the activity in the CPU register display. Note that the accumulator field in the CPU register display isn't changing, because our program causes it to reflect the value on the 8-bit switch device. But if you click the switches on the 8-bit device, you'll see the accumulator field update to reflect this new value. Last but not least, click the keypad's l~st (le,e~r162button to return the Beboputer to it's le,es~r mode.

M u l t i m e d i a ~Tntroductions a n d t h e Web Amongst a myriad of other topics, Bebop BYTES Back (the book accompanying the Beboputer) documents a series of interactive labs (similar to what we've done here, but in much more detail), and each of these labs comes equipped with a multimedia introduction. Although it doesn't strictly match our discussions here, we've included the multimedia overview from lab 4 for your edification and enjoyment. To invoke the multimedia viewer, either use Tools - > Multlm~la, or click the icon that looks like a film projector on the Beboputer's project window toolbar (note that a sound card is strongly recommended). Click the Exl= button in the multimedia theater when the presentation is completed.

-

......

- ..................

.......................

~. . . . . .

....~

Chapter 2 The BeboputerTM Virtual Computer

.................

......,,

,. .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

In addition to its multimedia content, the Beboputer is also "Internet Ready," by which we mean that you can use it to connect to some special BeboDuterweb pages (this assumes that you have a modem and access to the Internet and the worldwide web). As you'll discover, these web pages contain all sorts of cool stuff like competitions and additional programs and subroutines written by ourselves and other users.

Other eool S t u f f Although we haven't had time to go over it here, your demo copy of the

Beboputer contains a lot of other cool stuff, including a virtual sound card (which allows the Beboputer to do things like speak numbers aloud), a virtual QWERTY keyboard, and a virtual memory-mapped computer screen. You can access a lot of these devices by using S ~ u p - > Input Po~s and S ~ u p - > Output Po~s, and there's also a lot of information available in the online help. Furthermore, Appendix B of this book provides some additional discussions on the Beboputer's addressing modes, along with a summary of the Beboputer's instruction set. On the down side, you can't use this demo copy to execute the File - > Save Project command or the Memory - > Save I~AM command (see the online help for details on what these do). Also, the real Beboputer comes equipped with a bevy of general-purpose subroutines and smorgasbord of support tools, such as a cross assembler and a character editor, but all of these treats have been omitted from this demo copy. Having said this, the demo copy contains a lot of really good stuff, which should keep you occupied for many evenings to come. Enjoy!

BebopBYTESBack (An UnconventionalGuide to Computena),lSl3N 0-9651934-0-3, accompanied by a fully,functional copy of the Beboputer,then you can Should you be interested in acquiring

l~ F

ii check out the publisher s web pages at www.cioone.com or use the order t~

25


Chapter 3:

BOOL Logic Synthesis "Not without a sense of humor" In this chapter you will discover: W h a t is B O O L ? .............................................................................................................................................28 Instal!ing B O O L .............................................................................................................................................28 R u n n i n g B O O L ..............................................................................................................................................28

28


What i s / 3 0 0 s On the CD-ROM accompanying this book you'll find a directow called [500L, which contains the fully-functional BOOL logic synthesis package. This tool was created by a friend of mine, Alon Kfir, a man with a size 16 turbo-charged brain. Alon has kindly put BOOL into the public domain, which means that you can make copies of the software and give these copies away, but you may not charge any fees apart from nominal shipping and handling charges. Also, any such copies must contain all of the original files and you may not misrepresent the origin of these files. BOOL is a general-purpose tool for synthesizing two-level logic from a behavioral description, and is particularly useful for ASIC and PLD synthesis. BOOL contains an HDL compiler, a two level minimizer, a high level event driven simulator, and sophisticated output formatting routines. More details on BOOL, including the terms and conditions for its use are to be found in three files in the BOOL directory: readme.doc, hlghllte.cloo, and manual.doe, where this latter file is a complete 11,000 line tutorial manual and reference guide (so I'd strongly recommend that you print it out one chapter at a time :-)

lnstalling 1300s BOOL can run on any class of IBM/PC and compatibles under DOS 2.0 or above. Installing BOOL essentially consists of copying the files to your hard disk, and setting an appropriate search path to the executable and library files. 1) Create a directory called 1500L at the top level of your main hard drive 2) Copy all of the files from the BOOL directory on the CD-ROM into the BOOL directory on your hard drive.

Running

00s

The manual.doc file in the BOOL directory will walk you through a series of test cases that demonstrate the full capabilities of BOOL. For our purposes here, we just want to perform a simple experiment in order to show you the general principles. The topic in Chapter 18 is a rambling discussion on the design of a three-phase clock. During the course of these discussions we derive a truth table and extract a set of Boolean equations (Figure 3-1).

.

.

.

.

.

.

.

,,,,, .

.

.

.

.

.

.

.

,

.

Chapter 3 BOOL Logic Synthesis .

.

.

.

.

.

.

.

,.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

c13 = (~p3 & p2 & p1) I (p3 & p2 & p1) I (p3 & p2 & ~p1) ~12 = (~p3 & ~p2 & p1) l (-,p3 & pZ & p1) l (p3 & pZ & p1) cll = (~p3 & ~p2 & ~p1) I (~p3 & ~p2 & p1) I (~p3 & pZ & p1)

Figure 3-1. An example truth table and Boolean equations ('~' = NOT, "&' = AND, end '1' = OR)

If we were to implement these equations directly (taking shared product terms into account), we'd require five 3-input AND gates and three 3-input OR gates (note that we don't require any NOT gates, because we can pick up the negated versions of these signals from the complementary outputs of the D-type flip-flops that are used to generate the p1, p2, and p3 signals). Of course, the equations shown in Figure 3-1 are not optimized or minimized in any way. The discussions in Chapter 18 proceed to use Karnaugh Map techniques to minimize these equations, but for our purposes here we'll use BOOL. In fact there are many user scenarios for working with BOOL depending on the way your system is set up. BOOL itself runs under DOS, but my home computer is also loaded with Microsoft Windows 95, so the way in which I use BOOL reflects my system configuration. First of all I invoke the Notepad editor supplied with Windows 95, and I enter the following text (note that BOOL prefers to see keywords like minimize and print: in lowercase)"

inpul: p1, p2, p3; out;pul~ c11,ci2, ci3; cl3 = (!p3 & p2 & p1) I (p3 & p2 & p1) l (p3 & p2 & !p1); cl2 = (!p3 & !p2 & p1) i (!p3 & p2 & p1) I (p3 & p2 & p1); cll = (!p3 & !p2 & !p1) I (!p3 & !p2 & p1) I (!p3 & p2 & p1); minimize(d3, d2, cil); prinl:(ci3, ci2, cil); encl;

29

0

DesignusMaximus Unleashed/

The format of this file is really simple. First we declare our inputs and outputs; then we specify the Boolean equations we want to minimize; next we call the minimize function and tell it which signals we want it to process; and finally we call the print function which will output the results. Note that BOOL uses exclamation marks "!" (also known as "shr/ek" characters) to indicate inversions (as compared to Figure 3-1, in which we used tilde " - " characters). Next I use File - > Save in the text editor to save this source code to a file called c:\bool\3pclock.txt (substitute c: for the name of your hard drive if it's different). Now I use S t a r t - > Programs - > MS-D0S Prompt to open up a DOS window, then I use the command col c:\bool to change the directory to the work directory I created earlier (once again, substitute c: for the name of your hard drive if it's different). Now I use the dir command to assure myself that my 3pclock.txt file is indeed in this directory (call me "old-fashioned" if you will), then I run BOOL on this file using the c o m m a n d bool 3pclock.txt, which results in the following equations being displayed on my screen:

d3 = (p2 & p3) I (pl & p2); ci2 = (pl & lp3) I (pl & p2); cll = (!p2 & !p3) I (pl & !p3); You can only imagine my surprise and delight to discover that these equations are the same as those I generated by hand using my Kamaugh Maps in Chapter 18. Due to the fact that some of the product terms are shared between these equations, I can now implement this logic using just four 2-input AND gates and three 2-input OR gates (Figure 3-2). p3 el3 p2 p1 c12 !p3 pl ell !p3 .Ip2

Figure 3-2: The minimized solution from BOOL requires four 2-input AND gates and three 2-input OR gates

Chapter 3 BOOL Logic Synthesis

For your interest, you may care to note that I didn't close the Notepad editor containing my source file, because I might want to make some changes later. In fact I always keep both the editor and the DOS window on my screen. Thus, whenever I make any changes to my source file, all I have to do is perform a Save operation and then re-run BOOL. This interactive technique bouncing back and forth between Notepad and the DOS window provides a really fast and efficient way of interacting with BOOL. Last but not least, note that this trivial example did little to demonstrate the power of BOOL. This surprisingly sophisticated package can perform a wealth of cunning tricks, and it has proved itself to be endlessly useful to me over the years. For example, BOOL can synthesize hazard-free logic I~l if directed to do so, which is something that even the "big-boy" synthesis tools aren't particularly good at. In order to fully appreciate BOOL's features and capabilities, I strongly recommend that you read the manual.doe file provided with BOOL and perform all of the tutorial examples therein. Enjoy!

IHazards and hazard-free logic are discussed in Chapter 16.

31


Chapter 4:

MMLogic Multimedia Logic Design System

"A syncopated symphony of delight" In this chapter you will discover: W h a t is M M L o g i c ? ................................................................................................................................. 34

Installing M M L o g i c ................................................................................................................................ 34 R u n n i n g M M L o g i c .................................................................................................................................. 34

34


W h a t is ~j3/ls OK, this is really, really cool. As you're soon to discover, MMLogic (which was created by George Mills, Softronics Inc.) is a terrific program for learning the fundamentals of digital logic and experimenting with said logic. In fact the only problem is that Alvin and I were planning on doing something very similar, but now there doesn't seem to be much point, because George has done such an outstanding job. George very kindly gave me permission to include MMLogic on the CD-ROM accompanying this book. Note, however, that MMLogic is NOT in the public domain. The version included on this CD is Shareware, which means that once you install MMLogic you may use it in its fully functional trial mode for 30 days, after which the tool will automatically switch to a read-only mode. The readme file accompanying MMLogic describes how you can acquire a license, which will entitle you to use MMLogic in its fully functional mode indefinitely, and which also entitles you to all applicable upgrades to this version.

gnstaUin g ~)Vls MMLogic is suitable for use on Win32 Windows Platforms, including Windows 3.x (so long as you've got Win32s) I~l and Windows 95. On the CD-ROM accompanying this book is a directory called mmloglc, and inside this directory is a file called mmlogl10.exe. Use your file manager or Windows Explorer (or whatever) to locate this file and double-click on it with your mouse. This file is a self-extracting executable, which means that double-clicking on it will launch the process required to install MMLogic on your system; simply follow the prompts as they appear on your screen.

I~unnin g ~l)l/ls Assuming that you're running Windows 95, use S t a r ~ - > P r o g r a m s - > MultiMedia Logic - > MultiMedia Logic to launch MMLogic. Once you've launched MMLogic, you'll see a user window and a pallet. You can use the contents of the pallet to quickly draw your own circuit diagrams on the screen and then simulate them. For example, click the AND gate symbol on the pallet (left-hand column, second row from the top), move your cursor into the user area and click to place a copy of this gate, then move your mouse a little and click again to place a second copy of the gate.

INote that you must have a complete version of Win32s, which is not included with MMLogic. If you don't already have Win32s, you can download it over the web from www.microsoft,com.

Chapter 4 MMLogic Multimedia Logic Design System

35

Now click the pointer tool in the upper left-hand corner of the pallet, then double-click on one of your AND gates. This results in a form appearing, which allows you to specify certain attributes associated with this gate, such as its number of inputs and whether or not the output should be inverted (thereby forming a NAND) (Figure 4-1 ). Try selecting the 3 Inputs option and setting the Invert Output box, then click OK to see these changes occur in your schematic. Similarly, Figure 4-1" The properties form for the AND gate the properties form associated with the flip-flop device (right-hand column, fifth row from the top on the pallet) allows you to select between different flavors of latches and flip-flops. Once you've placed all the components you require and have wired them together, you can proceed to simulate your circuit. In fact MMLogic comes equipped with a wealth of example circuits, so let's use one of these. Use File - > Open to reveal an Examples directory. Double-clicking on this directory reveals a series of sub-directories, including one called Moderate, which is the one we're interested in here. Double-clicking on Moderate exposes a file called Bandit, and double-clicking on this file invokes the circuit for a one-armed bandit. At this time we're still in MMLogic's Draw mode, which is the mode we use to edit schematics. But we want to simulate this circuit, so use Simulate - > Run to place us into the Simulation mode. On the left-hand side of the schematic you'll spot four push buttons. Click the button marked Reset on the extreme left of the schematic to start the one-armed bandit running, and note the three devices on the right-hand side of the screen as they start to display bitmaps. When you're ready, click the three buttons marked Stop I, Stop 2, and Stop 3 (pausing for a few seconds between each button), which will halt their associated windows. Don't worry, once you see this running you'll quickly get the idea. Once you've finished playing with this example, use Simulate - > Stop to return to the Draw mode, then close this example. Now feel free to root around the other examples, or to start creating and simulating your own circuits. Enjoy!



Chapter 5:

Capturing and Synthesizing a Design "Textual, graphical, and mixed-level techniques "

In this chapter you will discover: Electronic Design A u t o m a t i o n ........................................................................................40 The Early Days ............................................................................................................................................... 41 The D a w n i n g of EDA ......................................................................................................................... 42 The Introduction of H a r d w a r e Description L a n g u a g e s ...... 46 Migrating Existing G a t e - L e v e l Designs to PLDs ...................................47 The Introduction of Verilog a n d VHDL ...............................................................48 Top-Down, M i d d l e - O u t , a n d Bottom-Up .......................................................49 G r a p h i c a l Entry M e c h a n i s m s .............................................................................................50 Logic Synthesis a n d L a n g u a g e - D r i v e n Design ...................................51 Mixed-Level Design ............................................................................................................................. 54

40


Electronic

Design

utomation

The phrase Electronic DesignAutomation (EDA) encompasses a number of distinct specialties, the main ones being Computer-AidedEngineenng(CAE), Computer-Aided Design (CAD), Computer-AidedManufacture (CAM), and Computer-Aided Test(CAT) (Figure 5-1).

I~

Electronic~ Design Automation (EDA)

i

i

iiiiiiiiiiii!ii

"1

i Ziiill

Figure 5-I: Electronicsdesign automation includes computer-aided engineering, design, manufacture, and test At the circuit board level, CAE includes capturing the design and verifying its functionality and timing; CAD is concerned with laying out the board (that is, placing components on the board and describing the connections between them), along with any real-world verification such as signal integrity and thermal analysis; CAM involves anything to do with manufacturing the board; and CAT refers to the testing of the board. By comparison, when working with Application-Specific Integrated Circuits (ASICs) and Field-Programmable Devices (FPDs), CAE is generally accepted to encompass both the capture process and any mapping software used to squeeze the design into the device. I~l Apropos of nothing at all, some engineers feel that the terms CAE and CAD are misleading, in that it would make more sense to use CAD to refer to the process of capturing the design and something like Computer-Aided Layout (CAL) to indicate the process of layout. The reason for using the terms CAE and CAD as we do is that the layout fraternity started using computer-aided techniques first, so they grabbed the CAD designation. Thus, when design engineers finally caught up, they were obliged to chose a new label, and CAE was apparently the best they could come up with. Over time, layout guys and gals came to refer to themselves as layout designers or simply designers, based on the fact that they practiced CAD. Similarly, the layout fraternity refer to people who conceive and capture designs as engineers on the basis that they practice CAE. Unfortunately, nobody bothered to inform the "engineers," who therefore blissfully stroll through life referring to themselves IASICs and FPDs are discussed in more detail in Chapter 19.

Chapter 5 Capturing and Synthesizing a Design

as "designers," and referring to the layout guys as .... "the layout guys." For the purposes of this book we will use the terms "designer" and "engineer" interchangeably, thereby giving everyone an equal opportunity to have something to moan and groan about.

~he E~rly D~ys As I poise myself to pen these words a grim chill is stealing over me, because I know that l'm about to open a huge "can of worms," but this is the path we have to tread to make any sense out of the horrors that are to come. Way back in the mists of time, say around the 1960s, the majority of electronic designs were created by large companies, because they were the only ones who could afford to do it. Neglecting for the moment manufacturing and test, the world as seen by engineers was divided into two camps: the engineerS themSelves and the drafting office. Prior to the advent of computer-aided techniques, engineers captured designs by drawing circuit diagrams on whatever surface came to hand, including scraps of paper, shirt sleeves, and tablecloths. These masterpieces were then passed to the drafting department, where they were manually redrawn and annotated to the company's internal standard. (To increase the fun, each organization had its own standard). The resulting "official" schematics were subsequently handed on to the layout draftsmen who performed the physical layout of the board by hand, and who were considered (at least by themselves and their mothers) to be at the top of the drafting totem pole. (In order to be "politically correct" we should perhaps say "draftsmen and draftswomen," but in those days you could count the number of draftspersons of the female persuasion on the fingers of one foot.) A common scenario in those days was for engineers to be on the staff and for drafting personnel to be union members (this scenario still occurs to this day in certain industries ~ for example, the automotive industry springs to mind). Unfortunately, it was not unknown for friction to develop between these two groups, and woe betide any hapless engineers who got on the wrong side of the drawing office, because their jobs were mysteriously prone to "unforeseen" delays, and some jobs might even disappear into the nether regions from whence they never reemerged into the light of day (in much the same way that today's engineers quickly learn not to annoy their system administrators). For their part, the layout draftsmen accepted a schematic and generated the circuit board's physical layout. In order to do this they typically worked at a scale of 4:1, which meant that everything was four times its actual size. First the draftsman applied sticky cutouts called footprints to a transparent sheet of mylar, where these footprints were used to represent the physical locations of the

41

42

DesignusMaximusUnleashed! components. Next they marked the positions of the tracks on the sheet using colored pens (in the case of double-sided boards, a red pen was used to represent the tracks on one side of the board while a blue pen was employed to indicate the tracks on the opposing side). The next stage in the process was referred to as "taping up," in which sticky black tape was used to represent the true widths of the tracks and pads (still at a scale of 4:1).c21 The resulting taped-up artworks would eventually be photographed and reduced to generate a 1:1 film artwork, which would subsequently be used in the process of etching the board. 131 Meanwhile, the 4:1 taped artworks would be passed back to the drafting office to be redrawn by hand to create the "official" assembly and manufacturing drawings. Finally, the physical layout would be compared to the schematic by eye in order to ensure that the two were synchronized. By golly, we certainly knew how to have fun in those days!

~he D~wning of ED~ When discussing the origins of EDA, it's tempting to assume that there was some master plan in mind, which would therefore allow us to plot a linear development from ground zero. In reality, different disciplines in a multitude of organizations, including industry and academia, were all merrily doing their own thing, to the extent that it's a miracle anything came together at all. Also, many interesting computer-aided activities were being pursued during the 1960s that addressed integrated circuit design issues, but we'll start by looking at board-level design, which is easier to comprehend in many ways. Board-level design in the early-1960s was predominantly based on the use of discrete components such as transistors, resistors, and suchlike, and circuit boards themselves were predominantly single- or double-sided (which means that they only had tracks on one or both of their outer surfaces). On the layout side of the fence, a typical design cycle could be viewed as: 9 Initial design layout 9 Artwork generation 9 Manufacturing drawings

2 weeks (Design activity) 2 weeks (Post-design activity) 2 weeks (Post-design activity)

It was recognized that there were significant productivity advantages to be gained by reducing the time and effort associated with the post-design portions of the 2You can always recognize layout draftsmen of yesteryear by the fact that they abhor woolly sweaters (because tiny woolen fibers could become attached to the tape, be included in the artwork, and end up causing process problems and potential short circuits on the resulting circuit board). aThe process of creating circuit boards is more fully described in my book: Bebop to the Boolean Boogie (An Unconventional Guide to Electronics), ISBN 1-878707-22-1, HighTextPublications.


process. Thus, one of the first applications of computer-aided techniques at the board level was for the layout designers to use digitizing tables to capture the initial design layout. First they placed their transparent 4:1 mylar films carrying the sticky footprints and the pen-drawn tracks, pads, and vias onto a back-lit digitizing table. Then they proceeded to digitize and record the locations of all of the entities on the board. The resulting electronic representations could subsequently be used for such purposes as generating film artworks by feeding the data to a photoplotter; generating drawing office quality assembly drawings via a pen plotter; and constructing a wiring list that could be used to assist in the still manually-intensive process of checking the layout against the schematic. The result was a 50% reduction in the time spent on post-design activities. Meanwhile, engineers were starting to make use of analog simulation in the form of a program called SPICE, which stands for Simulation Program with Integrated Circuit Emphasis. As its name might suggest, SPICE (which was designed in the mid-1960s at the University of Berkeley, California) was originally intended for designing integrated circuits, but it quickly found use in analog board-level designs. Textual netlist

Tabular response

Tabular stimulus

Device knowledge database

Figure 5-2: The first analog simulators used text-based input and output In order to use SPICE, the engineer had to provide it with a description of the circuit in the form of a netlist. Initially this was supplied as a set of punched cards called a deck, and the term SPICE deck persists to this day. 141In addition to this netlist, the engineer also had to supply SPICE with a description of the stimulus 4The first iterations of SPICE ran as batch jobs. Later versions came equipped with a simple user interface called Nutmeg, whose name had no relevance beyond the fact that nutmeg is a spice m Oh, how we laughed!

43

44


to be applied to the circuit's inputs. This stimulus was described in terms of voltage and current values presented in tabular form. Similarly, the output from the simulator was also presented in tabular form, which made it an absolute swine to read and comprehend (but it was a whole lot better than trying to perform the calculations by hand) (Figure 5-2). Note that the file formats shown in Figure 5-2 are pseudo formats created solely for the purposes of this illustration (we're not trying to teach SPICE syntax here). Also note that analog simulation is discussed in greater detail in Chapter 11. For the purposes of this discussion, we need only be aware that it began to strike engineers that drawing a circuit diagram on a piece of paper and keying in the netlist by hand was a somewhat painful process. So the next step in the game was to use a program called schematic capture, which could be used to graphically draw the circuit on a computer screen using predefined component symbols and connecting them together. The schematic capture tool could then automatically generate a netlist for use with the analog simulator (Figure 5-3).

Component-leveleohematio !~1=10K

Textual n ~ l l e t W

~ _ _ CI=SUF

To analog simulator

GND=OV

Figure 5-3: Schematic capture could be used to generate a netlist for use with the analog simulator

Thus, engineers took a step towards the light. Strange as it may seem, however, schematic capture was still regarded as an engineering "toy" (or "tool" if you prefer), but it was not considered to represent the final design. The engineer could certainly use the schematic capture utility to print out a circuit diagram, but this diagram was then passed to the drafting office to be manually redrawn to the company standard, and it was several years before the output from schematic capture programs came to be accepted as being correct and archiviable documentation. Be this as it may, the fact that engineers were now generating netlists had a number of important ramifications, not the least that there were now two netlists associated with a design: the one generated by the engineers and the one digitized by the layout designers (albeit in different forms). Thus, the stage was set


for the arrival of tools that could automatically compare the two netlists to ensure that the design and layout databases were synchronized. Still later, automatic layout tools began to appear, which could accept a netlist as input and perform large portions of the layout process by themselves. Meanwhile, digital electronics was starting to gain a stronger foothold, because integrated circuits could be created containing a number of simple digital functions, such as four 2-input AND gates. Thus, in addition to placing the components and generating the connections between them (a process referred to as place-and-route), layout tools were augmented with the ability to experiment by swapping gates between different integrated circuit packages and swapping pins on gates. This lead to what we might refer to as the classical board-level design flow, which involves capturing the design as fiat (non-hierarchical) gateand/or component-level schematics, and communicating the design's topology to layout in the form of a fiat netlist (Figure 5-4). Flat, multi-sheet schematics Flat netliet

Back annotation

Figure 5-4: The classical board-level design flow The reason we describe these schematics as being "fiat" is that, with the exception of partitioning the board into major functional units, board level designers typically make minimal use of hierarchy. One reason for this is that the layout tool assigns individual names to component packages, such as IC1, IC2, IC3, and so forth. At some stage this information has to be back-annotated into the schematic, which can be very complex if the original design was captured in a hierarchical form. By comparison, IC and ASIC designs are not based on components contained in physical packages, so names can be arbitrarily assigned to individual blocks, and designers therefore make far greater use of hierarchic representations (in fact they are obliged to employ such representations due to the relative complexity of their designs).

45

46


~he ~Introduction of H a r d w a r e Description s The classical board-level design flow began to change in the early 1970s with the advent of Programmable Logic Devices (PLDs). Is) In the case of these devices, the designer specified the function the device was to perform using rudimentary, proprietary Hardware Description Languages (I-IDLs) such as ABEL TM from Data I/O | These languages could be used to describe Boolean equations and simple truth tables, and also had additional constructs to declare entities such as registered outputs. The text file containing this description was then fed to a PLD tool that optimized and minimized the Boolean equations, and used a knowledge database to generate a fuse map targeted to a device specified by the user. These fuse files could be created in a number of standard formats such as JEDEC (Figure 5-5).

Textual HDL (e.g. ADEL)

Optimization & minimization

Figure 5-5: One of the first uses of HDLs was to specify the function of PLDs

Fuee file (e.g. JEDEC)


Originally, it was the designer's responsibility to instruct the PLD tool as to which device it should target. But these tools became more sophisticated over time, and later versions allowed the designer to augment the optimization and minimization software's knowledge database with information as to each device's price and availability, along with extra data pertaining to such aspects as the user's own preferences. The tool could then determine the most cost-effective device that could accommodate this particular functional description. The tools were subsequently further augmented with the ability to automatically split large designs across multiple devices. The topic of PLDs is covered in more detail in Chapter 19. For our purposes here we need only note that there were several problems with this early PLD methodology, most of which revolved around the fact that the design of the 5PLDs are discussed in greater detail in Chapter 19

Chapter 5 Capturing and Synthesizing a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. .............

. .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.

.......

. .....................

- .....

board and the design of the programmable devices were almost completely distinct. For example, there weren't any automatic systems in place to ensure that the data associated with different versions and revisions of the board and devices kept in step. Secondly, early PLD tools often automatically dictated which device pins were assigned to which signals. This meant that the person capturing the schematic couldn't connect any wires to the symbol for the programmable device until the PLD tool had been run, which could therefore impact the layout designer. Even worse, modifying the HDL source and re-running the PLD tool could result in the pins being reassigned, which might therefore require modifying the board's layout. Not surprisingly, these problems were somewhat aggravating to all concerned (particularly the layout designer), but we digress ....

)l/ligrating Existing

ate-s

Designs to Ps

Following the introduction of the first PLDs, an interesting flavor of design capture emerged to take account of the fact that so many existing designs were represented as gate-level schematics and netlists. A market emerged for designers to take these designs (or portions thereof), automatically translate the schematics into their HDL equivalents, and then re-implement that design using one or more PLDs. This allowed designers to dramatically reduce the size and cost of new generations of the board-level product with relatively little expenditure of time and effort (Figure 5-6).

Existing gate-level schematic or netlist

Textual HDL

Fuse file

Figure 5-6: Migrating existing gate-level designs to PLD implementations As an interesting counterpoint to this approach, some designers work in sort of the reverse manner. These designers like to take advantage of specifying their design in the form of Boolean equations, but they wish to target a resulting netlist

47

48


toward discrete primitive gate and register devices. One recent example known to

the author involves a medical application, whose designers, for reasons of their own, simply have more confidence in discrete devices as opposed to programmable logic.

~ h e ~Tntroduction of Verilo~ a n d ~ f l D s As was previously noted, the early PLD optimization and minimization tools employed simple proprietary HDLs. This may have remained the case indefinitely, except that other segments of the EDA market also began to employ HDL representations for simulation and logic synthesis, where synthesis was predominantly targeted towards IC and ASIC designs. Initially these simulation and synthesis HDLs were also proprietary, but over time the industry standardized on two languages: VHDL (IEEE 1072) and Verilog (IEEE 1364) (Figure 5-7). ,AL,

13ehavioral

(Algorithmic)

~r dL

~'~,~,~:~,~,~!~,!~:~:;~!~,~!~!i!~!~!~:~!~!i~i~!~i~i:~84:~::i!~!~!~i

VHi )L

~.:. :.........

Verilog

FSM::

Funcr,ional Ir

Structural

9~h

Gat~ . . .

.

.

.

.

.

.

.

.

.

.

.

.

.

Figure 5-7: High-level comparison of Verilog and VHDL The reason Figure 5-7 shows both of these languages as not fully covering gateand switch-level constructs is due to timing. Although each language is capable of representing the functionality of gates and switches, they have varying degrees of success in representing delays, and neither language is fully capable of handling the delay effects seen in deep-submicron integrated circuit technologies (see also the discussions in Chapter 25).


The lowest level of modeling abstraction is called structural, which refers to switch- and gate-level netlists. The next level of abstraction is referred to as functional, which ranges from Boolean equations, through Finite State Machines (FSMs), to Register Transfer Language (RTL) descriptions. (RTL is shown as being at a higher level than FSM, because the latter representations are, by definition, bounded to a finite number of states.) The highest level of modeling abstraction is referred to as behavioral, which is, in the author's humble opinion, a somewhat misleading term, in that all levels of abstraction essentially describe behavior. A more appropriate designation might be algorithmic, but we have to live in harmony with the rest of the world, so we're stuck with "behavioral." Each language has its advocates and its detractors. Proponents of VHDL point to its power, versatility, and capability for extremely high levels of modeling abstraction, while the supporters of Verilog feel that this language is more intuitive to use and more closely relates to the hardware it is employed to represent. During the late 1980's and early 1990's, a period referred to by some observers as "the HDL wars," the advocates of each language loudly proclaimed the early demise of the other. However, it now appears certain that both languages will maintain a significant presence for the foreseeable future. Also of interest is the fact that both VHDL and Verilog support the concept of hierarchy, which is of particular application in the design of ASICs and ICs (but of less interest in the case of board-level designs). The early PLD HDLs did not support the concept of hierarchy, although this has now been added to languages like ABEL. Many of the early HDLs are still in use, because a great many tools have been developed to generate and process them over the years. However, a large proportion of such tools now also accept VHDL, Verilog, or both.

~op-Down, ~iddle-Out, ~nd ~ottom-lAp There are three distinct design methodologies that are commonly referred to as top-down, middle-out, and bottom-up. A top-down methodology means that the designer specifies the design, or portions thereof, at a high level of abstraction, and subsequently progresses the design to the implementation level (where the implementation level is considered to be the lowest level with which a designer is concerned; for example, a gate-level netlist in the case of a digital designer or a transistor-level netlist in the case of an analog designer). In practice, designers always employ a top-down methodology in the initial stages of a design, even if only as a paper exercise (it's rare indeed for a designer to run into the office shouting: "Look at this great new device, now what can we design around it?"). A middle-out methodology refers to the use of previously created functions. These functions may range in complexity from relatively simple ASIC macro-

49

50


functions, through discrete integrated circuits (ICs), to complete sub-systems. Last but not least, a bottom-up methodology means that the designer directly implements the design, or portions thereof, at the lowest levels of abstraction, such as transistors, primitive logic functions, or ASIC cells. Prior to the use of HDLs combined with the minimization and optimization software used to design programmable logic devices, the top-down component of the design process typically only encompassed the partitioning of the design into a hierarchy of functional blocks. These functional blocks were then progressed to the implementation level using either the middle-out or bottom-up methodologies. The introduction of PLD techniques (followed by synthesis technology as discussed below) augmented the top-down design methodology by providing an automated technique to progress the design, or portions thereof, from a high level of abstraction to the implementation level. In reality, however, complex designs are rarely amenable to the use of a single design methodology, and designers must therefore have the ability to combine top-down, middle-out, and bottom-up techniques.

~raphical Entry ,Mechanisms An important consideration pertaining to the use of HDLs is their software nature. Hardware engineers often find it difficult to visualize a design in terms of an HDL, and many designers find HDLs too verbose and difficult to enter textually. These problems are best alleviated by graphical entry mechanisms, which more closely reflect the way in which designers think; for example, state-diagram and flowchart editors (Figure 5-8). Graphical etate diagram

Textual HDL (Verilog, VHDL, ABEL.... ) Graphical flowchart,

To logic synthesis

Figure 5-8: Graphical entry mechanisms can be used to generate HDL representations


A key feature of these graphical entry mechanisms is that they are capable of automatically generating simulatable and synthesizable HDL representations. Additionally, many of these tools provide the ability to select between alternative HDLs, which allows the designer to take full advantage of various technologyspecific tools.

s

Synthesis and s

Design

One of the strange aspects about the electronics industry is the way in which devices and methodologies appear, fade away, and reappear in different guises. 11 t.,lUq~:::~LIUII~:~U ~ l l l O . l l y

WUUlU

I.,tUIIIL LU LII~:~ t:~Ci/[Iy-J. 7 O U ~

C:l.b LIIt~ ~:~lllt~l~::~:~lll~t~ U I

tll~

ASIC, but the concept actually originated one and a half decades earlier, thereby occurring alongside the introduction of the first rudimentary (and conceptually much simpler) programmable logic devices. In 1967, Fairchild introduced a device called the Micromosaic, which contained a few hundred transistors. The key feature of the Micromosaic was that the transistors were not initially connected together. A designer used a computer program to specify the function the device was required to perform, and the program then determined the necessary interconnections and generated the masks required to complete the device. The Micromosaic therefore led the field as the forerunner to the modern ASIC, and also as one of the first real applications of computer-aided design. This device also exhibited one of the first examples, albeit rudimentary, of high-level design coupled with logic synthesis. Had the concepts behind Micromosaic been pursued, high-level design techniques would almost certainly have enjoyed widespread acceptance much sooner than they did, but, unfortunately, this technology faded away into the background for a while. This meant that when the use of ASICs started to become somewhat more commonplace in the early-1980s, their design methodologies were based on the traditional techniques that had been established for circuit boards. Thus, the designers of early ASICs used schematic capture to describe the function of their circuit as primitive logic functions and the connections between them. The schematic approach does convey certain advantages, not the least that it reflects the way in which designers think at the lowest level of abstraction, and it also allows expert designers to hand-craft extremely efficient functions. However, gate-level schematics are time consuming to enter and they don't lend themselves to "what-if" analysis at the architectural level. Also, verification using simulation is extremely CPU intensive at the gate level, and it is difficult to re-target gate-level schematics to new device technologies.

51

52


Since the early ASICs typically only supported between 2,000 and 5,000 primitive gates, the schematic capture approach was at least tenable, and it remained in force throughout most of the 1980s. However, as gate counts continues to rise through 10,000, 15,000, 20,000, and beyond, it became increasingly difficult to design these devices using traditional techniques. Thus, the late-1980s and the early-1990s saw increasing use of Language-Driven Design (LDD), which involved the combination of HDLs and logic synthesis technology (Figure 5-9). Textual HDL

Figure 5-9: Language-driven design refers to the combination of HDLs and synthesis technology

Gate-level netllet

Device

knowl~ge

database

Logic synthesis itself involves two distinct steps. First, the high-level HDL description is converted into a canonical form such as "sum-of-products"; second, these expressions are optimized and minimized taking into account the features of the target technology, such as how many loads each type of gate can drive. Also, designers can specify constraints such as maximum delay paths through the device, and the user can also instruct the synthesis tool to optimize different portions of the design to minimize either their delays or the area they occupy on the device. The early examples of language-driven design involved proprietary languages, but (as we've already discussed) the electronics industry eventually (largely) standardized on VHDL and Verilog. These HDLs are appropriate for describing both control and datapath logic at a reasonably high level of abstraction. This means that in the early stages of a project, the designer can concentrate on the architecture of the design as opposed to worrying about implementation details. Also, it is much more efficient to simulate designs at a high level of abstraction compared to the gate level, and it is far easier to perform "what-if" analysis at the architectural level. Synthesis technology then allows these high-level representations to be migrated to the implementation level, and it facilitates design reuse by allowing the design to be re-targeted to alternative implementation technologies.


Unfortunately, neither VHDL or Verilog were conceived with synthesis in mind (Verilog was initially targeted towards simulation, while VHDL was intended for documentation), which means that one can use these languages to describe constructs that cannot be synthesized (Figure 5-10). AL

Not amenable to

eyntheele ueing

15ehaviorai

tra~litional teehniquee

(Algorithmic)

~L Functional

Structural ,

VHDL Verilog

r Can be eyntheeized ueing traditional techniquee

i i i i i i!iijZiiiiiii!iiiii!iiiiiiii!i!i i!iii i i iiiiii!iiiiiiiiii!iiiiiii i iiiiiii!iiiiiiii Figure 5-I0: Verilog and VHDL both support constructs that can't be synthesized

To solve these problems, the Japanese came up with their own HDL called UDL/I, which was designed with synthesis and simulation in mind. Unfortunately, by the time UDL/I, arrived on the scene, Verilog and VHDL already held the high ground, and it never managed to attract much attention outside of Japan (interest in UDL/I is now almost non-existent even in Japan). LDD methodologies also have other problems, such as the fact that the textual gate-level netlists generated by synthesis tools are difficult to comprehend. Hence, another tool that began to appear was schematic synthesis, which accepts a gate-level netlist and automatically generates an equivalent schematic (Figure 5-11).

53

54

DesignusMaximus Unleashed! Textual HDL

Gate-level netiist

Gate-level schematic

Figure 5-1 I: Schematic synthesis helps designers "visualize" the results from logic synthesis LDD techniques are generally accepted to increase designer productivity (in terms of gates-per-day) by a factor of ten compared to designing at the gatelevel. Based on these promises of delectation and delight, a number of early adopters became overly enthusiastic, in that they decided LDD was the only way to go and discarded schematics as being "yesterday's technology." However, in addition to having to learn an HDL along with any associated software design techniques and disciplines, designers also have to learn how certain constructs and statements affect the synthesis tool. Today's synthesis tools are very powerful, but although it's possible to obtain good results (in the form of small and efficient designs), it's also easy for designs to get "out-of-control." Also, writing HDL code in two different ways which simulate exactly the same at the RTL level can synthesize to radically different gate-level implementations.

Mixed-s

Design

Although language-driven design can be very effective, certain portions of designs may not be amenable to logic synthesis techniques, in which case these portions inherently have to be captured at the gate level. Thus, the industry came to realize that schematics still had a role to play: first in describing the design graphically in terms of high-level functional blocks and the connections between them; and second, in describing certain portions of the design at the gate level. The resulting "mixed-level" design style offered the best of both worlds by allowing designers to mix schematic and HDL representations together.

............................................................................................

-::- ...........

: ...............................................


~::

.................................

: .............................................

--:::::.::

_. . . . . . . . . : . . . . . . . . . . . . .

: ..................................

- .............

: ..............................................

_:_

These systems were subsequently further extended to incorporate additional graphical entry mechanisms, such as the state-diagram and flowchart editors that had originally been conceived as standalone applications for programmable logic devices. Thus, today's mixed-level design capture systems support multiple entry mechanisms in a heterogeneous environment, thereby allowing designers to use the most appropriate tool for each portion of the design (Figure 5-12).

Textual HDL

Graphical State Diagram ~ii~ii!iiii~iiiiiiiiiiii!i~i~iiiiii!ii~i~i~i~i~i~i~i~i~i~ii~ii~i~i~i~i~i~i~ii~i~!i~i~` i iiili!~

:~ii!iiii!i!iiiii

~

~

z

9

,

,

Block-level , schematic /

~ii~i~!i~i~i~i~i~i!i~i~i~ii~ii~iii!ii~iii~i~ii~ii~i~i~i!~i!ii~!i~i~i~i~i~i~i!~i~i~i~i

when clock ri~ee /

then y = (a & b) I c; else y = c & 1(~1 ^ e);

I

::~::~:: :::::::::::::::::::::::~::~::~:~::~::~::~::~ ~:::~:::::::: ~ ~~~~:~:~ ~~:~

ii!i',',i',i~,!i i}i!ili

i}i'~i~i'~ii'~i / iiiii}iii! /

i,~ii,~~,i~,~i

i,,i,i,i,i,i,i~,~::: ~,

Graphical Flowcha~

~iii~ i

",, ,~ ........................

Gate-level schematic

Figure 5-12: Mixed-level systems ollow eoch podion ot the design to be represented at the most appropriate level of abstraction In this scenario, designers commence by creating a block-level schematic at a high level of abstraction. When designers subsequently decide to "push" into a block, they can choose to represent its contents as a flowchart, a state diagram, textual HDL, or a gate-level schematic. Furthermore, modern capture systems support the concept of "views," in which each block may have multiple representations at varying levels of abstraction. Also note that we've only introduced some of the more prominent design capture tools here, but that many more are available. For example, there are tools that accept HDL descriptions of state machines as input and synthesize their graphical counterparts, while other tools can be used to input a state machine in hand-entered HDL and generate a corresponding HDL output that's optimized for simulation and synthesis, and the list of such applications goes on, and on, and ......

55

56


The topic in this chapter wae published in an edited form in Electronics Design & Technology Network (EDTN) in July 1997, and is reproduced in ire original form here with their kincl permission. EDTN is a web-only publication for electronic~ engineer~, and provicle~ know-how, news, and clara eheet ~pecificatione for a broad range of technologies. It'~ actually pretty cool, and well worth your checking them out at www.~tn.com For your ruff, her reading pleasure, an excellent guide to the uee of hardware cleecription language~ is HDL Chip Deeign (A Practical Guide

for Deeigning, Syntheeizing, and Simulating ASICe and FPGAe ueing VHDL or Verilog) by Doug Smith, lSBN 0-9651934-3-&, Doone

Publications (www.cloone.com, call 1-800-311-3753).

With regard to the cleeign tools cllecues~ in this chapter, there are a number of venclore of euch appiicatione, anti new featuree anti techniquee become available on an almoet dally baeis. A great etarr, ing point, however, would be VeriBeet Inc., Boulder, CO, USA (www.veribeet.com, call 1-&OO-VEI~II3EST), who can eupply capture, eimulation, eynth~ie, anti layout utilitlee, either ae inclivicluai applicatione or ae an i n t e g r a ~ euite.

Chapter 6:

Digital Logic Simulation "Event-driven, cycle-based, hardware, and home-brewed"

In this chapter you will discover: From " S u c k - i t - a n d - S e e " t o S i m u l a t i o n ........................................................................ 58 T r a d i t i o n a l L o g i c S i m u l a t i o n .............................................................................................................. 58 Verilog a n d VHDL ........................................................................................................................................ 60 E v e n t - D r i v e n Simulators .............................................................................................................................. 61 D i s t r i b u t e d D e l a y s a n d N a r r o w Pulses ........................................................................ 63 M i x e d - L e v e l S i m u l a t i o n ..................................................................................................................... 66 C y c l e - B a s e d Simulators ................................................................................................................. 68 H o m e - B r e w e d Simulators .............................................................................................................. 69 H a r d w a r e Simulators A K A H a r d w a r e E m u l a t o r s ............................... 70

8


~ r o m HSuck-it-and-See" to S i m u l a t i o n There are a number of techniques that can be employed to verify the functionality of a digital circuit, ranging from the "suck-it-and-see" approach (which means that first you build it and then you see if it works), through various flavors of logic simulation, all the way up to formal verification technology. Prior to the advent of computer-aided techniques, the only way to determine whether or not your circuit would work was to use a technique called breadboarding, in which you insert components into a special circuit board, use small wires with pins on the end to connect the components together, and then power up the circuit to see if it functions as planned. The breadboarding technique is still used for portions of board-level designs to this day, but this approach is extremely inefficient for large circuits. Thus, during the mid to late 1970s, a number of programs known as digital logic simulators started to become commercially available.

~raditional s

Simulation

When digital simulation first arrived on the scene, the majority of board-level digital circuit boards consisted of simple logic functions (gates and registers) implemented in a technology known as Transistor-TransistorLogic (TTL). Both of these factors were to have significant implications as to the way in which early logic simulators were conceived and designed. In order to use one of these early logic simulators, the engineer was obliged to provide it with a description of the circuit in the form of a gate-level netlist. In addition to the netlist, the engineer also had to supply the simulator with a description of the stimulus to be applied to the circuit's inputs, where this stimulus was presented as a text file in tabular form. Similarly, the output from the simulator was presented in tabular form, which made it awkward to read and comprehend (Figure 6-1). Note that the file formats shown in Figure 6-1 are pseudo formats created solely for the purposes of this illustration. When the circuit is passed to the simulator, it accesses a pre-defined model library to determine the functionality and timing associated with each component, and then constructs a virtual circuit in the computer's memory. The simulator then applies the test vectors to the circuit and reports the results.

Chapter 6 Digital Logic Simulation Textual netlist

Tabular response

Tabular stimulus


Figure 6-I: The first digital simulators used text-based input and output

As computers became more powerful, these time-consuming and error-prone text-based techniques were superseded by graphical methods for capturing the schematic and stimulus and displaying the results (Figure 6-2). Gate-level schematic

Graphical response

I Graphical stimulus i _

I mU

iiii1iiii~i~!ii~iiiiiiiiiiiiiiiiiiiiiii

iiiiiIiiii

I

LI

F1

I_I-LI

I

_

I

I-l__ Lira1


Figure 6-2: Later digital simulators employed graphical input and output techniques

Note that the circuit can be described at many levels of abstraction, including flowcharts, state diagrams, and high-level hardware description language (HDL)

59

60


representations (see also the discussions in Chapter 5). For the sake of simplicity, however, these discussions concentrate on gate-level views of the circuit, but the following points are typically applicable to all levels of modeling abstraction. Also, although we're predominantly going to consider gate-level views, the simulation models for these gate-level components could themselves be represented at different levels of abstraction.

Verilog a n d "VHDs Early logic simulators were typically based on the concept of "simulation primitives" (simple logic gates and registers which were often represented as truth tables and which were inherently understood by the simulator), and any other devices were obliged to be modeled as a collection of these primitives. Later simulators used a plethora of proprietary hardware description languages, but the industry has now largely standardized on two main "tongues", Verilog and VHDL, which are described by the IEEE 1364 and 1076 standards, respectively (Figure 6-3).

B~havioral

(Al~orithmic) ..........

i ......................

!

VHDL

Ir "

............

...........i i.........

::

FunoCional if! .:

n

i.~

1

5truoCural

Figure 6-3: High-level comparison of Verilog and VHDL Both Verilog and VHDL can describe circuits at different levels of abstraction, from primitive switches and gates to behavioral representations. In some respects VHDL is more powerful than Verilog at the behavioral level; however, the majority of today's synthesis tools cannot accept anything more abstract than register transfer language (RTL) descriptions, which tends to level the playing field between the two languages. Note that Figure 6-3 indicates that neither Verilog nor VHDL completely cover the switch and gate levels. This is because

Chapter 6 Digital Logic Simulation although both languages can represent the functionality of these primitive elements, they have varying amounts of success when it comes to modeling sophisticated timing effects, and neither language can completely handle the more esoteric delay models required for deep submicron technologies (see also Chapter 25). But we digress .....

Event-Driven Simulators The most common form of logic simulation is classed as event-driven, because the simulator sees the world as a series of discrete events. When an input value ....

-.__-zJ-_

_

_ _ r

U I I Cl I O I I I I I I L I V ~ ~r

_L

. . . . .

L;II,ClII~

r

_" . . . .

1_r

. . . . . . .

!..--r

r

----r

r

LII~ ~IIIII..ILIQLUI ~VClILIClLtc:~ LII~ ~:~O.Lt:~ L U

- 1 _ r

LI~:~Lt::~IIIIIIIt:~

whether this will cause a change at the output and, if so, the simulator schedules an event for some time in the future (Figure 6-4).

,

b

I

c O~

Current

time

Future

time

Figure 6-4: The simulator evaluates the effects of changes on a gate's input(s) and schedules future events to occur on the gate's output(s)

In fact, most event-driven logic simulators allow you to attach minimum, ~ i c a l , and maximum (min.~yp:max)delays to each model. This allows us to represent the fact that electronic devices switch at different speeds depending on environmental conditions such as their temperature and voltage supply (which can vary across a circuit board), and also that slight variations in the manufacturing process cause differences in the switching speeds of otherwise iden~cal integrated circuits (Figure 6-5). Note that LH (meaning "low-to-high") and HL (meaning "high-to-low")are used to represent rising and falling transitions at the gate's output, respectively. For example, assume that the OR gate in Figure 6-5 was specified as having a LH delay of 5:10"15 n~ (where ns is the abbreviation for nanoseconds, meaning one thousandth of one millionth of a second, or 10 .9 seconds). This would mean that any change on an input causing the output to transition from a logic 0 to a logic 1 would take a minimum of 5 ns and a maximum of 15 ns to propagate through the gate and affect its ou~ut.

61

62

DesignusMaximus Unleashed! LH = min:typ:max HL = min:typ:max

O~ Note t h a t LH and HL repreeent rising anti failing traneitione at the output, respectively

i

!

mln i i :

i

i I?lax

i

i

Figure 6-5: Many logic simulators support min:typ:max delays When you run the simulator, you can select one of the min.r delay modes and the simulator will use that mode for all of the gates in the circuit. Also, some simulators allow you to select one delay mode as the default, and then force certain gates to adopt another mode. For example, you might set all the gates in your datapath to use minimum delays and all the gates in your control path to use maximum delays, thereby allowing you to perform a "cheap and cheerful" form of timing analysis (see also Chapter 7). One of the problems facing the creators of simulation models is that delay specifications are becoming more complex over time. In the early 1970s, it was common for all the delays of a simple gate to be specified in the data book as being identical. Over time, however, delays began to be specified more accurately, and today each input to output path typically has its own delay for both rising and falling transitions at the output (Figure 6-6). l a,b-> a,b-> a,b->

yb

Figure 6-6: Delay specifications have become more complex over time

y,yb

= ? ' ? ' ? ns

y yb

-- ? - ? ' ? - ?'?'?

~ l~T/Oe

ns ns

a,b-> y(LH)? ' ? ' ? ns ]1 a,b-> y(HL)? ' ? ' ? ns a,b -> y b ( L H ) = ? ' ? ' ? n s a,b-> yb(HL)?-?-? n s a a b b a a b b

-> -> -> -> -> -> -> ->

y(LH)y(HL)y(LH) y(HL) yb(LH)yb(HL)= yb(LH) yb(HL)

= = = -

?:?:? ?:?:? ?:?:? ?:?:? ?:?:? ?:?:? ?:?:? ?:?:?

ns ns ns ns ns ns ns ns

I

1990s

Chapter 6 Digital Logic Simulation Another problem facing designers is that each tool (such as simulation and synthesis) typically has its own model library, and it's frightening how often different tools return different delays. One trend I think we'll see is for the timing and functionality portions of models to become separate and distinct entities, c~ and something that needs to happen in the not-so-distant future is for diverse tools to make use of common timing libraries. I can envision a day when all of the tools use a common timing model that returns different levels of accuracy depending on the information that is fed into it. Thus, in the early (pre-layout) part of the design cycle the timing model would return delays at one level of accuracy, and these delays would become increasingly accurate as more and more information becomes available throughout the course of the design.

Distributed Delays and

larrow Pulses

In the early simulators, it was only possible to attach delays to primitive elements. Thus, .when you built a model such as a multiplexer, you had to distribute the delays over the primitive elements forming that model; this was known as the "distributed delay" style of modeling (and it was a complete pain in the rear end, let me tell you) (Figure 6-7a).

Individual gate delays .__ ...............

........

..................

Total path delays ..............................

o_---~--____...............................

a

L

-

(a) Distributed delays

iiiiiiiiiiiililil i,,!:

(b) Pn-Pn delays

Figure 6-7- Early logic simulators only supported distributed delays, but modern tools also support pin-to-pin (Pn-Pn) specifications The problem was that data books only give delays from the component's inputs to its outputs, so it was up to the person writing the models to fragment these delays and distribute portions of them throughout the model in order to achieve the correct total delays through each path (you can always tell an old simulation 11accept that this is non-trivial in certain cases such as negative setup and hold violations, but it can be done with a little thought.

63

64

DesignusMaximus Unleashed/

modeler by the fact that they're phenomenally good at solving simultaneous equations). By comparison, modern simulators usually support Pin-to-Pin (Pn-Pn) delay specifications, which can be taken straight from the data book and applied as total path delays from the component's inputs to its outputs (Figure 6-7b). Note that the term Pin-to-Pin (Pn-Pn) One of the arguments in favor of the delay means different things to distributed delay style of modeling is that it cli~erent people. Design engineers provides better handling of narrow pulses regard Pn-Pn delays as being the and is closer to the real world. (Of course, delays through a component from it~ this point is usually put forward by the inputs to it~ outputs. By comparison, vendors who don't support Pn-Pn delay layout cleeigners are typically not specifications.) This argument is countered concerned about what's in an by fact that a model's contents usually bear Integrated circuit package, and they only a passing correspondence to the usually u~e the term Pin-to-Pin delay internal structures of the physical device, so to refer to the time it takes a ~ignal the way in which distributed delay models to propagate from one component's handle narrow pulses is speculative at best. output, through a track, to another component's Input (deeign engineer~ Another interesting delay effect is that pulses would call the~e Point-to-Point (Ptcan be stretched or compressed as they pass Pt) clelay~). In this book we're using through gates due to "unbalanced delays" Pn-Pn and Pt-Pt to refer to on those gates (Figure 6-8). component and track clelays,

LH = lOne HL = 6ne

:=~

24he

==

,

=

'

'

I i

I , ,

,

, ,

16he

,

I i F"

Figure 6-8: U n b a l a n c e d

I 20ns

:: v;

d e l a y s c a n "stretch" or " c o m p r e s s " pulses

Note that Figure 6-8 only shows typical delays for reasons of simplicity. Due to the fact that the rising delay is larger than the falling delay in this example, a positive-going pulse applied to the input is compressed by the difference between the two delays. Similarly, a negative-going pulse applied to the input would be

Chapter 6 Digital Logic Simulation stretched by the difference. Also remember that the LH and HL annotations apply to transitions at the output, so if the gate includes a negation (such as a NOT, NAND, or NOR), then the opposite effect will occur (Figure 6-9). LH = l O n s HL = 6ns

24ne

~.-

j6ns i~ ~i ,

~ lOns

',

28ns

Figure 6-9: An inverting gate has the opposite effect This leads us nicely into the consideration of what the simulator does with narrow pulses; that is, what occurs when a pulse is applied to a gate's input when that pulse is narrower than the propagation delay of the gate. The first logic simulators were targeted toward simple TTL devices at the board level. These devices typically rejected narrow pulses, so that's what the simulators did, and this was called the "inertial delay model" (Figure 6-10). 15ns LH & HL = l O n s

a

.

y

~

.

.

6nsi .

~

Rejected

Passe~

Figure 6-10: The inertial delay model rejects any pulse that is narrower than the gate's propagation delay However, later technologies like ECL will pass pulses that are narrower than their propagation delays (as will devices such as delay lines), so the next step was for the modeler to be able to select between the inertial delay model and a "transport delay model" (Figure 6-11). 6nee ,.,=

LH & HL = lOns

a

~',

5

a

I

y

Passes

Y i

lOn~

i

Figure 6-1 I. The transport delay model propagates any pulse, irrespective of its width

65

66

DesignusMaximus Unleashed/ The problem with both the inertial and transport delay models is that they only provide for extreme cases. Over time, simulators began to use more sophisticated narrow pulse handling techniques, leading to the current state of the art which is knows as the "3-band delay mode/" (Figure 6-12). i

Tp

:

0%

r% >=p%

LH & HL = Tp v

propa~ja'r~e

I

I

I I

vl

p%

100%

>=r%, 1;

ENDCASE;

~el Figure 10- I: Pseudo HDL for a 2: I multiplexer using ? = "don't care" states

For the sake of completeness (and to prevent me from receiving a mailbag of irate letters), we should also note that some HDLs do permit "don't care" values to be assigned to outputs. In this case, however, the "don't cares" are intended for future use by a logic synthesis utility and not by the digital simulator itself (the simulator automatically converts these assignments to unknown • values at run time). One of the most common mistakes made by novice simulation modelers is that data-books tend to use • characters to represent "don't care" conditions. If the model writer neglects to translate these into 7s which represent "don't cares" to the simulator, then somewhere down the line, some poor soul is going to spend one heck of a long time trying to figure out what's happening (and l'm tired of that someone being myself). (~I

{~lhat D o e s "qdnknown" ~qctually ]~ean? A significant problem with today's digital simulators is that they tend to use Xs to represent a wide variety of different conditions depending on the portion of the circuit in which they appear. For example, consider a D-type flip flop (Figure 10-2).

D-type

o 0

::•ii]i!]i•iii•iiii!•ii!•!•i•!ii••iii!i•i!iii}iii•i•i•iiiiiiii}!i!!•iiiiii•iii•i•i!i!i!ii

clock

1Call me "old-fashioned" if you will.

q

x

i

iii clear

i

..... ~:~ .....

Figure 10-2: X values can be used to represent uninitialized registers

109

110 Designus Maximus Unleashed! Let's assume that power has recently been applied to the system and that the register was powered-up with its clear input in the inactive state. Thus, the unknown X value on the register's output represents an uninitialized state. Additionally, if we assume that sufficient time has elapsed for the register to stabilize internally, then we may also say that this X represents a good, stable logic 0 or logic I value, we just don't happen to know which particular logic value it is. Now consider two tri-state buffers driving the same node. Let's assume that both of the buffers are enabled, and that one is attempting to drive a logic 0 value while the other is attempting to drive a logic I (Figure 10-3).

0

0

Figure 10-3: X values can be used to clashes between multiple signals driving the same wire

In this case, the physical voltage on the output depends on the relative drive strengths of the two tri-state buffers, and the X may be used by the simulator to "warn" downstream logic functions that this signal is unknown. In a worse-case scenario, this X potentially represents an uncontrolled oscillation of unknown frequency and unknown amplitude. As a final example, consider three inverters connected so as to form a feedback loop (Figure 10-4).

Figure 10-4: X values can be used to represent a controlled oscillation

In this case, the X being generated by the inverter loop actually represents a controlled oscillation between good logic 0 and logic I values (in this context, the term "good" refers to the fact that the output isn't stuck at an intermediate voltage level, but that it is achieving real logic 0 and logic I thresholds). So without trying particularly hard we've discovered three cases where the simulator might use an • value to represent different things. In fact the logic value sets employed by some HDLs do support the concept of an uninitialized U value (for example, the VHDL "Standard Logic Value" set as defined in the IEEE

.....

~ = ~ _

.........

- ....................

~

.............

---.~.~-~

. . . . . . . . . . . . . .

--~:

:~

.

.

.

.

.

.

:.~

. . . . . . .

-~ ~ ....

. . . . . . . . . . . . . . . . . . .

:~

Chapter I0 UnknownX Values 111 - .......

.................

1164). 121These U values can be used to distinguish uninitialized registers from other types of Xs, but the situation is still far from satisfactory ......

IMho's ~ a k i n g

the Decisions ~qround Here 7qnyway?

If you're using digital simulation to verify a design, and if your company is creating its own simulation models, then it is absolutely imperative for the project leaders to decide and document exactly what they want X values to represent (or, more precisely, how they want their simulation modelsto deal with Xs). For example, consider the case of a 2:1 multiplexer, which has logic I values presented to both of its data inputs and an X presented to its select input (Figure 10-5).

2:1 Mux What should the output value be?

sel Figure I0-5: Someone has to decide what happens when an X value is presented to a multiplexer's select input

The decision that has to be made is: "What do we want this model to generate as its output?" Remember that the X driving the multiplexer's select input is coming from some other part of the circuit (as seen by the simulator). But the simulator (and thus the person writing the model) cannot differentiate between Xs, and it is therefore not possible to determine what any particular X represents. One option is to assume that Xs are generally "well-behaved"; that is, that an X either represents a stable logic 0 or logic I as shown in Figure 10-2, or even well-defined oscillation as shown in Figure 10-4. If we do decide to assume that Xs are well-behaved, then we may take the optimistic attitude that the output from the multiplexer should be a logic 1, on the basis that if both of the inputs are logic 1, then it doesn't really matter which one is being selected. On the other hand, if we acknowledge that Xs may actually represent an uncontrolled oscillation of unknown frequency and amplitude, then we should really take the pessimistic approach and cause the output to drive an X.

2This nine-value set is sometimes unofficiallyreferred to as MVL-9.

112 Designus Maxirnus Unleashed! e r i n g i n g Whiners or i~eckless ~hrill-$eekers? We can use the final decision to judge the cowardliness versus aggressiveness of the project-leaders. Are they merely cringing whiners of no account, or are they reckless irresponsible thrill-seekers who want to obtain an adrenaline-rush on the company's budget? Actually, l'm not advocating any particular view as to how Xs should be treated (I could but I won't), but I am stating that someone, somewhere has to make an informed decision. The absolutely worse thing that can happen is for different models to be created by multiple modelers without any documented standard as to how their models should view and handle ;Ks. If this is the case, then "Murphy's Law '131dictates that the different modelers are guaranteed to use different approaches. The result is that, without a company standard, the end-user doesn't know what any individual model may do when presented with unknown X values. If a designer uses two models with identical functions but created by different modelers, the models could respond differently to the same stimulus (this is generally not considered to be a good thing to happen). Even worse, consider a case where one model is a high-drive equivalent of the other; by simply exchanging models to test the effects of using a different drive capability, designers may completely change their simulation results, which can potentially consume endless painful hours before it's tracked down to differences in the way in which the two simulation models handle • values. 141

~Cs a n d ~ l n i t i a l i z a t i o n X values can perform a number of different (and, as we have seen, often incompatible) roles in digital simulation, but one very common role is that of indicating uninitialized elements. In this case, some users take the view that every memory element should power-up containing ~ , and if can't clear them out as part of your initialization sequence then "shame on you." In the real world, however, there's no such thing as an • and designers are endlessly inventive in making use of the fact that, in certain cases, it doesn't matter whether a particular element contains a logic 0 or a logic 1. For example, consider a number of D-type registers configured as a divide-by-n counter. In some applications, the designer may simply not care how the individual elements of the counter initialize, so long as the little rascal counts. Now a purist would 3Anything that can go wrong will go wrong! This was first espoused in a more sophisticated form by Captain Edward A. Murphy in 1949 as a good working assumption in safety-critical engineering. 41n addition to internally-developed models, it is also necessary to define exactly what you expect when you're acquiring models from outside sources; especially if these models are coming from multiple vendors.

Chapter 10 Unknown X Values

recommend using registers with clear inputs, but the overhead of tracking an additional clear signal around the circuit may be unacceptable to the designer. Similarly, in the case of RAMs, one would generally both expect and require them to power-up with Xs in the simulation to indicate that they contain random logic 0 and logic I values. However, if the output from the RAM feeds into some other logic such as a state machine which has already been initialized, then the Xs from the RAM may "escape" into this downstream logic and "poison it." Unfortunately, there is no all-embracing answer that covers every situation. Almost every digital simulator will allow you to "force" a value onto a selected signal. For example, in the case of the inverter loop we discussed in Figure 10-4, it would be possible to force one of the signals forming the loop to a logic O, hold that value for a sufficient amount of time for its effect to propagate around the loop, and then remove the forced value to leave the loop acting as an oscillator. However, you are advised to be parsimonious in your use of this technique, because you've just introduced something into your simulation that does not reflect the circuit's real world behavior, and it is not uncommon for problems to arise sometime in the future when the circuit is revised. In particular, you must document what you've done and ensure that other team members are aware of your use of this methodology. Another common technique is to use an internal simulator function to randomly coerce uninitialized • values into logic Os and logic ls. This can be a very useful strategy, but, if the simulator supports it, you should restrain yourself to only targeting specific "trouble spots." Also, at a minimum, you must ensure that you repeat the simulation with a variety of different random seed values. Perhaps the best advice one can offer is that hardware initialization techniques should be employed wherever possible, and that simulator "tricks" should be used sparingly and with caution. It is not unheard of (he said tongue-in-cheek) for a design to function in the simulation domain only to fail on the test bench, because the designer used the simulator to force conditions that simply could not occur in the physical world.

Xs in ~ i x e d - S i g n a l Environments Last but not least, particular care must be taken with regard to ~ in mixed-signal designs, in which a digital simulator is interfaced to, and is simulating concurrently with, an analog simulator. Obviously, X values are absolutely meaningless in the analog domain, so they have to be coerced into voltage levels representing artificial logic Os and logic l s as they are passed from the digital simulator to its analog counterpart.

11 3

114 DesignusMaximusUnleashed! The problem is that the analog portion of the circuit can act like an "X filter." For example, consider a digital portion of a circuit containing uninitialized Xs driving into an analog portion, which in turn feeds back into the digital portion. The simulation environment will remove Xs by coercing them into logic Os and logic l s as the signals move across the digital-to-analog boundary, but there is no way to restore them at the analog-to-digital interface. Thus, the down-stream digital portion of the circuit sees an optimistic view of the world, which may lead portions of the circuit to appear to be initialized when, in fact, they are not. Some mixed-signal simulation environments only offer the option to coerce the • values into logic Os (or logic ls) as they are handed over to the analog simulator. This technique should generally be avoided at all costs. Wherever possible, you should employ the technique of coercing the Xs to random logic Os and logic l s. Additionally, some systems combine an initial random assignment with the fact that every subsequent X on that signal will be alternately coerced to the opposite logic value to the one used previously. In all of these cases, you should plan on performing a number of simulations using a variety of random seed values. The moral of our story is that X values should be treated with both respect (they can be extremely useful) and caution (they can potentially be the source of diverse and subtle problems). It is not enough to simply say that Xs mean unknown, because first we have to define what we mean by "unknown." Similarly, it is absolutely essential to ensure that everyone involved in creating and using a particular set of simulation models is in complete agreement as to exactly how they expect those models to behave, both in the way the models generate ~ and the way in which they respond to them.

Xs of the 3uture The • values that we know and love so well are not necessarily be the same Xs we will play with in the future. There are a number of possibilities for the evolution of Xs that developers of digital simulators might consider should circuit designers determine that they need such capabilities. A few of these options are introduced below.

Static versus Dynamic ,Ks As we previously discussed, one of the problems with current digital simulation technology is that ~ are used to represent multiple conditions, from a steadystate and well-behaved unknown (which we might call a "static X"), all the way through to an uncontrolled oscillation of unknown frequency and unknown amplitude (which we may call a "dynamic X"). One solution would be for the

Chapter 10 Unknown X Values ,,,,,

.

.

.

.

,,

,

,, .

.

.

.

,r

,,,,,,,

r, ..........

,, r

,

,,

,r,,

,

,,

,,,

both the designer and the simulator to be able to distinguish between these extremes. For example, we might use two symbols, X and #X, to represent static and dynamic unknowns, respectively. In this case, an uninitialized register element (as shown in Figure 10-2) could generate well-behaved X values, while two gates driving incompatible values onto a common signal (as was illustrated in Figure 10-3) could result in a more pessimistic #X value. To illustrate one possible application of how these two values could be used, consider a modified pseudo HDL representation of a 2:1 multiplexer (Figure 10-6). 2:1 Mux

liHiiiiiHHii il

Y

h.~ v

II

A

!

y := CASE {sel} OF 0 => a, l=>b, X => aEQU b, #X => #X; ENDCASE;

sel

Figure 10-6: Pseudo HDL for a 2: I multiplexer using X and #X values

Note that for the purposes of this discussion, the EQU operator in our pseudoHDL is assumed to return an X if the values on inputs a and b are different, and it will return whichever value is on a and b if they are the same. As we see, unlike today's digital simulators in which everyone involved (the model writer and the model user) would have to agree whether an unknown X applied to the select input would cause an optimistic or pessimistic response at the output, the ability to differentiate between X and #X would allow the model to respond appropriately in both cases.

O.verse OVO

Xs

Today's simulators do not consider the effect that inverting logic functions have on Xs. For example, if an X is presented to the input of an simple NOT gate, the resulting output from the function is also X. Thus, another possibility for the developers of simulators would be to introduce the concept of NOT X (which we might represent as ~X). The concept of ~X values could greatly reduce pessimism and aid the simulator in clearing out uninitialized unknown values (Figure 10-7).

115

116 Designus Maximus Unleashed!

data clock1

I 1

, iI

X clock2

~X

D-type

D-type

Figure 10-7: Using ~Xs to reduce pessimism This is obviously a contrived example, but it serves to illustrate the point. Assume that the circuit has recently powered-up and the registers contain unknown states. With today's simulators, you could apply clock pulses to clockl until the end of time without any useful effect. However, if the simulator inherently understood the concept of ~X, then the first positive edge on clockl would cause that register's q output to toggle from its original X to a ~X value (similarly, the complementary qb output would toggle from a ~X to an X). The simulator could be made to recognize that one of these two values would have to represent a logic O, which would cause the downstream register to be placed into its s ~ state. Thus, even though the contents of the first register remain unknown, the simulator could use its transition from X to ~X to determine that the downstream register should now be placed into a known state, which could subsequently be used to clear unknowns out of other portions of the circuit.

Xs with ~D ~lumber$ As a final suggestion (and remembering that there are many other possibilities), we might consider giving each X a unique Identification Number (ID). Every X in existing simulators is indistinguishable from its counterparts, which can result in undue pessimism (Figure 10-8).

XOR

X0R x

x

What we get today

T

/

~ 0

What we'd prefer

Figure 10-8: Today's Xs are unduly pessimistic

Chapter 10 UnknownX Values 1 1 7 Even in a relatively simple case involving an XOR gate, the gate cannot recognize the fact that the X applied to both of its inputs comes from a common source. If the simulator could tell that both of these Xs were in fact the same (and assuming that we know that this is a "well-behaved" static X and not a dynamic #X as discussed above), then the output from the gate could be assigned the lesspessimistic value of logic O, which could aid in initializing other down-stream logic (remember that O XOR O - O and I XOR I -- O). The potential benefits increase dramatically if we consider a signal that diverges into multiple paths, where each path passes through several levels of logic, and then two or more of the paths reconverge at some point downstream. In fact, tracking Xs in this way would be similar in principle to the way in which today's dynamic timing analyzers resolve timing pessimism in circuits exhibiting reconvergent fanout (also known as common-mode ambiguity), isl Another, perhaps less obvious, application of Xs having IDs could be in pinpointing an X's origin. Assume that you're running your first-pass simulation, you're only monitoring the primary outputs from the circuit, and at some stage during the simulation you see some Xs in the output waveform display. The problem is that these Xs could have originated deep in the bowels of the circuit thousands of time-steps in the past. With today's simulators, your only recourse is to rerun the simulation and work your way back from the suspect primary output like a salmon swimming upstream. However, if the Xs had unique IDs, which were related in some way so as to keep track of parent Xs and their offspring, then it would be feasible to click your mouse on an X in the waveform display, and for the simulator to inform you that: "This X originated at time 6854 ns at gate G4569". Thus, you could immediately target the offending gate and monitor all of the signals in its immediate vicinity to quickly pinpoint and isolate the problem.

Aria

inally

Each of the above suggestions (• versus #• versus ~• versus • with IDs) could be useful in isolation, but a combination of all of them could dramatically improve the quality of digital simulations. One downside to all of this is that even today's simple Xs tend to negatively impact simulation speed, because they can procreate and propagate throughout a circuit at a frightening rate. The more sophisticated Xs discussed here, especially those with individual IDs, would certainly slow the simulator down even further. However, there are a number of ways to mitigate these detrimental effects. For example, one suggestion is for the simulator to only differentiate between X, ~X, SDynamic timing analysis was introduced in Chapter 7.

118 Designus Maximus Unleashed! and Xs with IDs during the time when the circuit is undergoing its initialization sequence. Once the circuit has been initialized (at a time specified by the user), the simulator could then revert to only considering X and #X values. And finally we should note that this excursion into the world of "Wouldn't it be nice if..." has only scratched the surface of what is possible. Ultimately, it is you, the designers in the trenches, who will determine how simulation tools evolve in the future by communicating your requirements to their developers. So don't be shy: "Hug a developer today!" The topic in this chapter was published in a condensed form under the title Xe in Digital Simulation: Beware, Here be Dragone, In the October 12th, 1995 Issue of EDN (www.ednmag.com), and i~ reproduced in it~ original form here with their kincl permission. |m

Chapter 11:

Analog and Mixed-Signal Simulation "Does it wriggle, or does it g o ker-thunk ?" In this chapter you will discover: There's No Such Thing As Digital! ........................................................................... 120 B e w a r e of Terms Like " C l o c k i n g F r e q u e n c y " . ................................... 120 A n a l o g Simulation ............................................................................................................................. 121 Digital Simulation ................................................................................................................................. 125 Mixed-Signal Verification Strategies ................................................................... 126 A / d , A / D , a n d a / D ........................................................................................................................... 127 A l t e r n a t i v e C o s i m u l a t i o n Strategies .................................................................. 128 Mixing A / D a n d A / d ...................................................................................................................... 131 S u m m a r y ............................................................................................................................................................ 132

120 Designus Maximus Unleashed! ~here's JVo Such ~hing 7qs Digital{ The phrase "mixed-signal" is typically understood to refer to designs containing both analog and digital functions or components, but this something of an oversimplification. In the real world every electronic component behaves in an analog fashion, but these components can be connected together so as to form functions whose behavior is amenable to digital approximations. As the speed, or clocking frequency, of a system increases, we start to move into an area known as "High-Speed Design," in which circuits containing only digital functions begin to exhibit increasingly significant analog effects in their interconnect. At some point (which depends on the system and the technology and is subject to debate) these effects become significant enough that they must be considered in the analog domain. As the clocking frequency increases still further, the digital functions themselves begin to exhibit analog effects. At sufficiently high frequencies, which vary by system and technology, "digital" and "analog" components and functions become almost indistinguishable. Thus, the phrase mixed-signal should actually be taken to refer to designs that exhibit both analog and digital characteristics. This distinction is important, because many designers are moving into the mixed-signal arena, even though they may consider their designs to be "purely digital."

~eware of ~erms ~ike "elocking 3requency" The introductory discussions above were wont to say things like: "As the clocking frequency of a system increases ...... " But we have to be very careful here. Many people associate High-Speed Design with higher clocking frequencies, but the two are not directly related. What is important is the rate of change of signals; that is, the speed of their "edges" (Figure 11.1).

edge epeeds

Signa! C

~~~

~~x~~

~

~~

I

Figure 11- I" Edge speed is more important than clock frequency when it comes to categorizing "high-speed" designs

Chapter 11 Analog and Mixed-SignalSimulation 1 2 1 The three signals shown in this figure all have the same frequency, but they transition between logic 0 and logic I values at different speeds. As the edge speed increases we move closer to having a perfect square wave. But wait! A square wave is actually composed of multiple sine waves at different harmonics. The closer we approach a perfect square wave the higher are the frequencies of the sine waves required to form it. This is also true of individual edges; the faster the edge rate the higher the frequencies of that edge's harmonic components. So "clock frequency" is something of a "red herring." When we increase the frequency of the system clock, we also need to increase the edge-speed of our signals so as to squeeze the same amount of activity into each clock cycle. To a large extent it's the high-frequency components of these "sharper edges" that causes us problems. Thus, some engineers may experience "high-speed" design problems in products driven by relatively slow system clocks.

7qnalog Simulation With the exception of certain applications such as computers, the majority of electronic designs in the 1960s and early 1970s contained substantial amounts of analog circuitry. One reason for this was that there were a relatively limited variety of digital functions available as integrated circuits, and the majority of these were at the small-, medium-, and large-scale integration level of complexity. (~I In addition to the lack of availability of digital functions, speed requirements demanded that certain portions of designs were implemented in analog. Clock frequencies of typical mid-1970s digital circuits were in the order of 5MHz, 121so signal processing or conditioning was predominantly handled by analog circuitry. Analog design can be somewhat esoteric (as can some analog designers), which prompted a number of universities to begin investigations into computer-based analog design aids during the latter half of the 1960s. One of the first analog simulators to be presented to the industry was the Simulation Program with Integrated Circuit Emphasis (SPICE), which emerged from the University of California in Berkeley in the 1970s. SPICE 1 became available around the beginning of the 1970s, while the more popular SPICE 2 appeared around the middle of the 1970s. There were a number of versions of SPICE 2, commencing with 2A1 and cumulating with 2G6.131 At that time, commercial vendors almost ~By one convention, SSI = I to 12 gates, MSI - 13 to 99 gates, and LSI - 100 to 999 gates. 2 The phrase "in the order of" is a slippery one (which is, of course, why I use it). In fact "in the order of 5 MHz" means anywhere from 500 KHz to 50 MHz, where the majority of mid-1970s digital circuits favored the lower end of this range. 3There was a 2G7 version of SPICE, which was essentially 2G6 with a BSIM MOSFET model, but it never gained wide acceptance.

122 Designus Maximus Unleashed! uniformly based their products on Berkeley SPICE, and most were based on version 2G6. Similarly for in-house systems created by companies such as National Semiconductors and Texas Instruments. All of the SPICE 2Gx versions were written in FORTRAN and were primarily intended to be run as batch processes, which is the way in which many designers still think of analog simulation today. Around 1988 to 1989, Berkeley developed SPICE 3, which was, to a large extent, SPICE 2 rewritten in C and restructured in an attempt to make it easier to add models. Additionally, SPICE 3 had a somewhat snazzier user interface which was called NUTMEG (a spice, get it?). Unfortunately SPICE 3 contained (and still contains) a number of problems, including some serious algorithmic bugs. However, it is important to remember that (to a large extent) Berkeley's goal is research rather than generating production code, and in this respect they have succeeded beyond all expectations. To understand the problems involved in cosimulating analog and digital simulators, it is first necessary to understand the way in which these simulators operate. In the case of an analog simulator, a circuit is represented as a matrix of differential equations and, for a given stimulus, the simulator solves the matrix in an iterative way as it attempts to converge on a solution. Consider the simple circuit shown in Figure 11.2. Vin

Vout

I~

o

o

~ C

D i ~ e r e n t l a i Equation RC x ( d V o u t / a t ) + V o u t = Vin Analytical Solution Vout(=) = 1 - e -=z=c

Figure 11-2: Analog simulation: simple example circuit The differential equation describes how the circuit behaves for any time-varying input, and the combination of this equation and the input stimulus is the only data available to the simulator. (Note that the analytical solution shown in Figure 11-2 is only applicable for the special case in which a step function is applied to Vin and which, in any case, is unknown to the simulator.) The analog simulator is faced with two objectives: to determine and return accurate results, and to do so quickly and efficiently. Unfortunately, these objectives clash with each other to a large extent. As the delta-time used to solve

Chapter 11 Analog and Mixed-Signal Simulation a differential equation approaches zero, the result returned by the equation approaches its optimal accuracy. But solving the equation an infinite number of times for infinitesimal time steps would mean that the computer would never actually arrive at a final result. Ideally, the computer would prefer to use large increments of time and therefore only be obliged to solve the equation on a limited number of occasions, but the possibility of error increases as a function of the size of the time increment. The solution adopted by analog simulators is illustrated in Figure 11-3 which, for the purposes of this example, assumes a step function applied to Vin. Vout ~L

Analytical solution (unknown to the computer)

J

i l

,c3 -,- C2) -,- O)

t

Iterative solution (calculated by the computer)

- Time

Figure 11-3" Analog simulation: solving differential equations numerically The simulator selects a time-step for some time in the future (called t in this example) and attempts to solve the differential equation (shown as point (I) in the figure). The simulator then examines this solution to see how close it came with respect to some tolerance criteria. If the required tolerance was not achieved, the simulator reiterates the calculation in an attempt to come closer to the required solution (shown as points (2) and (3) in the figure). A more complex circuit would be represented by a larger number of differential equations, each of which may affect the others, which is why the simulator stores the equations as a matrix and solves them all simultaneously. Remembering that the analytical solution is unknown to the simulator, it is reasonable to wonder how this process works; that is, how does the simulator know how well it's doing if it doesn't know what the answer should be? One of the easiest ways to visualize this is to consider the case where a colleague asks you to calculate the square root of a number, say 30. Although you don't know what the square root of 30 is, you do know a method that will allow you to calculate a solution. Using one technique, you may start with the number 5 and square that to get 25. Realizing that this is too low, you would then iteratively

123

124 Designus Maximus Unleashed! modify your starting number until you achieved a result that satisfied you to within some level of tolerance that you were prepared to accept ...... 5.00 5.20 5.30 5.40 5.45 5.47

x x x x x x

5.00 5.20 5.30 5.40 5.45 5.47

-------

25.00 27.04 28.09 29.16 29.70 29.92

If you feel that the final result is close enough for your needs (that is, within the required tolerance), then you may decide to stop at this point and inform your colleague that (as far as you are concerned) the square root of 30 is 5.47. This process is conceptually very similar to the iterative approach employed by the analog simulator to solve its differential equations and to converge on a solution. Thus, in addition to "tolerances," a common term that is often used in respect to analog simulation is "convergence", which means that the simulator has sufficiently powerful algorithms and the circuit is described using sufficiently accurate equations to enable the simulator to achieve a numerical solution. If, after a specified maximum number of iterations, the simulator has not managed to converge on an acceptable solution, then it shortens the time-step and tries again. Similarly, if the simulator converges on a solution using relatively few iterations, then it will employ a larger time-step to calculate the next point in the sequence. All modern analog simulators use a form of this adaptive time-step algorithm to achieve the optimal tradeoff between simulation accuracy and CPU efficiency. This affects the cosimulation of analog and digital simulators, because the digital world uses a fixed time-step, while the analog time-step can be dynamically changing. One of the classic problems with the original SPICE (and many of its derivatives) is that it pretty much required an expert to use it. Designers can spend an inordinate amount of time fine-tuning the simulator and adjusting the tolerances, thereby tightening or loosening the convergence criteria. Tightening the tolerances generally results in improved accuracy, but also causes the simulator to take longer to evaluate the circuit. Additionally, tightening the tolerances may result in the simulator never converging at all. Of more concern is the fact that changing the tolerances can significantly modify the output from the simulator. Another problem with SPICE is found in the core primitives, some of which have discontinuities in their equations, which can cause difficulties when trying to converge in the areas of these discontinuities.

Chapter 11 Analog and Mixed-Signal Simulation

By comparison, modern analog simulators typically have more sophisticated core equations than SPICE. Additionally, some modern simulators employ heuristic techniques which allow them to select different algorithms and attempt different solutions rather than simply saying "l'm sorry old bean, but ! couldn't converge." There are several other areas where modern analog simulators differentiate themselves from their forefathers. Traditionally, creating stimulus (as tables of numerical values) could be almost as taxing as designing the circuit itself. Today's graphical environments can offer utilities to facilitate the construction of highly complex waveforms, allowing designers to graphically create waveforms using straight-line and free-form drawing features. Such waveforms may then be modified using spline-based techniques or manipulated mathematically; for example, multiplying one waveform by another. In addition to displaying waveforms in the time domain, designers can also display and modify the waveform's spectral components (magnitude and phase). These techniques allow designers to construct complex "real world" waveforms which include such features as non-linearities, overshoot, ringing, and high-frequency noise. Finally, analog simulators are not obliged to operate at the transistor-level- they may support multiple levels of modeling abstraction, including digital logic primitives (such as gates and registers) with analog interface characteristics. Also of interest are analog behavioral languages which allow portions of a design to be represented at a high level of abstraction. In fact, some analog simulators are primarily used for system level and control engineering design tasks, and are relatively poor at the transistor level required for integrated circuit design.

Digital Simulation As for their analog counterparts, digital simulators also started out as university projects. For example, one of the first, called HILO, was developed by a team headed by Dr. Gerry Musgrave at Brunel University in England. The use of digital simulators trailed their analog equivalents, and digital simulation only began to attract significant commercial attention towards the end of the 1970s. Digital simulators are based on the concepts of a fixed time-step and an "event wheel", in which events are scheduled to take place at some time in the future, c41 When an input to a digital function changes state, the simulator evaluates the logical function to determine whether this change should cause a corresponding change at the output. If the simulator determines that an output change is 4Note that a digitalsimulator does not blindly simulate every single time-step. Once all of the actions associated with a particulartime-step have been executed, the simulatorskips any empty time-steps and leaps directlyto the next time-step in the event wheel which has an action to be performed.

125

126 Designus Maximus Unleashed! required, it looks up the delay associated with this change, then posts an event to the event wheel to be actioned at the appropriate future time.

The original digital simulators were targeted towards the designs of the day, which predominantly involved gate-level TTL. Additionally, the original simulators were based on proprietary hardware description languages (HDLs), which were generally little more than netlists calling simulator primitives. These languages were gradually extended to the functional level of Boolean expressions and Register Transfer Language (RTL) capability, followed by excursions into a more behavioral level of abstraction. Currently, the two most popular digital HDLs are VHDL and Verilog HDL, while the C programming language is also commonly used to represent certain functions at the board and system levels. Early digital simulators were based on a distributed delay model, in which each primitive gate had its own individual delays. This model remains useful for some applications, but modern digital simulators typically also support Pin-to-Pin (Pn-Pn) delay specifications, which are particularly advantageous for modeling the cells used in integrated circuit designs. Additionally, due to the fact that the early digital simulators were tailored to representing TTL logic at the board level, they predominantly used an inertial delay model, in which pulses that were narrower than the gate's propagation delay were rejected. The inertial delay model is insufficient for components such as delay lines, so digital simulators were augmented to support transport delay specifications, in which pulses are always propagated, irrespective of the width of the pulse or the propagation delay of the logic gate. Is~

jYlixed-$ignal Verification Strategies The traditional approach for designs that contain both analog and digital elements is to partition the design at the beginning of its development cycle. The digital and analog portions are then captured and verified in isolation, and they are only reunited at the prototyping stage. This is the simplest technique, and it may be appropriate for highly partitioned designs without feedback. However, this strategy does not provide the designer with much confidence that the digital and analog portions will interface correctly. A development of this technique is to verify one portion of the design, analog or digital, using the relevant simulator. The simulation output is captured and then coerced (mapped) into a suitable format for use as stimulus for the other portion. Once again, this technique may be suitable for highly partitioned designs without feedback, but it is typically painful and time consuming. SThe way in which digital simulators work (includingdetains on distributed delays versus Pn-Pn delays, and inertial delays versus transport delays) was introduced in more detail in Chapter 6.

Chapter I I Analog and Mixed-Signal Simulation

Neither of the above techniques can be categorized as true mixed-signal verification. To be classed as mixed-signal, the simulation environment must support the concurrent verification of both the analog and digital portions of the design. There are many cases where true mixed-signal verification is the only realistic alternative. Designs in this category include, but are not limited to, those exhibiting tightly coupled feedback between the analog and digital portions; for example, circuits employing Phase-Lock Loop (PLL) techniques. Additionally, the advent of multimedia technology is dramatically increasing the usage of Digital Signal Processing (DSP) techniques, which can involve sophisticated and tightly integrated combinations of analog and digital circuitry. Mixed-signal verification may also be required in the case of high-speed designs employing only digital components. Although the bulk of the design may be verified using a digital simulator, it may be necessary to subject the critical interconnection paths to a more exhaustive analog analysis. In some cases it may be sufficient to perform signal integrity analysis off-line (on the interconnect only), but cases where the parasitic effects are dependent on the state of other signals may mandate a mixed-signal approach. 161

ld,

ID, and aid

Until recently, the phrase "mixed-signal simulation" has typically been associated with the cosimulation of analog and digital simulators, but a more precise classification of simulation technology is beginning to emerge: D a/D A/D A/d A

= = = = =

Pure digital simulator Digital simulator with native analog capability Cosimulation of analog and digital simulators Analog simulator with native digital capability Pure analog eimulator

Designs containing large, complex portions of analog and digital may mandate the use of an A/D technique, which involves linking analog and digital simulators together. Many designs, however, may be responsive to the a/D or A/d forms of evaluation. The a/D technique is typically employed for primarily digital designs containing some proportion of analog. However, in this case the analog portions are usually in the form of relatively large functions which are amenable to behavioral representations; for example, analog-to-digital converters. Also, the a/D technique relies on a digital simulator which can support C models (or VHDL models with signals of type REAL). 6The concept of parasitic effects that are dependent on the state of other signals is introduced in more detail in Chapter 25.

127

128 Designus Maximus Unleashed! By comparison, the Aid technique relies on the use of an analog simulator that inherently understands the concept of digital primitives such as logic gates and registers. These gates are handled by the simulator in a digital fashion, but can have associated analog interface characteristics such as input and output impedances, input switching thresholds, output slope, overshoot, and frequency damping. A modern analog simulator with Aid capability can simulate a few tens of thousands of logic gates in this manner. The Aid technique is typically of use with primarily analog designs containing a limited amount of digital functionality in the form of relatively simple logic functions. The A/d technique is of particular interest for a number of reasons, not the least that analog simulators with this capability usually contain their own version of an event wheel. This can become significant when the analog simulator is cosimulated with a digital simulator as discussed below.

~lternative eosimulation Strategies Before introducing the various A/D cosimulation strategies, it is appropriate to consider the environment necessary to support full mixed-signal simulation. Today's mixed-level design practices require that each portion of a design may be represented at the most appropriate level of abstraction. On the digital side, the design system should ideally allow individual portions of a design to be represented using graphical techniques such as state diagrams, state tables, and truth tables, as textural HDL, as gate-level schematics and/or netlists, and as physical devices interfaced using a hardware modeler. Similarly, on the analog side, the design system should ideally allow individual portions of a design to be represented using an analog behavioral language, native digital logic (with analog interface characteristics), and as transistor-level schematics and/or netlists. The first requirement of such a system is that some hierarchical blocks may contain analog views and some may contain digital views. Additionally, the analog and digital portions of a design may not always be amenable to being partitioned into discrete blocks. Thus, the system should also support analog and digital elements in the same block; for example, primitive logic gates combined with transistors, resistors, and capacitors. After the design has been captured, the system should be capable of automatically partitioning the analog and digital functions and presenting them to the appropriate simulation engines. Additionally, the system should inject special elements to interface the analog and digital worlds (Figure 11-4).

Chapter 11 Analog and Mixed-Signal Simulation A digital traneition ie coerce~l into it~ analog counterpar~

/

Y Interface element

Digital domain

~

An analog transition is coerce~l into its digital counterpart

-•+5V 1 ov Analog domain

Interface element

~' Digitaldomain

Figure 11-4: The mixed-signal environment should automatically inject special interface elements For example, in the case of a digital function driving into the analog world, the interface element must map the "sharp" digital edges into analog equivalents such as impedances and slopes. To avoid the necessity for manual intervention, the system should automatically inject the appropriate interface element based on a technology parameter (such as S, AS, LS, ALS, F, ...) associated with the digital symbol. The system should also support user-defined technologies for fullcustom applications. Last but not least, the system should support cross-probing of analog and digital signals from the schematic, and display both analog and digital traces in the same analysis window. Moving on to the actual verification of the design, there are a number of cosimulation strategies available. The majority of cosimulation techniques may be classed as either Unified, Simulation Backplane, Glued, or Coupled. In the case of the unified approach, a single simulation database is shared by the digital and analog simulation engines. This is generally regarded as offering the fastest simulation speed, but the engines themselves are typically inferior. Note that, in this context, the term "inferior" does not necessarily imply that there is anything wrong with the engines, just that they are usually restricted in the levels of modeling abstraction they support and the types of analysis they can perform. For example, unified solutions are typically only capable of time domain analysis, even when performing "pure" analog simulations. Simulation backplanes are usually promoted in terms of "plug-and-play" capability; that is, the ability to combine digital and analog simulators of choice.

129

130 Designus Maximus Unleashed! In reality the supported simulators are usually limited, the final solution is often restricted to the smallest subset of capabilities offered by all of the simulators, and there can also be significant initialization problems. There is also an obvious overhead associated with having three processes communicating with each other (the two simulators and the backplane). Also, there can be a huge overhead associated with type conversion between simulation engines, and, potentially more troublesome, backplanes may perform inefficient and somewhat inaccurate type conversions via some intermediate form. By comparison, the glued approach refers to the case where two simulators are linked via a C interface in a master/slave relationship. The typical case is for the digital simulator to be the master, and for this master to "see" the analog simulator as a C model. The glued approach offers a much tighter coupling than a simulation backplane, as well as increased accuracy and efficiency. Last but certainly not least, we have the coupled approach, which is somewhat similar to the glued technique in that it involves linking the two simulators via a C interface. However, the coupled approach is based on an analog simulator with Aid capability, in which the analog simulator inherently understands the concept of digital primitives such as logic gates and registers. As was noted above, analog simulators with this capability usually contain their own version of an event wheel. In the coupled approach, both simulators have the ability to mutually schedule and access events on this event wheel. The proponents of this scheme believe that the coupled approach offers the best combination of features from the unified and glued techniques. A major consideration with all of the alternative cosimulation strategies discussed above is the way in which the analog and digital simulators are synchronized in time. As has already been noted, this is a non-trivial problem because the digital world uses a fixed time-step, while the analog time-step can be dynamically changing. The two most common synchronization techniques are known as the Lockstep and Calaveras algorithms. The Lockstep algorithm requires that the two engines are locked together in time throughout the course of the simulation, which means that the digital engine has to take the smallest time-step that the analog engine does. Additionally, the first engine to complete a particular timestep must wait for the other engine to catch up. By comparison, the Calaveras algorithm allows the simulators to run ahead of the other. If it is subsequently determined that evaluations in one domain would have affected the other domain, then time is "wound back" (as far as is necessary to account for the interaction) and the process is repeated with the new data. Champions of the Calaveras algorithm would say that the Lockstep technique is inefficient, because one simulator is always waiting for the other. Similarly,

Chapter I I Analog and Mixed-Signal Simulation

proponents of the Lockstep algorithm would say that the Calaveras technique is inefficient on the basis that the simulators are constantly throwing data away, and the simulation of a particular group of time-steps may be performed several times. In reality, each approach has its strengths and weaknesses, and the performance of each is strongly dependent on the topology and content of the particular circuit under evaluation. One technique that might be used to improve the Calaveras algorithm would be to monitor simulation activity to see which simulator runs ahead the most, and to then vary the proportion of CPU time that is made available to each simulator to balance the load.

I ixin

,"lid

,"lid

As we previously discussed, the Aid technique involved an analog simulator that inherently understands the concept of digital primitives such as logic gates and registers. These gates are simulated in a digital fashion, but can have associated analog interface characteristics such as input and output impedances, input switching thresholds, output slope, overshoot, and frequency damping. A modern analog simulator with Aid capability can simulate a few tens of thousands of logic gates in this manner. These Aid models combine the simulation accuracy of pure analog with simulation speeds which can be 250 times faster than their transistor-level equivalents; however, this is still substantially slower than simulating logic gates using a digital simulator. More important is the limitation of the number of logic gates that can be simulated using the Aid technique, because today's integrated circuits can contain many hundreds of thousands of logic gates. One answer to this problem is to use a combination of A/D and Aid simulation techniques (Figure 11-5). MD boundary == Digital Simulator '~

II

~=~

A/D boundary

Analog Simulator

~

!

~

i

Digital Simulator

.~..:~:::~::,::::~;~~ ~!i~]~:~~:~;~:~:~:~i~

ii!ii!ii~i~ililiiiii~iliii!iii~!i!i!i~ii!i!ii~ii~i~i~i~i~i~i!~i~i~i~i~i~,~~ i~i~i~i~i~i~ii~ ' ~: ~,"~

~;~:~:~:

::::::::::::::::::::::::::::::::::::::::::::::::::: iilil iiiiiiiiiii!i!i!::i::::::iiiili~::~::~:~:~:~:~: ~ ~..',~.~;~.,,.'..'

Figure 1 I-5: Mixing A/D and A/d techniques

\

!

Aid boundaries

~":~~"....... ~ ,

i~l

: ......... ~: "~ ........................ ~ ..................... ~::~i~::~::~ ~!~@".~!

~ii~i~i~!ii~i~ii~i!~!~ii~i~i~i!~iii~iii~i~ii~i~i~i~!~iii~iiiii~i~i~i~i~iii~i!i~i~i!i~i~i~i~i!!~i~i~!~! .............................................................................................

~

~ t ~

!iiiiiiii~/.ii~iiiiiiiii!iiiii!iiiiiiii!iiii i i i i i!i !i i iilili!iiiiiiii!!iiiiiiiiiiiiii!iliiiiiiii~i~iiiii~i iii

. . . . . . . . . . . . ~ ' ~ I ~ . . . . . . . . ,7 .........

Digital functions with analog interface characteristics

i

: ~ ~ " J ......

131

132 Designus Maximus Unleashed! The idea here is that devices at this ultra-large-scale of integration typically contain complex digital macro-functions such as microprocessor cores, blocks of memory, and communications functions. These functions can be rigorously characterized on an individual basis, and then represented as C models, as behavioral HDL models (such as VHDL or Verilog HDL), as physical devices interfaced using a hardware modeler, as gate-level netlists, or as a combination of all of these techniques. Thus, the strongly characterized digital macro-functions can be simulated in the digital domain, which can be interfaced to the analog domain using A/D mixedsignal techniques. Meanwhile, the critical paths in the remaining "glue logic" (the simple digital primitives linking the macro-functions) can be simulated in the analog domain using Aid mixed-signal simulation techniques.

Summary A number of independent surveys indicate that the late 1990s will see a rapid increase in the use of mixed-signal simulation technology. As we have discussed, there are a variety of strategies available including: digital simulators with native analog capability (a/D); analog simulators with native digital capability (Aid); and full cosimulation of analog and digital simulators (AID). Also, the most advantageous approach in many cases may be to use a mixture of strategies; for example, AID combined with Aid. With regard to cosimulation, there are a number of techniques, and it is difficult to state that any particular approach is superior to any other, because each design presents its own unique problems which demand their own unique solutions. In fact, the choice of a particular cosimulation technique may be largely governed by the target application; for example, small numbers of large, complex analog and digital functions may be appropriate for one approach, while large numbers of small, simple analog and digital functions may dictate an alternative technique. That's it. You are on your own. Be careful. It's a jungle out there.

The topic in this chapter was published in a oondensed form under the title Some Designs Send Mixed Signals, in the October 9th, 1997 Issue of EDN (www.ednmag.com), and is reproduced in its original form here with their kind permission.


Chapter 12: A minus B = A + NOT(B) + 1 "Has a n y o n e s e e n m y t w o ' s complementor? " In this chapter you will discover: It All S e e m e d So Easy Then ...............................................................................................136 C o m p l e m e n t T e c h n i q u e s .....................................................................................................136 Signed Binary N u m b e r s ............................................................................................................140 The A r i t h m e t i c / L o g i c Unit (ALU) ................................................................................143 The " C o r e " ALU ...................................................................................................................................... 144 Extending t h e C o r e ALU to Perform S u b t r a c t i o n s ..................... 148

136 Designus Maximus Unleashed!

~Tt ~qll S e e m e d S o E a s y ~hen

Following the joys of the "Microprocessor 101" courses we endured at college, most of us are reasonably confident that we understand the way in which computers add and subtract binary numbers. Thereafter, we bask in the rosy glow that assembly-level instructions such as A00 ("add without carry"), AOIPG ("add with carry"), SUB ("subtract without carry"), and SI.I~G ("subtract with carry") hold no fear for masters of the universe such as we. I~l The years race by as if they're in a desperate hurry to get somewhere, until we arrive at that grim and fateful day when someone asks us to replicate an addeffsubtractor function ourselves, either as a chunk of logic for a design, or possibly using the hardware description language of our choice to create a model for simulation and synthesis. Our first port of call may well be to blow the cobwebs off our microprocessor course notes, only to find that there's more to this than we seem to recall. The description of the AlPlP instruction (which doesn't require a carry-in) looks simple enough, saying something like a[7:O] plue ~[7:O] = a[7:0] + ~[7:O] (assuming an 8-bit datapath). It's when we turn our attention to the SUB, whose definition may be something along the lines of a[7:O] minue ~[7:O] = a[7:O] + NO'r(~[7:O] ) + I, that we realize that perhaps we should have paid just a tad more attention in Prof. Gonzo Dribbler's Monday morning lectures (possibly to the extent of actually staying awake). Light begins to dawn after a few moments contemplation, as we start to recall that these calculations are performed using two's complement arithmetic. So it comes as something of a shock when we come to peer at the block diagram of the Arithmetic-Logic Unit (ALU), desperately searching for a two's complementor, only to find a humble one's complementor glaring back at us as though it has every right to be there. "Holy socks Batman, how can this be?" Obviously we need to go back to first principles in order to figure this out .....

eomplement ~echm'que$ There are two forms of complement associated with every number system, the radix complement and the diminished radix complement, where the term "radix" (which comes from the Latin word meaning "root") refers to the base of the number system. Under the decimal (base-10) system, the radix complement is also known as the ten's complement and the diminished radix complement is known as the nine's complement. First consider a decimal subtraction performed using the nine's complement technique - a process known in ancient times as "Casting out the nines" (Figure 12-1). ~In many microprocessor instruction sets, the mnemonic SU~B ("subtract with borrow") is used in preference to SLIBG("subtract with carry"), but the resulting actions are identical.

Chapter 12 A minus B = A + NOT(B) + 1 1 3 7

Nine's complement equivalent

Standard subtraction .

.

.

.

.

.

.

.

.

.

.

.

647 -283 =364

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

647

999

-283

~

=71 6

+ 716 =1 3 6 3

endaroundcarry

.-1 364

Take nines complement

Figure 12-I" Decimal subtractions performed using nine's complements don't require any borrows, but they do require an end-around carry

The standard way of performing the operation would be to subtract the subtrahend (283) from the minuend (647) which, as in this example, may require the use of one or more borrow operations. To perform the equivalent operation using a nine's complement technique, each of the digits of the subtrahend is first subtracted from a 9. The resulting nine's complement value is added to the minuend, then an end-around-carry operation is performed. The advantage of the nine's complement technique is that it is never necessary to perform a borrow operation (hence its attraction to those of limited numerical ability in the days of yore). Now consider the same subtraction performed using the ten's complement technique (Figure 12-2). The advantage of the ten's complement is that it is not necessary to perform an end-around-carry, because any carry-out resulting from the addition of the most-significant digits is simply dropped from the final result. The disadvantage is that, during the process of creating the ten's complement, it is necessary to perform a borrow operation for every non-zero digit in the subtrahend. (This problem can be overcome by first taking the nine's complement of the subtrahend, adding one to the result, and then performing the remaining operations as for the ten's complement). Nine's complement equivalent

Standard subtraction .

647 -283 =364

.

.

.

.

.

.

.

.

.

.

.

.

.

.

=

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

1 000 283 717

Take tens complement

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

647, + 717 =1 3 6 4 364

i

drop any carry

Figure 12-2: Decimal subtractions performed using ten's complements do require borrows, but they don't require an end-around carry

138 Designus Maximus Unleashed! Similar techniques may be employed with any number system, including binary (base-2), in which the radix complement is known as the two's complement and the diminished radix complement is known as the one's complement. First consider a binary subtraction performed using the one's complement technique on 8-bit unsigned binary values, where such values can be used to represent positive integers in the range 0~0 to 255~0 (Figure 12-3). Standard subtraction 00111001 -0001 1 1 10 = 000 1 10 1 1

One's complement equivalent ...................................................................................................................

~1

-r

11111111 -00011110 = 11100001 \

A Take once

,

__~ 00111001 ~ + 11100001 = 100011010

I

r

/

complement

L

9I

00011011

endaround carry

,57,0- 301o=27,0

Figure 12-3: Binary subtractions performed using one's complements don't require any borrows, but they do require an end-around carry

Once again, the standard way of performing the operation would be to subtract the subtrahend (000111102) from the minuend (0011i0012), which may require the use of one or more borrow operations. (Don't beat your head against a wall trying to understand the standard binary subtraction because we won't ever be doing one - simply take my word as to the result). To perform the equivalent operation in one's complement, each of the digits of the subtrahend is first subtracted from a 1. The resulting one's complement value is added to the minuend, then an end-around-carry operation is performed. As for the nine's complement process, the advantage of the one's complement technique is that it is never necessary to perform a borrow operation. In fact, it isn't even necessary to perform a subtraction operation, because the one's complement of a binary number can be generated simply by inverting all of its bits, that is, by exchanging all of the 0s with l s and vice versa. This means that, even if we stopped here, you already know how to perform a simple binary subtraction using only inversion and addition, without any actual subtraction being involved! Now consider the same binary subtraction performed using the two's complement technique (Figure 12-4).

Chapter 12

A minus B = A + NOT(B) +

1 139

Two's complement equivalent

Standard subtraction

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

O0111 O01 -00011110

-

= 00011011

=

100000000 00011110

\

1 1100010

A

Take twos

__~ ~ -+y

/

O0111001 1 1100010

i drop

= 100011011

any

carry

00011011

complement 571o- 30~o= 271o

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

,

Figure 12-4: Binary subtractions performed using two's complements do require borrows, but they don't require an end-around carry

As for the ten's complement technique, the advantage of the two's complement is that it is not necessary to perform an end-around-carry, because any carry-out resulting from the addition of the two most-significant bits is simply dropped from the final result. The disadvantage is that, during the process of creating the two's complement, it is necessary to perform a borrow operation for every non-zero digit in the subtrahend. This problem can be overcome by first taking the one's complement of the subtrahend, adding one to the result, and then performing the remaining operations as for the two's complement. As fate would have it, there is also a short-cut approach available to generate the two's complement of a binary number. Commencing with the least significant bit of the value to be complemented, each bit up to and including the first I is copied directly, then the remaining bits are inverted (Figure 12-5). MSB

complemente~t

LSI3

.................................................................................

Copy from LSB up to

and including the first 1 Invert any remaining bits complement

Figure 12-5" Fortunately there's a shortcut technique for generating the two's complement of a binary value

Unfortunately, both the one's and two's complement techniques will return incorrect results if we're using unsigned binary representations and a larger value is subtracted from a smaller value; that is, for these techniques to work, the final result must be greater than or equal to zero. The reason for this is fairly obvious,

140 DesignusMaximusUnleashed! because subtracting a larger number from a smaller number results in a negative value, but we've been using unsigned binary numbers which, by definition, can only be used to represent positive values. It is obviously impractical to only ever perform calculations that will have positive results, so we are obliged to come up with some way of representing negative values. One solution is to use signed binary numbers.

Signed

~inary N u m b e r s

In standard decimal arithmetic, negative numbers are typically represented in

sign-magnitude form by prefixing the value with a minus sign. For example, a value of plus twenty-seven would be represented as +27 (or just 27 for short), while a value of minus twenty-seven would be indicated as -27 (where the '+' or '-' is the "sign" and the '27' is the "magnitude", hence the "sign-magnitude" designation). Similarly, we could replicate the sign-magnitude form in binary, by simply using the most significant bit to represent the sign of the number (0 -- positive, 1 - negative). However, computers rarely employ the sign-magnitude form, but instead use a format known as signed binary. Signed binary numbers can be used to represent both positive and negative values, and they do this in a rather cunning way. To illustrate the differences between the sign-magnitude and signed binary formats, consider the decimal sign-magnitude representations of plus and minus twenty-seven, along with the same values represented as signed binary numbers (Figure 12-6). N~af, ive value P'oeit,ive value

o

ol \

~

+271o

ll U 1 0 l 0 1 0 12 /

(-12 1o) + (,lol,o) - -27,o

Figure 12-6: Positive and negative versions of a number look radically different in the signed binary format Unlike the decimal values, the bit patterns of the two binary numbers are very different, because the signed binary equivalent of-2710 is formed by combining -12810 with + 101~0. That is, the least significant bits continue to represent the same positive quantities as for unsigned binary numbers, while the most-

:

,,,,,,,,,,

. . . . .

C h a p t e r 12 A minus B = A + NOT(B) + I . .........

,,,,,,,,,,

,,,,

,

,,,

,

.

.

.

.

significant bit is used to represent an actual negative quantity rather than a simple plus or minus. In the case of a signed 8-bit number, a '1' in the sign bit represents -27 (- -128), and the remaining bits are used to represent positive values in the range 010 through + 127 m. Thus, an 8-bit signed binary number can be used to represent values in the range -128 m through + 127 m. At a first glance, signed binary numbers appear to be an outrageously complex solution to a fairly simple problem. In addition to representing an asymmetrical range of negative and positive numbers (-128~0 through + 127 m in the case of an 8-bit value), the way in which these values are formed is, to put it mildly, alien to the way we're used to thinking of numbers. Why then, you may ask, don't we simply use the most-significant bit to represent the sign of the number and leave it at that? Well as you may expect, there's reason behind our madness. First, if we did use the most significant bit to represent only the sign of the number, then such numbers would accommodate both +0 and -0 values. Although this may not seem like a particularly hairy stumbling block, computers are essentially dumb, and it would introduce complications in recognizing whether or not a given value was less than zero or equal to zero (or whether +0 was greater than or equal to -0). But there's a lot more to signed binary numbers than this. Now pay attention, because this is the clever part; closer investigation of the two binary values in Figure 12-6 reveals that each bit pattern is in fact the two's complement of the other! To put this another way; taking the two's complement of a positive signed binary value returns its negative equivalent, and vice versa (the only problem being that, due to the asymmetrical range, the largest negative number can't be negated; for example, in an 8-bit number, you can't negate -128 m to get + 128 m because the maximum positive value supported is + 127m). The end result of all this rigmarole is that using signed binary numbers (which are also commonly referred to as two's-complement numbers) greatly reduces the complexity of the operations within a computer. To illustrate why this is so, let's consider one of the simplest operations: that of addition. Compare the following additions of positive and negative decimal values in sign-magnitude form with their signed binary counterparts (Figure 12-7). First examine the standard decimal calculations - the one at the top is easy to understand, because it's a straightforward addition of two positive values. However, even though we are familiar with decimal addition, the other three problems aren't quite as simple, because we have to decide exactly what to do with the negative values. By comparison, the signed binary calculations on the right are all simple additions, irrespective of whether the individual values are positive or negative.

141

142 Designus Maximus Unleashed! Decimal signmagnitude

Signed binary

+

57 30

00111001 +00011110

=

87

=01010111

57 + -3 0

O0111001 + 11100010

=

27

= 00011011

+

-5 7 30

11000111 +00011110

= -2 7

= 11100101

-5 7 + -3 0

+ 11100010

= -8 7

= 10101001

11000111

Figure 12-7: The signed binary form facilitates a d d i n g both positive a n d n e g a t i v e values

If a computer were forced to use a binary version of the sign-magnitude form to perform additions, then instead of performing its calculations effortlessly and quickly, it would have to perform a painful sequence of operations. First of all the computer would have to compare the signs of the two numbers. If the signs were the same the computer could simply add the two values (excluding the sign bits themselves), because, in this case, the result would always have the same sign as the original numbers. However, if the signs were different, the computer would have to subtract the smaller value from the larger value, and then ensure that the correct sign was appended to the result. As well as being time consuming, performing all of these operations would require a substantial amount of logic gates. Thus, the advantage of the signed binary format for addition operations is apparent: signed binary numbers can always be directly added together to provide the correct result in a single operation, irrespective of whether they represent positive or negative values. That is, the operations a + b, a + (-b), (-a) + b, and (-a) + (-b) are all performed in exactly the same way, by simply adding the two values together. This results in adders that can be constructed using a minimum number of logic gates and are consequently fast.

chopt., 12 A mi,.u ,

- A §

§

l

Now consider the case of subtraction. We all know that 10 - 3 - 7 in decimal arithmetic, and that the same result can be obtained by negating the right-hand value and inverting the operation; that is, 10 + (-3) - 7. This technique is also true for signed binary arithmetic, although the negation of the right hand value is performed by taking its two's complement rather than by changing its sign. For example, consider a generic signed binary subtraction represented by a - I~. Generating the two's complement of I~ results in -b, allowing the operation to be performed as an addition: a + (-I~). Similarly, equivalent operations to a - (-~), (-a) - b, and (-a) - (-I~) are all performed in exactly the same way, by simply taking the two's complement of ~ and adding the result to a, irrespective of whether a or I~ represent positive or negative values. This means that computers do not require two different blocks of logic (one to add numbers and another to subtract them); instead, they only require an adder and the ability to generate the two's complement of a number, which tends to make life a lot easier for all concerned. Early digital computers were often based on one's complement arithmetic for a variety of reasons, including the fact that two's complement techniques were not well understood. But designers quickly migrated to the two's complement approach, because of the inherent advantages it provides. Unfortunately, the problem that we noted at the beginning of this chapter remains, which is that when we examine a computer's ALU, there isn't a two's complementor in sight; instead a humble one's complementor glares balefully at us from it's nest of logic gates. So where is our two's complementor? Is this part of some nefarious government scheme to deprive us of the benefits of two's complement arithmetic? Well fear not my braves, because the ghastly truth is about to be revealed .....

~he ~lrithmetic/Z~ogic IAnit (~qs The heart (or, perhaps, the guts) of the CPU is the arithmetic~logic unit (ALU), where all of the number crunching and data manipulation takes place. For the purposes of these discussions we'll assume a computer whose data bus is 8 bits wide, and whose ALU therefore works with 8-bit chunks of data (Figure 12-8). The ALU accepts two 8-bit words A[7:0] and 1317:0] as input, "scrunches" them together using some arithmetic or logical operation, and outputs an 8-bit result which we've named F[7:0]. Whatever operation is performed on the data is dictated by the pattern of logic Os and logic l s fed into the ALU's instruction inputs. For example, one pattern may instruct the ALU to add A[7:0] and 1317:0] together, while another pattern may request the ALU logically AND each bit of A[7:0] with the corresponding bit in 1317:0].

143

144 Designus Maximus Unleashed! .

\~o'~,~r

j.......-

.................

.....

'

"""' c'\s 2:~:~&0~ ~

~~

_,,

t ~

c ~c -enable

(active low)

w

x

y

Figure 19-2 I: Tri-statable outputs can be p r o g r a m m e d to act as inputs

In this example, the unprogrammed device commenced with three inputs and three outputs, but the user actually required a device with four inputs and only two outputs. By means of the appropriate fuses, the tri-state buffer on the y output was disconnected from the ~enable control and connected to a constant logic 1. Because w and x are still required to function as outputs, their associated links in the AND array must be blown away to ensure that these pins will not have any effect as inputs. The ability to configure pins as outputs or inputs provides a great amount of flexibility, and saves the designer from having to purchase myriad devices with every conceivable combination of inputs and outputs. Certain PLDs are equipped with registers on the outputs, and others with latches. Depending on the particular device, the registers (or latches) may be provided on all the outputs or on a subset of the outputs. Registered devices are particularly useful for implementing Finite State Machines (FSMs). All of the registers (or latches) typically share a common control signal, which therefore requires only a single input pin on the device (Figure 19-22).

262

Designus Maximus Unleashed! w

From 01~ array

clock

(poeitive edge)

a-type flipflop~

Figure 19-22: PLD with registered outputs In this example, the outputs are shown as being registered with D-type flip-flops, but alternative register types such as JK flip-flops or T-type flip-flops may be more suitable for certain applications. It can be inconvenient to supporting a dedicated device for each type of register. As a solution, some devices have configurable register elements whose type can be selected by programming appropriate fuses. Registered (or latched) outputs may also incorporate bypass multiplexers (Figure 19-23).

From OR array

clock (poeitive edge)

Multiplexer~

l~-type flipflope

Figure 19-23: Registered outputs with bypass multiplexers

Chapter 19 Field-Programmable Devices

By means of appropriate fuses, the control inputs to the multiplexers can be individually set to select either the non-registered data or its registered equivalent. There are also a variety of other common options, such as the ability to select true or complemented outputs. An individual PLD typically only provides a subset of the above capabilities, but these may be combined in a variety of ways; for example, registered outputs may be followed by tri-state buffers.

i~eprogrammable Ps One consideration with fusible link (and antifuse) technologies is that once they have been programmed there is no going back. This may be of particular concern with PROMs as the data they store is prone to change, but it's also true for the other PLDs. In reality, all of the components, including the diodes, transistors, and fuses are created on the surface of a single piece of silicon substrate (Figure 19-24a); however, it can be useful to visualize the device as consisting of two distinct strata (Figure 19-24b). In the real world, all the components (including the fuses) are constructed on a single piece of substrate

(a) Real world

We can visualize the components and fuses as occupying two distinct

Fuses

AND and OR arrays

(b) Pretend world

Figure 19-24: Visualizing components and fuses as occupying two distinct strata Earlier in our discussions we introduced the concepts of EPROM, EEPROM, and FLASH transistors and/or cells. To see how these fit into the scheme of things, we can simply visualize replacing the fuses in the previous example with these reprogrammable transistors (Figure 19-25). Once again, don't be confused by these figures. Irrespective of the technology used, from standard PLDs to EEPLDs, all of the components are created on the surface of a single piece of silicon substrate; it's just sometimes easier to regard the programming fuses/switches as occupying their own strata.

263

264

Designus Maximus Unleashed! Fusible

links

=j

m

~___

(a) PLD

EPI~OM transistors

-II f

EEPROM I transistors flt

(b) EPLD

(b) EEPLD

Figure 19-25: PLDs versus EPLDs and EEPLDs

Note that Generic Array Logic (GAL) devices are sophisticated versions of EEPLDs with a few extra "bells and whistles." Reprogrammable devices convey advantages over fusible link and antifuse devices, in that they can be more rigorously tested at the factory by undergoing one or more program and erase cycles before being shipped to the end user. Also, in those cases where components can be programmed while remaining resident on the circuit board, these devices are referred to as being In-System Programmable (ISP).

Programming Ps Programming a traditional PLD is relatively painless because there are dedicated computer programs and tools for the task. The user first creates a computer file known as a P/..D source file containing a textual Hardware Description Language (I-IDL) description of the required functionality (Figure 19-26).

Textual HDL (e.g. ABEL) o~p~

Optimization &

minimization

w,x. y, =

~i~i,~i~!i~i~i~i~i~~~!!?i~:~i~i/~i ~/~,i~i~i?:~i!

Figure 19-26: Using a textual source file to create a fuse file


Fuse file (e.g. JEDEC) o ~ o o o ,11 ~iol o~o o o~ oo z zo.oozooQ ~ . oo

z ~... .t.= i'll

Chapter 19 Field-Programmable Devices In addition to Boolean equations, the PLD source file may also support truth tables, state tables, and other constructs, all in textual format. Additional statements allow the user to specify which outputs are to be tri-statable, which are to be registered, and any of the other programmable options associated with PLDs. A special computer program is used to process the PLD source file. This program makes use of a knowledge database which contains details about the internal construction of all the different types of PLDs. After the user has instructed the program as to which type of device they wish to use, it analyzes the equations in the source file and performs algebraic minimization to ensure optimal utilization of the device's resources. The program accesses the knowledge database for details about the designated device and evaluates which fuses need to be blown to implement the desired functionality. The program then generates a textual output file comprising 0 and 1 characters which represent the fuses to be blown. There are a number of formats that can be used to represent these fuse files, where one c o m m o n standard is known as a JEDEC format. 121

Unprogrammed device

Programmed device

(a) Main computer

(b) Device programmer

Figure 19-27: Programming a physical SPLD As an alternative to the user specifying a particular device, the PLD program can be instructed to automatically select the best device for the task. The program can base its selection on a variety of criteria such as the speed, cost, and power consumption of the devices. The program may also be used to partition a large design across several devices in which case it will output a separate fuse file for each device. Finally, the designer takes a virgin device of the appropriate type and places it in a tool called a programmer, blower, or burner (Figure 19-27). The main 2The fuse files for PROM (and related) devices are typically represented using Intel Hex or Motorola S-Record formats.

265

266


computer passes the JEDEC file to the programmer, which uses the contents of the file to determine which fuses to burn. The designer presses the G0 button, the programmer applies the appropriate signals to the device's inputs, and a new device is born.

eomplex Ps

(ePs

A CPLD essentially consists of multiple SPLDs on a single chip. The programmable switches may be based on fusible links, antifuses, EPROM transistors, EEPROM transistors, or SRAM cells (Figure 19-28). Programmable In~rconn~

,.d

Input/output pine ~ .

SPLD-IIk=

blocke

Figure 19-28: Generic CPLD

Note that the programmable interconnect may contain a lot of wires (say 100), but that it would be impractical to feed all of these wires into each SPLD block. Thus, the blocks are interfaced to the interconnect using some form of programmable multiplexer (Figure 19-29). I00 wlres

~_ ..............................................

"'-,,,

/

~

wu~8~

.........................................

Figure 19-29: A multiplexer is used to select a subset of the programmable interconnect to be fed to each SPLD block

/

Chapter 19 Field-ProgrammableDevices2 6 7 As usual, both the logic and the programmable switches are really constructed on the same piece of silicon, but it is sometimes easier to visualize them as occupying two distinct strata (Figure 19-30). Programmable switchee Logic

Figure 19-30: Visualizing components and programmable switches as occupying two distinct strata In the case of CPLDs based on SRAM programmable switches, some variants increase their versatility by allowing individual blocks of SRAM to be used either as programmable switches or as an actual chunk of memory. Note that the above illustrations represent the architecture of a fairly simple CPLD, but that these devices can have a lot of SPLD blocks and be much more sophisticated (Figure 19-31 ). SPLD blocks Input/Output t

J

Figure 19-3 I: A more sophisticated CPLD architecture

Interconnect

268


One of the main advantages with respect to CPLDs is that, in addition to their reasonably high densities, they offer fairly predictable timing because of their regular structures. Over the last few years the market for CPLDs has grown significantly, and a variety of competing products are now available from several companies. CPLDs are being utilized in many commercial applications, one of the most significant being the re-working of existing SPLD-based designs into more cost effective implementations that use fewer chips.

3ield-Programmable

ate qrrays

SPLDs and CPLDs are tremendously useful for a wide variety of tasks, but they are somewhat limited by the structures of their programmable AND and OR planes. At the other end of spectrum are full-blown ASICs, which include gatearrays, standard cell, and full custom devices. Perhaps the simplest of the fullblown AS ICs are gate arrays, which are based on the concept of basic cells (Figure 19-32).

Pure CM05 baeic cell

BICMOS baeic cell

Figure 19-32: Examples of gate array basic cells Each ASIC vendor determines the mix of transistors, resistors, and other components that will be contained in their particular basic cell. Silicon die are then constructed containing large numbers of these basic cells, which may be arranged in a number of different ways; for example, consider channeled gate array architectures (Figure 19-33). There are two main facets to the silicon die: the transistors (and other components) and the interconnect. As we've seen, the transistors (in the form of basic cells) are pre-created by the foundry. The designer then provides a gatelevel netlist representing the desired functionality of the device, and the foundry creates the custom masks used to lay down the interconnect. Thus, these devices may be referred to as Mask Programmable Gate Arrays (MPGAs).

Chapter 19 Field-Programmable Devices I/0 cells/pads Channels \ Basic c

.....i,I~ ~ ...

.....~

Single-column arrays

...........

Dual-column arrays

Figure 19-33: Channeled gate array architectures

These devices are characterized by being very generic, having fine-grained architectures (at the level of primitive functions such as gates and registers), and having very high capacities of up to 800K equivalent gates or more, but they also have high startup costs and long lead times. Thus, there is a large gap between SPLDs and CPLDs at the lower end of complexity and ASICs at the high end (Figure 19-34). Generic

u~age

~

Application-Specific Circuit !i~~i !i~~i ~i~i ~i ~i ~i ~i ~i ~i!~i ~i !~i ~i ~i ~i !~i ~i !i~!~!~!~~i!i~!iIntegrateml ~i ~i ~i !~~i ~i i

iiiii/

i~!~i~i[i~i~i!~i~i~i~i~]!i~i~J~ii~i~Programmable i~i~i~ Device

ii!!i

liiiiiiilii i~iUili!iiiiiiiil

Figure 19-34: FPGAs were designed to bridge the gap between SPLDs and ASICs

Towards the end of the 1980s, a new breed of devices called FieldProgrammable Gate Arrays (FPGAs) began to appear on the scene. These devices combined many aspects of mask-programmable gate arrays (such as high-density) with characteristics of SPLDs and CPLDs (such as the ability to program them in the field) (Figure 19-35).

269

270


Figure 19-35: Spectrum of "application-specific" devices One differentiating factor is that the majority of FPGAs are coarse-grained, which means that they consist of islands of programmable logic surrounded by programmable interconnect. One of the things that makes FPGAs a little tricky to work with is that all of the vendors field their own unique architectures, but a generic course-grained device might be as shown in Figure 19-36. Froc3remmable Io~jIc block

i

~

84 .

.

.

.

.

Frogjrammable ewitchin~jmatrix

Fro~jrammable connection matrix

9

Figure 19-36: Generic coarse-grained FPGA architecture The majority of FPGAs are either based on antifuse or SRAM programmable switches. In the case of coarse-grained devices, the two predominant architectural variants are to use Look-Up Tables (LUTs) or multiplexers. First consider the LUT approach, of which there are two main sub-variants (Figure 19-37).

Chapter 19 Field-ProgrammableDevices 2 7 1 Required f u n c t i o n b

a

Truth table

b c

Y

iiili

.................................................................................................

y = (a & b) l c

C

y

, ............................................

.....Q....Q . ....!I . ....i...... S I ~ A M cells

a

~ iiiiiiiii!iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii!

iiiiiii

I!

.

.

.

.

.

J

%

iii .

a

b

c

Figure 19-37: Look-up table (LUT)-based FPGAs Assuming 3-input LUTs, one technique involves using a 3:8 decoder to select one of eight SRAM cells that contain the required truth table output values. Alternatively, the SRAM cells can be used to drive a "pyramid" structure of multiplexers, where the multiplexers are themselves controlled by the values on the input variables and "funnel down" to generate the output. Alternatively, as opposed to LUTs, some FPGA architectures are based almost purely on multiplexers (Figure 19-38)

y = (a & b) l c

0

c

0

Figure 19-38: Multiplexer-based approach (this example features an Actel-type logic module) Unfortunately, there are several problems with these coarse-grained FPGA architectures. First, interconnect delays are not as predictable as they are with SPLDs and CPLDs. Second, each vendor employs special fitting software to map

2 72 Designus Maximus Unleashed! ....

,,

,,

,,

,

,,,

....

,,

,,,,,,,,,,

. . . . . . . . .

,

.

,

,

,

.

.

.

.

.

.

.

.

.

,

. . . . . . . . . .

designs into their devices, which makes it well-nigh impossible to migrate a design from one vendor to another While maintaining anything like the same propagation delays. Third, the majority of synthesis tools (which are geared towards fine-grained AS|C architectures) output gate-level netlists, but FPGA fitting tools usually do a ,less than superb job of placement or packing from these netlists. Thus, in addition to relatively poor utilization of device resources, it's difficult to estimate realistic propagation delays prior to routing, which means that you sometimes have to perform a lot of finagling of the design in the downs~eam portions of the design cycle to make it work. However, there are some design techniques that are particularly apt for coursegrained FPGA architectures, such as the EDIF Library of Parameterized Modules (LPMs).

Designus Maximus Unleashed!

Designus Maximus Unleashed!

Unleashed

Unleashed

Unleashed

Unleashed

Unleashed

Unleashed

Unleashed

Unleashed

Unleashed

Unleashed

Unleashed

Unleashed

Unleashed

Unleashed

Unleashed

Unleashed

Unleashed

Unleashed

Unleashed

Unleashed

Unleashed

Unleashed

Religion - Maximus The Confessor

Silverlight 1.0 Unleashed [Unleashed Series]

Aufregung im Circus Maximus

Destiny Unleashed

PRIMAL Unleashed

Desire Unleashed

Designus Maximus Unleashed!