TECHNOLOGY IN CONTEXT
The Changing Role of the ASIC and the SoC
The Changing Nature of the ASIC
As designs become more compact and power consumption becomes an ever more important issue, the need to address these demands with single-chip ASICs grows. To meet these demands, however, the nature of the ASIC needs to change.
ALAN A. VARGHESE AND MICHAEL B. DOERR, COHERENT LOGIX
Page 1 of 1
Is the ASIC dead? Not if you consider that ASICs comprised a $20 billion market in 2010. And industry analyst company Semico Research projects that total ASIC design starts will grow at a healthy CAGR of 7.6 percent from 2010-2014. Regardless, the question is valid for many reasons.
The cost of ASIC development in the latest generation of semiconductor technology can run into tens of millions of dollars. The mask set and wafers are a small portion of this cost; the major portion comes from architecture definition, design, verification, and layout. To get a return on such a large investment, market volumes need to be very high.
As shown in Figure 1, the development costs to spin an ASIC in the 45 nm node can amount to more than $40 million. If we consider research and development costs to be 20 percent of revenue, then revenue target needs to be in the range of $200 million. And at a device ASP of say, $20, that would mean a volume requirement in excess of 10 million units to justify the cost of investment.
A comparison of the development costs versus unit volume and revenues needed to justify an ASIC design.
If there is a mistake in the ASIC specification or design, these costs will have to be revisited. And industry surveys show that only about one-third of ASIC designs are bug-free at first silicon.
Thus today, OEMs are cost-challenged and hesitant to spin their own ASIC. Instead, an IDM or semiconductor company collects requirements from various markets and customers, and then designs an ASIC based on a “sweet spot” of requirements. This generates high end volumes that will justify the costs of chip development. The problem with this kind of approach is that the OEM’s time-to-market is dependent on the IDM’s product strategy and timeline. To make matters worse, the competition may have access to the chip at the same time, and it may be hard to differentiate in the marketplace.
Another challenge with ASIC design is that it can take as long as 12-18 months from design concept to engineering samples. Unfortunately, market windows for new products, especially in consumer electronics, could be just a few months, and failing to have a product at the start may result in significantly reduced revenues. With fast changing market requirements and industry standards, it is challenging to predict all of the functions and features that are required at time of product launch. For example, the mobile wireless industry is currently transitioning from third generation technologies to what is termed as 4G. But 4G comprises a sequence of standards such as Release 8.0, 8.4, 8.6, 9.0 and so on. When designing an ASIC that will be out in only 12 months, which release features should the ASIC include? The mistake of leaving out a product feature in the ASIC can result in missed customer opportunities.
In addition, ASIC design requires specialized skills such as programming in Register Transfer Level (RTL), which is again a challenge. Though signal processing has infiltrated many areas of engineering and product design, not many people know how to program in low-level code such as RTL.
Are FPGAs or General-Purpose Signal Processors the Solution?
FPGAs and general-purpose signal processors do mitigate some of the negatives of ASICs. But as systems become handheld and more mobile, power consumption is a critical constraint, and both of these architectures typically consume high power. In addition, the per-unit costs for FPGAs and general purpose processors are too high for high-volume markets.
Some FPGA vendors offer the ability to “harden” their solution eventually into an ASIC. Though this option offers some advantages, it still results in a device that is larger and more power-hungry than a custom designed ASIC, due to the underlying FPGA fabric in the design. And it does not eliminate the need to program in hardware design language. The bulk of engineering effort in ASIC/FPGA design is in place-and-route and meeting timing convergence, which can consume months of engineering effort.
More recent products available in the marketplace such as structured ASICs allow customization through programmable metal layers. These compare favorably to FPGAs in terms of unit costs, but do not have the capacity, performance and power consumption metrics of a custom ASIC solution.
The Holy Grail in Terms of a Signal Processing Platform?
The Holy Grail would be a reconfigurable platform on which to quickly test out product concepts, ideas and algorithms. The processor should be programmable in a high-level language. Such a platform would give the software team actual hardware to test on, instead of simulation (usually too slow) or hardware-emulation. The design would be tested on actual production hardware at-speed.
Reconfigurability would allow for changing market and customer requirements; making changes that would be prohibitive in an ASIC. And it would be relatively easy on the reconfigurable processor. The risk of an engineering change request (CR) impacting time-to-market (TTM) is considerably reduced.
Also required is high-performance. Signal processing requirements continue to increase in step with Moore’s Law, so it is good to have multi- or many-core type of processor performance. And if additional signal processing power is required in the future, the platform should allow seamless extension of the underlying architecture and programming model.
The most important requirement is to be able to go to market on the same development platform. And if end-market demand and volumes take off, there needs to be an ability to convert the reconfigurable design to a custom ASIC to reduce cost and get the highest performance and lowest power consumption. This conversion should be relatively easy and not require writing any RTL code, due to reasons previously mentioned.
Since it’s hard to predict how markets will ramp, this type of approach defers any high costs of chip development and production until end-demand is clearly known.
Software First, Hardware Last Design Methodology
The traditional industry approach was to choose specific hardware, and then develop software on that platform. But what we need is a new methodology by which software and applications are first developed independent of hardware implementation, and independent of software/hardware co-design issues.
Functional correctness needs to be the initial objective; cost, power-consumption and other implementation details are relegated to a subsequent step. The software is written in a high-level and well-known language such as C. This allows considerable productivity increases in comparison to RTL coding since there is no need for logic synthesis, place and route, and the timing closure required in ASIC/FPGA design.
The software is the “golden” reference code as well as the final product, and thus the software investment is preserved from prototype to production. Compare this with the typical methodology of first implementing a C or Matlab model of the algorithms, then manually converting that to RTL code, and finally having to make sure the RTL is bit-exact with the golden reference model.
Execution is performed in real-time and the debug cycle is fast, in the order of minutes rather than weeks and months. All this translates to fast time-to-market and time-to-revenue. The other advantage is that software written in high-level language is much more portable. Thus the OEM is not tied to any chip supplier, but can have a multi-source strategy right from project inception.
The most important advantage of this methodology is that since hardware comes last, hardware is matched perfectly to the different stages of the product life-cycle; and performance, power-consumption and cost are designed exactly to market and customer requirements.
What Would the Design Flow Look Like?
The design flows would differ depending on the type of market being addressed. Figure 2 shows the design flow and the different stages for a low-volume emerging market.
Design flow for a low-volume emerging market using reconfigurable hardware.
At the prototype stage, the engineer starts from the product specifications or market requirements and writes software in high-level language. This software can be immediately compiled and run on the reconfigurable processor.
When market conditions are right, the product can be shipped exactly as-is for customer trials and initial deployments. There is no new silicon involved, and the product is “right enough” for the application. Specification changes, software bugs and CRs derived from the field-trials can be addressed and incorporated. Finally in the volume production stage, software can be added that enhances product functions and feature-set and competitive differentiation.
Figure 3 shows the design flow stages for a high-volume and mature market. The major difference here is that in the volume production stage, the reconfigurable chip can be converted to a custom ASIC/ SoC (system-on-chip) for best form-fit, cost and power consumption.
Design flow for a high-volume and mature market using reconfigurable hardware and eventual conversion to a full ASIC.
During this stage, unused communications links in the chip architecture are removed, and critical links are hard-wired for best performance. Memory size and organization are matched to the exact application and market profile. The I/O is optimized to reduce pincount and package size, and the drivers are matched for exact loading. The processor core is synthesized and hard-wired for ideal performance. Also, additional IP cores may be integrated such as microcontrollers, embedded DRAM, and analog functions. This process results in a custom floor-plan or metal layer programmable ASIC.
It is important to note that, a portion of the processor can be preserved to stay programmable; thus with this method all the advantages of an ASIC are retained, with the added benefit of re-configurability.
A technology from Coherent Logix called HyperX comes very close to the Holy Grail definition of signal processing platforms. The architecture combines value added characteristics such as re-configurability, performance, programming ease and time-to-market into a single software and hardware platform capable of spanning commercial, industrial and defense applications. In addition, the technology offers the following benefits:
• Balanced communication and computation capabilities
• High cost efficiency
• System of systems on a single chip
• Power-aware management resulting in 10-fold improvement over current state-of-the-art reconfigurable processors
• High productivity algorithm-to-hardware development environment
• Lifetime field upgrades
• Scalable to address performance versus cost in the marketplace
• Clear path to custom ASIC solution
The software first, hardware last design methodology employing Coherent Logix’s HyperX technology is shown pictorially in Figure 4.
Design methodology used with HyperX.
Are there any negatives with the kind of design approach we have outlined here? If an OEM has many man-years of code developed in RTL, then it may be difficult to discard that legacy code-base and start from scratch in a high-level language. And in certain mature markets where industry requirements are static and end-volumes are well-known and significant, it may make sense to go directly to ASIC development.
But for the majority of markets in signal processing, the existing industry paradigm needs to change. What we need is a model in which innovative ideas can be rapidly implemented on a flexible, programmable platform and taken to market. And if the market and end-demand are high, the option exists to convert the design into the most cost-effective, power-optimum, and custom solution. A reconfigurable general-purpose processor that can also morph into a reconfigurable ASIC will enable a new breed of innovation in signal processing.