cover feature
Transcription
cover feature
The Official Publication of The Embedded Systems Conferences and Embedded.com MARCH 2008 VOLUME 21, NUMBER 3 Learn today • Design tomorrow p. 16 >> Linkage in C & C++ p.9 >> Atomic transactions p.27 >> Calculating CRC efficiently p.33 >> 20 Years Ago: Hardware description languages p.41 >> Ganssle: Determining complexity p.49 90% CUT IN EMISSIONS AND 50% CUT IN DEVELOPMENT TIME. THAT’S MODEL-BASED DESIGN. To meet a tough performance target, the engineering team at Nissan used dynamic system models instead of paper specifications. The result: 50% time savings, the first car certified to meet California’s Partial Zero Emissions Vehicle standard, and a U.S. EPA award. To learn more, visit mathworks.com/mbd Accelerating the pace of engineering and science ©2005 The MathWorks, Inc. Need to make sure they line up for your product first? With more than half of the product development cycle consumed by debugging, finding bugs faster means your product will get to market first. Green Hills Software provides premier tools that pinpoint the most elusive bugs in minutes, instead of hours or days. With the MULTI ® development environmentʼs time-saving code analysis tools, errors in code are automatically found, long before the debugging process begins. MULTI and the TimeMachine™ debugger allow developers to easily find every bug so that shipping a product with known problems becomes a thing of the past. With Green Hills Softwareʼs sophisticated technology youʼll produce a better product and get it out the door long before your competition. Call 800-765-4733 or visit us on the web www.ghs.com to learn more. Copyright © 2006 Green Hills Software, Inc. Green Hills, the Green Hills logo, MULTI and TimeMachine, are trademarks or registered trademarks of Green Hills Software, Inc. in the U.S. and/or internationally. All other trademarks are the property of their respective owners. RADIO + MCU + FLASH + USB Low-Power RF System-on-Chip The new CC1111 from Texas Instruments is the first sub-1 GHz RF SoC with an integrated full-speed USB controller, enabling a fast and easy bridge between PCs and RF. The integration of a high-performance radio, MCU, Flash memory and USB controller results in smaller PCB size, easier assembly and reduced overall system cost. Combined with TI’s SimpliciTI™ network protocol, the CC1111 provides easy development and improved low-power design. Wireless Sensor Network High-Performance Analog >>Your Way CC1110 CO2 Sensor CC1110 Full-Speed USB 2.0 Occupancy Sensor CC1110 Light Sensor High-Performance Analog >> Your Way, Technology for Innovators and the red/black banner are trademarks of Texas Instruments. XXXXXX © 2007 TI SimpliciTI, High-Performance Analog >> Your Way, Technology for Innovators and the red/black banner are trademarks of Texas Instruments. 1942A0 © 2008 TI For development kits, samples and datasheets, visit >> www.ti.com/cc1111 800.477.8924 ext. 4189 THE OFFICIAL PUBLICATION OF THE EMBEDDED SYSTEMS CONFERENCES AND EMBEDDED.COM columns programming pointers OO9 Linkage in C and C++ BY DAN SAKS www.embedded.com MARCH 2008 VOLUME 21, NUMBER 3 Cover Feature: Designing DSP-based motor control using fuzzy logic BY BYRON MILLER break points Taming software complexity The increased use of variable-speed drive motors to reduce energy consumption will require a shift from PID controllers to systems based on fuzzy logic algorithms to simplify design, reduce development time, and eliminate complex math formulas. A simple equation can help you measure the complexity of your code. BY JACK G. GANSSLE BY GEORGE HARPER Although you may not have heard of atomic transactions, they’re likely to change how you design and verify embedded systems. e Efficient CRC calculation with minimal memory footprint BY YANIV SAPIR AND YOSEF STEIN You can implement the cyclic redundancy check function in an embedded systems design with minimal impact on memory or performance by using linear feedback shift register instructions more intelligently. OO33 #include OO4 LiMo Foundation aims to put Linux in your handset BY RICHARD NASS Will a pro-Linux consortium unwittingly present a roadblock instead smooth sailing for mass adoption of Linux? OO Hardware/ software verification enters the atomic age + + + + OO49 departments OO16 27RR Scope determines what you can see within a translation unit. Linkage determines what you can see across translation units. parity bit What are our readers thinking? Go to the Embedded.com Forum to join the discussion. www.embedded.com/forum advertising index OO48 marketplace OO51 in person ESC Silicon Valley San Jose Convention Center April 14–18, 2008 www.embedded.com/esc/sv/ on-line www.embedded.com 41RR Programming your own microcontroller Web archive: BY ERNEST L. MEYER www.embedded.com/wriguide When this article was written 20 years ago, the FPGA was only five years old and not widely used yet. Here’s an early how-to article on PLD design that stands the test of time. www.embedded.com/archive Article submissions: EMBEDDED SYSTEMS DESIGN (ISSN 1558-2493 print; ISSN 1558-2507 PDF-electronic) is published monthly by CMP Media LLC., 600 Harrison Street, 5th floor, San Francisco, CA 94107, (415) 9476000. Please direct advertising and editorial inquiries to this address. SUBSCRIPTION RATE for the United States is $55 for 12 issues. Canadian/Mexican orders must be accompanied by payment in U.S. funds with additional postage of $6 per year. All other foreign subscriptions must be prepaid in U.S. funds with additional postage of $15 per year for surface mail and $40 per year for airmail. POSTMASTER: Send all changes to EMBEDDED SYSTEMS DESIGN, P.O. Box 3404, Northbrook, IL 60065-9468. For customer service, telephone toll-free (877) 676-9745. Please allow four to six weeks for change of address to take effect. Periodicals postage paid at San Francisco, CA and additional mailing offices. EMBEDDED SYSTEMS DESIGN is a registered trademark owned by the parent company, CMP Media LLC. All material published in EMBEDDED SYSTEMS DESIGN is copyright © 2005 by CMP Media LLC. All rights reserved. Reproduction of material appearing in EMBEDDED SYSTEMS DESIGN is forbidden without permission. #include BY Richard Nass Editor in Chief Richard Nass (201) 288-1904 [email protected] LiMo Foundation aims to put Linux in your handset P urple Labs has joined the LiMo Foundation. Unless you’re really in the know, you’ll probably look at this announcement the same way I did. I said, “Who is Purple Labs, and what is the LiMo Foundation?” But more importantly, “Why is this important to me?” Let me first start with who the LiMo Foundation (www.limofoundation.org) is. Founded by Motorola, NEC, NTT DoCoMo, Panasonic Mobile Communications, Orange, Samsung Electronics, and Vodafone, the group claims to be an independent, not-for-profit entity that strives to increase the adoption of Linux within the mobile industry, particularly for mobile handsets. The LiMo Foundation aims to leverage the mobile Linux platform (hence the name, LiMo) to create an open, transparent, scalable ecosystem spanning application and middleware developer communities and to encourage the creation of compelling, differentiated, and enhanced consumer experiences. Not too long ago, the LiMo member list grew with the addition of Aplix, Celunite, LG Electronics, McAfee, and Wind River as Core members. Additional Associate members include ARM, Broadcom, Ericsson, Innopath, KTF, MontaVista Software, and NXP. The Foundation, Richard Nass is editor in chief of Embedded Systems Design. You can reach him at [email protected]. which is open to device manufacturers, operators, chip-set makers, independent software vendors, integrators, and third-party developers, expects to see the first handsets supporting the LiMo platform reach the market in the first half of 2008. It probably won’t come as much of a surprise to learn that Purple Labs (www.purplelabs.com) is a supplier of embedded Linux solutions for mobile phones. In addition to joining the LiMo Foundation as an Associate member, it will support the organization’s mission to develop a worldclass Linux-based software platform for mobile devices. The company claims to be the first commercial Linux platform for feature phones in the consortium. This extends the LiMo initiative to mass-market mobile handsets. While I thought that Linux already had a place in this market, a flavor of the operating system is now endorsed by an industry consortium, assuming that was even necessary. I’d probably argue to the contrary. Having to go through yet another governing body, albeit a light-handed governing body, still presents a roadblock to mass adoption. Good technologies tend to eventually find their way into mainstream devices, regardless of whether they’re adopted by an industry group. I suspect the same will be true for Linux, if it’s not already true. Richard Nass, [email protected] 4 MARCH 2008 embedded systems design www.embedded.com Managing Editor Susan Rambo [email protected] Contributing Editors Michael Barr John Canosa Jack W. Crenshaw Jack G. Ganssle Dan Saks Larry Mittag Art Director Debee Rommel [email protected] European Correspondent Colin Holland [email protected] Embedded.com Site Editor Bernard Cole [email protected] Production Manager Pete Scibilia [email protected] Director of Audiences Services Kristi Cunningham [email protected] Subscription Customer Service P.O. Box 2165, Skokie, IL 60076 (800) 577-5356 (toll free), Fax: (847) 763-9606 [email protected] www.embeddedsystemsdesigncustomerservice.com Back Issues Kelly Minihan (800) 444-4881 (toll free), Fax: (785) 838-7566 Article Reprints, E-prints, and Permissions PARS International Corp. 102 West 38th Street, Sixth Floor New York, NY 10018 (212) 221-9595, Fax: (212) 221-9195 [email protected] www.magreprints.com.quickquote.asp Publisher David Blaza (415) 947-6929 [email protected] Editorial Review Board Michael Barr Jack W. Crenshaw Jack G. Ganssle Bill Gatliff Nigel Jones Niall Murphy Dan Saks Miro Samek Corporate David Levin Scott Mozarsky Tony Uphoff Robert Faletra Paul Miller Philip Chapnick Anne Marie Miller Marvlieu Jolla Hall Marie Myers Alexandra Raine Chairman Chief Financial Officer President, CMP Business Technology Group President, CMP Channel President, CMP Electronics Group President, CMP Game, Dobb’s, ICMI Group Corporate Senior Vice President, Sales Senior Vice President, Human Resources Senior Vice President, Manufacturing Senior Vice President, Communications FAST-FORWARD THE LEARNING CURVE. Maximize your team’s existing expertise. Familiar yet powerful tools—like Microsoft® Visual Studio® and the .NET programming model—allow your team to focus project hours on building the next generation of smart, connected devices. Plus, componentized and fully configured platforms in Windows ® Embedded can help save more unnecessary effort—so more time can be spent differentiating your final product, or simply bringing it to market faster. Learn more about how to fast-forward device development at: windowsembedded.com/fastforward COVERITY FINDS THE DEADLY DEFECTS THAT OTHERWISE GO UNDETECTED. Your source code is one of your organization’s most valuable assets. How can you be sure there are no hidden bugs? Coverity offers advanced source code analysis products for the detection of hazardous defects and security vulnerabilities, which help remove the obstacles to writing and deploying complex software. With Coverity, catastrophic errors are identified immediately as you write code, assuring the highest possible code quality—no matter how complex your code base. FREE TRIAL: Let us show you what evil lurks in your code. Go to www4.coverity.com to request a free trial that will scan your code and identify defects hidden in it. © 2007 Coverity, Inc. All rights reserved. Your code is either coverity clean—or it’s not. Reticulitermes Hesperus, or Subterranean Termite—unchecked, property damage estimated at $3 billion per year. Electron Micrograph, 140X Rethink performance. Embedded performance per watt just got a big boost. This is powerful stuff. You need designs to do more, but can’t increase power. No problem. Thanks to breakthroughs in 45nm, multi-core architectures, and a host of other exclusive innovations, Intel’s latest quad-core platform produces up to 67% more compute performance per watt.* Go to town. intel.com/go/rethink *Compared to previous generation Quad-Core Intel® Xeon® platform. Actual performance may vary. Comparison details at intel.com/go/rethink Intel and the Intel logo are trademarks of Intel Corporation in the U.S. and other countries. © 2008 Intel Corporation. All rights reserved. The Newest Semiconductors The ONLY New Catalog Every 90 Days Experience Mouser’s time-to-market advantage with no minimums and same-day shipping of the newest products from more than 335 leading suppliers. The Newest Products For Your Newest Designs www.mouser.com Over 925,000 Products Online (800) 346-6873 programming pointers BY Dan Saks Linkage in C and C++ A In my earlier article on the scope name declared in C or C++ rules,1 I explained the distinction may have attributes such as type, scope, storage durabetween declarations and definition, and linkage. Not every name tions, but omitted some details. has all of these attributes. For examThose details are pertinent to the ple, a function name has a type, a concept of linkage, so let’s take a scope, and a linkage, but no storage look at them first. duration. A statement label name has only a scope. DECLARATIONS AND An object’s type determines the DEFINITIONS object’s size and memory address A declaration associates attributes alignment, the values the object can with names. A declaration either inhave, and the operations that can be troduces a name into the current performed on that object. A functranslation unit or redeclares a name tion’s type specifies the function’s introduced by a declaration that apparameter list and return type. peared earlier in the same translaA name’s scope is that portion of tion unit. A declaration for a name a translation unit in which the might also be a definition. Informalname is visible.1 (A translation unit ly, a definition is a declaration that not only says “here’s a name,” but is the source code produced by the Scope determines what also “here’s all the information the preprocessor from a source file and you can see within a trans- compiler needs to create the code all its included headers.) C supfor that name”. ports four different kinds of scope: lation unit. Linkage deterC++ lets you declare all sorts of file scope, block scope, function mines what you can see things that aren’t valid in C, such as prototype scope, and function across translation units. classes, namespaces, and linkage scope. C++ generalizes file scope specifications. Not surprisingly, these into namespace scope, and adds features make the distinction between definitions and other class scope. declarations, as well as the linkage rules, more complicated An object’s storage duration determines the lifetime of the storage for that object.2 That is, it determines how and in C++ than in C. However, we don’t really need to consider all those features to explain linkage—using just functions when during program execution the storage for that oband objects should provide adequate illustration. ject comes and goes. Each object in C and C++ has one of For function declarations that are valid in both C and the following three storage durations: static, automatic, C++, the rule for deciding when a function declaration is and dynamic. Only objects have storage duration. Enualso a definition is the same for both languages, namely, meration constants, functions, labels, and types don’t. that a function declaration is also a function definition if Which brings us to linkage. A name’s linkage affects whether two or more declarations for that name are valid, it includes a brace-enclosed body, as in: and if so, whether they refer to the same entity (such as a function or an object). Understanding linkage clears up a int abs(int v) number of misconceptions about the behavior of C and { C++ programs. return v < 0 ? -v : v; }; Dan Saks is president of Saks & Associates, a C/C++ training and consulting company. For more information about Dan Saks, visit his website at www.dansaks.com. Dan also welcomes your feedback: e-mail him at [email protected]. A function heading without a body, as in: int abs(int v); is just a declaration. www.embedded.com | embedded systems design | MARCH 2008 9 programming pointers For object declarations that are valid in both C and C++, the rule for deciding when an object declaration is also a definition is—surprisingly—simpler in C++ than in C. In C++, an object declaration is also a definition unless it contains an extern specifier and no initializer. For example, all of the following object declarations are also definitions in C++: int i; static int j; extern int k = 0; // definition // definition // definition They are definitions whether they appear at file scope, namespace scope, or block scope. The following object declaration is not a definition: extern int m; // non-defining declaration Again, the rule I just cited is how C++ distinguishes object definitions from other object declarations. The cor- // foo.c #include “foo.h” int foo(int n) { ... } to ensure that the function defined in the source is working with the same declaration(s) as in the header. After preprocessing, the translation unit contains: int foo(int n); int foo(int n) { ... } From the compiler’s viewpoint, these are two declarations for the same function in the same scope. They refer to the same function because they have linkage. responding rule in C is complicated by the added presence of these things called tentative definitions. A tentative definition is an object declaration that might also be a definition, or it might not, depending on the presence of other definitions. In truth, the previous declarations for i and j are tentative definitions in C. C++ doesn’t recognize tentative definitions, so some combinations of object declarations that are valid in C aren’t valid in C++. The C++ rule for distinguishing object definitions from other object declarations works equally well in C as in C++. If you follow that rule in C, you won’t go wrong. THE CONCEPT OF LINKAGE In some cases, C and C++ let you declare the same entity more than once, in different translation units, different scopes of the same translation unit, or even in the same scope. For example, the common C technique for packaging a library function is to declare the function in a header: // foo.h // from the header which declares the function twice. The second declaration is also the definition. From the compiler’s viewpoint, these are two declarations for the same function in the same scope. They refer to the same function because they have linkage. C and C++ provide for three levels of linkage: name with no linkage denotes an entity that can’t be • Areferenced via names from anywhere else. with internal linkage denotes an entity that can • Abename referenced via names declared in the same scope or in other scopes of the same translation unit. with external linkage denotes an entity that can • Abename referenced via names declared in the same scope or in other scopes of the same translation unit (just as with internal linkage), or additionally in other translation units. Both function and object names can have either internal or external linkage. Object names can also have no linkage. Beyond that, all other names in C have no linkage. In contrast, other names in C++ can have external linkage, including names for classes, enumeration types and constants, namespaces, references, and templates. References and function templates can also have internal linkage. LINKAGE FOR FUNCTIONS A function declared without a storage class specifier normally has external linkage by default. Placing the keyword extern in a function declaration such as: int foo(int n); extern int foo(int n); and define the function in a corresponding source file. That source file should include the header, as in: 10 MARCH 2008 | embedded systems design | www.embedded.com has no effect. With or without the extern specifier, you N IO RS L E B A NE W AV V AI E L NI LabVIEW. Limited Only by Your Imagination. Communicate via multiple protocols including Bluetooth Build and program robots with LEGO® MINDSTORMS® NXT using software powered by NI LabVIEW Graphically program concurrent, real-time applications Develop your human machine interface (HMI) display Target 32-bit microprocessors and FPGAs Independently control multiple servo motors Real-Time and Embedded PRODUCT PLATFORM LabVIEW Real-Time Module LabVIEW FPGA Module LabVIEW Microprocessor SDK NI CompactRIO Embedded Hardware Platform Signal Processing High-Performance Test Industrial Control When the LEGO Group needed parallel programming and motor control tools intuitive enough for children, it selected graphical software powered by NI LabVIEW. With LabVIEW graphical system design, domain experts can quickly develop complex, embedded real-time systems with FPGAs, DSPs, and microprocessors. >> Expand your imagination with technical resources at ni.com/imagine © 2007 National Instruments Corporation. All rights reserved. CompactRIO, LabVIEW, National Instruments, NI, and ni.com are trademarks of National Instruments. Other product and company names listed are trademarks or trade names of their respective companies. LEGO and MINDSTORMS are trademarks of the LEGO Group used here with special permission. 2007-9039-821-101D 866 337 5041 programming pointers can place this function declaration in a header, include that header in several source files, compile each file, and link the compiled modules together. Subsequently, all calls to that foo from any of those source files will call the same function. A function declared at file or namespace scope with the keyword static has internal linkage. That is, when you declare: static int foo(int n); Written either way, these declarations are valid in both C and C++, and foo has internal linkage. However, just because you can do this doesn’t mean you should. Writing function declarations that differ only in their storage class specifiers is rarely, if ever, necessary, and can be confusing. If a single identifier has both internal and external linkage in the same translation unit, the resulting program has undefined behavior. That is, it’s an error, but you might not get an error message from the compiler all calls to foo in that translation unit will be to a Written either way, these declarations are function foo defined in that same translation unit. If valid in both C and C++ . . . however, just the translation unit contains calls to foo, yet function foo isn’t defined in that translation unit, the because you can do this doesn’t mean program won’t compile or link, even if there’s a defiyou should. nition for function foo in another translation unit. Table 1 illustrates how C and C++ determine or linker. For example, reversing the order of the exthe linkage for a function from the storage class specifier and the scope of the function’s declaration. For example, tern and static declarations from the previous examthe row labeled extern shows that a function declared ple, as in: extern doesn’t always have external linkage. The row labeled none shows that a function declared without a storextern int foo(int n); // external linkage age class specifier at file, namespace, or block scope be... haves as if it were declared with the keyword extern. For example, a single translation unit can contain the static int foo(int n); // undefined behavior following declarations: yields undefined behavior. All the more reason not to static int foo(int n); // internal linkage write things like this. ... extern int foo(int n); // still internal The extern declaration could be in an inner scope, as in: static int foo(int n); ... // internal linkage int bar(int m) { extern int foo(int n); // still internal ... } Linkage for functions in C and C++. storage class at file scope (C) or specifier namespace scope (C++) auto extern register static none invalid normally external linkage, but possibly internal linkage* invalid internal linkage same as extern LINKAGE FOR OBJECTS Table 2 illustrates how C and C++ determine linkage and storage duration for an object from the storage class specifier and the scope of the object’s declaration. It shows, for example, that a non-const object declared at file or namespace scope without a storage class specifier, such as: int n; has external linkage and static storage duration. This declaration is also a definition in C++ but only a tentative definition in C. at block scope invalid normally external linkage, but possibly internal linkage* invalid invalid same as extern *The name has internal linkage if previously declared with internal linkage in a visible declaration. Table 1 12 MARCH 2008 | embedded systems design | www.embedded.com at class scope (only in C++ ) invalid invalid invalid internal linkage external linkage It’s the best connected 15-year-old in the MCU industry. ColdFire® Architecture. The perfect 32-bit compilation. The ColdFire Architecture has a 15-year heritage steeped in innovation. With more than 100 individual devices, ColdFire has one of the broadest 32-bit portfolios in the industry. Whether it’s USB, Ethernet, CAN or ZigBee®, ColdFire connects and controls millions of networked products in homes, offices and factories around the world. ColdFire also enables your design to keep pace with today’s eco-trends thanks to its industry-leading, ultra-low-power 32-bit MCU. And to make its own ecosystem even stronger and more vibrant, we are now openly licensing ColdFire V1. Find out what ColdFire can do for you. Meet ColdFire at freescale.com/coldfire101 and save 50% on the QE128 Development Kit.* * While supplies last. Freescale™ and the Freescale logo are trademarks and ColdFire is a registered trademark of Freescale Semiconductor, Inc. All other product or service names are the property of their respective owners. ©Freescale Semiconductor, Inc. 2008. programming pointers Linkage and storage duration for objects in C and C++. storage class at file scope (C) or specifier namespace scope (C++) auto extern register static none at class scope (only in C++ ) at block scope invalid normally external linkage, but possibly internal linkage;* static storage invalid internal linkage; static storage normally external linkage, except that const objects in C++ have internal linkage; static storage no linkage; automatic storage normally external linkage, but possibly internal linkage;* static storage same as auto no linkage; static storage same as auto invalid invalid invalid external linkage; static storage no linkage; same storage duration as enclosing object *The name has internal linkage if previously declared with internal linkage in a visible declaration. Table 2 With many C compilers, you can place this declaration in a header, include that header in several source files, compile each source file, and link them together. The linker will treat one of those tentative definitions as a definition and all the other tentative definitions as declarations referring to that definition. This behavior is a common extension to the C standard, but may not be portable to all C environments, and doesn’t work in C++. Using C++, you’ll get a link error complaining about a multiply-defined symbol. If you want the code to compile and link in C++ as well as C, you must declare n with the extern specifier, as in: extern int n; As before, n has external linkage, but now the declaration is not a definition—not even a tentative one in C. You can place this declaration in a header, include that header in several source files, compile each source file, and link them together. But you’ll still get a link error, unless there’s exactly one definition for all those declarations to reference. Just one of the source files must provide a definition for n. Any one of the following definitions will do: 14 // still internal linkage int foo(int v) { static int n; ... } // still no linkage defines two distinct objects named n, both with static storage duration. The n at block scope still has no linkage. There’s more to say about linkage, but this is enough for now. ■ 1. An object declared at block scope without a storage class specifier has automatic storage duration and no linkage. For example, in: int foo(int v) { int n; ... } static int n; ENDNOTES: int n; int n = 0; extern int n = 0; static int n; both parameter v and local object n have no linkage. You can’t write a declaration for an integer v elsewhere and get it to link to foo’s parameter v. Likewise for n. Thus, the two objects named n in this example are distinct objects. If you add the static storage class specifier to the declaration of n at block scope, you change its storage duration but not its linkage. For example: // internal linkage 2. Saks, Dan, “Scope regions in C and C++,” Embedded Systems Design, November, 2007, p. 15. Available online at www.embedded.com/columns/programmingpointers/ 202600398. Saks, Dan, “Storage class specifiers and storage duration,” Embedded Systems Design, January, 2008, p. 9. Available online at www.embedded.com/columns/programmingpointers/ 205203843. ACKNOWLEDGMENTS: // no linkage MARCH 2008 | embedded systems design | www.embedded.com My thanks to Steve Adamczyk of the Edison Design Group (www.edg.com), Tom Plum of Plum Hall (www.plumhall.com), and Joel Saks (www.joelsaks.com) for their valuable assistance with this article. SMIlE, MaRS! ThreadX RTOS manages camera software critical to NaSa mission ® “We found ThreadX to be a proven solution based on its demonstrated success for the Deep Impact mission, so using it for the HiRISE instrument aboard the MRO was a logical decision. ThreadX delivered a first-rate performance for us and helped the MRO mission return extraordinary high-resolution images from Mars.” – Steve Tarr, HiRISE Software Lead, Ball Aerospace & Technologies Corp. Images courtesy NASA: http://mars.jpl.nasa.gov/mro MRO spacecraft depicted in Mars orbit: NASA The Mission Opportunity Rover When they wrote the embedded software that controls the cameras aboard the Mars Reconnaissance Orbiter (MRO), a team of Ball Aerospace and Technology Corp. engineers led by Steve Tarr knew they only had one chance to get it right. If there was a seriT H R E A D ous flaw anywhere in the software, the $720 million spacecraft might have no more value than a digital camera dropped in a bathtub. Tarr and his team wrote 20,000 lines of code and used Express Logic's ThreadX RTOS. The software has worked flawlessly, resulting in history-making photographs such as the one to the left that shows the Opportunity rover traversing the surface of Mars. The Technology With its intuitive API, rock-solid reliability, small memory footprint, and high-performance, ThreadX delivered the goods for NASA's MRO. ThreadX is in over 450 million electronic devices from NASA's MRO to HP's printers and digital cameras. Which RTOS will you choose for YOUR next project? Order today on Amazon Real-Time Embedded Multithreading Using ThreadX and ARM by Edward L. Lamie Small Memory Footprint • Fast Context Switch • Fast Interrupt Response Preemption-Threshold™ Technology • Picokernel™ Design • Event Chaining™ Broad Tools Support • Supports All Leading 32/64-bit Processors • Easy to Use Full Source Code • Royalty-Free For a free evaluation copy, visit www.rtos.com • 1-888-THREaDX Copyright © 2007, Express Logic, Inc. ThreadX is a registered trademark of Express Logic, Inc. All other trademarks are the property of their respective owners. cover feature Designing DSP-based BY BYRON MILLER V ariable-speed drive (VSD) motors provide hope for greatly reducing energy consumption and reliance on foreign fuels. In one approach, digital signal processors (DSPs) are being used to create a new generation of VSD-based controllers for motors such as brushless direct current (BLDC) motors. However, these motors present challenges. Controlling motor speed on a BLDC motor is complicated when using traditional proportional, integral, and differential (PID) controllers because they rely on a complex mathematical model and are computationally intensive. An alternative approach is to use fuzzy logic (FL) algorithms to eliminate the need for complex math formulas and provide an easy-to-understand solution. FL motor control also has a shorter development cycle compared to PID controllers, and thus a faster time-to-market. This article discusses the process of using FL algorithms to control BLDC motors using a Texas Instruments c28xx fixed-point family of DSPs. BLDC CONTROL MODEL DEVELOPMENT Before constructing the FL engine, we must first develop a model to base the design on. FL controllers use heuristic knowledge and express the design using a linguistic description of the model. Rather than develop a model from scratch, we’ll use the PID controller model as a starting point. Once developed and implemented, the FL controller is improved by adjusting its parameters. In general, there are three design steps for developing a FL BLDC controller: 16 MARCH 2008 | embedded systems design | www.embedded.com The increased use of variable-speed drive motors to reduce energy consumption will require a shift from PID controllers to systems based on fuzzy logic algorithms to simplify design, reduce development time, and eliminate complex math formulas. motor control using fuzzy logic cover feature The BLDC controller block diagram. termine system behavior, rather than complex math equations. For example, IF the error (E) is equal to NM and + Hysteresis Ιρ ΔΙ Voltage current 3-Phase I dt change in error (CE) is equal to PS, inverter – controller Position then the change in the armature voltcy decoder age (CV) is equal to NS. The number Speed controller of rules used is based on the experience of the designer and the knowledge of Encoder cε ε the system. Thus, for our system the d/dt number of rules used is 25, which is + – ω d/dt based on our basic PID controller ωρ model using the PID’s control surface. Figure 1 In order to energize the armature, the CV fuzzy output must be converted back to a crisp output. This process is natively, CE is negative iff the current called defuzzification. A popular 1. Define inputs, outputs, and the speed is greater than the set speed. method of defuzzification called the controller’s range of operation. center of gravity method is used; I’ll 2. Define fuzzy membership set func- When close to the set speed CE alternates between positive and negative discuss it in greater detail later. tions and rules. values. CV is the energizing voltage apThe last step of design is to adjust 3. Tune the engine. plied to the armature. This voltage is the membership functions and rules. expressed in implementation as a pulse This stage is also referred to as tuning. Figure 1 shows the block diagram of Tuning is used to imthe BLDC controller model. prove the performance The first step is to define Instead of math formulas, a fuzzy-logic of the FL controller. the relevant inputs and outOnce designed, the puts of the model. The incontroller uses fuzzy rules to make a controller is ready to puts are the error (E), which decision and generate an output; be implemented. is the current error between how cool is that? The FL controller the set speed (SS) and the implementation is current speed (CS). The othwidth modulation (PWM) duty cycle. made up of three modules. They are er input is the change in error (CE), The next step is to define the fuzzy fuzzification, rule-base, and defuzzifiwhich is the difference between the cation. The following sections discuss current error, and the previously calcu- membership set functions, variables and rules. In order to work, non-fuzzy the modules as related to the FL-BLDC lated error (PE). The output is the (crisp) inputs and outputs must be implementation. change in armature voltage (CV), converted into fuzzy ones. Conversion which is the difference between the is performed by using linguistic variFUZZIFICATION current armature voltage (CAV) and ables to represent input and output Fuzzificaton is the process of convertthe stored value of the previous armaranges. These are also referred to as ing crisp value data into fuzzy data. ture voltage (PAV). The resulting fuzzy variables. Fuzzy variables are used The resulting fuzzy data conversion is model equations are as follows: to partition a region of values for based on the degree of fuzzy set memmembership functions. For example, bership of input variables. For this apE = SS – CS five variables are used to map the inplication, motor control input variCE = E – PE puts and output. They are negative ables are rotational error (Error) and CV = CAV – PAV medium (NM), negative small (NS), change in rotational error (Cerror), zero (Z), positive small (PS), and posiwhich are taken from the PID conMotor speed units are in revolutive medium (PM). The model’s inputs troller model discussed earlier. Error is tions per minute (RPM), and E deterand outputs are membership set functhe absolute error from one sample mines how close we are to the target tions that are described over the range time to the next. Similarly, Cerror is speed. So for E > 0 motor speed is below set speed. Alternatively, E < 0 indiof operation by the five fuzzy variables. the change in Error from one sample time to the next. The formulas for cates that the motor is spinning faster Instead of math formulas, an FL each are: than the set speed. CE determines concontroller uses fuzzy rules to make a troller direction to adjust. CE is posidecision and generate an output; how Error = SetSpeed – CurrentSpeed tive if and only if (iff) the current cool is that? FL rules are in the form of Cerror = Error – PreviousError speed is less than the set speed. AlterIF-THEN statements. Fuzzy rules deBLDC motor 18 MARCH 2008 | embedded systems design | www.embedded.com The Microchip name and logo, the Microchip logo and dsPIC are registered trademarks of Microchip Technology Incorporated in the USA and in other countries. All other trademarks mentioned herein are property of their respective companies. ©2008, Microchip Technology Inc. All rights reserved. More Efficient 3-Phase Motor Control Explore the New Motor Control Solutions from Microchip Are you considering moving to brushless motors, eliminating costly sensors or adding PFC? Let Microchip show you how to improve your efficiency, lower noise, reduce your form factor and explore cost reduction options. Visit www.microchip.com/DSCMOTOR and discover Microchip’s comprehensive motor control solutions, which feature 16-bit digital signal controllers, free software, development tool discounts, technical training and more! Looking for? Energy Savings Noise Reduction Cost Reduction Better Torque Control Improve Reliability to... Microchip Has the Solution! Add Power Factor Correction PWM with 2 Time Bases Incorporate Field-Oriented Control Free Software Incorporate Sinusoidal Control Free Software Remove Expensive Sensors Free Software, 4 S&H ADC Integrate PFC and Motor Controller PWM with 2 Time Bases Integrate Controller on Motor 6x6 mm Small Packages Easily Migrate to Other DSCs in Portfolio Optimized Feature Set Remove Crystal 1% Internal Oscillator Incorporate Field Oriented Control Free Software Better Loop Response Multiple S&H ADC Migrate from Brushed to Brushless Motors Free Software Noise Profile Diagnostics DSP Resource On-chip Purchase Microchip’s motor control development solutions at... microchip DIRECT www.microchipdirect.com www.microchip.com/DSCMOTOR Microcontrollers • Digital Signal Controllers • Analog • Serial EEPROMs cover feature The membership function for the input variables Error, and Cerror. y 0x1AAA X1[ ] 0x0 0x0 0x196A 0x13F 0x0 X2[ ] 0x0 0x0 0x19D6 0x6A 0x0 PM PS ZE NS NM Fuzzified data resulting from Error equal to 0x30 (x-axis) and Cerror equal to 0x10 (x-axis). Array NM NS ZE PS PM Table 1 -0x5000 -0x3554 0x1AAA 0 -0x1AAA 0x5000 0x3554 Figure 2 The fuzzified membership function for the input variable Error: X1[]. y 0x196A 0x1AAA NM NS ZE PS PM 0x13F -0x5000 -0x3554 -0x1AAA 0 0x1AAA 0x3554 0x5000 Figure 3 The fuzzified membership function for the input variable Cerror: X2[]. y 0x19D6 0x1AAA NM NS ZE PS PM 0x6A -0x5000 -0x3554 -0x1AAA 0 0x1AAA 0x3554 0x5000 Figure 4 The inference rule table. Error: X1[ ] NM NS ZE PS PM NM Cerror:X2[] NS ZE PS PM NM NM NM NS ZE NM NM NS ZE PS NS ZE PS PM PM ZE PS PM PM PM NM NS ZE PS PM Table 2 20 As mentioned during the design section, five membership sets are defined for variables Error and Cerror: 3. ZE: Zero 4. PS: Positive Small 5. PM: Positive Medium 1. NM: Negative Medium 2. NS: Negative Small Figure 2 shows the membership sets for variables Error and Cerror. The MARCH 2008 | embedded systems design | www.embedded.com membership sets are triangular-shaped and overlap to provide good response. Each set has a maximum value of 0x1AAA. This differs from typical fuzzy logic literature, which sets the maximum range equal to one. Using a maximum value of 0x1AAA for the range reduces computational complexity. Specifically, the multiplying operation is reduced to either a series of additions or subtractions rather than converting to and from a floating point number. The resulting fuzzification of the input variables produces a vector with five components that correspond to the fuzzy membership sets NM, NS, ZE, PS, PM. The value (y-axis) of each component represents the degree of membership for that crisp input value. The vectors containing the fuzzified values of Error and Cerror are denoted by arrays X1[] and X2[] respectively. For example, with Error equal to 0x30 (x-axis), and Cerror equal to 0x10 (x-axis), the resulting fuzzified data are shown in Table 1. Figures 3 and 4 graphically show the resulting fuzzified values for Error and Cerror. FUZZY INFERENCE RULES Fuzzy inference rules operate on the fuzzified data to determine the system’s behavior. Specifically, the fuzzified data is applied against the rule table. Linguistically, this is where the input data Error and Cerror are compared with the rule table. The rule table contains membership set components NM, NS, ZE, PS, and PM, depending on the control surface. The output is “inferred” from the valid or “fired” rules. The inference process is described by pseudo code in Listing 1. Table 2 shows the initial rule base for the motor control surface. Microcontroller Development Tools ARM Microcontroller Solution ARM Powered Microcontrollers – available from many silicon vendors; offer high computing performance along with rich peripherals. Turn ARM Microcontrollers into your solution for cost-sensitive powerful applications – with Keil Development Tools. ® Cx51 Keil Cx51 is the de-facto industry standard for all classic and extended 8051 device variants. C51 Version 8.5 includes the latest devices such as XC800,ADE7169, and C8051F4xx - F6xx. More information: www.keil.com/c51 C/C++ Development Kit JTAG Debugger The RealView Microcontroller Development Kit (MDK) is the complete software development environment for ARM7/9 and Cortex-M1/M3. ULINK2® connects to the JTAG or 2-wire debug interface and supports on-the-fly debugging and Flash programming. MDK is easy to learn and use, yet powerful enough for the most demanding embedded ARM ® application.The integrated Device Database simplifies tool configuration and includes more than 250 ARM Powered Microcontroller variants for your embedded project. C166 Keil C166 is the complete software development environment for Infineon C166, XC166, XC2000 and ST Microelectronics ST10 with debug and programming support via ULINK2. More information: www.keil.com/c166 ® RealView Microcontroller Development Kit RTX RTOS Kernel Library µVision Device Database & IDE µVision Debugger & Analysis Tools Examples and Templates RealView C/C++ Compiler Complete Device Simulation A/D Converter I/O Ports Debug Run-Control Timer/Counter Interrupt System Debug Channel PWM UART Flash ROM CPU RAM ARM RealView MDK combines the best-in-class ARM C/C++ Compiler, the genuine Keil µVision IDE/Debugger/Simulator, and the royalty-free RTX RTOS Kernel. More information: www.keil.com/arm Real-Time Clock I2C/SPI DMA ® Ethernet RealView Real-Time Library SD/MMC Interface USB CAN TCPnet Networking Suite Flash File System USB Device Interface CAN Interface Examples and Templates RTX RTOS Source Code RTOS and Middleware The RealView Real-Time Library (RL-ARM) solves the real-time and communication challenges of your ARM project and expands MDK with essential components for sophisticated communication and interface peripherals. Keil MCB evaluation boards come with code size limited tools and extensive example projects that help you get up and running quickly with your own embedded application. More information: www.keil.com/boards Learn more about RealView MDK, RL-ARM, and ULINK2. Download a free evaluation version from www.keil.com/demo or call 1-800-348-8051. www.keil.com cover feature Listing 1 Inference rules pseudo code. MinValue = MaxValue = 0 Y[0..N] = 0; For (I = 0 to N) { for (j = 0 to M) { MinValue = Min{X1[I], X2[M]}; // compare each X1 element to X2 element and store // smaller value // store max value found among X2 members If (Max{X1[I], X2[M]} > MaxValue) // { MaxValue = Max{X1[I], X2[M]}; } // add max value to output vector function defined by // membership rules MaxValue += output_vector_member(x); } } FUZZY LOGIC DEFINITIONS Centroid calculation function: used for producing an exact output value by calculating the center of gravity of the union of areas bound by membership functions and the input variable axes. Defuzzification: a general method for determining the best exact or “crisp” output of a given fuzzy set, defuzzification uses the centroid calculation function or a similar function to generate a crisp output. Fuzzification: a method for converting a “crisp” input value to a fuzzy membership function. The resulting fuzzy value is a member of a multivalued set. Fuzzy control system: a control system based on fuzzy IF-THEN rules that use fuzzy sets for input and output. Fuzzy inference system: a collection of fuzzy IF-THEN rules. Fuzzy logic: logic that uses linguistic variables to describe a system. Examples include: “fast,” “slow,” and “medium.” Fuzzy set: any set that allows its members to have different “grades” of membership. Each member may be expressed by a continuous number between zero and one: [0,1]. This contrasts to Boolean logic that limits set members to a value of either zero or one. Fuzzy system: a system whose variables range over states that are fuzzy sets. Membership function: the mapping of a fuzzy set that associates each set member with its grade of membership. 22 MARCH 2008 | embedded systems design | www.embedded.com Defuzzified output vector table. Array NM NS ZE PS PM Y[ ] 0x0 0x13F 0x196A 0x0 0x0 Table 3 In the earlier example, output vector Y[] is shown in Table 3. DEFUZZIFICATION Defuzzification is the process of converting fuzzy data back into crisp value data. For the purpose of this application the defuzzified value determines the duty cycle of the PWM signal used to drive the motor. The duty cycle is determined by using the modified centroid calculation function. The defuzzification approach used here takes the centroid function and multiplies it by a coefficient. The modified calculation is also known as the centroid point calculation function. This approach provides additional precision over the centroid calculation function. The centroid point calculation is obtained by the center point of the function that is the result of the multiplication of the output membership function by the output vector Y[]. The formula for the centroid point calculation is: Defuzzified Value = Σ_Y[i] X multCoeff[I] / Σ Y[i] where Y[i] are the i-th elements of the output vector, and multCoeff[i] are the multiplying coefficients of the output membership function. The index i has a range of i = 1 to i = 5. Figure 5 shows the graphical representation of the output membership function used by this application with the coefficients of [-0x10, -0x8, 0x0, 0x8, 0x10]. Using the example output vector Y[] = [0x0, 0x13F, 0x196A, 0x0, 0x0], the following defuzzification output value is calculated: Defuz = 0 X (-16) + 319 X (-8) + 6506 X (0) + 0 X (8) + 0 X (16) / 0 + 319 + 6506 + 0 + 0 = -2552 / 6825 => -0.37391 cover feature ECAP1-3 capture signals from the halleffect sensors. The motor is driven with PWM signals generated by the DSP and translated to a 3-phase output. The six PWM signals are used to source the 3phase power inverter. The power inverter converts the six signals to a 3phase signal that directly powers the motor. The 3-phase power inverter function is handled by an auxiliary Figure 6 shows the graphical representation of the centroid point calculation for the output vector Y[]. termined by detecting edges from signals received from the hall-effect sensors. The signals are fed into the TMS320F2812’s capture pins and are debounced to eliminate noise or false edges from motor oscillations. The actual motor speed is calculated by counting the edge-triggered signals from the Hall-effect sensors via a software module. Figure 7 shows the hardware block diagram for controlling a three phase BLDC motor. HARDWARE DESCRIPTION The eZdsp2812 board is used in this motor control application. At the heart of the eZdsp board is the TMS320F2812 DSP. The TMS320F2812 is a 150-MHz device that uses timer T1 running at 20 kHz for generating PWM1-6 signals, and timer T2 running The fuzzy controller calculates at 40 kHz for executing inthe absolute and differential based on the SOFTWARE terrupt service routines DESCRIPTION (ISRs). Additionally, the intarget set speed, current speed, and The motor control put capture pins CAP1-3 are previous absolute error. software is composed used to collect speed data of DMC Library modfrom the hall-effect sensors. motor control board. Spectrum Digital ules and the FL motor control routines. Other members of the 28xx family Seven of the DMClib modules are used provides two boards that provide this may be substituted for the in this application. They are: function: the DMC550 and the TMS320F2812. For instance, the eZdsp2808 board may be used if the timers DMC1500. Either board plugs directly into the eZdsp28xx board. driving the PWM and ISRs are Datalog Hall-effect sensors are used for changed. Specifically on the eZdsp2808 BLDC3PWM feedback for the fuzzy logic control board, EPWM1-3 is used for PWM Hall3_Drv loop. The commutation instants for the generation, while CPU timer 0 is used Mod6_Cnt 3-phase power inverter switches are defor an ISR interrupt source. Similarly, Rmp2Cntl Ramp_Cntl Speed_PR • • • • • • • The output membership function. y NM NS -0x10 -0x8 ZE 0x0 PS PM 0x8 0x10 Figure 5 The output membership function multiplied by vector Y[]. y NM NS -0x10 -0x8 ZE 0x0 0x13F 0x196A PS PM 0x8 0x10 Figure 6 24 MARCH 2008 | embedded systems design | www.embedded.com Additionally, the FL motor control is handled by a main FuzzyCtl() routine; this is FuzzyBLDC() for BLDC motors. When configured, these components demonstrate fuzzy logic control of a variable speed motor. The software works by first performing configuration, then application-specific setup. Specifically, the GPIO pins are configured to act as PWMs and CAPture pins. Next the timers and module parameters are initialized, as well as ISR setup. After all peripherals are setup, interrupts are enabled, and the main control loop is entered. The main control loop calls the fuzzy controller once every 8.7 ms. The error values are converted through fuzzification into fuzzy values and stored in X1[], and X2[]. Once converted, the fuzzified values applied to the fuzzy inference rules. The results from the inference module are stored in Y[]. Output from Y[] is then applied cover feature to the defuzzification module to convert the fuzzy value back to a crisp value. The resulting crisp value is a PWM offset that is added to the current PWM duty cycle; creating a closed loop system. The updated PWM value is checked to see if the new value is within bounds, and appropriate action is taken if it is not. Finally the fuzzy controller returns the updated PWM duty cycle count to the calling routine. Figure 8 shows a debug session of the demo application. Channels 1 &2 (the display window in the upper-right hand corner) displays the PWM counter, and the capture of the hall-effect sensors respectively. Channels 3 & 4 (the display window beneath channels 1 & 2) show the edge-triggered versions of the PWM counter and the hall-effect sensors. The watch window displays important variables. Most important are SetSpeed, and CurrentSpeed. These values are close enough so that the output of the fuzzy controller has a zero value. Also note the other values used in the controller process. This session shows the motor under no-load conditions. The behavior may be slightly different with a load. Moreover, if a finer granularity is desired it may be necessary to tune the controller. ■ Byron Miller is an independent firmware engineer specializing in the design of microprocessors, DSPs, hardware debug, porting, as well as the development of firmware for control, data acquisition, fuzzy logic, and Internet appliances. He has a BA in computer science and a masters in software engineering. You can reach him at [email protected]. FURTHER READING: Von Altrock, Constantin. Fuzzy Logic and NeuroFuzzy Applications Explained. Englewood Cliffs, NJ: Prentice Hall, 1995. Miller, Byron. The Design and Development of Fuzzy Logic Controllers. Minneapolis, MN: Impatiens Publications, 1997 Demonstration application motor control block diagram. 3.3V BLDC motor 12Vdc 6 - PWMs 3-Phase inverter 3-Phase TMS320F/C2812 CAP1 - 3 X1 Hall effect sensors X2 Figure 7 Motor debug session. Figure 8 Brubaker, David. “Fuzzy-logic system solves control problem,” EDN June 18, 1992, p. 121. Brubaker, David. “Design and simulate your own fuzzy setpoint controller,” EDN January 5, 1995, p. 167. V. Donescu, D.O. Ncacsu, G. Griva, “Design of a Fuzzy Logic Speed Controller for Brushless DC Motor Drives,” IEEE Spectrum September 1996, p. 404. G. Klir, D. Schwartz, “Fuzzy logic flowers in Japan, IEEE Spectrum JULY 1992, p. 32. M. Chow, Y. Tipsuwan, “Fuzzy Logic Microcontroller Implementation for DC Motor Speed Control,” IEEE Spectrum March 1999, p. 1271. Brubaker, David. “Fuzzy-logic basics: intuitive rules replace complex math,” EDN June 18, 1992, p. 111. J. Lee, T. Im, H. Sung, Y. Kim, “A Low Cost Speed Control System of Brushless DC Motor Using Fuzzy Logic,” IEEE Spectrum April 1999, p. 433. Miller, Byron. “A Top-Down Approach to Fuzzy Logic Design,” Embedded Systems Programming, July 1998, p. 52. Simon, Dan. “Fuzzy Control,” ESP July, 2003, p. 55. Miller, Byron. “Fuzzy Logic Does Real Time on the DSP,” Dr. Dobbs Journal, July 2004, p. 25. Fuzzy Logic: An Overview of the Latest Control Methodology. (TI doc – SPRA028). Fuzzy Logic Motor Control with MSP430x14x. (TI doc- SLAA235). TMS320F/C28xx Data Manual. (TI doc – SPRS174M). www.embedded.com | embedded systems design | MARCH 2008 25 From the core to the access, over copper, optical fibers and through the air, AMCC powers and connects the technology that connects today's world. With unique solutions like the PowerPC 405EX, winner of Electronics Products’ 2007 Product of the Year award, we’re setting the pace in the development of: • Power Architecture Processors • Datacom PHYs • SAS and SATA RAID Controllers • Telecom PHYs • Framers/Mappers • Storage Processors And we’re ready to help you with all your PROCESS • TRANSPORT • STORE applications. Ready to find out more? Visit us at... San Jose, CA April 15-17, 2008 Expo Booth 2010 or learn about the latest AMCC products online at www.amcc.com AMCC is a registered trademark of Applied Micro Circuits Corporation. All other trademarks are the property of their respective holders. Copyright © 2007 Applied Micro Circuits Corporation. All Rights Reserved. feature Although you may not have heard of atomic transactions, they’re likely to change how you design and verify embedded systems. Hardware/software verification enters the atomic age BY GEORGE HARPER W hile the 1940s and 1950s saw the dawn of the nuclear age for power and weaponry, a half a century later we’re just now entering an atomic age of a different sort. Having little to do with radioactivity, this atomic age is about software and hardware design, specifically using atomic transactions, by far the most powerful technique for managing one of our most tricky problems, concurrency. Even if you haven’t heard of atomic transactions before, they’re likely to have an impact on your future work, whether you design embedded software, architect systems, perform verification, or design hardware. Atomic transactions are not a new technology, but the increasing complexity and amount of concurrency in systems is pressing their emergence in all of these areas. So, just what are atomic transactions? And, how are they already manifesting themselves in embedded systems software, processor, and hardware design? After introducing atomic transactions and ways in which they’re revealing themselves, this article will take a special look at their implications to verification. e- e+ + + + ee- ATOMIC TRANSACTIONS 101 If you are familiar with database transactions, you’ve probably already been exposed to atomic transactions. When processing multiple, simultaneous transactions, databases use atomic transactions to maintain consistency. Imagine a couple who share a bank account and simultaneously make two withdrawals of $100 from separate ATM machines across town (Figure 1). Several steps are involved in each withdrawal: A) checking the www.embedded.com | embedded systems design | MARCH 2008 27 feature A common instance of the use of atomic transactions is in databases, such as those used in ATM machine applications. The example here shows simultaneous withdrawals from one account. ATM 1 ATM 2 Bank operations (non-atomic) ATM 1 Get balance = $1000 Output $100; Calculate new balance = $900 Update new balance ATM 2 Account ATM 1 $1000 Get balance = $1000 Get balance = $1000 Output $100; Calculate new balance = $900 Update new balance Bank operations (Atomic) ATM 2 $1000 Output $100; Calculate new balance = $900 Update new balance $900 Get balance = $900 $900 Output $100; Calculate new balance = $900 $900 Incorrect Update new balance balance; B) providing the money and calculating the new balance, and; C) updating the balance with the new amount. Now imagine that each step were independent (1A, 1B, and 1C for one of the couple and 2A, 2B and 2C for the other) and performed in the following order: 1A, 2A, 1B, 2B, 1C, 2C. What would happen? Both would receive $100, but the bank account would only be debited a total of $100, instead of $200. Databases use atomic transactions to prevent this inconsistency from occurring and ensure that steps A, B, and C happen together and indivisibly for each withdrawal transaction. Atomic transactions ensure that the two withdrawals are performed in one of two orders: 1A, 1B, 1C, 2A, 2B, 2C or 2A, 2B, 2C, 1A, 1B, 1C. Atomic transactions have the same properties that we saw in the bank ATM example. These transactions are atomic, which means that they are indivisible and all-or-nothing. Atomicity ensures that multiple, related operations occur $800 TRS EXPRESSES ATOMICITY One example of a high-level specification language using this computational model is the term rewriting system (TRS). TRSs offer a convenient way to describe parallel and asynchronous systems and prove an implementation’s correctness with respect to a specification. TRS descriptions, augmented with proper information about the system building blocks, also hold the promise of high-level synthesis. High-level architectural descriptions that are both automatically synthesizable and verifiable would permit architectural exploration at a fraction of the time and cost required by current commercial tools. A TRS is defined as a tuple (S, R, S0), where S is a set of terms, R is a set of rewriting rules, and S0 is a set of initial terms. The state of a system is represented as a TRS term, while the state transitions are represented as TRS rules. The general structure of rewriting rules is: Correct Figure 1 28 Account descriptions of the highest abstraction and simplifies the reasoning around correctness. indivisibly, as though they’re happening in isolation and without having to be concerned about other system activities. And, atomicity ensures that multiple, related operations are all-or-nothing—all of the operations in a transaction are completed or none of them are completed. These properties ensure a consistent state relative to all other transactions in the system. Many high-level specification languages for concurrent systems express concurrent behavior as a collection of rewrite rules, where each rule has a guard (a Boolean predicate on the current state) and an action or set of actions that transform the state of the system. The active rules, where the guards are true, can be applied in parallel, but each rule operates as an atomic transaction—each rule observes and ensures a consistent state relative to all other rules in the system. This atomicity model is popular because it enables concurrent behavioral MARCH 2008 | embedded systems design | www.embedded.com ( ) s1 if p s1 → s2 (1) where s1 and s2 are terms, and p is a predicate. We can use a rule to rewrite a term if the rule’s left-hand-side pattern matches the term or one of its subterms, and the corresponding predicate is true. The new term is generated in accordance with the rule’s right-hand side. If several rules apply, then any one of them can be applied. If no rule applies, the term cannot be rewritten any further. In practice, we often use abstract data types such as arrays and FIFO queues to make the descriptions more readable. With proper abstractions, we can create TRS descriptions in a highly modular fashion. And using a compiler for hardware synthesis from TSRs, such descriptions can be translated into a standard hardware description language like Verilog. By restricting the generated Verilog to be structural, commercial tools can be used to go all the feature way down to gates and layout. The terms’ grammar, when augmented with details such as instruction formats and sizes of various register files, buffers, memories, and so on, precisely specifies the state elements. Each rule is then compiled such that the state is read in the beginning of the clock cycle and updated at the end of the clock cycle. This single-cycle implementation methodology automatically enforces the atomicity constraint of each rule. All the enabled rules fire in parallel unless some modify the same state element. In case of such a conflict, one of the conflicting rules is selected to fire on the basis of some policy. An example of the power that the use of TSR atomicity brings to hardware synthesis is illustrated in Figure 2, in which Euclid’s algorithm for computing the greatest common divisor (GCD) of two numbers is expressed in TSR notation. From this, the Term Rewriting Architectural Compiler generates a Verilog description of the circuit shown in Figure 3. Euclid’s algorithm for greatest common divisor (GCD) using rewrite rules. ATOMICITY AND GENERATING HARDWARE/SOFTWARE How do atomic transactions such as those employed in TRSs contrast with other approaches used in software and hardware, such as with C/SystemC, Verilog, and VHDL? Contrasting these approaches with atomicity highlights just how low-level, manually intensive, and fragile these approaches are. In all of these other approaches, coordinating and managing the access to shared resources, which includes both arbitration and control, must be done explicitly and from scratch by the engineer in every instance. This makes these approaches: Rewrite rules to implement Euclid’s algorithm. • • Tedious, due to the ad hoc, low-level nature of managing concurrency. Error prone, subject to race condi- ( ) ( ) ( ) ( ) R1 GCD a, b → GCD b, a if a > b, b ≠ 0 R2 GCD a, b → GCD a, b − a if a ≤ b, b ≠ 0 Example of rules executing. ( Apply R2 ) Apply R2 ( ) Apply R1 ( ) GCD 6,15 → GCD 6, 9 → GCD 6, 3 → ( ) Apply R2 Apply ( )R ( ) GCD 3, 6 → GCD 3, 3 → GCD 3, 0 Figure 2 • 2 Solution: 3 is the GCD of 6 and 15. tions, interface protocol errors, mistimed data sampling (for hardware), deadlocks, among others. Brittle to changes, requiring the control to be redesigned each time there is a small change in the specification or implementation. Another issue with these approaches www.embedded.com | embedded systems design | MARCH 2008 29 feature The greatest common divisor circuit. The δ wires represent the new state values, while the π wires represent the corresponding rules’ firing condition. π1 + π2 π1 Enabled δ1, x x > – π1 δ2, x π2 π2 Zero? δ1, y δ1, y δ2, x y δ1, x Enabled Figure 3 π1 is that shared resource management is non-modular in nature, extending across module boundaries throughout system designs. Even if you ensure that individual modules operate properly from an atomic operation standpoint, you cannot use them as black boxes as you compose larger systems with them. Atomicity management requires control logic, and control logic is inherently non-modular. As you compose larger and larger systems, threads, events, always blocks and processes do not scale. Atomic transactions, in contrast, dramatically raise the level of abstraction by automatically managing the complex aspects of concurrency: shared resource arbitration and control. And, atomic transactions can be easily composed at a system level, allowing modules to be integrated as black boxes, without having to consider the impact of inter-module interactions on the internal resources of the modules. With atomic transactions, module-level testing can leveraged at the system level, without having to reverify that interface protocols at every interface point are properly being handled and remaining within required boundaries. IMPLICATIONS FOR EMBEDDED As a much higher level of abstraction for concurrency, atomic transactions are becoming available in areas that previously have not benefited from their power. 30 While widely available as a database tool, how are atomic transactions likely to surface for those writing embedded systems software, working with processors, and designing hardware? Programming for multicore and multithreaded processors requires conscious, low-level synchronization of access to shared memory resources. In order to make software development more efficient for these architectures, this burden needs to be removed. The burden for coordinating access to shared resources needs to shift from the engineer to the programming languages, operating systems, compilers, and processors. Expect to see atomic transactions as an additional concurrency tool in software languages, supplementing the roles currently played by lower level mechanisms like semaphores, events, and locks. According to “M’soft: Parallel programming model 10 years off” (Rick Merritt (EE Times, 7/23/07, available at www.em bedded.com/201200461), Microsoft is planning to build atomic transactions into C# and is already building software transactions into Haskell. Burton Smith of Microsoft was quoted in this article, “I think we ultimately will see atomic transactions in most, if not all, languages. That’s a bit of a guess, but I think it’s a good bet.” Also, expect to hear about “transactional memory.” It’s already getting a lot MARCH 2008 | embedded systems design | www.embedded.com of attention as a key mechanism in architecture circles for ensuring atomicity with multicore, multithreaded architectures. A transactional memory mechanism enables a series of shared memory reads and/or writes to occur atomically. If all memory accesses cannot complete, the transaction may be fully aborted and retried later. Transactional memory allows a software programmer to think about each transaction as a single-threaded operation, leaving the details of shared resource management to the underlying software and hardware. While transactional memory solutions have been implemented in software, the performance overhead for maintaining transaction logs argues for hardware support. For this reason, a lot of research is focusing on the right kinds of hardware support to build into processors. Hardware mechanisms in commercial products shouldn’t require a long wait. According to Sun, support for transactional memory is “imminent.” (At ISSCC recently, Sun outlined details of their Rock processor with transactional memory.) For those working directly with processors, writing software and debugging applications, expect to encounter transactional memory and associated language, compiler, run-time, and (possibly) operating-system support. IMPLICATIONS FOR VERIFICATION There are several ways in which atomic transactions are likely to affect verification: first, as a hardware and/or software component, such as transactional memory, that must be verified; second, as an additional tool in the verification toolbox; and, finally, as a device-under-test (DUT) that has been designed with atomic transactions. Verifying atomic-transaction mechanisms: As transactional memory and other mechanisms become more prevalent, more people will be involved in the verification of multicore-, multiprocessor-, multithread-based designs that use atomic transactions. Doing so will require a deep understanding of the atomic transaction mechanisms and their potential failure feature modes. Test scenarios for these types of designs are complex and numerous, as they involve system-level hardware and software with many subtle corner cases. Fortunately, while these mechanisms may be more complex to verify, they dramatically reduce the complexity for software teams that are end-users of the devices in which these mechanisms live. Using atomic transactions as a new verification tool: Although verifying atomic-transaction mechanisms is akin to handling yet another complex piece of IP, its more interesting to explore what atomic transactions can deliver as a verification tool. Managing complex concurrency is an issue for hardware verification engineers as well—and will soon be a much broader one for those verifying software. Atomic transactions can simplify the complexity of concurrency and consequently accelerate verification efforts and reduce bugs in testbenches and models developed by verification teams. When validating concurrent designs, test-case stimulus generation can get complex, involving contortions and a lot of complex control to induce desired conditions. Atomic transactions simplify the specification of the requisite conditions under which a test case should be performed—and simplify the generation of the proper stimulus. Atomic transactions allow each test case to be written succinctly and separately. Other verification activities that can be challenging, especially when concurrency comes into play or cycle accuracy is required, are creating golden reference models, system models, and verification models. Designing these types of models typically takes much longer than desired or required and often involves much more debugging than acceptable. With its much simpler concurrency model, atomic transactions accelerate the development of these types of models and dramatically reduce the bugs. And, the best thing of all, these models and testbenches can be synthesized into efficient RTL for use in emulators and FPGAs. Imagine being able to develop a golden reference model quickly and run it in hardware against a synthesizable testbench at orders of magnitude faster than simulation. DUT designed with atomic transactions: When verification teams are the downstream beneficiaries of designs built using atomic transactions instead of traditional, lower-level concurrency mechanisms, the verification teams will adapt their methods and experience improvements in the verification process thanks to the design’s stronger EMBEDDED STOR AGE SOLUTIONS Reliable File Systems SAFE HCC specializes in storage solutions for embedded systems NAND Flash NOR Flash interface semantics and simpler concurrency model. I’ll explain the methods and improvements in part two of this article, posted online at Embedded.com. ■ George Harper is vice president of marketing at Bluespec and has more than 15 years of experience in the semiconductor industry. He holds a BSEE and MSEE in electrical engineering from Stanford University and an MBA from Harvard University. He can be reached at [email protected]. COMPLETE USB SOLUTIONS USB Stacks USB Device Data Flash TINY uC Flash Data Flash USB Host Serial Fash FAT File Systems FAT THIN Quick Start storage devboards are available for: MSP340, LPC2xxx, STR7xx, XC16x, AT91SAM7, 8051 and more. HDDs Embedded Pipe Windows driver for embedded application control Mass Storage MTP CDC HID Embedded Pipe Bootloader Mass Storage Printer CDC HUB HID Embedded Pipe OTG Supported Targets Include: MMC/SD/SDHC Compact Flash EHCI, OHCI, ISP1161, ISP1362, ISP1561/2, NAND Flash ISP1761, MAX3421e, STR71x, STR91x, MMC/SD/SDHC Compact Flash Data Flash NAND Flash All our systems are sold royalty free with full C source code and our unrivalled suppor t. LPC2148, LPC23xx, LPC24xx, LPC3180, AT91SAM7xx, AT91SAM926x, AT91RM9200, MPC834x, MCF52xxx, MCF53xx, MCF54xx Embedded design, realization and porting services available w w w . h c c – e m b e d d e d . c o m www.embedded.com | embedded systems design | MARCH 2008 31