Embedded Systems Design Europe - April 2008 - (Page 36)

veriﬁcation 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.eetimes.eu/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 36 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-undertest (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 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 veriﬁcation 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 veriﬁcation tool. Managing complex concurrency is an issue for hardware veriﬁcation 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 veriﬁcation efforts and reduce bugs in testbenches and models developed by veriﬁcation 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 speciﬁcation 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 veriﬁcation activities that can be challenging, especially when concurrency comes into play or cycle accuracy is required, are creating golden reference models, system models, and veriﬁcation 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 efﬁcient 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 veriﬁcation teams are the downstream beneﬁciaries of designs built using atomic transactions instead of traditional, lower-level concurrency mechanisms, the veriﬁcation teams will adapt their methods and experience improvements in the veriﬁcation process thanks to the design’s stronger 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 gharper@bluespec. com. APRIL 2008 | embedded systems design europe | www.embedded.com/europe 033-034-035-036.indd 36 8/04/08 12:36:01 http://www.eetimes.eu/201200461 http://Embedded.com http://www.embedded.com/europe

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

Embedded Systems Design Europe - April 2008 Contents Chip Industry Confronts 'Software' Gap Wind River's VxWorks OS Part of the nEUROn UCAV Demonstrator iSuppli Cuts Electronic Equipment Forecast Study Says GigE Vision Not Mature Chip Aids Wireless Health Monitoring Kontron Reports Strong Financial Growth Xilinx Completes Virtex-5 Line-Up French Project Builds Open Platform Home Automation Group Uses Enocean Radio Layer MIPs Adds Multi-Core Option to Portfolio Cover Feature: Next Gen Programmable Chips: Why Can't Hardware Be More Like Software? Improving Productivity & Quality With Domain-Specific Modeling Efficient CRC Calculation With Minimal Memory Footprint Do-It-Yourself Linux Embedded Development Tools Hardware/Software Verification Enters the Atomic Age New Products Advertising Contacts

Embedded Systems Design Europe - April 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.