Part of the  

Chip Design Magazine

  Network

About  |  Contact

Posts Tagged ‘SystemC’

System Level Power Budgeting

Wednesday, March 12th, 2014

Gabe Moretti, Contributing Editor

I would like to start by thanking Vic Kulkarni, VP and GM at Apache Design a wholly owned subsidiary of ANSYS, Bernard Murphy, Chief Technology Officer at Atrenta,and Steve Brown, Product Marketing Director at Cadence for contributing to this article.

Steve began by nothing that defining a system level power budget for a SoC starts from chip package selection and the power supply or battery life parameters. This sets the power/heat constraint for the design, and is selected while balancing functionality of the device, performance of the design, and area of the logic and on-chip memories.

Unfortunately, as Vic points out semiconductor design engineers must meet power specification thresholds, or power budgets, that are dictated by the electronic system vendors to whom they sell their products.   Bernard wrote that accurate pre-implementation IP power estimation is almost always required. Since almost all design today is IP-based, accurate estimation for IPs is half the battle. Today you can get power estimates for RTL with accuracy within 15% of silicon as long as you are modeling representative loads.

With the insatiable demand for handling multiple scenarios (i.e. large FSDB files) like GPS, searches, music, extreme gaming, streaming video, download data rates and more using mobile devices, dynamic power consumed by SOCs continues to rise in spite of strides made in reducing the static power consumption in advanced technology nodes. As shown in Figure 1, the end user demand for higher performance mobile devices that have longer battery life or higher thermal limit is expanding the “power gap” between power budgets and estimated power consumption levels.

Typical “chip power budget” for a mobile application could be as follows (Ref: Mobile companies): Active power budget = 700mW @100Mbps for download with MIMO, 100mW @IDLE-mode; Leakage power <5mW with all power-domain off etc.

Accurate power analysis and optimization tools must be employed during all the design phases from system level, RTL-to-gate level sign-off to model and analyze power consumption levels and provide methodologies to meet power budgets.

Skyrocketing performance vs. limited battery & thermal limit (ref. Samsung- Apache Tech Forum)

The challenge is to find ways to abstract with reasonable accuracy for different types of IP and different loads. Reasonable methods to parameterize power have been found for single and multiple processor systems, but not for more general heterogeneous systems. Absent better models, most methods used today are based on quite simple lookup tables, representing average consumption. Si2 is doing work in defining standards in this area.

Vic is convinced that careful power budgeting at a high level also enables design of the power delivery network in the downstream design flow. Power delivery with reliable and consistent power to all components of ICs and electronic systems while meeting power budgets is known as power delivery integrity.  Power delivery integrity is analogous to the way in which an electric power grid operator ensures that electricity is delivered to end users reliably, consistently and in adequate amounts while minimizing loss in the transmission network.  ICs and electronic systems designed with inadequate power delivery integrity may experience large fluctuations in supply voltage and operating power that can cause system failure. For example, these fluctuations particularly impact ICs used in mobile handsets and high performance computers, which are more sensitive to variations in supply voltage and power.  Ensuring power delivery integrity requires accurate modeling of multiple individual components, which are designed by different engineering teams, as well as comprehensive analysis of the interactions between these components.

Methods To Model System Behavior With Power

At present engineers have a few approaches at their disposal.  Vic points out that the designer must translate the power requirements into block-level power budgeting to come up with specific metrics.

Dynamic power estimation per operating power mode, leakage power and sleep power estimation at RTL, power distribution at a glance, identification of high-power consuming areas, power domains, frequency-scaling feasibility for each IP, retention flop design trade-off, power-delivery network planning, required current consumption per voltage source and so on.

Bernard thinks that Spreadsheet Modeling is probably the most common approach. The spreadsheet captures typical application use-cases, broken down into IP activities, determined from application simulations/emulations. It also represents, for each IP in the system, a power lookup table or set of curves. Power estimation simply sums across IP values in a selected use-case. An advantage is no limitation in complexity – you can model a full smart phone including battery, RF and so on. Disadvantages are the need to understand an accurate set of use-cases ahead of deployment, and the abstraction problem mentioned above.  But Steve points out that these spreadsheets are difficult to create and maintain, and fall short for identifying outlier conditions that are critical for the end users experience.

Steve also points out that some companies are adapting virtual platforms to measure dynamic power, and improve hardware / software partitioning decisions. The main barrier to this solution remains creation of the virtual platform models, and then also adding the notion of power to the models. Reuse of IP enables reuse of existing models, but they still require effort to maintain and adapt power calculations for new process nodes.

Bernard has experienced engineers that run the full RTL against realistic software loads, dump activity for all (or a large number) of nodes and compute power based on the dump. An advantage is that they can skip the modeling step and still get an estimate as good as for RTL modeling. Disadvantages include needing the full design (making it less useful for planning) and significant slowdown in emulation when dumping all nodes, making it less feasible to run extensive application experiments.  Steve concurs.  Dynamic power analysis is a particularly useful technique, available in emulation and simulation. The emulator provides MHz performance enabling analysis of many cycles, often times with test driver software to focus on the most interesting use cases.

Bernard is of the opinion that while C/C++/SystemC Modeling seems an obvious target, it also suffers from the abstraction problem. Steve thinks that a likely architecture in this scenario has the virtual platform containing the processing subsystem and memory subsystem and executes as 100s of MHz, and the emulator contains the rest of the SoC and a replication of the memory subsystem and executes at higher speeds and provides cycle accurate power analysis and functional debugging.

Again,  Bernard wants to underscore, progress has been made for specialized designs, such as single and multiple processors, but these approaches have little relevance for more common heterogeneous systems. Perhaps Si2 work in this area will help.

EDA Industry Predictions for 2014 – Part 2

Thursday, January 9th, 2014

This article provides the observations from some of the “small” EDA vendors about important issues in EDA.  These predictions serve to measure the degree of optimism in the industry.  They are not the data to be used for an end of year scorecard, to see who was right and who was not.  It looks like there is much to be done in the next twelve months, unless, of course, consumers change their “mood”.

Bernard Murphy – Atrenta

“Smart” will be the dominant watchword for semiconductors in 2014.  We’ll see the maturing of biometric identification technologies, driven by security needs for smart payment on phones, and an increase in smart-home applications.   An example of cool applications?   Well, we’ll toss our clunky 20th-century remote controls, and manage our smart TV with an app on our phone or tablet, which will, among a host of other functions, allow point / text input to your center of living entertainment system – your smart TV. We’ll see indoor GPS products, enabling the mobile user to navigate shopping malls – an application with significant market potential.  We’ll see new opportunities for Bluetooth or WiFi positioning, 3D image recognition and other technologies.

In 2014 smart phones will be the dominant driver for semiconductor growth. The IoT industry will grow but will be constrained by adoption costs and immaturity. But I foresee that one of the biggest emerging technologies will be smart cards.  Although common for many years in Europe, this technology has been delayed in the US for lack of infrastructure and security concerns.  Now check out businesses near you with new card readers. Chances are they have a slot at the bottom as well as one at the side. That bottom slot is for smart cards. Slated for widespread introduction in 2015, smart card technologies will explode due to high demand.

The EDA industry in 2014 will continue to see implementation tools challenged by conflicting requirements of technology advances against the shrinking customer-base that can afford the costs at these nodes. Only a fundamental breakthrough enabling affordability will affect significant change in these tools.  Front-end design will continue to enjoy robust growth, especially around tools to manage, analyze and debug SoCs based on multi-sourced IPs – the dominant design platform today. Software-based analysis and verification of SoCs will be an upcoming trend, which will largely skip over traditional testbench-based verification. This will likely spur innovation around static hookup checking for the SoC assembly, and methods to connect software use-cases to implementation characteristics such as power and enhanced debug tools to bridge the gap between observed software behavior and underlying implementation problems.

Thomas L. Anderson – Breker

Electronic design automation (EDA) and embedded systems have long been sibling markets and technologies, but they are increasingly drawing closer and starting to merge. 2014 will see this trend continue and even accelerate. The catalyst is that almost all significant semiconductor designs user a system-on-chip (SoC) architecture, in which one or more embedded processors lie at the heart of the functionality. Embedded processors need embedded programs, and so the link between the two worlds is growing tighter every year.

One significant driver for this evolution is the gap between simulation testbenches and hardware/software co-verification using simulation, emulation or prototypes. The popular Universal Verification Methodology (UVM) standard provides no links between testbenches and code running in the embedded processors. The UVM has other limitations at the full-SoC level, but verification teams generally run at least some minimal testbench-based simulations to verify that the IP blocks are interconnected properly.

The next step is often running production code on the SoC processors, another link between EDA and embedded. It is usually impractical to boot an operating system in simulation, so usually the verification team moves on to simulation acceleration or emulation. The embedded team is more involved during emulation, and usually in the driver’s seat by the time that the production code is running on FPGA prototypes. The line between the verification team (part of traditional EDA) and the embedded engineers becomes fuzzy.

When the actual silicon arrives from the foundry, most SoC suppliers have a dedicated validation team. This team has the explicit goal of booting the operating system and running production software, including end-user applications, in the lab. However, this rarely works when the chip is first powered up. The complexity and limited debug features of production code lead the validation team to hand-write diagnostics that incrementally validate and bring up sections of the chip. The goal is to find any lurking hardware bugs before trying to run production software.

Closer alignment between EDA and embedded will lead to two important improvements in 2014. First, the simulation gap will be filled by automatically generated multi-threaded, multi-processor C test cases that leverage portions of the UVM testbench. These test cases stress the design far more effectively than UVM testbenches, hand-written tests, or even production software (which is not designed to find bugs). Tools exist today to generate such test cases from graph-based scenario models capturing the design and verification intent for the SoC.

Second, the validation team will be able to use these same scenario models to automatically generated multi-threaded, multi-processor C test cases to run on silicon and replace their hand-written diagnostics. This establishes a continuum between the domains of EDA, embedded systems, and silicon validation. Scenario models can generate test cases for simulation, simulation acceleration, emulation, FPGA prototyping, and actual silicon in the lab. These test cases will be the first embedded code to run at every one of these stages in 2014 SoC projects.

Shawn McCloud - Calypto

While verification now leverages high-level verification languages and techniques (i.e:, UVM/OVM and SystemVerilog) to boost productivity, design creation continues to rely on RTL methodologies originally deployed almost 20 years ago. The design flow needs to be geared toward creating bug-free RTL designs. This can be realized today by automating the generation of RTL from exhaustively verified C-based models. The C++/SystemC source code is essentially an executable spec. Because the C++/SystemC source code is more concise, it executes 1,000x–10,000x faster than RTL code, providing better coverage.

C and SystemC verification today is rudimentary, relying primarily on directed tests. These approaches lack the sophistication that hardware engineers employ at the RTL, including assertions, code coverage, functional coverage, and property-based verification. For a dependable HLS flow, you need to have a very robust verification methodology, and you need metrics and visibility. Fortunately, there is no need to re-invent the wheel when we can borrow concepts from the best practices of RTL verification.

Power analysis and optimization have evolved over the last two years, with more changes ahead. Even with conventional design flows there is still a lot more to be optimized on RTL designs. The reality is, when it comes to RTL power optimization, the scope of manual optimizations is relatively limited when factoring in time to market pressure and one’s ability to predict the outcome of an RTL change for power. Designers have already started to embrace automated power optimization tools that analyze the sequential behavior of RTL designs to automatically shut down unused portions of a design through a technique called sequential clock gating. There’s a lot more we can do by being smarter and by widening the scope of power analysis. Realizing this, companies will start to move away from the limitations of predefined power budgets targets toward a strategy that enables reducing power until the bell rings, and it’s time for tape out.

Bill Neifert – Carbon

Any prediction of future advances in EDA has to include a discussion on meeting the needs of the software developer. This is hardly a new thing, of course. Software has been consuming a steadily increasing part of the design resources for a long time. EDA companies acknowledge this and discuss technologies as being “software-driven” or “enabling software development,” but it seems that EDA companies have had a difficult time in delivering tools that enable software developers.

At the heart of this is the fundamental cost structure of how EDA tools have traditionally been sold and supported. An army of direct sales people and support staff can be easily supported when the average sales price of a tool is in the many tens or hundreds of thousands of dollars. This is the tried-and-true EDA model of selling to hardware engineers.

Software develoopers, however, are accustomed to much lower cost, or even free tools. Furthermore, they expect these tools to work without multiple calls and hand-holding from their local AE.

In order to meet the needs of the software developers, EDA needs to change how it engages with them. It’s not just a matter of price. Even the lowest-priced software won’t be used if it doesn’t meet the designer’s needs or if it requires too much direct support. After all, unlike the hardware designers who need EDA tools to complete their job, a software programmer typically has multiple options to choose from. The platform of choice is generally the one that causes the least pain and that platform may be from an EDA provider. Or, it could just as likely be homegrown or even an older generation product.

If EDA is going to start bringing on more software users in 2014, it needs to come out with products that meet the needs of software developers at a price they can afford. In order to accomplish this, EDA products for programmers must be delivered in a much more “ready-to-consume” form. Platforms should be as prebuilt as possible while allowing for easy customization. Since support calls are barriers to productivity for the software engineer and costly to support for the EDA vendor, platforms for software engineers should be web-accessible. In some cases, they may reside fully in the cloud. This completely automates user access and simplifies support, if necessary.

Will 2014 be the year that EDA companies begin to meet the needs of the software engineer or will they keep trying to sell them a wolf in sheep’s clothing? I think it will be the former because the opportunity’s too great. Developing tools to support software engineers is an obvious and welcome growth path for the EDA market.

Brett Cline – Forte

In the 19th century, prevailing opinion held that American settlers were destined to expand across North America. It was called Manifest Destiny.

In December 2014, we may look back on the previous 11 months and claim SystemC-Based Design Destiny. The Semiconductor industry is already starting to see more widespread adoption of SystemC-based design sweeping across the United States. In fact, it’s the fastest growing worldwide region right now. Along with it comes SystemC-based High-level synthesis, gaining traction with more designers because it allows them to perform power tradeoffs that are difficult if not impossible in RTL due to time constraints. Of course, low power continues to be a major driver for design and will be throughout 2014.

Another trend that will be even more apparent in 2014 is the use of abstracted IP. RTL-based IP is losing traction for system design and validation due to simulation speed and because it’s difficult to update, retarget and maintain. As a result, more small IP companies emerge with SystemC as the basis of their design instead of the long-used Verilog hardware design language.

SystemC-Based Design Destiny is for real in the U.S. and elsewhere as design teams struggle to contain the multitude of challenges in the time allotted.

Dr. Raik Brinkmann – OneSpin Solution

Over the last few years, given the increase in silicon cost and slowdown in process advancement, we have witnessed the move toward standardized SoC platforms, leveraging IP from many sources, together with powerful, multicore processors.

This has driven a number of verification trends. Verification is diversifying, where the testing of IP blocks is evolving separately to SoC integration analysis, a different methodology from virtual platform software validation. In 2014, we will see this diversification extend with more advanced IP verification, a formalization of integration testing, and mainstream use of virtual platforms.

With IP being transferred from varied sources, ensuring thorough verification is absolutely essential. Ensuring IP block functionality has always been critical. Recently, this requirement has taken on an additional dimension where the IP must be signed off before usage elsewhere and designers must rely on it without running their own verification. This is true for IP from separate groups within a company or alternative organizations. This sign-off process requires a predictable metric, which may only be produced through verification coverage technology.

We predict that 2014 will be the year of coverage-driven verification. Effective coverage measurement is becoming more essential and, conversely, more difficult. Verification complexity is increasing along three dimensions: design architecture, tool combination, and somewhat unwieldy standards, such as UVM. These all affect the ability to collect, collate, and display coverage detail.

Help is on the way. During 2014, we expect new coverage technology that will enable the production of meaningful metrics. Furthermore, we will see verification management technology and the use of coverage standards to pull together information that will mitigate verification risk and move the state of the art in verification toward a coverage-driven process.

As with many recent verification developments, coverage solutions can be improved through leveraging formal verification technology. Formal is at the heart of many prepackaged solutions as well as providing a powerful verification solution in its own right.

Much like 2009 for emulation, 2014 will be the year we remember when Formal Verification usage dramatically grew to occupy a major share of the overall verification process.

Formal is becoming pervasive in block and SoC verification, and can go further. Revenue for 2013 tells the story. OneSpin Solutions, for example, tripled its new bookings. Other vendors in the same market are also reporting an increase in revenue well above overall verification market growth.

Vigyan Singhal – Oski Technologies

The worldwide semiconductor industry may be putting on formal wear in 2014 as verification engineers more fully embrace a formal verification methodology. In particular, we’re seeing rapid adoption in Asia, from Korea and Japan to Taiwan and China. Companies there are experiencing the same challenges their counterparts in other areas of the globe have found: designs are getting more and more complex, and current verification methodologies can’t keep pace. SoC simulation and emulation, for example, are failing, causing project delays and missed bugs.

Formal verification, many project teams have determined, is the only way to improve block-level verification to reduce stressing out SoC verification. The reasons are varied. Because formal is exhaustive, it will catch all corner case bugs that are hard to find in simulation. If more blocks are verified and signed-off with formal, it means much better design quality.

At the subsystem and SoC level, verification only needs to be concerned with integration issues rather than design quality issues. An added benefit, all the work spent on building a block-level formal test environment can be reused for future design revisions.

We recently heard from a group of formal verification experts in the U.S. who have successfully implemented formal into their methodology and sign-off flow. Some are long-time formal users. Others are still learning what applications work best for their needs. All are outspoken advocates eager to see more widespread adoption. They’re doing model checking, equivalence checking and clock domain checking, among other applications.

They are not alone in their assessment about formal verification. Given its proven effectiveness, semiconductor companies are starting to build engineering teams with formal verification expertise to take advantage of its powerful capabilities and benefits. Building a formal team is not easy –– it takes time and dedication. The best way to learn is by applying formal in live projects where invested effort and results matter.

Several large companies in Asia have set up rigorous programs to build internal formal expertise. Our experience has shown that it takes three years of full-time formal usage to become what we call a “formal leader” (level 6). That is, an engineer who can define an overall verification strategy, lead formal verification projects and develop internal formal expertise. While 2014 will be the watershed year for the Asian market, we will see more formal users and experts in the years following, and more formal successes.

That’s not to say that adoption of formal doesn’t need some nudging. Education and training are important, as are champions willing to publicly promote the power of the formal technology. My company has a goal to do both. We sponsor the yearly Deep Bounds Award to recognize outstanding technological research achievement for solving the most useful End-to-End formal verification problems. The award is presented at the annual Hardware Model Checking Competition (HWMCC) affiliated with FMCAD (Formal Methods in Computer Aided Design).

While we may not see anyone dressed in top hat and tails at DAC in June 2014, some happy verification engineers may feel like kicking up their heels as Fred Astaire or Ginger Rogers would. That’s because they’re celebrating the completion of a chip project that taped out on time and within budget. And no bugs.

To paraphrase a familiar Fred Astaire quote, “Do it big, do it right and do it with formal.”

Bruce McGaughy – ProPlus Design Solutions

To allow the continuation of Moore’s Law, foundries have been forced to go with 3D FinFETs transistors, and along the way a funny thing has happened. Pushing planar devices into vertical structures has helped overcome fundamental device physics limitations, but physics has responded back by imposing different physical constraints, such as parasitics and greater gate-drain, gate-source coupling capacitances.

More complex transistor structures mean more complex SPICE models. The inability to effectively body-bias and the requirement to use quantized widths in these FinFET devices means that circuit designers have new challenges resulting in more complex designs. This, coupled with increased parasitic effects at advanced technology nodes, leads to post-layout netlist sizes that are getting larger.

All this gets the focus back on the transistor physics and the verification of transistor-level designs using SPICE simulation.

Above and beyond the complexity of the device and interconnect is the reality of process variation. While some forms of variation, such as random dopant fluctuation (RDF), may be reduced at FinFET nodes, variation caused by fin profile/geometry variability comes into play.

It is expected that threshold voltage mismatch and its standard deviation will increase. Additional complexity from layout-dependent effects requires extreme care during layout. With all these variation effects in the mix, there is one direct trend –– more need for post-layout simulation, the time for which gets longer as netlist sizes gets larger.

Pre-layout simulation just does not cut it.

Let’s step back and review where the 3D FinFet transistor has taken us. We have more complex device models, more complex circuits, larger netlists and a greater need for post-layout simulation.

Pretty scary in and of itself, though, the EDA industry has used a trick whenever confronted with capacity or complexity challenges. That is, trading-off accuracy to buy a little more capacity or performance. In the SPICE world, this trick is called FastSPICE.

Now, with 3D FinFETs, we are facing the end of the road for FastSPICE as an accurate simulation and verification tool, and it will be delegated to a more confined role as a functional verification tool. When the process technology starts dropping Vdd and devices have greater capacitive coupling, it results in greater noise sensitivity of the design. The ability to achieve accurate SPICE simulations under these conditions requires extreme care in controlling convergence of currents and charges. Alas, this breaks the back of FastSPICE.

In 2014, as FinFET designs get into production mode, expect the SPICE accuracy requirements and limitations of FastSPICE to cry out for attention. Accordingly, a giga-scale Parallel SPICE simulator called NanoSpice by ProPlus Design Solutions promises to address the problem. It provides a pure SPICE engine that can scale to the capacity and approach the speed of FastSPICE simulators with no loss of accuracy.

Experienced IC design teams will recognize both the potential and challenges of 3D FinFET technology and have the foresight to adopt advanced design methodologies and tools. As a result, the semiconductor industry will be ready to usher in the FinFET production ramp in 2014.

Dave Noble – Pulsic

Custom layout tools will occupy an increased percentage of design tool budgets as process nodes gets smaller and more complex. Although legacy (digital) tools are being “updated” to address FINFeT, they were designed for 65nm/90nm, so they are running out of steam. Reference flows have too many repetitive, time-consuming, and linear steps. We anticipate that new approaches will be introduced to enable highly optimized layout by new neural tools that can “think” for themselves and anticipate the required behavior (DRC-correct APR) given a set of inputs (such as DRC and process rules). New tools will be required that can generate layout, undertake all placement permutations, complete routing for each permutation AND ensure that it is DRC-correct – all in one iteration. Custom design will catch up with digital, custom layout tools will occupy an increase percentage of design tool budgets, and analog tools will have the new high-value specialized functions.

Accellera Systems Initiative Continues to Grow

Thursday, October 17th, 2013

By Gabe Moretti

The convergence of system, software and semiconductor design activities to meet the increasing challenges of creating complex system-on-chips (SoCs) has brought to the forefront the need for a single organization to create new EDA and IP standards.

As one of the founders of Accellera, and the one responsible for its name, it gives me great pleasure to see how the consortium has grown and widened its interests.  Through the mergers and acquisitions of the Open SystemC Initiative (OSCI), Virtual Sockets Interface Alliance (VSIA), The SPIRIT Consortium, and now assets of OCP-IP, Accellera is the leading standards organization that develops language-based standards used by system, semiconductor, IP and EDA companies.

As its original name implies, Accellera is Italian meaning accelerate, its activities target EDA tools and methods with the aim of fostering efficiency and portability.

Created to develop standards for design and verification languages and methods, Accellera has grown by merging or acquiring other consortia, expanding its role to Electronic System Level standards, and IP standards.  It now has forty one member companies from industries such as EDA, IP, semiconductors, and electronics systems.  As a result of its wider activities it even its name has grown and now is “Accellera Systems Initiative”.

In addition to the corporate members Accellera has formed three Users Communities, to educate engineers and increase the use of standards.  The Communities are: OCP, SystemC, and UVM.  The first one deals with IP standards and issues, the second supports the SystemC modeling and verification language, while the third one works on Unified Verification procedures.

Accellera has 17 active Technical Committees.  Their work to date has resulted in 7 IEEE standards.  Accellera sponsors a yearly conference DVCON held generally in February but also collaborates with engineering conferences in Europe and Japan.  With the growth of electronics activities in nations like India and China, Accellera is considering a more active presence in those countries as well.

Accellera Systems Initiative has taken over OCP-IP

Tuesday, October 15th, 2013

By Gabe Moretti

Accellera has been taking over multiple standards organization in the industry for several years and this is only the latest.  The acquisition includes the current OCP 3.0 standard and supporting infrastructure for reuse of IP blocks used in semiconductor design. OCP-IP and Accellera have been working closely together for many years, but OCP-IP lost corporate and member financial support steadily over the past five years and membership virtually flatlined. Combining the organizations may be the best way to continue  to address interoperability of IP design reuse and jumpstart adoption.

“Our acquisition of OCP assets benefits the worldwide electronic design community by leveraging our technical strengths in developing and delivering standards,” said Shishpal Rawat, Accellera Chair. “With its broad and diverse member base, OCP-IP will complement Accellera’s current portfolio and uniquely position us to further develop standards for the system-level design needs of the electronics industry.”

OCP-IP was originally started by Sonics, Inc. in December 2001 as a means to proliferate it’s network-on-chip approach.  Sonics CTO  Drew Wingard has been a primary driver of the organization.  It has long been perceived as the primary marketing tool of the company and it will be interesting to see how the company (which has been on and off the IPO trail several times since its founding) fairs without being the “big dog” in the discussion.

A comprehensive list of FAQs about the asset acquisition is available.

Results from the RF and Analog/Mixed-Signal (AMS) IC Survey

Wednesday, October 2nd, 2013

A summary of the results of a survey for developers of products in RF and analog/mixed-signal (AMS) ICs.

This summary details the results of a survey for developers of products in RF and analog/mixed-signal (AMS) ICs. A total of 129 designers responded to this survey. Survey questions focused on job area, company information, end-user application markets, product development types, programming languages, tool vendors, foundries, processes and other areas.

Key Findings

  • More respondents are using Cadence’s EDA tools for RFIC designs. In order, respondents also listed Agilent EESof, Mentor, Ansys/Ansoft, Rhode & Schwartz and Synopsys.
  • More respondents are using Cadence’s EDA tool for AMS IC design. Agilent EESof, Mentor, Aniritsu, Synopsys and Ansys/Ansoft were behind Cadence.
  • Respondents had the most expertise with C/C++. Regarding expertise with programming languages, C/C++ had the highest rating, followed in order by Verilog, Matlab-RF, Matlab-Simulink, Verilog-AMS, VHDL, SystemVerilog, VHDL-AMS and SystemC.
  • For RF design-simulation-verification tools, more respondents in order listed that they use Spice, Verilog, Verilog-AMS, VHDL and Matlab/RF-Simulink. For planned projects, more respondents in order listed SystemC, VHDL-AMS, SystemVerilog, C/C++ and Matlab/RF-Simulink.
  • Regarding the foundries used for RF and/or MMICs, most respondents in order listed TSMC, IBM, TowerJazz, GlobalFoundries, RFMD and UMC.
  • Silicon-based technology is predominately used for current RF/AMS designs. GaAs and SiGe are also widely used. But for future designs, GaAs will lose ground; GaN will see wider adoption.
  • RF and analog/mixed-signal ICs still use fewer transistors than their digital counterparts. Some 30% of respondents are developing designs of less than 1,000 transistors. Only 11% are doing designs of more than 1 million transistors.
  • Digital pre-distortion is still the favorite technique to improve the efficiency of a discrete power amp. Envelope tracking has received a lot of attention in the media. But surprisingly, envelope tracking ranks low in terms of priorities for power amp development.

Implications

  • Cadence continues to dominate the RFIC/AMS EDA environment. Virtuoso remains a favorite among designers. RF/AMS designers will continue to have other EDA tool choices as well.
  • The large foundries, namely TSMC and IBM, will continue to have a solid position in RF/AMS. But the specialty foundries will continue to make inroads. Altis, Dongbu, Magnachip, TowerJazz, Vanguard and others are expanding in various RF/AMS fronts.
  • There is room for new foundry players in RF/AMS. GlobalFoundries and Altis are finding new customers in RF, RF SOI and RF CMOS.
  • The traditional GaAs foundries—TriQuint, RFMD, Win Semi and others—are under pressure in certain segments. The power amp will remain a GaAs-based device, but other RF components are moving to RF SOI, SiGe and other processes.

Detailed Summary

  • Job Function Area-Part 1: A large percentage of respondents are involved in the development of RF and/or AMS ICs. More respondents are currently involved in the development of RF and/or AMS ICs (55%). A smaller percentage said they were involved in the last two years (13%). A significant portion are not are involved in the development of RF or AMS ICs (32%).
  • Job Function Area-Part 2: Respondents listed one or a combination of functions. More respondents listed analog/digital designer (30%), followed in order by engineering management (22%), corporate management (12%) and system architect (10%). The remaining respondents listed analog/digital verification, FPGA designer/verification, software, test, student, RF engineer, among others.
  • Company Information: Respondents listed one or a combination of industries. More respondents listed a university (23%), followed in order by systems integrator (18%), design services (14%), fabless semiconductor (13%) and semiconductor manufacturer (10%). The category “other” represented a significant group (13%). The remaining respondents work for companies involved in ASICs, ASSPs, FPGAs, software and IP.
  • Company Revenue (Annual): More respondents listed less than $25 million (27%), followed in order by $100 million to $999 million (24%) and $1 billion and above (22%). Others listed $25 million to $99 million (8%). Some 19% of respondents did not know.
  • Location: More respondents listed North America (60%), followed in order by Europe (21%) and Asia-Pacific (10%). Other respondents listed Africa, China, Japan, Middle East and South America.
  • Primary End-User Application for Respondent’s ASIC/ASSP/SoC design: More respondents listed communications (67%), followed in order by industrial (28%), consumer/multimedia (24%), computer (21%), medical (15%) and automotive (12%).
  • Primary End Market for Respondent’s Design. For wired communications, more respondents listed networking (80%), followed by backhaul (20%). For wireless communications, more respondents listed handsets (32%) and basestations (32%), followed in order by networking, backhaul, metro area networks and telephony/VoIP.
  • Primary End Market If Design Is Targeted for Consumer Segment. More respondents listed smartphones (34%), followed in order by tablets (24%), displays (18%), video (13%) and audio (11%).

Programming Languages Used With RF/AMS Design Tools:

  • Respondents had the most expertise with C and C++. Regarding expertise with programming languages, C/C++ had an overall rating of 2.47 in the survey, followed by in order by Verilog (2.32), Matlab-RF (2.27), Matlab-Simulink (2.17), Verilog-AMS (2.03), VHDL (1.99), SystemVerilog (1.84), VHDL-AMS (1.70) and SystemC (1.68).
  • Respondents said they had “professional expertise” (19%) with C/C++. Respondents were “competent” (27%) or were “somewhat experienced” (37%) with C/C++. Some 17% said they had “no experience” with C/C++.
  • Respondents said they had “professional expertise” with Verilog-AMS. (13%). Respondents were “competent” (15%) and “somewhat experienced” (35%) with Verilog-AMS. Some 38% said they had “no experience” with Verilog-AMS.
  • Respondents said they had “professional expertise” with Verilog (12%), or were “competent” (30%) or were “somewhat experienced” (36%). Some 22% said they had “no experience” with Verilog.
  • Respondents said they had “professional expertise” with Matlab-RF (10%), or were “competent” (27%) or “somewhat experienced” (42%). Some 21% said they had “no experience” with the technology.
  • Respondents also had “professional experience” with VHDL (10%), SystemVerilog (9%), SystemC (7%), Matlab-Simulink (6%) and VHDL-AMS (3%).
  • Respondents had ‘’no experience” with SystemC (55%), VHDL-AMS (51%), SystemVerilog (49%), Verilog-AMS (38%), VHDL (36%), Matlab-Simulink (26%), Verilog (22%), Matlab-RF (21%) and C/C++ (17%).

Types of Programming Languages and RF Design-Simulation-Verification Tools Used

  • For current projects, more respondents listed Spice (85%), Verilog (85%), Verilog-AMS (79%), VHDL (76%), Matlab/RF-Simulink (71%), C/C++ (64%), SystemVerilog (56%), VHDL-AMS (44%) and SystemC (21%).
  • For planned projects, more respondents listed SystemC (79%), VHDL-AMS (56%), SystemVerilog (44%), C/C++ (36%), Matlab/RF-Simulink (29%), VHDL (24%), Verilog-AMS (21%), Verilog (15%) and Spice (15%).

Which Tool Vendors Are Used in RFIC Development

  • More respondents listed Cadence (60), followed in order by Agilent EESof (43), Mentor (38), Ansys/Ansoft (29), Rhode & Schwartz (26) and Synopsys (25). Others listed were Aniritsu, AWR, Berkeley Design, CST, Dolphin, EMSS, Helic, Hittite, Remcon, Silvaco, Sonnet and Tanner.
  • The respondents for Cadence primarily use the company’s tools for RF design (68%), simulation (73%), layout (67%) and verification (43%). The company’s tools were also used for EM analysis (27%) and test (22%).
  • The respondents for Agilent EESof primarily use the company’s tools for RF design (54%) and simulation (65%). The company’s tools were also used for EM analysis, layout, verification and test.
  • The respondents for Mentor Graphics primarily use the company’s tools for verification (55%), layout (37%) and design (34%). Meanwhile, the respondents for Rhode & Schwartz primarily use the company’s tools for test (69%). The respondents for Synopsys primarily use the company’s tools for design (40%), simulation (60%) and verification (48%).

Which Tool Vendors Are Used in AMS IC Development

  • More respondents listed Cadence (48), followed in order by Agilent EESof (26), Mentor (22), Aniritsu (19), Synopsys (18) and Ansys/Ansoft (15). Others listed were AWR, Berkeley Design, CST, Dolphin, EMSS, Helic, Hittite, Remcon, Rohde & Schwarz, Silvaco, Sonnet and Tanner.
  • The respondents for Cadence primarily use the company’s tools for AMS design (79%), simulation (71%), layout (71%) and verification (48%). The company’s tools were also used for EM analysis and test.
  • The respondents for Agilent EESof primarily use the company’s tools for design (42%), simulation (69%) and EM analysis (54%).
  • The respondents for Mentor Graphics primarily use the company’s tools for design (50%), simulation (46%) and verification (55%). The respondents for Aniritsu primarily use the company’s tools for test (47%). The respondents for Synopsys primarily use the company’s tools for design (61%) and simulation (67%).

Areas of Improvement for Verification and Methodologies

  • Respondents had a mix of comments.

Foundry and Processes

  • Foundry Used for RFICs and/or MMICs: More respondents listed TSMC (32), followed in order by IBM (27), TowerJazz (19), GlobalFoundries (17), RFMD (13) and UMC (13). The next group was Win Semi (12), ST (11), TriQuint (11) and GCS (10). Other respondents listed Altis, Cree, IHP, LFoundry, OMMIC, SMIC, UMS and XFab.
  • Of the respondents for TSMC, 87% use TSMC for RF foundry work and 55% for MMICs. Of the respondents for IBM, 81% use IBM for RF foundry work and 41% for MMICs. Of the respondents for TowerJazz, 84% use TowerJazz for RF foundry work and 42% for MMICs. Of the respondents for GlobalFoundries, 76% use GF for RF foundry work and 41% for MMICs.
  • Complexity of Respondent’s Designs (Transistor Count): More respondents listed less than 1,000 transistors (30%), followed in order by 10,000-99,000 transistors (14%) and 100,000-999,000 transistors (14%). Respondents also listed 1,000-4,900 transistors (11%), greater than 1 million transistors (11%) and 5,000-9,900 transistors (10%).
  • Process Technology Types: For current designs, more respondents listed silicon (66%), followed in order by GaAs (32%), SiGe (27%), GaN (23%) and InP (10%). For future designs, more respondents listed silicon (66%), followed in order by SiGe (31%), GaN (28%), GaAs (16%) and InP (13%).

Technology Selections:

  • Which Baseband Processor Does Design Interface With: More respondents listed TI (35%), ADI (22%) and Tensilica/Cadence (18%). Respondents also list other (26%).
  • Technique Used To Improve Discrete Power Amplifier Efficiency: In terms of priorities, more respondents listed digital pre-distortion (38%), followed in order by linearization (27%), envelop tracking (14%) and crest factor reduction (10%). In terms of priorities, the technique that showed the lowest ranking was envelop tracking (37%), crest factor reduction (21%) and linearization (14%).

Test and Measurement

  • Importance of Test and Measurement: More respondents listed very important (34%), followed in order by important (24%), extremely important (20%), somewhat important (19%) and unimportant (3%).

lapedus_markMark LaPedus has covered the semiconductor industry since 1986, including five years in Asia when he was based in Taiwan. He has held senior editorial positions at Electronic News, EBN and Silicon Strategies. In Asia, he was a contributing writer for Byte Magazine. Most recently, he worked as the semiconductor editor at EE Times.

Interface Additions To The e Language For Effective Communication With SystemC TLM 2.0 Models

Thursday, August 23rd, 2012

The last several years have seen strong adoption of transaction-level models using SystemC TLM 2.0. Those models are used for software validation and virtual prototyping. For functional verification, TLMs have a number of advantages—they are available earlier, they allow usersto divide their focus on verifying functionality and protocol/timing details, they enable higher level reuse, and they can be used as reference models in advanced verification environments. Leveraging these benefits requires a convenient and seamless interface to TLM 2.0. New additions to e in the Cadence Specman technology portfolio enable verification engineers to communicate efficiently with SystemC models that have TLM 2.0 interfaces.

To read more, click here.