Embedded Systems Design - March 2008 - (Page 30)

0308esd.p27to31 2/13/08 7:54 PM Page 30 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 δ1, x Enabled > – π1 x δ2, x π2 Zero? δ1, y π2 δ1, y y Enabled δ2, x δ1, x 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 beneﬁted 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 efﬁcient 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 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 veriﬁcation: ﬁrst, as a hardware and/or software component, such as transactional memory, that must be veriﬁed; second, as an additional tool in the veriﬁcation toolbox; and, ﬁnally, 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 veriﬁcation 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 MARCH 2008 | embedded systems design | www.embedded.com http://www.embedded.com/201200461 http://www.embedded.com/201200461 http://www.embedded.com

Table of Contents Feed for the Digital Edition of Embedded Systems Design - March 2008

Embedded Systems Design - March 2008 Contents #Include Programming Pointers Designing DSP-based Motor Control Using Fuzzy Logic Hardware/Software Verification Enters the Atomic Age Efficient CRC Calculation with Minimal Memory Footprint Programming Your Own Microcontroller Advertising Index Break Points Marketplace

Embedded Systems Design - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.