By Frank Schirrmeister
January is prediction month! After writing my 10 year Look-Back on Technology last week, I attended an IDC briefing called “Riding the Momentum: IDC Software Predictions 2013.” IDC is looking at the IT world from four angles that they call four pillars: Cloud, Big Data/Analytics, Social Business and Mobility.

In the opening presentation—called “In a Diverse World of Software, Where is the Growth?”—the term “Consumerization of IT” came up. I had heard that term quite a bit before. As matter of fact, a talk by Joe Costello on that exact topic pushed me over the edge in 1997 to pack my bags, move to the United States and to join Cadence. But the same slide also showed the term, “ITization of Consumers.” That was new to me.

The graph illustrated how enterprise cloud computing enables the access, sharing and integration of content across devices and teams and is blended with consumer mobility, which allows creation of many types of content on many devices. Similarly, the consumer-driven social web that generates real-time and continuous collaboration blends with big data and analytics that allow monitoring the social web, aggregation and the delivery of analytic applications for enterprises and consumers.

When looking at that blended picture, I realized that BYOD does not only mean “Bring Your Own Device” anymore. It also means to “Bring Your Own Data.” And it is a good example how true system design—the system, semiconductor and its associated software—impacts design needs. Applications and their needs drive both the system and the system on chip needs! In this scenario both enterprise and consumer data reside in several locations. They need to be synchronized and accessed from various locations. Tools are working both locally on the mobile systems we carry as well as in the cloud where a lot of the data resides.

Incidentally, that same week I had switched on iCloud for synchronizing my contacts, calendar and some key photos, as well as iTunes Match to enable synchronization for my library of songs. The impact on my home network was severe, and exactly as the picture above shows, it let me experience the blending of my consumer needs with my professional needs, between Apple, Cadence, my home and my phone. While the volume of my calendar and contacts is relatively small, my audio collection has grown to 23,334 songs totaling 124 GB. It turns out that iTunes Match is smart and only uploads songs it does not already know —but still, there is a lot of synchronization going on. iTunes Match does not support video, which would be at least a 10x multiple of my audio bandwidth and storage requirements. Now imagine how this would extrapolate for a chip design …

Going back to my 10 year Look-Back on Technology, in which I concluded that a surprising number of predictions actually came true, the January issue of IEEE Spectrum from 2003 had a section on networking and telecom. The main two items, with admitted 20-20 perfect hindsight, are cloud storage and the sheer need for bandwidth. A couple of articles stand out:

In “What’s wrong with Telecom,” Peter A. Bernstein describes the dilemma telecom was in back in 2003. The “Telebomb” as he called it had five key ingredients—Greed, Corporate Crime, Misguided Regulation, Too Much Debt and A Broken Business Model. He concludes the article with a section that there is hope, but correctly points out an issue we are still dealing with 10 years later: “Fixing the business model is more problematic. It will get fixed, to be sure, because in a world that is ever more network-centric, what the network does and delivers will always be valuable. But figuring out exactly where that value lies is still a challenge.” The value chain in networking has been completely changed. I am well aware that with synchronizing my 124 GB audio collection combined with my Netflix streaming and my daughter’s “My Little Pony” downloads, I am now very easily approaching the 500GB limit that my ISP imposed before my bandwidth is getting throttled or I have to become a “business user.”

In “What’s Right with Telecom,” Steven M. Cherry predicted that “Reliable high-speed mobile Internet access will be a foundation for products and services we can barely imagine. Only when the networks are built will the lightning bolt of invention strike clever engineers and entrepreneurs. But we already know that our increasingly mobile lifestyles will make cell phones and PDAs even more important than they are today.” As my iCloud/iTunes Match example shows, there have been enough “lightning bolts of invention” to simply burst available bandwidth. My eight-year old daughter at this point expects instant media access in a way that she asks “whether the episode of My Little Pony has been downloaded yet” before she actually considers watching it.

So what does all this mean for system-level design? Well, there are two perspectives here—enablement and use.

On the enablement side, the need for networking, connectedness, and collaboration drives a lot of the software and hardware developments our tools are used for. It is a key driver for emulation and acceleration and our virtual platforms are connected virtually to virtual networks via Ethernet.

On the use side, using cloud- and networking-based techniques for development of chips and systems, the security and synchronization of data will be a key issue. Extrapolating from my iCloud and iTunes Match synchronization networking issues, keeping the database of a chip-design project synchronized with a cloud based copy seems to be a very challenging undertaking, not even considering the security and IP concerns. But then again, with more networking bandwidth enabled by semiconductor technology and its associated software ahead, even that will be in the cards.

More fun for us is ahead in EDA!

—Frank Schirrmeister is group director for product marketing of the System Development Suite at Cadence.

By Frank Schirrmeister
This my last post in this Blog for this year and it is time to look back at the year and try to see what’s next. How fast time flies became clear in a funny way to me this morning when listening to the “Tagesschau” while showering – the 8pm news I grew up with back in Germany – courtesy of modern video Blog technology. Apparently the parking fines in inner cities have to be increased by 5 Euros. My fellow countrymen had not increased them since the 1990s and it now has simply become cheaper to pay the ticket fine than to pay the actual parking fee. Oops.

Abstraction versus Detail in EDA

Some things change, others don’t. In EDA, while enabling the latest semiconductor design, we have been constantly balancing abstraction and detail as the graph in this blog shows. The way to deal with more complexity is to use more abstraction – which the industry has done successfully in various ways to raise the design entry level for mainstream design from transistors to gates to RTL. On the implementation side for design at deep-submicron levels, process technology is forcing us to deal with more and more detail than previously. An illustration of how little the actual fundamental drivers have changed is the fact that I took this graph straight from a presentation I did 10 years ago in 2002 at the Workshop on Electronic Design Processes in Monterey. The presentation was called “IP Authoring and Integration for HW/SW Co-Design and Reuse – Lessons Learned” (slides, paper) and I have to give credit for this illustration and the slide to Paul McLellan – now with SemiWiki – whom I had worked with at Cadence and who had shown a similar graph around 2000.

So where are we heading in chip design now in 2012? If one combines market estimates then we are dealing with much more complex designs, but a flat or only slightly growing number of them. Advanced Systems on Chips over the next couple of years will soon have more than 110 IP blocks to be integrated, will involve more than 70% re-use and more than 60% of design effort likely will be in software. They will contain multiple processing cores, forcing  software to be distributed across cores. Low power issues are becoming so important that they have to be addressed at the architectural level too. Application specific issues will drive specific design flows, and designers have to take into account large analog mixed signal content. Overlaid over all these technical complexities, we are seeing changing team dynamics on what tasks teams are performing – as in design vs. verification for example, combined with rapidly changing industry dynamics in the constant changes between aggregation and disaggregation, making it interesting to observe who actually designs chips – system or semiconductor houses.

Now looking back in the context of all that at the year about to end, two key trends stick out from my perspective for verification:

First, the need for more and more verification to make sure that the actual chips can be taped out requires more and more verification cycles to be executed before confidence is high enough that a tapeout can happen. It is not just the hardware but also the software executing on the hardware processors. This is one important driver to revert to hardware assisted verification – acceleration, emulation and FPGA based prototyping. It has been a hot area in the industry this year with some re-alignment, new products and acquisitions.

Second, pure force by itself is not sufficient to deal with complexity — verification also needs to become smarter. This is what is driving the combination of the different verification engines. We have seen in 2012 more combinations of transaction-level models and virtual platforms with RTL in simulation, acceleration, emulation and FPGA based prototyping, as well as smarter connections between RTL simulation and hardware assisted verification. This trend is only likely to become stronger in 2013.

Looking at the system-level, in light of balancing detail and abstraction, the elevator has stopped so to speak, and is even moving down towards more detail. While the industry has always attempted to enable making architectural decisions for users as early as possible, that has always had the issue that the amount of detail to base the decisions on had been limited early in the design flow. The simple reason is that models are required for early decisions and the effort to create the models has to be balanced against the gravity of the decisions they enable. Especially in light of complex interconnect that has hundred of parameters, model creation has become so complex that the actual architectural decisions have been pushed downstream using cycle accurate models at the RTL level. More and more customers I meet find it too risky to make decisions based on abstracted models and instead generate the RTL, execute it and make their decisions based on the results they get.

This situation creates some interesting perspectives for 2013 and going forward. For one, automation in the creation of the assembled RTL will become even more important, as will automation in making the associated software fit, i.e. updated drivers etc. This also directly impacts the two verification trends I mentioned above – getting to more cycles faster to make decisions will still be important in 2013, and so will be the need to combine the different engines in smarter ways.

Happy Holidays and a successful 2013!

—Frank Schirrmeister is group director for product marketing of the System Development Suite at Cadence.

By Frank Schirrmeister
In my last post on “The Complexity of System Development and Verification” I outlined five main use models for verification at four levels of scope, enabled by seven execution engines. So how exactly do users choose between the different execution engines to run hardware and software together before the actual chip is available? It is far from trivial. The seven engines I identified are Software Development Kits, Virtual Prototypes, RTL Simulation, Acceleration, Emulation, FPGA Based Prototypes, and Development Kits that are based on the actual silicon samples once they are back from fabrication.

Two engines are used in pretty much every design flow I have seen – RTL Simulation and Development Kits. The choice whether or not to provide Software Development Kits (SDKs) and Virtual Platforms depends on how many independent software end users are expected to provide software. They are not part of the mainstream design flow to develop the actual hardware yet, but in an apps driven world at least SDKs have become a necessity for consumer devices like the Apple iPhone, the BlackBerry devices and others.

Which engines to use to execute RTL – RTL Simulation, Acceleration, Emulation or FPGA Based Prototyping – remains a matter of choice. Depending on project complexity, there may be a project phase of 6 to 12 months in which these engines are applicable before silicon. They can also be used  post-silicon to reproduce defects found during silicon bring-up. There is really no question on RTL Simulation; it is part of every mainstream design flow.

For acceleration let’s look at a couple of customer examples that were recently reported. At CDNLive Silicon Valley PMC Sierra reported on “Functional Verification of Next Generation IC’s with Next Generation Tools”. Their application is in high-speed, complex, multi-protocol routing with 100+ Million Gate SoC design. Their architecture contains 10 sub-systems, some of which could be classified as stand-alone chips! They run on a 18-month schedule. With simulation only it can take hours to send a single frame, and running the full regression suite can take more than a week. As a result interactive debug is difficult — it can take a long time to reproduce bugs and the team has to create simpler simulations to get reasonable simulation times.

Bottom line, longer simulation times mean a greater time lag between the release of RTL and subsequent verification before the next RTL release, which makes it challenging to complete a comprehensive verification plan while meeting time-to-market demands.  To address the speed challenges, PMC chose the Palladium XP Verification Computing Platform for both acceleration and emulation. In the case of acceleration they combined complex test benches using Specman with Palladium XP. They were able to execute simulations that would have taken one hour in 80 seconds, which meant effectively a 40x speedup with a 26 M gate DUT. PMC considers it straight-forward to migrate from simulation to simulation acceleration in their environment – major re-architecting of the test bench is not required and as a result simulation and simulation acceleration can co-exist as part of their overall verification strategy.

For PMC the main motivation to choose acceleration has been execution speed, and Cambridge Silicon Radio (CSR) reported on the same motivation during the recent CDNLive Israel earlier this year. Their presentation was called “NC compatible acceleration with Palladium XP” and it summarized their choice for HW assisted verification based on the need for a platform for SW development, accelerating RTL logic HW tests, short bring-up of new designs and debug capabilities. For CSR using an environment which runs at faster speed but really looks and feels like simulation was key. Using Acceleration they achieved in average about 500x speed improvement over RTL simulation (between 314x and 962x measured over nine test cases).

Speed is the main motivator for adding acceleration to RTL simulation.

The last remaining choice is between emulation and FPGA based prototyping. Let’s again look at users. A variety of users point out in John Cooley’s Deepchip.com in ESNUG 486 #1 the trade-offs they are going through in choosing hardware-assisted verification. It boils down to five considerations:

• “speed” – how fast does the engine execute
• “turn-times” – how long does it take to get up and running after new RTL is available
• “visibility” – how well can one debug the hardware and software running on it
• “connectivity to the real world” – how easy can a user connect to the interfaces the actual chip under development connects to
  • “multi-user” access – how easy can the system be made available to users, ideally remotely

This is also confirmed by Samsung and Altair as recently presented at CDNLive Israel (Slides 26 to 28 and 31 to 33). Their assessment was actually a little more intricate as outlined in the following table:

Example Selection Criteria for HW Assisted Verification

Altair is using a Verilog simulator combined with an Instruction Set Simulator (ISS) to create a debug environment for the SW engineers. They also build custom FPGA boards, for which they can be customize more components and lower bill of materials. As downside that requires a dedicated set of resources and long bring-up time for each design. In using rapid FPGA-based prototyping they use standard HW boards with software and an ASIC-like flow. For emulation they use Cadence Palladium and trade the lower speed than FPGA-based prototyping against very fast compile times, very good hardware debug capabilities and scalable capacity.

Samsung Israel needs to verify 5-32 Million Gate Image Signal Processing designs with infinite configurations and images. They use the Incisive Unified Simulator for scenario based verification at the block and integration level, which enables complex checkers for quick root-cause debugging. FPGA boards require design partitioning and longer ramp-up times, as well as longer turn-around times once new RTL is available, and longer debug times. Samsung is using Palladium emulation in synthesizable test bench and in circuit emulation mode, which can be used at early verification stages with end to end checkers.

As summarized in the table above, Altair and Samsung confirm the main issues described in in ESNUG 486 #1 influencing the choice for hardware assisted verification – speed, turn-times, visibility and multi-user access.

Where does all this leave us with respect to system design and verification? Choosing the right engine can be difficult at times. On the flip side we product managers in EDA need to make sure to define the requirements for these engines appropriately. There is always temptation to define a specific engine too broadly, which bears the risk to arrive at what we called where I grew up the “Eierlegende Wollmichsau” – the pig we can get our bacon from, that has wool we can shave off for clothing,  that can produce milk and lays eggs as shown below (I found the picture here). It would be nice, but does not exist — just like in system design and verification, where no single engine rules and all engines are needed in the flow and are best used in combination to make best use of their individual advantages.

Die Eierlegende Wollmilchsau

—Frank Schirrmeister is group director for product marketing of the System Development Suite at Cadence.

By Frank Schirrmeister
The electronics industry is undergoing a fast transition towards new paradigms for system development and verification as traditional development methods reach their breaking points. Developing a system development and verification environment can become a costly undertaking, and can involve many direct and sometimes even more hidden cost. To understand the cost aspects, one needs first to understand the underlying market drivers as well the complexity of a system development verification environment.

While I have started touching on some of the cost of ownership aspects around bring-up time in a recent post, it turns out that by the time I am summarizing the complexity I will run out of Blog space for today, so this is really part 1 of a set of Blogs discussing the real cost of verification. Here we go:

With semiconductor design at its core, seven major trends are driving the development and verification requirements.

• Further miniaturization towards smaller technology nodes leads to constant growth in design complexity. There is simply more and more content to verify.
• While the complex designs are increasing in numbers, their growing development cost and decrease in overall design starts leads to increased pressure to reach proper returns on investment and to require first pass success to ensure proper monetization.
• The need for flexibility drives on-chip programmability with a strong trend towards multicore architectures combined with a rapid increase of embedded software content.
• IP reuse in both software and hardware is exceeding 60% of the semiconductor content and is growing fast.
• Low power requirements drive design teams to provide more functionality within constantly shrinking power envelopes.
• An increase in the analog/mixed signal portion of semiconductor and system designs drives the need for mixed level simulation.
• Application specificity drives the need towards basic hardware/software platforms for application domains like wireless, networking and automotive

In order to develop and verify the resulting complex hardware/software systems that development teams are facing today, the hardware has to be executed – prototyped – to allow verification and software execution. Most customers I talk to have at this point decided that tape out without prototyping using hardware assisted verification is too risky. There are, however, several different types of prototypes that allow hardware/software integration and debugging. In addition, different users within a design team have potentially different needs for prototype capabilities. The choice of the right prototyping technique is driven by which scope they cover best and which use model thy support.

The four different scopes for verification are hardware blocks, hardware/software sub-systems, systems on chips (SoCs) containing hardware and software and finally SoCs and software running on it within the system environment they reside in.

The five main verification use models are:

• Hardware verification – requiring deep insight into the hardware
• Software verification – requiring access to the hardware interface but being OK with black-boxed hardware functionality
• Hardware/Software verification – requiring access to both hardware and software details
• Performance and Power Verification – confirming that architecture partitioning decisions were correct
• Verification of system integration – making sure that given the various levels of scope, the integration of blocks into sub-systems and sub-systems into SoCs is done correctly

System Verification Framework

Now, the main seven prototyping engines for verification of hardware and software are:

• Software Development Kits (SDKs), like the Android and Apple iOS development kits allowing programming against more abstract APIs like JAVA. Main advantages are speed and usability. The hardware is abstracted away so much that detailed hardware effects may get lost.
• Virtual Prototypes allowing execution of the actual software binaries against defined register interfaces. Main advantages are execution speed and software debug/analysis. The hardware is functionally correct and can be annotated with performance information if needed, but  is not as accurately represented as some low level analyses require.
• RTL Simulation executing the actual hardware in pure simulation. Main advantages are hardware debug with constraints, assertions, metric driven verification, as well as turnaround times when RTL changes, making it a great vehicle for verification for hardware blocks and sub-systems and when RTL is not very mature yet. Speed degrades very fast with growing scope and complexity, and while software can be executed on RTL representations, it is so slow that software development and debug efficiency is very limited.
• Acceleration combining RTL Simulation and hardware assisted verification. The test bench executes in simulation on the workstation and the design under test executes in the hardware. While speed increases substantially – factors of 100x to 1000x over pure simulation can be reached – the main advantage remains the set of advanced debug capabilities. Speed is still not sufficient for efficient hardware/software development and debug. In the project flow RTL is still not mature enough to make investments in mapping into FPGA based hardware a reasonable investment. Bring-up and debug turnaround time are still key criteria for the right engine here.
• Emulation executing the full design within hardware, either using synthesizable test benches or being connected to the real word using rate adapters (SpeedBridges). Main advantage over simulation and acceleration here is speed – emulators reach into the MHz range which enables software development including OS bring-up. From emulation, users still expect a couple of different RTL spins to be brought in per day as the RTL has not matured far enough. Debug insight into the hardware is key, as is the ability to connect to the system environment using rate adapters – think of connecting a networking chip to Ethernet to directly connect to the internet.
• FPGA Based Prototypes executing the hardware in an array of FPGAs offer even higher speeds reaching the range of 10s of MHz. This main advantage allows software development with software debuggers attached using JTAG, as well as hardware regression usage due to the increased speed. Connection to the system environment can be at speed if the FPGA based prototype is fast enough. The downside of FPGA based engines lies in the slower bring-up of the design and much more limited hardware debug, including limitations to execution control – i.e. starting and stopping the design.
• Finally, once engineering samples are available, prototypes based on the actual silicon can be used. Speed is as the developers intended, but debug insight into the hardware is limited to what has been made available using On Chip Instrumentation like ARMs System Trace Module (STM). Software debuggers are attached using JTAG and allow software development. Like FPGA based prototypes, control of execution is very limited.

Four levels of scope, five main use models and seven execution engines – sounds complex, doesn’t it? The figure associated with this post shows overlaid over the seven engines the main use models I had indicated.

Well, now that we defined the complexity of a system-level verification environment we can discuss the cost, but as indicated I am out of Blog space for today. I started touching on some of the specific cost aspects in my previous post … look for the next post to in which I will touch on the cost of ownership aspects in more detail.

—Frank Schirrmeister is group director for product marketing of the System Development Suite at Cadence.

By Frank Schirrmeister
Last weekend I spent time with my 7 ½-year-old daughter (the ½ is crucially important at that age) on our tree house project. Well, it is more a tree “deck” so far, which is quite respectable though given that we just started building it in one weekend (as the book I quickly downloaded that evening on the iPad actually recommended). A project like this gives endless opportunities to teach children things, from safety around power tools to setting up the project, cleaning up, and optimization of the actual steps when doing repeatable tasks like screwing down deck planks. I realized on Monday that all of this is applicable to electronic design as well

If you have ever had a 7 ½-year-old design partner building anything, you will know that patience is not necessarily a strong suit of theirs. So you want to get to it fast, whatever “it” is. This weekend Sydney had chosen a color and was painting the four base poles. Prep was easy: Wear clothes we don’t care about anymore, find paper to put the bucket and brushes on, etc. Then we worked on the deck planks—there is a sub-floor like structure on the four newly painted poles installed around the tree—and we had bought deck planks earlier. Prep? Out comes the table saw, measuring tape, power drill, various drill bits, deck screws, etc. As you can imagine the process of setting everything up, measuring, debugging why we had cut one of the planks to the wrong length (classic diagonal misalignment bug) and re-cutting took much longer than actually installing the about 30 square feet of deck planks that day. Once we were on it the main thing was about speed of getting the next plank up, how many we could carry at the same time and how fast we could drill and screw—loading time, capacity and performance so to speak.

Before clean-up I realized over home-made lemonade (sugar is my daughter’s secret ingredient) that this was actually quite instructive for my day to day job during the week, as well. In the four engines of the System Development Suite the main three characteristics we are typically looking at when executing hardware/software designs are speed, accuracy (TLM vs. RTL) and capacity. In articles like “Combining Prototyping Solutions to Solve Hardware/Software Integration Challenges” I have outlined  other characteristics, such as turnaround time, time of availability, and debug efficiency, but it seems we are getting back to speed, accuracy and capacity far too fast.

What works as comparison between the actual engines—Virtual Prototyping, RTL Simulation, Acceleration/Emulation and FPGA Based Prototyping—works just as well to compare the different options users have on the market. Our acceleration/emulation business is running on all cylinders and we are clearly the market leader. In customer meetings I often hear the question, “So how do I compare productivity, really?”

Well, as my daughter would tell you about our deck planks (while selling you some lemonade), it is simply all about the setup and turn-around time! There is a reason why we are calling our engine the Palladium XP “Verification Computing Platform.” It has been conceived as a verification computer with a specialized processor to which we compile the RTL to be executed and for which we enable specialized hardware debug similar to what users are used to in RTL simulation. This is pretty unique. Other platforms for hardware acceleration out there are based on FPGAs, either commercial or custom. As a result there is no need for Palladium XP to do the layout within FPGAs or do partitioning between them, which is a complicated, time consuming process. Bottom line: The setup and compile time, i.e. how to get to “it” in my daughter’s language, is significantly faster, as is the debug cycle as the debug insight is great. The Figure associated with this post shows a typical example for a 128 million gate design.

Design Productivity in an Acceleration/Emulation Environment

Our customers see three times faster compile times, as well as significantly faster debug loops, and as a result get to up to six design turns per day—at least three times as many as they see in FPGA-based systems. This provides real advantages for design engineers, as well. My daughter’s attention span is naturally limited at 7 ½ years, but even for trained professionals their concentration will suffer after 12 hours of hard work, so squeezing in 2 to 3 runs in the first 10 hours is key to real productivity.

The other question we often hear in customer meetings is about “cost of ownership.” This deserves its own post, but suffice it to say that my daughter had motivated a friend of ours to come over to “play” and help. It turned out he was very helpful (as he was taller than 40 in) in helping to hold up studs. But if I had had more power drills we could have parallelized the preparation of the deck planks as well. While this may have helped with the set-up time, there is a cost associated with that—just like in the compile farms needed for compiles to FPGA-based hardware acceleration.

You see where I am going with that:)

And by the way,  just to be crystal clear, this is not to bash FPGAs. We do see a clear need for FPGA-based hardware acceleration, as well, and in fact offer those systems called Rapid Prototyping Platform RPP as part of the System Development Suite. Both have their use in customer’s project as I had described in previous articles. The above commentary simply applies to FPGA-based systems playing in the Acceleration/Emulation market.

Bottom line: This was a productive weekend for the tree house project…and my daughter now knows about what questions to ask to get the best design productivity for acceleration/emulation, as well.

—Frank Schirrmeister is group director for product marketing of the System Development Suite at Cadence.

By Frank Schirrmeister

Seven Layers of Hardware/Software Debug

Of course I will be in trouble once this blog is posted. This post is about hardware/software debug,  and I tried to layer a set of different levels for the scope and applicability of debug. I counted seven layers, but I am sure that one may be able to arrive at a different numbers of layers of debug depending on one’s counting.

The layers I counted are illustrated in the graphic associated with this post. It shows a multi-core chip as it could be used as an application processor for phones or tables. The chip features multiple processor cores – including ARM big.LITTLE – and features customer specific blocks for graphics and application acceleration, high-speed, low-speed and general peripherals.

All of the blocks are connected through a hierarchy of SoC interconnect fabrics. The chip itself is then connected to real world interfaces on a printed circuit board, connecting to cellular modems, audio, video and other interfaces. Complex software is running on several of the components,. oOf course this includes the processor sub-systems, but complex software is likely also running on the accelerators for graphics (think CUDA programming models) as well as application accelerators for multimedia applications, not to mention digital signal processors in the system.

So how does one go about debug, verification and validation of such a system?

At the top of the graphic I illustrated some of the engines used for verification, validation and the actual hardware/ software debug. Designers will use transaction-level simulation in Virtual Prototypes,  and use RTL simulation for verification. Acceleration and emulation also operate at the RT-Level, as does FPGA based prototyping. All three technologies offer different advantages regarding bring-up speed, bug turnaround and bring-up time, as well as the actual execution speed and debug insight into the hardware.

At the end the actual chip will be used in development boards to allow final validation of software and in-system-environmental operation. Now the user operates with “the real deal” at the actual target speed, but only a limited set of debug capabilities is typically embedded in silicon and exposed to the user. All these engines, from TLM to RTL execution and the actual chip, have one unifying property – they generate the set of information necessary to enable debug, verification and validation.

So what do the layers of debug look like?

At the lowest level the actual hardware itself needs to be verified and debugged. This can happen at the scope of individual IP blocks, sub-systems, and the actual system-on-chip (SoC) as well as at the scope of the SoC within its system context.

Similar to pure hardware debug, the bare metal software executing at the lowest level of abstraction needs to be functionally verified. It needs the hardware it executes on to be modeled in sufficient detail, but the main intent at that level is to validate the software functionality and its interaction with the hardware.

While the debug at the lowest levels is focused on hardware and software functionality, respectively, the more complex the device under verification becomes—and the more important software will become as part of the debug as it influences the interaction.

When operating systems (OSes) like Android, Linux or Windows Mobile come to play, the scope of debug and validation again changes. Now the debug has to happen in an OS-aware way, i.e. the software will use specific functions and APIs as they are provided by the OS.

Given the complexity of designs, integration itself becomes an item to be debugged and validated. Are the 100s of IP blocks connected correctly? The dependencies and relationships between functions – the sequence of execution – become important and need to be validated. Has the initialization been done in the right order? Is the bring-up of one peripheral dependent on another one being initialized first?

Again, validation of key parameters like performance and power needs to move one level upwards. Are portions of the design switched off at the right time to optimize power consumption? Is there enough memory bandwidth?

Finally, at the highest level, the application scenarios become important. These are the use cases we users see and expect to work. My daughter’s use of her iPod touch may consist during a day of 70% standby, 15% videos on YouTube, 10% games and 5% texting with her friends. My use of my iPhone will be very different—and both her usage and my usage need to be translated into application scenarios which need to be validated.

Why is all this important and I am writing about this? Each layer has its own target user group, and the dependencies of hardware on software and vice versa do change significantly. However, with increasing complexity the lines become blurry and given the overall unbound nature of verification, decisions on where and how much to verify, debug and validate has significant influence on when a design team is “done.”  In an ideal world all of this would work under one Integrated Development Environment (IDE) to allow efficient exchange of information between the different user groups.

Are we there yet?  Far from it … Users are facing a large number of different debug and verification environment, often disconnected. There is huge room for innovation here!

—Frank Schirrmeister is group director for product marketing of the System Development Suite at Cadence.