Archive for 2009

This is a follow-up post to my previous post on effort related to hardware and software design called “Riding the Software Hockey Stick”. I did get a couple of comments, which are related to the the validity of the the data I presented.  Well, sometimes you just have to admit that you were wrong … So what did I do wrong? This was not quite as bad as the spirits I had called in my blog conversation with Ran Avinun from Cadence (for the non-Germans, the reference to “the spirits I called” comes from an old Goethe poem).

I was very excited to try out a new tool I downloaded to try the animation of .gif files. So why not combine my experiment with some blogging? I had participated to questions to some of the surveys we did here at Synopsys, specifically as it relates to the effort spent during projects on hardware and software development. The question we asked was “What percentage of your total project effort is spent on software development (vs. hardware development) during design?”. We asked this question at several events starting at the Synopsys User Group (SNUG) in Santa Clara 2008, all the way through 2008 at the other worldwide SNUG events and then through 2009 at DVCon and two virtual conferences.

Using my new tool I have the animated those results and then claimed a trend towards more software versus hardware. Brian Bailey rightfully pointed out that I should not have put the results from different events in sequence in order to determine a trend. And he is right, this is where I went wrong, even though the animation looks nice and seemed to indicate a trend.

The second set of comments was related to the animation itself, that it was difficult to follow and also difficult on the eyes. So below you find the data in an un-animated fashion. I also followed Jacob Engblom’s recommendation to check on the different communities which actually answered the survey.

My take away from all this is as follows:

• While I was wrong to indicate a trend over time, the importance of software the overall chip related project development effort  remains unquestionably an important issue.
• Results of the survey taken at the Virtual Multicore Conference 2009 skews the data the most, given the very high percentage of software engineers and system architects.
• The communities for the first three data sets and also the final one are pretty closely comparable.
• Going forward I will try to make sure that we ask the same questions on the community definition to make sure that we can compare the communities.

At the end of the day I lost a little bit too eager to try to outline a trend here, but when looking at the data objectively it is very clear that software is very important for project success. The fact that this is true across different communities who answered the surveys makes it even more sticky.

Thank you now for your reference the data I had animated right next to each other:

I am exposed to embedded software and its testing again a lot lately. An article from Jack Ganssle made me think of the old “United Colors of Benetton” commercial (picture from here). Are software and hardware developers perhaps not so different afterall? BTW, before proceeding, if you are not signed up for Jack’s newsletter “The Embedded Muse”, then I’d highly recommend to do it. It’s a great source of information about the embedded world.

In his article on “The Use of Assertions” he refers to a Microsoft paper called “Assessing the Relationship between Software Assertions and Code Quality: An Empirical Investigation”. The paper nicely outlines that the use of assertions increases code quality and gives empirical proof. I include a graphic from page 10 of the paper below. The example nicely shows a high fault density for code that has zero assertion density and higher assertion density for code with low fault density.

So far so good.

The article also compares dynamic and static tools. There is a graph on page 11 which empirically shows that the bug percentages found dynamically via assertions are actually higher that the bug percentages using static analysis tools. Well, at first I was clinching and wondering – wouldn’t it be great if this could be done all statically? There are different embedded software companies out there focusing on static vs. dynamic testing and it reminds a bit of the hardware world where we find bugs using formal and dynamic verification as well. The immediate conclusion could be: Hey, they are not so different after all those hardware and software verification engineers.

However. after a great read of Microsoft’s James Larus, et. al, called “Righting Software” and some of the references from the original Microsoft Paper, it turns out there are are fundamental differences as well. In my mind there is always a difference of verifying “form” vs. verifying “function”. Verifying function means to me to make sure that code is doing what it is supposed to do, “wait until the USB connection is established and then start some other functions”. Verifying form means to me to make sure that the function is expressed the right way and correctly, i.e. all memory allocated used to do a task is indeed freed at the end, all internal and external coding guidelines are met.

It seems to me that dynamic assertions are used in both worlds to make sure function and form is met. I can make sure with an assertion that a specific state is hit – or never hit – as well as indicating that at the of a major process not all memory has been released, or semaphores have been executed in the wrong order, which may result in a risk of locks in a multicore system.

Static verification – at least the ones I encountered – is in the hardware world mostly used to verify function. Certain states have to be hit or are never allowed to become true. Given that there are so many the “state explosion” has always been an issue on the hardware side. From what I can tell the static verification tools in the software world seem to be focused on verification of form mostly. Hence I have not seen any issues around state explosion in the software world.

Some differences, some similarities. Perhaps assertions can be a bridge between HW and SW verification as my colleague Tom Borgstrom (read his Blog “On Verification” here) put it in a discussion recently. Or I may be completely wrong on all this … so I am looking forward to your comments!

Earlier this week I attended an ICCAD co-located session on the future of EDA. Jim Hogan and Paul McLellan led an interesting discussion on what has to change to make a chip development successful in 2012. A lot of the early feedback in the Blogosphere on EDA seems to be right akin to the movie scripts like in Doomsday or the upcoming 2012. Are we at five minutes to twelve on the doomsday clock (the is picture borrowed from here)? I would argue that EDA always has been part of a complex changing landscape and has been able to solve the challenges. Will we again? Sure, I know a lot of people working on it daily!

The slides of the presentation Paul and Jim used showed some interesting data, including a graph on adoption of technologies on page 5. The iPhone and iTouch are the fastest adopted consumer devices ever, beating the iPod itself and the internet. Software is key to that success. Paul also pointed out that semiconductor economics determines a lot of issues in our industry. As a result of cost shifting to software, Paul and Jim articulated the requirement of a software sign-off.

If you have read any of my Blog entries before, then you know that I wholeheartedly agree with the importance of software. I also fully agree with the direction we need to take to enable software development and as early as possible hardware/software integration. The key is timing. I know exactly what my Dad would say in this situation. He would quote the old German saying that “nothing is consumed as hot as it is cooked”. Don’t take me wrong – I do not want to downplay the importance of change. The questions are when, how and where. On “when” – we certainly have been trying for a while to get to the next level of abstraction. With transaction based design we are making progress I am part of teams who are working on the “how” every day in our world of system-level design, virtual platforms for early software development an so on. On “where” it is very clear to me that change is not EDA specific, it happens everywhere in the semiconductor related eco-system.

The adoption curve of page 5 of Jim’s and Paul’s presentation made me choose the title of the Blog. One key differentiator in the development of Apple’s iPhone and the iTouch is “control”. The design of the hardware and the software is controlled by the same company. The situation is different for phones using Windows Mobile, Symbian or Android. Here the OS and hardware are controlled by different vendors. The OS effectively locks in the channel to access the hardware and provides the necessary monetization – providers take a share of every application sold through that channel. The idea is great and if a vendor has control of both he can flexibly allocate the monetization between hardware and software.

System-level design may turn out to be about control and about enabling communication to assert it. One of the beauty of system-level models – of functional algorithms and of architectural platforms running software – is that they allow effective interaction between companies or between groups within companies early on in the design flow. In exchange that communication enables better control of requirements. For example architects can change the hardware to address issues the software brought up. And eventually we may arrive as suggested by the ICCAD discussion at a “software signoff”. Will EDA help get us there as part of a constantly changing ecosystem? Time will tell. We are definitely working on it daily! My boss is knocking … back to work

Some of the recent coverage on our recent high-level synthesis (HLS) announcement is missing an important aspect. Fundamentally the discussion on entry languages is misleading. HLS is not about languages. Sorry, no war here. It is about the amount of information explicitly defined compared the amount of information left open and guided by constraints. While there is no language which does it all, pretty much all languages can express multiple levels of detail.

For example, Bryon Moyer over at TechFocus Media provided an interesting perspective giving the different languages personalities in his article “Living With Ambiguity: The Other HLS”. Bryon makes good points but the different personalities are in my mind really not competing, they are mostly complementing each other but also have some overlap.

Let’s try an analogy. How has your boss been treating you lately? Bosses fall into different categories, as we all know. Some bosses tell you “get this partnership done” and then leave all the details up to you. They may set constraints together with you regarding what the main objectives for the partnership should be, but you have freedom to go about it and implement it as you see fit. At the other end of the spectrum you find bosses who are with you every step of the way. They participate in decisions on detailed tactics. The key difference lies in the amount of freedom to “make things up”, or to “pull things out of thin air” given the basic constraints set by the objectives.

Well, in HLS we face exactly the same situation. In the press pitch we used the picture on the left to explain the relationship between the different levels to express detail. A flaw in the description is that we used languages. We really meant abstraction levels. While the 3 lines of M code just define a function, the 20 lines of C code are much more precise about which types to use. The 200 lines of RTL code are very specific, down to the bit. All the loops are unrolled and specific resource usage is defined.

If you allow a tool to “make more things up”, i.e. create more of your implementation automatically based on constraints, ultimately you will gain key benefits. Not only will it will be simpler and easier to create a working algorithm, you will also work on significantly smaller code and you will likely introduce less bugs into the flow. Everything comes at a price though. You have less actual influence on how loops get unrolled and which specific resources are used etc. You give up that freedom in exchange for the benefits mentioned above.

When it comes to languages, they really do not directly compete too much. Starting with M you define the algorithm and you set constraints on frequency, power and area and then you let the tool do the rest. Similar things can be done in C. We have seen that with  a couple of hundred lines of C code you can easily implement FFTs and IDCTs from C as well with little overhead. However, if you need more specific control, i.e. want to be a more influential “boss to your tool”, then you have to add specific information to your C or SystemC code to specify how to unroll loops and which resources to use. You are essentially doing hardware design in C. From a language perspective you can express a lot of this level of detail and detailed constrains in other languages as well – SystemVerilog for example.

In closing, let’s see which implementation choice my daughter will choose now that I told her to clean up her room. She can put everything way properly, could pile it and hide it in drawers or even just push everything into the “papa-taboo” area under her bunk bed. Let me get over there and be more specific with my constraints …

There is a lot of conversation these days about the impact of Electronic System Virtualization (ESV) on software development. Isn’t it obvious, that it is much better to develop software earlier, before chips are available? Don’t you agree that looking into the guts a multi-core platform for debugging a tough multi-threading problem is much easier using a Virtual Platform, than to use a board with a JTAG connected debugger? Wouldn’t it be nice if the semiconductor and OEM supply chain use this as their standard way of accelerating their time to market? Isn’t this the only problem that ESV addresses?

Actually this only one problem, albeit a big one, that ESV addresses. It deals typically with the next generation silicon and product, which in most companies is called N+1.

What about the products, that are further out, say N+3? Do you have the software applications that will run on those products in your hand today? No, they will be invented in the next few years. Do you even know the processors that you will be using for N+3? Maybe, but there are no models for those yet. What you do know today is the type of applications that you need to run. You may know the performance profile in terms of traffic that they trigger. You probably know exactly, which interconnect and protocol you will be using, because the interconnect, the backbone of your chip, is typically stable for many generations of platforms that you are developing or will be using.

Getting a precise idea, what your interconnect will deliver for the myriad of use cases and applications, that you need to support, is critical for making your design decision for N+3. The right ‘connection’ with the right bandwidth and priority management between your processors and the internal/external memory systems determines, if your N+3 chip or end product is competitive or not.

If you are a development engineer at an OEM or semiconductor company, this is what you care about.

However, it is even more critical that your company cares about a ‘connection’ at a business level. If you are the SmartPhone OEM trying to stay ahead of the pack or beating #1, you need to specify the most advanced silicon platform that will deliver on that goal. If you are a semiconductor company, that has a socket in N+1, you want to maintain that socket for N+3 or push your competitor out of it.

If you are the OEM, how do you communicate to your bidders, what they need to deliver? If you are the semiconductor supplier, how do you credibly pitch, what you can do vs. your competitor? The risks for miscommunication and missing the performance are high. What if you had an ESV solution, that serves as the specification that you can rely on for N+3? Do you want to have a ‘connection’ between you as an OEM and you as a semi based on industry leading interconnect IP, protocols and ESV solutions for architecture design?

Missing the ‘connection’? Talk to ARM and CoWare.

It’s all about the models. We have been using this tag line here at Synopsys for a while now. Now that SystemC TLM-2.0 finds more and more adoption in the industry, the focus is shifting from proprietary simulation by itself to standards based simulation. That shift enables interoperability and with that the models become much more important, just as the productivity tools making life with simulations easier.

Sometimes the challenge with abstract models can be … that they are abstract and that they are models. Per definition they are omitting information. That may be OK for abstract are like the “Model for an Unknown Monument” to the left (Source: EspenDietrichson). It requires some thought when applied to electronic design.

At ARM TechCon3 I will present this Friday a talk on “Increasing Software Development Productivity with ARM and Synopsys Modeling Solutions”. The main theme will be that all models have their limitations and that users have to be thoughtful how to apply them. Specifically, I will talk about the eight main characteristics for choosing models, especially when used for software development in virtual platforms or on FPGA prototypes (which can be considered as yet another “model”, even though they are considerably “more real”):

• Time of Availability: Once the specifications for a specific design are frozen, the time it takes for models to become available directly determines how long software developers will have to wait before starting on the project.
• Execution Speed: Ideally models provide an accurate representation of how fast the real hardware will execute. For software regressions, execution that is faster than real time can be beneficial.
• Accuracy: The type of software being developed determines how accurate the underlying models have to be to represent the actual target hardware, ensuring that issues identified at the hardware/software boundary are not introduced by the development method itself.
• Production Cost: The cost of models is comprised of both the actual cost of production, as well as the overhead cost of bringing up hardware/software designs within it. The production cost determines how easy a development method can be replicated to furnish software development teams.
• Bring-up Cost: Any required activity needed to develop models outside of what is absolute necessary to get to silicon can be considered overhead. Often the intensity of the pressure that software teams face to get access to early representations of the hardware determines whether or not the investment in bring-up cost is considered in order to create positive returns.
• Debug Insight: The ability to analyze the inside of a design, i.e. being able to access signals, registers and the state of the hardware/software design, is a very important model characteristic to enable debug.
• Execution Control: During debug, it is important to stop the models of the target hardware using assertions in the hardware or breakpoints in the software, especially for designs with multiple processors in which all components have to stop in a synchronized fashion.
• System Interfaces: If the target design is an SoC, it is important to be able to connect the models to real-world interfaces. For example, if a USB interface is involved, for verification and software development it is important to connect the development method to real USB protocol stacks. Similarly, for network and wireless air interfaces, connection of the design representation to real world software is important to execute software development.

The talk will be at ARM TechCon3 on Friday, 10/23, at 10:00am in the MCUs & Tools track. I am looking forward to meeting you there to discuss this further.

I will also be available on the exhibition floor on Wednesday and Thursday to present our Virtual Platform solutions and the connections to the ARM Fast Model Enablement program, through which ARM and Synopsys provide a critical mass of models to get closer to the goal of drag and drop assembly of virtual platforms. Enabled through standardization with the SystemC TLM-2.0 APIs, ARM based subsystems containing Fast Models from ARM combined with busses, peripherals and infrastructure components from the DesignWare System-Level Library can be integrated into virtual platforms using the Synopsys Innovator IDE. Together with Synopsys services to enable model customization for peripherals and processors, ARM and Synopsys partner to enable developers to get to virtual platforms with the right combination of models for software development, verification and architecture as early as possible.

We all make these decisions on a daily basis. For me it is about the morning coffee. Do I prepare it at home, get it as early as possible, or do I wait until I am passing the coffee shop on my way to work, a path I have to take anyway.

For model usage we are facing a similar issues. When looking at a standard design flow, it is a fairly straightforward decision to take RTL – something which will be created in a path of a project anyway – and use it to create with fairly predictable overhead a software development environment, may it be an FPGA prototype, an emulator or software based hardware/software co-verification. In contrast, the C models needed for virtual platforms – for example to feed into our Innovator based virtual platforms – are not part of most “normal project flows”, which today still start with written specifications and then lead into RTL.

Today we introduced the Synphony High-Level Synthesis solution, which takes M language input – often used interactively for algorithm analysis – and creates RTL from it. Together with M, Synphony HLS accepts model-based design entry. Examples for model-based design entry here are The Mathworks Simulink and of course our Synopsys System Studio.

When looking at M at first I myself was quite confused, as it is often used interactively for algorithm analysis. However, by itself there is really not much simulation there. However, we used the opportunity of our LTE Whitepaper about next generation wireless systems to query users on which tools they use for algorithm design entry. Interesting enough, as the graph above shows, out of more than 500 respondents, 32% pointed to M, 29% pointed to C based entry  and 22% to model-based design entry, with our Synopsys System Studio fairing very well as number two used tool (32%).

M is really the next level up above C based technologies – and therefore Synphony HLS is really complementing C based synthesis technologies. Looping back to my coffee analogy earlier, one key item I am excited about is the Synphony High-Level Synthesis capability to provide on the way to implementation models which can be used for virtual platforms and verification. In an example we are showing to customers, 3 lines of M translate to 20 lines of C-code and 200 lines of RTL. As a result, creating C models as natural byproduct of this flow, will be yet another source of models for virtual platforms, in this case covering the communications and multimedia application domains.

Well, for those of you familiar with dancing, I am not talking here about the sequence in Rumba – albeit that’s fun too – but instead of being within a hockey stick adoption curve. How do you identify a trend clearly? You ask the same question multiple times and over time you will see the trend. That’s what we did with the following question: “What percentage of your total project effort is spent on software development (vs. hardware development) during design?”. We asked this question since March 2008 – at the Synopsys North American User Group meeting SNUG, then throughout the year during later user group meetings. We then asked again at DVCON 2009 in San Jose and finally at two recent events – the Virtual Multicore Conference and the EETimes Virtual SoC Conference (for which by the way you can still register and watch the archived presentations and our virtual booth).

The result is quite amazing to me and shown in an animated graphic on the left. Essentially, over this 18 month period the answer to this question shifted fundamentally. At SNUG 2008 84% of the users responded with either “0% to 25%” or “26% to 50%”. That means that for 84% the hardware effort was dominant. However, 46% already responded at that time that the software effort is between “26% and 50%”. I was quite happy with that response at the time.

Well, over the last 18 month the answer has shifted quite fundamentally. As the animation shows the numbers for software increased over the year. 15 month later, at the Virtual Multicore Conference, 61% of the respondents reported higher effort on the software side. And most recently, 18 month after we asked that question for the first time, at the EETimes Virtual SoC Conference 54% reported higher effort on the software side. That number is slightly down from the previous peak, but the audience was much more hardware oriented compared to the multicore conference.

So what does it all mean? Are we within the hockey stick transition to software taking over in importance in chip design? Perhaps. This is a good and relevant data point. And the impact on traditional hardware techniques may be even more profound, as I outlined in my Electronic Design column “When One Plus One Has To Be Less Than One”. Software becomes the means for verification, i.e. the software running on processors in the design becomes the actual testbench. The main advantage here is that the testbench can be re-used across different process steps:

• Verification can start using transaction-level models and virtual platforms even before RTL is available
• Once RTL is developed, the same testbenches can be re-used, now verifying the RTL in co-simulations of TLM models and RTL
• When the RTL is mapped to a FPGA prototype, the same testbench can still be re-used – both in pure FPGA hardware and in System Prototypes – hybrids of virtual platforms and FPGA prototypes.
• Even post silicon the same testbenches can be executed to test that that actual silicon is correct.

There are obvious differences in the amount of verifiable detail in each steps. Still, it looks like we have interesting times for verification ahead of us.

Day 2 of the Embedded Systems Conference here in Boston kicked of with a key note by T. J. Rogers, CEO of Cypress Semiconductor, one of the longest tenured CEOs as he started Cypress in 1982. The key note was themed around “solving problems you don’t know existed for customers you have never met”.

It started with a fun connection of wine to systems. Rogers, an avid wine enthusiast, showed papers from which he learned and optimized wine making. What else is more natural than using Cypress products to help with the wine making? In an effort to keep enough sun on his Pinot Noir but to not over heat it at the same time, a couple of videos introduced how Rogers used his company’s product PSOC – the programmable system on chip – to control the temperature system in his wine/backyard “Clos De La Tech”. Temperature sensors are literally inserted into the wine, gauge and wirelessly transmit the temperature and then literally trigger water cooling for the grapes.

Rogers outlined the history and reasoning behind PSOC and also was giving interesting insight into some of the PLD wars. He admitted Cypress’s loss against Lattice due to some of those issues they had not thought about. In the processor their customers simply chose the competitive solution to do “PSOBs”, i.e. programmable systems on board. However, the subsequent improvements positioned them well for some of the consumer needs in 2007 with products they did in 2004. With respect to the “evolution of programmable systems” Rogers clearly argued for PSOC 3 and PSOC 5 being the next steps after the transitions from PLD – CPLD – FPGA – PSOC. According to their business plan, this will let Cypress expand from being “the biggest dwarf in the room” (i.e. being a player only in the $5B 8bit microcontroller market) into the 16 Bit and 32 Bit markets, which they are addressing with 8051 and ARM Cortex M3 based products.

At the end Rogers turned his keynote theme around into “solving problems your boss jerked you around on because he talked to customers you never met”. Oh well.

Roger’s keynote was noticeably better attended than the keynotes on the first day. That made me think about the relevance of this show to our business here at Synopsys. We are here in the ARM Partner Pavillion and I was a track chair for sessions around “Improving Productivity at the HW/SW Interface”. Software becoming more important for our customers in the System on Chip (SoC) domain is a clear trend.

However, the type of embedded systems dealt with here in Boston are not 100% in our core target market. Browsing through the exhibition guide there are 132 companies. They fall (according to their own characterization) into the following categories:

This explains why I am looking here at a lot of hardware boards, lots of 8bit and 16bit microcontrollers … all of which are a tad less interesting for virtual platforms. It will be interesting to see which direction this conference and exhibition will take going forward.

After my post DAC hibernation period – busy times – I am checking in again here from Boston at the Embedded Systems Conference. What do barbeques, headphone and green technology have in common? Well, apparently the “design component” and Robert Brunner, the industrial Designer of such product lines as the Apple II, Macintosh, Newton, and PowerBook. After a short night in “Hotel United” I did arrive on the red eye flight in Boston just in time for the key notes at ESC.

Robert Brunner, founder and creative director of the San Francisco-based design firm Ammunition, was quite inspiring. He talked about design as a complete process, with all disciplined being involved. He gave a couple of examples from companies in which he is involved in. Starting with “Fuego” he showed pictures of the BBQ I will continue to lust after for a while now. Their BBQs are dubbed as the “iPhones of grills” and the design aspect clearly achieved the target of making BBQing a joint experience, with the BBQ in the center.

Brunner then continued with “Beats By Dr. Dre” showing the design aspects of high quality headphones for the target group which thinks that “badly compressed music with bad ear plugs” is the standard. I especially liked the declared Dr. Dre marketing strategy that “a whole lot of people owe him a whole lot of favors”. This approach got a surprising line up of celebrities endorse the headphones, including the new “heartbeats” by Lady Gaga headphones which are doubling as fashionable ear rings.

To make the line up complete with Green Technology Brunner gave two facts worth repeating. The first fact came from Al Gores “Generational Challenge to Repower America”: “Scientists have confirmed that enough solar energy falls on the surface of the earth every 40 minutes to meet 100 percent of the entire world’s energy needs for a full year. Tapping just a small portion of this solar energy could provide all of the electricity America uses.”

The second fact came from the International Energy Agency: Worldwide, consumer electronics represent 15 percent of household power demand, and that is expected to triple during the next 20 years. To satisfy the demand from gadgets will require building the equivalent of 560 coal-fired power plants, or 230 nuclear plants.

After that introduction Brunner talked about “Regen”, which aims to revolutionize personal and home electronics with a new class of design-driven, light-powered products. The products he showed were both beautiful and practical, and of course all powered by light. The five key components of Regen’s “Smart Architecture Platform” are a Power Efficient Architecture, Hybrid Power Techniques using USB when the light goes away, USB compatibility, User Interfaces and Wireless Connectivity.

The design focus of Brunner’s keynote was immediately compensated with a somewhat geeky industry address by Kevin Dallas, GM of the Windows Embedded Division at Microsoft. Titled “Delivering Compelling Devices”, Dallas’ address was well executed and brought several on stage demos, including an industrial one from Siemens, which showed interesting user interfaces allowing to interact with the design and production line using gestures on the touch screen. Dallas announced Windows Embedded CE 6.0 R3, again with nice user interfaces, this time focused on the consumer market.

Before I went off to the show floor to man our booth in the ARM Partner Pavillion, I couldn’t help but noticing that my neighbor all along had used the same gestures introduced by Microsoft on stage on his iPhone while browsing and checking email. Oh well.

Visit us here in Boston and don’t miss the remaining sessions in the track “Improve Productivity at the HW/SW Interface” I chaired:

Wednesday, September 23, 2009

[ESC-304] Lessons Learned from Hardware/Firmware Integration Problems
Gary Stringham
Wednesday, 8:00am — 9:15am

[ESC-322] Coprocessing and Multiprocessing Techniques to Accelerate Software
Skip Hovsmith
Wednesday, 2:00pm — 3:15pm

[ESC-342] Developing Software Prior to Silicon using System Prototyping
Juergen Jaeger
Frank Schirrmeister
Wednesday, 3:30pm — 4:45pm

Thursday, September 24, 2009

[ESC-403] How to Write Reusable Device Drivers
Gary Stringham
Thursday, 8:00am — 9:15am

See you in Boston!