So what types of virtualization was I involved in recently? Well, there is a bunch:

• In day to day life at work I am involved in providing virtual representations of hardware to software developers and hardware verification engineers. This type of virtualization allows to work with a representation of the hardware a long time before the hardware is actually available. It provided real time to market savings.
• We are re-modeling our house. With Google Sketchup we are using a full 3D model of the house to decide on how to decorate (see the upper left picture). Two effects kick in here. First, the world really is flat. It would have taken me a couple of weekends to become fully proficient on Google Sketchup’s modeling capabilities. It did cost me less than $200 to virtually hire a firm to provide me a fully functional, accurate model of the house within a couple of days. There are plenty of firms worldwide providing Google Sketchup services. The second effect is one of time and cost savings. Pre-viewing things virtually in the virtual house allow us to make decisions faster and to get highest quality at the end – we are avoiding surprises at the very end when for example the cabinetry is built.
• I am using Facebook and LinkedIn pretty regularly. It allows me to keep – virtually – in touch with friends and colleagues.
• I have run several virtual trade shows now – we started last year. They allow to reduce cost on all side. Vendors reduce show preparation and execution cost, attendees reduce travel time and cost and can be very selective in what they look at. The next virtual show we will be doing here at Synopsys is the Synposium from August 31st to September 2nd.

So, why am I optimistic that the future will need us after all? Well, with all virtualization the human element still remains at the core. All virtualization technologies reduce cost, time to results, improve the quality of the end result and make the interaction more efficient. But all the actual content comes from us – humans – and will come from us for quite some time. Even in a virtual tradeshow the most value can be achieved by actively interacting with the vendors present for instant messaging like communication. While Billy Joy argues successfully in “The Future Doesn’t Need Us” how robotics, genetic engineering, and nanotech are threatening to make humans an endangered species, I don’t think virtualization is contributing to this trend given that it just makes interaction more efficient. But then again, I may be wrong. Let me know what you think!

So see you next – virtually – at the Synposium, a Synopsys Virtual Event, to chat about the benefits of virtualization at our virtual system-level design booth. In addition, the virtual show will allow you to learn from the comfort of your desk about Synopsys EDA software, IP, prototyping and services used in semiconductor design, verification and manufacturing. Until then I am off doing non-virtual activities during my honeymoon

I remember those days quite clearly – has it really been ten years? When searching for “PKS” I found headlines like “IBM Integrates Envisia PKS Into Its ASIC Design Flow”, “Cadence’s Ambit PKS speeds tapeout at EmpowerTel Networks” and “Cadence Envisia Physically Knowledgeable Synthesis Selected by Ericsson Microwave Systems AB; Cadence Envisia PKS Used For Successful Million-Gate Production Design”. These headlines were all from about mid 2000. I am getting sentimental – at that time I was the product manager for Cierto Virtual Component Co-Design (VCC), which was probably 10 years ahead of its time. Somehow corporate had hired a leftover consultant to rename all or products to sound like cars. And I remember being somewhat jealous of my colleague’s situation in synthesis, because unlike us in the “Cierto” system-level flow, the “Envisia” guys in synthesis just had found a way to connect to the main business of layout and implementation. They made the next level down in abstraction – layout – part of their flow. The static predictions of what the impact of layout on timing would be, were simply running out of steam. Layout and synthesis would be integrated, or at that time, at least synthesis became layout aware. From a business perspective this meant that the next abstraction level up – logic synthesis – was connecting directly to the main business.

So ten years later I find myself looking at an ever changing landscape of customers. System Houses like Nokia abandon hardware and do only software. Semiconductor houses like TI, Marvell and Freescale provide more and more software as part of their complex platforms. IP providers like Tensilica combine their IP and software to provide sub-systems. In that changing landscape we are now starting to connect the manufacturing of foundries with the system-level world of transaction-level models – we are closing the loop just like ten years ago logic synthesis did. The picture on the left illustrates what is happening. Properties like power, performance and area (PPA) are characterized at the foundry level and annotated into system-level transaction-level models. As a result the design flow becomes more predictable and decisions can move up in the design chain to the user who defines the architecture, more and more the system house based on the software architecture.

Here are two examples which underline this point:

• TSMC recently announced Reference Flow 11, in which users for the first time ever now can get a foundry defined reference flow for system-level design. In the examples users can analyze their technology choice’s impact on power at the transaction-level the effect  .
• At the Interoperability Breakfast at DAC, Subramani Kengeri (Global Foundries) presented together with John Cornish (ARM) and Joachim Kunkel (Synopsys), how IP Providers, Foundries and System-Level Tool Providers interact more closely to provide technology characterizations into transaction-level models. All of this is meant to raise the level of abstraction at which design decisions happen. Global Foundries was specifically pointing to Virtual Prototypes as “Application optimized Integrated Platforms and Collaborative System Design Solutions” at the system-level combined with “Automated Precision Manufacturing (APM) and Early enablement of System level views” at the silicon level.

History repeats itself! Ten years on I find myself in the same situation as my “Envisia”colleagues were ten years ago. We are starting to close the loop from system-level to implementation! All this is great news and probably yet another indicator that the marker for system-level design tools is finally moving towards mainstream.

In his book “Hot, Flat and Crowded” the author Thomas Friedman gives us a comprehensive perspective on the fundamental equations this planet operates from. He connects population, natural resources, energy and information technology into these equations. One of his conclusions for energy production and consumption balance is to have a systemic approach, which optimizes the system from the top level with intelligent energy generation, distribution, storage and consumption. He warns that our current system for energy production and distribution is largely overdesigned for delivering peak capacity 24/7.

Nobody designs electronic products from a power perspective with the same energy waste today. Energy is either very limited (mobile devices) or expensive (infrastructure). Semiconductor companies are doing a lot to optimize energy consumption from using the best low power silicon processes, efficient micro and macro architectures and advanced, software-driven power management. By implementing all of these approaches at the software, RTL and transistor levels, semiconductor companies have been able to squeeze an amazing amount of processing power onto single chips.

Is that enough? Have we managed power every way possible in the best possible ways? Maybe not. Here are a few experiments for the undecided:

· 1st: Use your smartphone to browse, comment on, and update your Facebook feed and see how long it takes to empty your battery that way.

· 2nd: Take several HD videos of your incredibly entertaining kids . I recommend keeping a sharp eye on your battery level and wearing a glove on the hand holding the device.

· 3rd (for next year): Use your LTE enabled smartphone and stream a movie from the internet.

What is going on here? Clearly high-speed video and the related high-speed wireless access are the main power drains on you battery. This trend is only going to accelerate in the future, as 3D video and LTE-A will be experiences consumers will want to pay for.

All of these experiences have one thing in common – Lots of digital signal processing. The only way to achieve the best signal processing algorithm is to start telling the algorithm designers that they have to be power conscious and optimize their algorithms much more than they used to for performance and power.

So if you want to save big, go and talk to your algorithm design teams. They need both some recognition and some well-deserved pressure to save your day. As Friedman said, “either we are going to rise to the level of leadership, innovation, and collaboration that is required, or everybody is going to lose big.” The winners in the semiconductor space will be those that rise to the challenge of designing to save energy at the algorithm level.

We are definitely within a transformation of the value chain, and what makes this so interesting for us in the “system-level design space” is the fact that our customer targets are shifting. Take the simplified view in the picture of this post. What used to be – like in the case of Nokia – a vertically integrated environment in which companies provided the silicon, the hardware and the software, has now changed into a separated set of design and value chain participants. After Nokia had transferred parts of its IC operations to ST Microelectronics back in November 2007, it has now essentially fully transformed into a company focusing on the software for their phones, fully moving the chip development into suppliers. The picture on the left tries to illustrate what the different design chain participants are focusing on. The software development, from lower level firmware through OS, driver, middleware and application software, essentially changes ownership. More and more of it is pushed to semiconductor providers and IP providers, which have to provide software with their devices.

I had run across a more elaborate analysis of the “Strategic Options” for Nokia as part of a Sloan MIT Lecture on Technology Strategy back in 2005. The section on Nokia provided by Professor Rebecca Henderson shows on page 6 the ecosystem from chipset manufacturing to network operation and service provisioning. It looks like the current situation is closer to the “nightmare” option on page 14 than the actual suggested vision on page 21, in which market share growth was accomplished with more vertical integration.

So why do I care in particular? Well, given all the transformation leaves the big question who the target customer really is for somebody in the “system-level design space”, or ESL. Take virtual prototypes for example. As software development tools they are right at the border between silicon and software. Who uses them? Who develops them? Traditionally virtual prototypes have mostly been used by software developers, in system houses and semiconductor companies. With the transformation of the user base, system houses gain more and more influence in demanding virtual prototypes used as software development tools. That means, different dynamics in the value chain and new customers for us in the system-level area of EDA. Interesting times indeed!

FIve: Technology consolidation has begun. Well, it has accelerated. What has happened over the last year is that Synopsys bought CoWare, VaST and Synfora – enhancing their technology arsenal for for algorithm design, ASIP processor design, high-level synthesis, architecture design and virtual prototyping. Cadence has bought Denali – trying to catch up somewhat to Synopsys’s position in IP. The way we look at system-level design involving Systems on Chip and Chips in Systems is fairly straightforward. Users need lots of blocks in their designs. They need to either be able to re-use them or make new onesfast. They then need to integrate them into one or multiple chips in the system, assess whether their connections are properly architected and provide prototypes of them as early as possible to provide links to embedded software development. This results in needs for IP and various views of it (including system-level models), needs for technology to create new and differentiating blocks fast, to efficiently integrate blocks and finally to provide prototypes for software development. With the accelerated consolidation of technologies it becomes easier to optimize flows across different technologies. See us at the Synopsys System-Level Booth to check out the technologies we have in this domain.

Four: Design Chain enablement becomes a key requirement. Pressure for enablement across the design chain has increased tremendously. In the chain from semiconductor IP providers, to semiconductor providers, to system houses and finally software developers we increasingly see the respective next element of the chain driving the previous one in supplying the right models. A great example are virtual platforms, which allow system houses and semiconductor providers to more efficiently interact. See our suite demos on virtual platforms to find out more.

Three: Standards enable interoperability. The standards-enabled ecosystem (see picture on the left) has grown tremendously since last year. Standards like Accellera’s IP-XACT and OSCI/IEEE SystemC TLM-2.0 enable a strong ecosystem which allows to make sure that system-level technologies can interoperate properly, allowing users to create repeatable flows. Check out our partners at the Synopsys Standards booth to see how SystemC TLM_2.0 enables interoperability.

Two: Links to Verification find adoption. Being on the move to higher levels of abstraction is now combined with strong links back into verification. A fair portion of the system-level design market has been “ESL Verification” for a while, i.e. connecting transaction-level models to verification. Over the last year we did see the trend continuing and more and more developers now make software part of their testbenches for hardware verification. Check out the paper we co-authored with Infineon called “High Speed Models for Automotive Microcontrollers: Verification of the TriCore AUDO FUTURE TC1797 Virtual Prototype”.

One: Foundries are starting to incorporate system-level flows. Not only links to verification but even links into semiconductor technology data find their adoption. Performance, Power and Area (PPA) data characterized at various technology nodes can now be made available to drive decisions at the system-level. For example, in the TSMC system-level reference flow we recently announced, users can see with data created using virtual platforms at the transaction-level how the software will impact power consumption at different technology nodes. Check out our system-level reference flow at the TSMC booth.

Time will tell when and how system-level design technologies will cross the chasm and find mainstream adoption, but in a Sally Bowles “Maybe This Time” fashion it certainly feels different this time around. See you in Anaheim!

When Carver Mead and Lynn Conway published their famous statement about the ‘tall thin engineer’ in their book "Introduction to VLSI System Design" in the early 80ies, designs had about 5,000 gates. Their vision was to change VLSI design into a process, that was repeatable and also that designers could understand the entire process well enough to create chips starting with the knowledge of the design intent down to the final mask set. If we look into the reality 30 years later, the opposite has become true. The SoC design process has been decomposed into a number of major categories: System-level design, Software development, RTL design, RTL2GDSII, Design for Manufacturing with vastly different knowledge disciplines.

In this View From The Top we of course do not look down to DFM, so we are definitely not the prototype of that tall thin engineer. At best we can see that our end point from a hardware implementation perspective is RTL for implementation and some reference model or test vectors, we provide to the RTL designers.

So how should system-level tools support hardware implementation flows? First of all the role of system-level tools is to make sure that the design intent is completely specified and is validated in the system context. Second the tools should facilitate an easy way of getting to RTL.

How do system-level engineers know, if their specification of design intent is complete? The best way for them is to express their specification in a way that is intuitive, allow for reuse of their knowledge and manages complexity through encapsulation. This is the essence of model-based design. In the domain of communication systems design any algorithm designer today will start with a conceptual block diagram and for simulation use C-models to explore the overall system performance. Block diagram based tools with a large amount of proven models, such as SPW and System Studio, are the default way for design teams today.

Once designers have captured their system using this model-based approach, the complete power of the high-performance simulation tools for performance exploration, specifically going to the required fixed-point precision is at their disposal. At a minimum this model-based fixed-point specification is a reliable, easy to understand meet-in-the-middle reference for RTL designers and algorithm designers. However with the proven Synopsys tools for implementation, algorithm designers can take it one step further: They can either rely on proven DSP implementation building blocks, built-in C to RTL translation technology or high-level model-based synthesis using Synopsys’ Synphony to automatically create RTL which can go straight into RTL2GDSII flows. Hundreds of thousands gates blocks are being designed every day with these flows, retargeting from FPGA to SoC included.

The basic questions of how much implementation expertise and algorithm design engineer needs and how much domain expertise an RTL designer needs does not have a fixed answer. Design teams will always need to stretch to bridge the gap. Synopsys can help to make the stretch easier!

First of all, my own Blog productivity has been miserable. My last Blog post two month ago? Ouch. Sorry for that. My excuse: We were very busy with the integration of the various acquisitions we made. However, the discussion on design productivity makes me think back on the two most memorable EDA speeches I have heard. One was in 1997, Joe Costello was talking about “negative target fixation” as part of a seminar tour. Productivity and how Cadence addresses its improvement, was the topic of the rest of the speech. At the time I was an EDA user and the speech helped convince me to join EDA. The other speech was given by Aart De Geus at DATE, I think in 2000 or 2001. I vividly remember going home with the thought “now that the Genome is deciphered, the design productivity gap is the next big problem to figure out. Let’s get to it”. And we did! According to the ITRS since 2001 design productivity has been improved through automation more than 18-fold for hardware and it has more than doubled for software.

So what does this all mean for us in EDA? The main message ITRS gives us in 2009 remains: Cost (of design) is the greatest threat to continuation of the semiconductor roadmap. Without the productivity improvements provided by tools, development cost would simply explode. The graphic on the left tries to illustrate this and is based on ITRS data. The overall semiconductor development cost – hardware and software – is kept in check under $100M. In order for that to happen, certain productivity deltas have to be achieved. Over the next ten years – until 2011 – this will have to lead to an overall, cumulative 50 fold productivity improvement in software development and a 26 fold productivity improvement in hardware development.

50 fold productivity improvements are hard to imagine at first. For my planned house re-model taking about 50 days, the equivalent would be to do all of it in a day. The involved design technology improvements cited by the ITRS are the “Intelligent test bench”, a “Concurrent software compiler” helping to automate the partitioning across processor cores, “Heterogeneous massive parallel processing”, “Transactional Memory”, System-level Design Automation” and ultimately a “Executable specification”.

So are those productivity improvements even feasible?

A good reference comparison from manufacturing would be automotive. The first production Ford Model T was built in 1908 in Detroit. It did cost about $850. This being $17,000 in 2007 inflation-adjusted dollars makes this about the same price of a new Ford Focus. This is comparable to the consumer industry. For the same price or less, users are getting much more functionality in their devices like cell phones and compute devices. Production time wise the first Model Ts rolled off the band about every 12 hours in the early days, every 93 minutes in 1914, once per minute in 1920 and at its peak every 24 seconds. That’s a 1800 fold improvement in manufacturing productivity within a decade or so. The item difficult to gauge is the car development complexity. I did not find real data here, but GM introduced the first Engine Control Unit (ECU) with a microprocessor in 1979. Combine that with the fact that today’s cars easily have more than 50 ECUs in them, suddenly the factor 50 no longer looks that out of the question anymore.

At the end of the day the challenges for the next decade to achieve the required productivity improvements seem to be doable. Given the mix of hardware and software changes our increased attention here at Synopsys on software development certainly seems to be timely and correct.

Creating Revenue from Spectrum – Algorithms and Software are the key

By Johannes Stahl

When a piece of land in your community gets rezoned to become a housing area this land becomes more expensive for developers as housing zones are still a scarce resource. Very similar wireless operators go out and acquire expensive spectrum to provide their services to you. They need to utilize this scarce resource it in the most effective way.

The whole war for standards in the wireless domain is about who controls the spectrum and in which way this enables controlling the entire eco system for delivering services to consumers. A well known example of top level control has always been the Chinese government, who has fostered local Chinese versions of communication standards. When WCDMA was adopted by the world, China would create the TD-SCMDA version of it and around that operators like China Mobile would be able to drive their supply chain providing solutions.

The history only seems to repeat itself with the upcoming LTE standard. The TD-LTE version of the standard, which uses a different way to allocate spectrum and time to the individual users compared to the general LTE standard (also known as FDD mode), is again being developed for the local Chinese market. But interestingly enough TD-LTE will now also apply for other countries as the spectrum allocation being offered by those governments is similar to the spectrum structure required for TD-LTE (in communications theory lingo this is spectrum called ‘unpaired’).

TD-LTE and LTE (FDD) standards require very similar physical layer processing requirements, so that even with a split into two versions the eco system will be quite capable of providing cost effective solutions based on scalability. Although the standards are very similar, they are definitely not identical. This poses two challenges for the developers of baseband solutions.

For both standards the performance characteristics of the physical layer, which is largely determined by one parameter – the system throughput – will require optimization of the detailed signal processing that is used to drive the specific spectrum allocation and hence the reconstruction of the received signal. This is by no means trivial and requires 1000s of long simulations with millions of test vectors. Better algorithms, better performance, more revenues for the operators. Time and effort well invested by the supply chain.

The implementation of chip sets that can span both standards (and maybe even WiMAX) is evenly challenging, as high data rates requires optimum signal processing architectures and at the same time switching between standards asks for software programmability. All of the above at the lowest power to satisfy you as a smart phone user. From a design perspective this means actually going back and forth between algorithm design, architecture design and software implementation in order to achieve the design goals.

If you are responsible for baseband products at a semiconductor or handset manufacturer you better off being equipped with integrated system-level design solutions to get your product into the LTE market with predictable success.

Hard IP has been already targeted to a specific implementation technology – TSMC, Global Foundries etc. Generally this happens for blocks that are already optimized, in the digital world these may be ARM cores for TSMC, in the analog and mixed signal world these can for example be physical interface IP (PHY IP) pre-ported to target technologies. For example, the Synopsys DesignWare USB 2.0 PHY IP has been ported to over 50 processes and configurations ranging from 180nm to 28nm.

Soft IP has not yet been targeted to a specific technology node but is instead available as synthesizable, pre-verified RTL, which the user can target to a technology of their choice using logic synthesis. A good examples is the Synopsys DesignWare IP Solution for AMBA Interconnect, which comes with synthesizable IP for the interconnect fabric, DMA controllers, memory controllers and peripheral IP, along with verification IP to make sure the design works in its context and tools to assemble the IP at the RT-level

So what does this mean in Slartibartfast’s world of designing the San Francisco Bay Area? They key difference between hard and soft and IP is shown in the picture at the left. Soft IP is delivered at the equivalent to the Street-Level in a textual form. Slartibartfast’s designers describe how many houses the customer needs, how they are connected to each other etc. They do not describe the actual layout, i.e. where to place these items. They don’t even describe the actual number of houses, sizes and connections because it all depends on how many people have to use the houses and streets as well as how often they need access. Form this textual description logic synthesis now creates the actual placement of the components, how they are connected etc. Another set of automation tools lays the different components out across the landscape. The final description – the blueprint how to build everything including all walls, electricity, plumbing etc. is then sent to manufacturing.

For hard IP the process is different. Instead of using automation to get from the street level textual description to the actual blueprint on how to layout everything across the landscape, everything is custom made. The Oakland Harbor used in the last Hitchhiker’s post is one example, for which the characteristic of how the water behaves over time, what type of ships arrive etc. cannot really be changed. It’s fixed like the line characteristics for USB PHY’s are and it has to follow certain protocols like USB Controllers have to. While the digital portion typically is synthesizable, the actual interface to the analog world is hard to implement in an automated fashion. For this purpose hard IP (interfacing the water) is an actual implementation at the blueprint level, which can be place and it has been already optimized and verified for the technology chosen to implement the Bay Area.

So why do both exist? Hard IP is not flexible but instead optimized for a specific technology, so it will be at best area, power or performance. In cases like Analog IP it typically is the only option of delivery. Soft IP is offering flexibility – users can choose more options in the area-power-performance target domain. Soft IP is typically configurable with parameters and users can even extend the RTL to add custom functionality. The latter comes at a cost – users have to verify that the additional functionality didn’t break the original design, which is typically pre-verified and comes with verification IP.

Regardless of which type of IP was chosen, IP Reuse in general is crucial to increase design productivity!

What happened? In my last post I likened the Oakland harbor to a USB interface. Thomas Bollaert commented in his Blog entry title ‘The “S” in ASIC’ on the role of IP reuse and that ‘IP has an important role to play, but not an exclusive one’. Hey, I fully agree. How let’s look at where we are on the scale between IP reuse and creation of new IP.  I would at least want to augment the comment ‘it will be quite some time before chips are an assemblage of IP blocks’ with the notion that large chunks of design are already today. The graph on the left shows IP reuse data from Semico Research. The average number of IP blocks per chip is already around 50 and set to grow to more than 70 over the next couple of years. Together with data that more than 50% of a chip is reused today already (a number which is set to grow to at least 60% over the next couple of years), there is already a large amount of IP assembly going on today..

So what are these IP blocks? Well, processors like ARM, Atom, MIPS, PowerPC etc. for one. These blocks are designed to be a scalable business – i.e. being sold multiple times. The analogy of the Oakland harbor was meant to indicate other blocks which are a scalable business – connectivity blocks for defined interfaces like USB, SATA, DDR etc. Given that these follow defined standards, the main decision is whether to have them available or not. A custom implementation will in most cases not be differentiating for a chip vendor. As a result they will tend to reuse IP for those and focus their differentiation on some of the custom blocks Thomas describes (like video or audio) as well as on the software provided on the processor.

So with assembly of IP blocks being a given, where does high-level synthesis fit in? Well, it certainly does for new blocks. Even if IP-reuse grows to 60% or 70% as predicted, those remaining 30% are still a big chunk of work. That’s where high-level synthesis fits in with two effects. First, it accelerates the time to implementation. In addition it increases verification efficiency by enabling transaction-level verification combined with a repeatable, automated flow to implementation.

How far one takes this depends on perspective. Some vendors definitely take it a bit too far in questioning IP reuse at the RT-level as “high effort, error prone work” and “restricting architectural flexibility”. Pushing TLM models as the only golden source from which one synthesizes takes it too far. High-level synthesis from the transaction-level needs to be seen in conjunction with IP reuse of larger blocks like USB, SATA, DDR etc. Just like in the transition from gates to RTL, I doubt that high-level synthesis will eradicate reuse of smaller blocks. It will augment it and perhaps even use it by using the smaller blocks of IP to map to.

As always, the truth to me lies somewhere between the extreme positions.