System Design and Verification

Virtualization and Verification With Posedge Software

jasona — Wed, 19 Nov 2008 11:00:00 GMT

Posedge Software is a Cadence Verification Alliance Member with skills in two of my favorite areas: virtualization and embedded software verification. Posedge has worked with ISX as far back as 2006. Besides the fact that they are skilled in verification I must also mention that they are from Minnesota, mostly to prove that my home state is not a complete wasteland and other smart people also live here (even though the temperature was 15 degrees Fahrenheit this morning). I sat down with Henry Von Bank of Posedge to find out more about his interests in embedded software verification and his previous work with QEMU and Open Virtual Platforms.

Hi Henry, what does Posedge Software do?

Posedge Software provides consulting services and tools for both hardware and software verification, in particular using Specman Elite and ISX. We have experience with software development, hardware verification, and other skills needed to put together a complete system verification environment

When did you become interested in virtualization?

Like many people, I've used virtualization to run multiple operating systems on one PC (usually for running Windows on top of Linux). I've also found virtualization very useful for software development, particularly for device drivers and other embedded software. Often the only other option is to debug on the real hardware, which is not ideal.

The other thing that fascinates me with virtualization is that you can stop the execution and poke and prod at the internals of the hardware or operating system. There often isn't another way to do this except by adding lots of instrumentation to the software and using debuggers and debugging hardware. I don't think this aspect of virtualization is being exploited as much as it could be, but it has a lot of potential.

I understand you have worked with QEMU in the past and more recently Open Virtual Platforms, what do you find most interesting about them?

The interesting thing about these two virtualization technologies is that they support a variety of target processors, such as ARM and MIPS, while still maintaining good performance. They also allow a variety of peripherals to be used in the virtual target, including real hardware attached to the PC, and emulated hardware. This can be extremely useful for testing and debugging.

While QEMU has more or less a fixed number of platforms it supports, with OVP you create a custom platform that has any number of processors and peripherals. The APIs for creating models in OVP are also much better defined and easier to use.

Can you tell us a little about the performance possible with Virtual Platforms?

The goal for virtualization is generally to get as close to native speeds as possible for the virtual machine. With the clock frequencies and dedicated virtualization instructions in modern processors, the performance is more than adequate. When a smaller, embedded processor is the target, you can potentially run it faster than the real hardware. When doing system verification, anything that can increase performance and shorten test times is valuable.

What type of embedded processors have you been working with?

In the past I've done embedded systems development with platforms ranging from 8-bit micro-controllers to high performance DSPs, and also with systems running embedded Linux. Lately I've been working mostly with MIPS processors.

Did you find anything interesting about how OVP models are created or the interfaces they provide?

One interesting thing with OVP models is the concept of intercepts. An interception library can be created and loaded into the processor model and can catch specific function calls that are made and either replace the behavior of that function, or perform other checking and monitoring. With this you could potentially collect coverage info, and give visibility into your kernel, without modifying any of the software and without affecting the state of the system.

Tell us about your experience with Incisive Software Extensions (ISX)?

I have worked on several projects using ISX, creating the mini-adapters and other work interfacing tools with Specman. While it certainly takes some effort to get the ISX infrastructure in place, once complete you can treat the software similar to any other component in the verification environment. Another thing I like about ISX is that it works independent of the simulator, and really can be used with any type of software execution environments including things like QEMU and OVP.

What kind of problems do you think can be addressed by the combination of Virtual Platforms and ISX?

Software verification has always lagged behind hardware verification, mostly because of the lower cost of making changes and providing updates, even as software complexity has increased greatly. The other issue with performing software verification is that you often do not have precise control over the platform. For example, when writing a device driver it might be tested simply by plugging in the real hardware. This can leave many corner cases untested.

I think hardware verification techniques such as constrained-random testing and coverage-driven verification can help remedy this. Using Specman with ISX provides a foundation on which software verification environments can be built. Virtualization is necessary to handle the complexity of modern software, as it can be too slow, or otherwise too expensive, to use hardware simulators and emulation/acceleration to execute the software.

Another problem that I think ISX and virtualization would be good at is multi-threaded and multi-processor applications. This is a big issue in the software development world and being able to stop execution and inspect the state of each process and processor from the testbench would be very helpful for testing and debugging.

How can readers contact you to get more information about your work?

They can check out the Posedge Software website at or email me.

Thanks to Henry for sharing some of his insight into virtualization and verification. I found the most interesting topic Henry mentioned to be the "interception functions" in OVP. I started discussing code instrumentation a bit in a previous post, but there is a lot more to cover here. From what I have seen so far the ability to add code to the simulation that is invoked based on the execution of the target software is really cool. Maybe in a future post I can provide more details on this feature of OVP.

Portable Design Names Cadence Incisive Palladium Dynamic Power Analysis its September 2008 Product of the Month

Ran Avinun — Tue, 04 Nov 2008 21:45:00 GMT

In his article in Portable Design, John Donovan wrote:

Palladium Dynamic Power Analysis represents a methodology shift for power budgeting of electronic devices with system-level implications. With a focus on productivity improvement, DPA helps to quickly identify the average and peak power consumption of SoC designs running real software in various operational scenarios. Leveraging Palladium III’s built-in memory and RTL Compiler power estimation engine, Cadence provides the first high-performance, cycle-accurate integrated solution delivering full-system power analysis of designs, including both hardware and software.

In recognition of their achievement, Portable Design names Cadence Incisive Palladium Dynamic Power Analysis its September 2008 Product of the Month.

If you want to read more details, please click here

The Power of Cadence System Power Flow vs. Viewing from the Top

Ran Avinun — Thu, 30 Oct 2008 02:04:00 GMT

I feel that I must respond to the following blog published by Frank Schirrmeister. Virtual prototypes clearly have their value and their place in the SoC design flow (especially as platforms for software development) but they are hardly a substitute for hardware-assisted solutions and you need to find a way to connect them to your implementation and verification flows otherwise what you see may not be what you get. Let me start with some facts:

Both of the tools (Palladium accelerator/emulator and InCyte Chip Estimator) described at the above blog as "products in question" in fact have very fast ramp-up time and are being used in production by many customers. The InCyte Chip estimator tool can be brought up by designers in less than an hour and Palladium systems have shown again and again during the last 7 years their ability to bring-up new designs in less than a week with thousands of successful projects taped-out. The addition of power information into these tools can be extracted easily by adding power information (based on a popular industry format - liberty files) into the analysis.

Let me provide several examples, we have seen recently.

Case A: A start-up company was looking for a new funding. The company had engaged with Cadence and within less than a couple of weeks brought their full SoC design into Palladium, allowing them to demonstrate it into their VCs. If this company had chosen a Virtual Platform solution, they would have been out of business before the full environment was up and running. If this company had wanted to estimate power consumption accurately pre-silicon with SW applications, only a single solution in the market would allow them to do it - Palladium Dynamic Power Analysis. Based on the recent results, one of our customers confirmed 5% accuracy between the dynamic power analysis switching results in Palladium and the real silicon measurement in the lab. By any means, this is what the customers need. Fast and accurate power analysis at early phase of the design.

Case B: A large size semiconductor company was trying to win a socket with their customer. In order to win, they had to prove this customer the architectural performance improvements they had achieved with their new design. This analysis had to be done very early in the design process. They tried to simulate the environment using virtual platform but the results were not accurate enough so their customer asked them to incorporate a cycle-accurate simulator into the environment. However, this environment would not run fast enough. So, they ported the design into a Palladium system and showed the results to the end-customer helping them to win the desired socket. Palladium Dynamic Power Analysis can be easily added and measured with any design. Any new SystemC IP that will be created in this design can be ported to the emulation system within days (and in some cases within hours) using combination of C-to-Silicon high-level synthesis tool and Palladium Compiler.

Case C: Cisco recently evaluated InCyte Chip Estimator results (see article) and confirmed 10% die area accuracy compared to real silicon. According to the information we have collected from 130 designs the power estimation provided by InCyte Chip Estimator is 30% accurate. The input information to the tool can include extraction of data based on dynamic simulation, emulation (or even silicon results) of IPs from previous designs and statistical information.

In his blog, Frank said: "Now the accuracy is much better and real software can run on the RTL given sufficient hardware support, but the ability to make trade-offs is very, very limited. The amount of effort it took to first write the RTL, to then verify it and even bring it up on hardware, altogether is so prohibitively expensive that in most cases fundamental architecture changes are hopeless at this point." Although the number of customers running full SoC with embedded software based on commercial virtual platforms is growing, it will take some time until all legacy IPs will be described in high-level of abstraction and I predict that these platforms will continue to operate in parallel and as a hybrid solution to RTL emulation platforms. As was stated above, big reason our customers use RTL emulation platforms is for accuracy, and while virtual platforms can offer certain performance, eventually the need to accuracy becomes critical and can not be overlooked, even for initial performance and power estimation analysis. Frank seems to forget in his statement above that the average bring-up time of new virtual platforms takes 6-12 months while the average bring-up time of many emulated designs takes days. As any other flow, the power estimation flow is not an exception.

There is no single tool which can solve all your problems. I agree - Virtual platform seems the "dream comes true" solution, allowing users to make performance and architectural trade-offs as they run their applications and software together early in the design cycle however, it does not come for free. Most customers do not have the models, the infrastructure or the people allowing them to build these platforms. Even if they get these models or experts to build the platform (from the EDA vendor or from their own company), it takes long time to do it and if your design cycle is short, you may miss the mark and not get the platform up and running but only after your RTL is ready. Now, even if you build this platform successfully 9-12 months in advance, how do you know that your virtual platform representing your real design? How do you connect it to your verification and implementation environment and realistic power information? Frank seems to overlook these things. Looking at the analogy of the story described at the blog above, using a system-level platform that is not targeting the actual hardware for performance analysis and power trade-offs guarantees that the Chamelon will become a snake and you will get bitten. This is something even Frank's 3 year old smart daughter can understand! You must now create a methodology to correlate your discoveries at the system-level for power analysis with those actual results at the RT level or even at silicon... Who will be doing this effort while you are busy working on your next architecture?

Cadence is taking instead, a more pragmatic approach. Our solution is being used today, effectively to solve these issues with a focus on getting feedback from the "real" silicon. ESL is all about discovery but also about connecting to the reality of what you are doing today.... not just about creation of another model that has to be maintained and synced up manually with your implementation. This connection must be there and should automatically get updated as new IPs are being created. Our System power estimation/exploration flow includes the following steps:

Use InCyte Chip Estimator to run quickly pre-RTL (pre IP selection) static power estimation for your SoC with 30% accuracy, decide upon your low-power techniques and automatically generate CPF file that carries these techniques and can be used as the input power information through the entire design and implementation flow.
Model your newly created IPs in SystemC and quickly map these to RTL (or gates) with C-to-Silicon Compiler.
Run accurate dynamic power estimation at the block-level (with Incisive Enterprise Simulator) and at SoC (with SW) using Palladium emulation.
Get initial SoC (with embedded software) estimated average power results and identify your "interesting" peak power windows using Palladium Dynamic Power Analysis.
Get accurate estimation (+/-5%) of your SoC average and peak power results using real stimulus actual embedded SW with Palladium Dynamic Power Analysis, leveraging RTL Compiler accurate power analysis engine.

These 5 steps can be done in matter of days, instead of weeks or even months, as assembling Virtual prototypes would require. A combination of static power analysis, high-level synthesis for newly created IPs and dynamic power analysis with emulation can provide you good SoC power estimation and exploration flow (including hardware and software) even at the early phase of your design. As always, comments are welcome.

ESC Boston: Day 2

jasona — Wed, 29 Oct 2008 22:21:00 GMT

This morning before heading to ESC it dawned on me that the park across the street from my hotel was the Boston Public Garden. Maybe it was the swans on the hotel logo, but the ironic thing is that the only way I knew about this park was by reading the book Make Way for Ducklings to my kids. I previously reported that 4 weeks ago we had a new baby girl. During the week following the birth, as my wife was recovering, I took over teaching our 5 year old Kindergarten (all our kids are home schooled). I found out that one of the usual Kindergarten tasks is to do something called Five in a Row which involves reading the same book to a child five days in a row. The book I was assigned to read was Make Way for Ducklings (Viking Kestrel Picture Books). My 5 year old was quite excited to hear that I was at the park where the ducklings followed the swan boats and ate peanut shells dropped by the passengers. Below is a picture from my visit to the park on the way to ESC.

My talk was the last session of the day, but even with the late time slot the attendees were interested in the idea of Coverage Driven Verification for Embedded Software. This was my forth talk at ESC, but first one at the Boston conference. You can take a look at the slides and the paper. Overall, I think the attendees were intrigued by the concept. The majority of attendees seemed to test software on a physical target board and were familiar with writing tests, downloading them to the board, running them, and collecting the results back on the host. The presentation could have used some more details on how to make the physical connection between the host machine and a target board via the mailbox and a hardware channel such as USB, Ethernet, JTAG, etc.

The session before mine was related to code instrumentation, a topic that is close to ISX, especially with the introduction of the monitoring features in version 8.2. The talk demonstrated a way to create your own structural coverage tool by using the C preprocessor. I think most attendees were a bit shocked to think about replacing every construct in C with a macro that inserts code to log which statements were executed, but the presenter, Ark Khasin, definitely won some points for creativity. I had seen an article on it previously on embedded.com so I wasn't as surprised as others might have been. Even if the solution is not completely practical it is worth a look. Attempting to parse C code yourself does take effort so the solution to use the C compiler you already have makes some sense. There is also a paper on the MacroExpressions website.

For ISX we have relied on extracting as much information about the embedded software to be verified from debugging information found in object files. I'll talk more about the pros and cons of code instrumentation in a future post, but there is probably no one size fits all solution.

Ideally, there is no need to instrument source code to collect code coverage, functional coverage, do performance profiling, and more. In order to provide these features on uninstrumented code it's necessary to not only use a simulator or vitual machine to run the code but it is also necessary to have some detailed knowlege about the processor that is running the software. Tools that provide a simulation engine and models can do a lot of things with uninstrumented code. For example, with VMware you can debug uninstrumented Linux kernel code running in a virtual machine.

From the start ISX was designed not to rely on the details of simulation tools and models. The main reason is that are so many ways to run software and so many combinations of processors and tools that it's impossible to keep up and users typically don't really want to hear that they can improve verification, but step one is to replace the models they are using. It also makes things like doing verification with the software running on an actual target board a bit of a problem. As a result ISX uses generic C code to provide the verification connection to embedded software. Working at the source level means the solution is generic and can be used with any processor model and C compiler.

Working at the source level is very flexible but also presents some challenges in the instrumentation area. It means some C code must be added or modified to get the benefits of verification, and sometimes engineers don't really like to think about modifying the code for verification purposes. After I get back from ESC I'll cover the details of various approaches to code instrumentation.

It's good to see the Embedded Systems Conference is still going strong. I'm always amazed by the diversity of the types of products produced by the engineers that attend.

Virtualization Taxonomy

jasona — Wed, 29 Oct 2008 00:57:00 GMT

I arrived safe and sound at the Embedded Systems Conference in Boston today. It's been a few years since I have attended ESC, but it all came back to me quickly, and is just as I remember it, a lot of small booths with vendors showing small boards doing something (hopefully something interesting and not something small).

The most interesting talk I attended was Virtualization for Embedded and Real-Time Systems. Virtualization is one of favorite topics to follow as I'm pretty sure it has many applications in both embedded systems and for EDA tools that have yet to be realized. This talk was a 90 minute session jammed with all things related to virtualization by somebody who clearly has spent years understanding and implementing many types of virtualization.

I found a good wikipedia page that is a good summary of some of the material that was covered.

One of the primary applications in embedded systems is to use virtualization to run multiple operating systems on a single CPU. This is not unlike server applications in a data center, but in embedded applications the operating systems are heterogeneous. Often times one of the operating systems is a legacy OS and the other is a general purpose OS like Linux. This enables cost reduction of hardware as processors get faster since multiple boards can be replaced by a single board. Another example that seems to be popular among the embedded virtualization vendors is to run the protocol stack for making phone calls on the mobile phone in one virtual machine and the general purpose OS that handles the display, other peripherals, and all the applications in another virtual machine. This way the user cannot download and run poorly behaved applications that might interfere with the core capability of making phone calls. Trango is another vendor working in this area. The concept sounds very promising to keep the games, e-mail, and web browsing from causing poor call quality.

If you can follow and understand the picture below you have a good start at understanding commonly used virtualization techniques. This is just the first level. For every one of these there are interesting topics such as using virtualization to improve software debugging and to profile software execution.

There are multiple talks on the ESC program about virtualization. It seems to be one of the hot topics in embedded software. This talk definitely helped me understand all of the kinds of virtualization and gave me a better understanding of how many of them work, including the VMware that I use everyday.

I would love to hear about other applications or ideas on how virtualization is being used or could be used.

Is Host-Code Execution History?

jasona — Fri, 17 Oct 2008 07:00:00 GMT

Before getting into the details of today's topic I'm happy to report a brand new baby girl was born on October 1 into the Andrews family of Ham Lake, MN. She is our sixth child, and the forth girl to go along with two boys. Currently, I play a lot of golf with my oldest three kids and with the new baby girl I'm assured the three youngest will form my next foursome after the oldest three grow up and leave home.

My first job in EDA (back when I only had 1 child) was at Simulation Technologies in St. Paul, MN working on a product called Virtual-CPU or just V-CPU for short. The software was developed inside Cisco in San Jose by a consultant named Benny Schnaider for the purpose of early integration of software running with hardware simulations of Cisco routers. Details of V-CPU were first published at the 1996 Design Automation Conference in a paper titled "Software Development in a Hardware Simulation Environment". I have continued to toil in EDA, but Benny has moved on to many other things including working in another of my favorite areas, virtualization, at a company called Qumranet. There is even one line in his CEO profile hinting at this V-CPU work at Cisco.

At the time Cisco used off-the-shelf MIPS processors on boards with custom ASICs to build routers (these were the days before every chip had multiple processors embedded in it). The ASICs were simulated in Verilog-XL (on Sun and HP workstations) and the software was the Cisco operating system, IOS. It was not feasible to obtain any kind of model of the MIPS processors that would run inside Verilog-XL, so Benny implemented a way to run the software on the host machine and use a network socket to connect to the Verilog simulator and drive a MIPS bus functional model. This technique of running software on the host machine at high speeds and only communicating with the simulator when interesting data accesses occurred is called host-code execution.

One of the coolest features of V-CPU was something called "implicit access". Most companies that are using host-code execution today use "explicit access". This means they require all places in the code that access the hardware to call read() and write() functions so every hardware access goes through a common set of functions and then they use #ifdef to change the hardware accesses to call the simulator if they are doing verification with host-code execution. If they are running on the target system, then pointer dereferences are used. The code below shows an example of explicit access. This works just fine if software engineers plan for host-code execution and structure the code correctly to access the hardware from a central location.

If the planning was not that great or if the code base is just large and uses scattered pointers everywhere, there is no way to go into the code and change every hardware access into a function call. This is where implicit access came in. It provided a way to automatically trap pointer dereferences that were reading and writing to hardware locations and convert the load or store instruction into a simulated read or write. For reads it would put the result into the proper host CPU register and the user had no idea that a line of C code would magically turn into a bus transaction on a Verilog BFM. The code below shows implicit access, of course it's nothing but regular C code using pointers, but underneath was some nifty low-level programming involving the assembly language of the host machine. In the V-CPU days Cisco ran the software on Sun workstations so the complexity of the load and store instructions on the Sparc RISC processor was much less than the x86 instruction set which is the most common host CPU today. Implicit access made host-code execution feasible for projects that didn't really plan for it.

I still run into host-code execution at companies today. Over time they have figured out how to plan for it or have created something similar to the clever implicit access feature in V-CPU, but I have to wonder if the days of host-code execution are coming to and end. Chris Tice, who is the General Manager of the Cadence emulation group, tells of how he once told a customer that host-code execution didn't seem that important and they could just do everything with a Palladium emulator. He says it took some time for him to recover because engineers really like the ease-of-use and performance of running software on a host machine. Chris is a sharp guy so I'm sure he understands the benefits now also.

The main reason I'm pondering the end of host-code execution is because of the emergence of new high performance CPU models that execute the instruction set of the embedded processor and run at nearly the speed of the host. Given the hassle of host-code execution I would prefer to cross compile the software and run the target instruction set. Beyond the implicit or explicit access issue, this also eliminates issues with differences in data type sizes, data structure layout, byte order (endianess) and other differences between the host and target processor. New techniques are now available that use code translation to dynamically translate the target instructions into host instructions. These models provide the speed of host-code execution and run the target instruction set.

Recently I have been working with three tools that provide very high performance models of embedded processors. Two commercial ones are the ARM System Generator and Simics from Virtutech. An open source software that I also work with is QEMU. Another that I don't have direct experience with is sponsored by Imperas is OVP. All of these models provide excellent performance for popular embedded processors. Since details of how the proprietary tools work are harder to come by, here is a link to some info on how QEMU works, it's interesting stuff.

Yesterday I ran a test that booted and ran embedded Linux for 30 seconds of simulation in only 15 seconds of wall clock time. The equivalent speed is greater than 1 GHz (and this is on a not very impressive laptop).

Anybody out there doing interesting things with either host-code execution or with fast CPU models?

Running fast is just the tip of the iceberg, there are lots of other interesting topics related to the Virtual System Prototype or Virtual Platform. The parallels to the workstation and server virtualization industry are also very interesting, since I usually run the embedded system Virtual Platform inside a VMware virtual machine, but these are all topics for another day. The virtual model is quickly becoming the logic simulator for software engineers, and holds great promise to improve embedded software development. Unfortunately, it's time for me to follow the #1 rule of parenting, sleep when the baby sleeps.

Early Embedded Systems Conference Coverage

jasona — Mon, 13 Oct 2008 11:36:00 GMT

Today, a friend sent me a link to an article on embedded.com that talks about my upcoming presentation at the Embedded Systems Boston Conference. I love the title about turning hardware and software design upside down. I guess it's true that this is what I have been doing for some time.

The unique thing about it was that was the first time I could remember where an article appeared in a publication or on the web that wasn't really planned. Most of the time there are meetings with editors and efforts to show them interesting things and feed them material to use in filling publications and websites. This one was completely unplanned and just showed up with no effort or intervention from anybody. A refreshing change.

If you are in the Boston area I encourage you to attend the session and all of the other great sessions going on at ESC. I have presented in both San Jose and Chicago, but this is my first time in Boston. I would be happy to actually meet a real person who is reading the blog activity on cadence.com.

System-level design and verification - at the center!

Ran Avinun — Tue, 07 Oct 2008 14:09:00 GMT

This year, Cadence increases its focus on system-level design and verification events. During the latest CDNLive San-Jose that was held in September, the guest keynote - Dr. Jan Rabaey, Distinguished Professor of Electrical Engineering at the University of California, Berkeley, described the challenges and opportunities facing customers and partners in the years ahead.

System-level design was the center of his talk. According to Dr. Rabaey: "The moment for true system-level design is finally here".

In his presentation, Dr. Rabaey quoted Alberto Sangiovanni-Vincentelli, co-founder and chief technology advisor at Cadence by saying: "Recognition of the common requirements for co-design of hardware and software will create new solutions that eventually will lead into productivity gains, lower cost and first-path design success."

Dr Rabaey added: "The semiconductor and the design automation industries focused in the past on "component design". They need to address the system space in a hollistic way by addressing the following challenges:

A. Complexity and emerging behavior of networked systems
B. System-level matrix-driven design and verification
C. System-level reliability

The complexity issue can be solved by:

A. Raising the abstraction-model
B. Enabling a "virtual engineering" design methodology
C. A system-level design science development

"Finally," said Rabaey. "If you ignore system-level design, you're toast."

Many good presentations were delivered by customers in the system-level space at CDNLive San-Jose. If you missed the event, do not worry; Many of these presentations will be published at the community Web site. You also have the opportunity to hear about Cadence system-level solutions during the up-coming events.

ARM Development Conference - Oct 7th through Oct 9th at the Santa Clara Convention Center:

1. Visit Cadence at Booth # 519 & 616
2. Come to hear about a new ARM/CDNS Hardware/Software Co-verification environment on Tuesday, Oct. 7th at 12:30 p.m. at the Santa Clara Convention Center, Connected Community Theater.

Rapid System-Verification Techtorials:

The up-coming system-verification techtorial will provide you info about Cadence system-level solutions with the following highlights:
Transaction-level modeling
Transaction-based acceleration
SystemC simulation
In-circuit emulation
Acceleration of constrained-random coverage-driven verification
HW/SW co-verification
Metric-driven methodology/Verification planning and management
Sign-up for to these techtorials here.

Power Aware Design Now at System Level

Ran Avinun — Mon, 06 Oct 2008 11:34:00 GMT

Several years ago, I have purchased a cell phone with a 2 years contract from one of the major wireless service providers in the US. The battery lifetime between charges of this phone was terrible - 24 hours. The service provider promised me that there will be a firmware upgrade which will improve the battery charge time. 9 months later, I uploaded new firmware which allowed me to double the time between charges. These kind of issues are common within the electronic manufacturers community.

Why is it being discovered so late and by the end-user rather by the designer of the phone?

Why did it take 9 months for the software designers to fix it and provide a new firmware?

A year ago, I had a long discussion about power consumption with an engineer at a major semiconductor company in silicon valley. I have learned that this company is very conservative about power budget since it can not afford to fail. As a result, they were very conservative and had to use higher-cost packages in order to ensure working devices. The same engineer told me that more accurate power estimation will help his company to reduce the margin and lower the cost per device sold.

So, as you make your system power trade-offs, you need to make your assessment and the trade-off between being conservative (i.e. increase price per device) or being aggressive (which could cause you device failures or recalls).

In recent discussions with customers, I have found out that power estimation at the system-level is becoming more and more critical to design engineers.

Cadence has recently introduced two capabilities that help designers to estimate and explore power at the system-level.

First, Cadence® InCyte Chip Estimator now offers low-power planning capabilities, including automatic creation of the Common Power Format. InCyte allows designers to perform accurate pre-RTL power estimation and to explore the impact of various low-power techniques. Within seconds, users can quantify the technical and economic impact of these techniques, at the pre-RTL stage in the design cycle. With a design specification as the primary input, users select parameters such as a target manufacturing process, what IP they are considering using within the device, performance targets and amounts of memory. In addition to estimating parameters such as die size, power consumption and cost, the system also enables side-by-side comparison of low-power techniques including multiple power domains, selective block power down, voltage scaling, clock scaling and more. Analysis can be completed in seconds and provide valuable feedback to assist in architectural what-if analysis, planning and feasibility assessments.

Second, Palladium® Dynamic Power Analysis helps to quickly identify the average and peak power consumption of SoC designs running with real software and real stimulus in various operational scenarios. In addition, Palladium Dynamic Power Analysis helps designers to compare power consumption among different design instances (i.e. finding “hot-spots” - which block/IP relatively consumes more/less power) and analysis of power consumption under specific working conditions. The capability is built on top of a Cadence HW emulation system and software solution that leverages the Cadence RTL Compiler power estimation engine and the SimVision waveform/power browser which is bundled with Palladium Dynamic Power Analysis.

If you want to read more information, read here.

I would also be interested to hear about your system-level power challenges and find out if these capabilities can potentially help you.

The cell world

Ran Avinun — Wed, 24 Sep 2008 11:30:00 GMT

Earlier this Summer, I was lucky enough to attend the CDNLive show in Japan. One of the keynote speakers at the show was Mr. Mitsuo Saito, Chief Fellow at Toshiba Corporation Semiconductor Company. Mr. Saito-san delivered a presentation about the 20 years battle for the fastest application-specific processors and the future direction of the semiconductor industry in his mind - dreaming "Cell" world.

Mr. Saito-san described in his exciting presentation the tremendous efforts have been done in Toshiba by his team to develop an application-specific processor "winner". A "winner" has been defined by Mr. Saito-san as a processor that has the "right" characteristics from the technology side and the link to a successful business plan so the winning processor design can be translated into a winning product.

Mr. Saito-san discussed many processors that have been designed by him and his team at Toshiba started in the mid 80's including the RISC MIPS-based architecture R8000, TX39, "GSP" and many others. Although some of these processor designs were "brilliant" they were all moderately successful in the market. In some cases, as a result of missing the market window, in other cases as a result of lack of connection into the "right" partner in the business side or simply immature market for this type of applications. Mr Saito-san and his team were persistent.

Playstation 1:
After many failures, they continued to think about the next-generation processor and were trying to "break the ice". Finally they introduced the processor that became the core of Playstation 1 which was unexpectedly big success with over hundred million sets manufactured and sold. The original business model intent was to make money from the software license. In reality both Sony and Toshiba made money even from hardware, mainly due to the semiconductor cost reduction over time. The performance of the 3D engine was not very good and the emotion of the characters could not be presented well.

Playstation 2:
The next-generation hardware (targeted for playstation II) was focusing on the graphics. Embedded DRAM technology based graphics was employed. The main processor could not have enough performance and therefore a dedicated graphic processor had to be developed. Toshiba (in collaboration with Sony) developed a new graphic processor (called Emotion Engine) with floating point performance (very important for graphic applications) that was at that time 3X faster compared to the Pentium 2/3 processors. This emotion engine processor had specific superscalar RISC core and special vector units. It displayed 100's of Millions of vectors per second - 3-5X more than Intel and AMD processors that were available at that time. This processor was introduced late to the market and caused delays to the PS2 introduction that later on (around 2003) became very successful.

The lessons learned from this project (which I believe can be used in may projects) as described by Saito-san are:

1. If the development is similar to the previous one, schedule prediction and performance estimation can be accurate however for new concept design (similar to the one here), expect unplanned delays.
2. Keep good relationship and update your partner or customer continuously
3. Hiding the status from your customer is not generally a good idea and recovery is very difficult
4. Too much explanation will cause unnecessary worry to the customer

Playstation 3:
Toshiba started to look at their next generation processor in 1999. They did not have to use the same architecture that was used in playstation 2. The requirements were much beyond game console and were looking into home entertainment center.

The broadband network was perceived to have a big impact for this device. The next generation processor was supposed to address various applications with scalable architecture. The real-time computation was key for gaming and network and the decision was to use a new architecture.

Toshiba, IBM and Sony have agreed to set-up a joint development team for a next generation processor -- the cell processor.

The processor had four building blocks/elements: PowerPC processor, Synergistic processor, memory flow controller and local storage. Playstation 3 was launched successfully in 2006, incorporating the cell processor with key benefits including: media performance and movie quality and became a new hit.

Beyond Playstation 3:
After the introduction of Playstation 3, Toshiba started to look at other applications of the cell processor. Some of the unique benefits have been identified in the area of real-time face tracking, hand gesture user interface.

The cell processor architecture opened the opportunity to provide network transparent model with collaboration of multiple devices. Same program can be applicable to various performance machines while keeping real-time connecting devices as cell phone, computer servers, digital TV and game consoles. As the follow-on to the cell processor, Toshiba has developed a derivative processor called the SpurseEngine with the requirement to support full high-definition digital life.

According to Mr. Saito-san, high-definition demands break-through to overcome the limitations of conventional PCs. It needs 6 times higher bandwidth than standard definition. Conventional PC architecture of CPU and GPU can only decode HD video. Therefore, CPU will not be capable of real time handling HD Video in the near future. Especially, when you would like to use applications such as authoring, transcoding, editing, indexing and searching. The SpusreEngine was designed to solve this bandwidth issue with much better results for these capabilities compared to nVidia GPU and Intel CPU processors.

Therefore, Saito-san claims that the next generation PCs will need 3 processors: CPU, GPU and Stream Processor (i.e. the SpursEngine). Toshiba released in Japan on July 14th its first laptop called Qosmio with the SpurseEngine processor. We will see in the future how this new technology will change the computer world.

Message to the EDA world
Saito-san final messages were:
1. The current focus is on SoC with HW/SW co-design of dedicated H/W and S/W.
2. The future (next decade) is about S/W solution. Future designs are going to be software centric designs - i.e. the
    major focus is moving from hardware to software and systems.
3. The EDA needs to go through a major revolution focusing more on the system-level rather than the IC level.

My take aways:
1. Do not give up. You will likely fail several times before you will be successfully as a designer.
2. There is a bright future to embedded SW and system-level design
3. Future system-design and verification tools can help designers to get their design right and eliminate unexpected
    project delays
4. In the future, we will see more and more application-specific processors therefore there will be more processor
    design teams in the market. These teams will demand ESL tools and early HW/SW design tools.

As always, I am interested in your opinion, especially if you are involved in this space.

Embedded Software Bugging and Debugging

jasona — Wed, 17 Sep 2008 12:02:00 GMT

In one of my previous posts I introduced an interesting book titled Dreaming in Code. One of the great quotes from the book pertains to today's subject, embedded software debugging. If you don't have the book you can look it up on the book excerpt page of the author's website for the book.

If you talk with programmers about this, prepare for whiplash. On the one hand, you may hear that things have never looked brighter: We have better tools, better testing, better languages, and better methods than ever before! On the other hand, you will also hear that we haven’t really made much headway since the dawn of the computer era. In his memoirs, computing pioneer Maurice Wilkes wrote of the moment in 1949 when, hauling punch cards up the stairs to a primitive computer called EDSAC in Cambridge, England, he saw the future: “The realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs.” From Wilkes’s epiphany to the present, despite a host of innovations, programmers have been stuck with the hard slog of debugging. Their work is one percent inspiration, the rest sweat-drenched detective work; their products are never finished or perfect, just varying degrees of “less broken.”

An article I read today from EDN titled "Shedding light on embedded debugging" confirmed that the situation has not changed much. For the last three years about one third of the respondents identified debugging as the number one thing they would like to improve about embedded software design. The article covers a wide range of debugging technologies that are available such as virtual system prototypes, better host tools, on-chip debugging features, and trace buffers. Even with all this available the survey indicates that all of these have not been able to make a dent in the number of engineers identifying debugging as the main thing they would like to improve.

One of the items discussed in the article is that many embedded systems don't lend themselves to debugging since they contain hardware like sensors and actuators that are hard to model and make traditional breakpoint based debugging difficult. I don't recall who told me this info, but about 12 years ago Cygnus (long since acquired by Red Hat) was promoting something in gdb called tracepoints because some engineers had to debug code that was controlling an elevator. Setting a breakpoint in the software as the elevator was on the way up wasn't a good idea as it may cause the elevator to blow out through the top of the building. I don't know if the feature is still in use, but it's still in gdb, just type "help tracepoints" at the gdb prompt.

Unfortunately, I don't have the solution to all the world's debugging problems, but I do have a very small feature that may be of interest to some of you. The feature is part of ISX and is called Embedded Software Trace. It's a plugin for SimVision that helps figure out what embedded software is doing during verification. Like the elevator problem, many engineers doing SoC verification have to deal with software and find that interactive debugging is not always practical in a batch and farm environment. Embedded Software Trace links the hardware debugging environment in SimVision with what is happing in the software running on a model of the CPU in the simulation.

The user can move a cursor as normal on the SimVision waveform (or any other SimVision window) and the Source Browser will display the location of the executing software. The Embedded Software Trace toolbar on the Source Browser has some nifty features like next and step (forward and backward) and search for addresses, functions, and combinations of source file and line number. This makes it very easy to find out what is happening in the software at the same time you are debugging the hardware. Below is a screen shot of a Source Browser with the Embedded Software Trace toolbar. The screen shot is also a sneak preview of SimVision 8.2 as regular SimVision users will notice the completely new look and feel for 8.2 that will be released in Q4.

Embedded Software Trace is just another SimVision window type, and you can find it by doing Windows -> New -> Embedded Software Trace or type "window new eswtrace" at the SimVision> prompt. Of course, you need to have Specman installed since ISX is delivered as part of Specman.

One of the great benefits of blogging is the ability to get information about these nifty features directly into the hands of people that need them. When I was working in small companies it was easy to promote such things to users, but in a company the size of Cadence this is a small feature of ISX, and ISX is part of an ESL package, and the ESL package works with the Incisive Simulator, and the Incisive Simulator is actually something users can buy. As the R&D project leader for ISX, blogging is truly the best way to communicate things like Embedded Software Trace to users.

I hope you like it and feel free to send feedback and ideas on how to improve things.

CDNLive SJ - system design and verification - don't miss it

Ran Avinun — Tue, 09 Sep 2008 08:25:00 GMT

If you are a system validation/verification engineer, an architect, a power engineer or an embedded SW engineer, you should stop-by and visit us at CDNLive. See below some specific information on what you will be able to see in this domain: Hope to see you there.

- Ran

Day 1 - Monday - was very exciting with fully packed agenda including a full day of system design and verification techtorial with demos, customers and partners presentations. Thank you for those who attended and presented. Please share what you learned with the ones who did not have chance to be there and if you like us to improve our program for next show, write your comments below.

Day 2 - Tuesday (today)

11am - low-power panel at Salon V on the second floor

3:55pm - Track 1 Session 1FV5 – Using ISX to build a constrained random test environment from directed C-
based tests by NXP.

4:45pm - Track 1 Session 1FV6 – An HDTV SoC Development Team’s first Experience with HW/SW Co-Verification
by Genesis Semiconductor

5:45pm - The recent (July 14th) announced C-to-Silicon Compiler demo at the technology night

6:15pm - Xtreme (with hot-swap) demo at the technology night

7:30pm - The recent (Sep 8th) announced Palladium Dynamic Power Analysis demo at the technology night

8pm - ARM-based HW/SW co-verification demo with a real design at the technology night

Day 3 - Wednesday

        10:30am - Track 2 Session 2FV7 – Maximizing the ROI of Palladium of Palladium HW to validate massively threaded
                        CMT processor - by Sun Microsystems

        11:20 - Track 2 - Transaction-based Acceleration

4:30pm - Cadence system design and verification overview and roadmap - main stage - 1R11

Day 4 - Thursday

10am - Track 1 Session 1FV12 – System-level verification of hard disk controller using Specman and ISX

The Road to Better Software Verification

jasona — Thu, 28 Aug 2008 12:39:00 GMT

It seems the debate over the benefits of better software verification is still alive and well. I just read a blog post by Frank Schirrmeister on Software Developer Attitude and the topic of hardware vs. software methodology. Part of the post brings up the argument that the cost of failure for hardware is very clear. The deadlines are fixed by tape out, and if the device doesn't work it means major schedule slip, lost revenue, etc.

The result of this high risk is that engineers take great care to avoid such negative consequences. The post reminds us that software is "soft" and can always be fixed by downloading patches, updating to the latest version, or better yet the system automatically downloads the new updates so it is always up to date.

Many of the software engineers I talk to understand that updating software is not so easy. I'm of the opinion that treating software more like hardware would be of great benefit, although I readily admit I don't always do it myself. I also think hardware verification is probably not as rigorous as we maintain and that the gap between hardware and software quality is really not that big. Hardware verification engineers tell me they just run out of time and cannot verify as much as they would like to.

When I was a hardware designer working in a server company we were designing systems using Intel processors. It was at the time when the Pentium took over from the i486. Although my memory is not that good I do recall getting a book of errata from Intel with each revision of the chip and often changing to the latest sample chips as we developed the processor boards. The book usually contained a list of various functional issues such as don't run this sequence of instructions, don't turn on this mode, and of course make sure to have a big heat sink and plenty of fans. Obviously this is very old data, but I was able to find an article about the machine from 1996. I expect somebody out there can tell similar stories about early silicon and actually using approaches that allow for multiple revisions of a chip.

The software world is not that much different. Coding probably takes about 20% of the overall time and testing takes anywhere between 40% and 80% depending on the level of quality required for the application (also from the The Mythical Man Month by Brooks, see link below).

One of the key aspects of software is that the longer it takes to find a bug the more it costs to fix. Currently, I write software at Cadence that goes into Specman. I can tell you that if I find a problem when I'm first developing a feature or during the "development window" I can fix it very easily just by changing the code.

I don't have to tell anyone, enter anything in the bug tracking system, or fill out any forms of any kind. If I find a problem in the same code after the release reaches beta, I need to enter it in the bug tracking system, prepare a new clearcase view with the fix, tell the release manager that I have a new fix to make, discuss why it's very much needed, is low risk and won't disrupt the release by breaking a bunch of other stuff, rerun all 80,000 tests, schedule a day to merge my fix, and do it when I get the go ahead to make the change.

This is a much bigger overhead compared to the first case when I just made the change by myself and was done. If an issue is found by a customer after the product ships the process is similar except there is some additional overhead to communicate with the user and maybe the customer support people about the issue and the solution. I can also tell you that the time from the initial code freeze until the product reaches downloads.cadence.com could be in the 4 to 8 week range, maybe not that much different from the time required to get first samples of a chip.

Sure, there is still some flexibility in case of a major issue may not be there for a chip, but you can see life is not as easy as just finding a bug and fixing it and telling somebody to download the fix.

Also remember, my story is EDA software that runs on an ordinary workstation. Embedded systems usually have more constraints on changes to software. For example, to change firmware in a disk drive may require an entire certification sequence to be run in a lab with a rack of hundreds of drives.

Such certification may take a couple of weeks to complete the required number of usage hours to declare the firmware certified for customer usage. My experience is that any serious software project, especially when it also involves custom hardware is not as easy as "just download service pack 2".

I would be willing to bet that the number of man hours that went into testing service pack 2 was just as much as testing the original release. In each subsequent update release the improvements to the software shrink and the testing time remains constant.

The key to improving software verification is to be able to put a metric or value on the result of the added verification, especially when it is added early in the process. Most software engineers have good intentions to test early and test often, but in reality nobody is really measuring much except everybody wants to know if the software engineer can get the features done before the code freeze. In this environment, it's difficult to decide to introduce extra testing that takes more time when the software might just work without it.

The conclusion seems to link back to my previous post on the need to have dedicated engineers assigned to verification, more metrics on the costs of fixing bugs at various stages in the life cycle, and better ways to eliminate bugs as early as possible. Better scheduling tools based on actual past activity may also help by avoiding the usual rush just before code freeze.

There are people in Cadence working on these issues for our own software, and I believe there are many opportunities to develop products that will help embedded software engineers by providing increased automation to start down the road to better software verification. Happy coding and may all your bugs be found quickly and painlessly.

ESL: The state of the industry and what’s next?

Ran Avinun — Mon, 25 Aug 2008 09:05:00 GMT

While ESL continues to remain in its infancy, there are signs within the industry pointing towards eventual mainstream usage. With the rapid migration towards advanced process nodes (high capacity), increased hardware and software complexity, and the pressure to reduce the number of ASIC/ASSP designs (including the need to use the same IP or in some cases the same device for multiple applications) – it is no wonder ESL is moving faster towards reality.

If you would like to read more about the current state of ESL and where the current trajectory is going to take us - take a look at this article.

I’m interested to hear about your point of view and comments on the article.

Ran

Embedded Systems Conference Boston 2008

jasona — Thu, 21 Aug 2008 17:26:00 GMT

Friday is that last day to get the Early Bird price for the Embedded Systems Conference scheduled for October 28-30 at the Hynes Convention Center in Boston. There are a lot of great sessions on embedded software development including a track on Debugging, Verification, and Test that will be anchored by my presentation on CDV for embedded software.

Hope to see you there!

[ESC-463] Coverage Driven Verification for Embedded Software
Speaker: Jason Andrews (Cadence Design Systems)
Date/Time: Wednesday (October 29, 2008) 4:15pm — 5:45pm
Location (room): 204
Submission Proposal History: New
Formats: 90-Minute Class

Key Takeaways
Attendees will discover how constrained random test generation, checking, and functional coverage provide new confidence as well as expose bugs that are not commonly found using traditional directed testing approaches.
Audience level: Intermediate

Prerequisites
Attendees should be familiar with C programming, methods use to test C code, as well as common test planning and execution methodologies.

Presentation Abstract
This class uses actual examples of embedded software to describe and discuss the verification technique of coverage driven verification (CDV). The process of planning, regression management, test creation, constrained random generation, checking, and functional coverage for software will be described using examples of embedded software. Topics such as how to define metrics to demonstrate software quality and how to measure such metrics are included. CDV is also compared to other traditional testing techniques.
Track: Debugging, Verification & Test