The good? The bad? The ugly? IP Perspectives from Vendor to SOC Designer
Massimo Vanzi, CEO, Accent
Navraj Nandra, Director Product Marketing, Mixed-Signal IP, Synopsys
Abstract :
While the IP landscape will always look different when seen through the eyes of SOC designers, integrators and IP vendors, these players gain a significant advantage if they see each others’ roles more clearly. This article explores the perspectives of three such players and their different ways of working with IP with an eye to making life with IP easier for everyone.
The good, the bad, the view of the SoC design firm
From the point of view of an SoC designer, it is fair to say that as chips incorporate more and more IP, IP providers who have big menu lists with many different types of IP are going to become more important. An SoC design company such as Matrox Graphics buys a lot of IP that is non-graphics IP. For example, the company purchases many I/O interfaces, PLLs, and DACs from outside. By focusing on the internal design, Matrox can offer value-added products.
On the other hand, Matrox also sells IP. In the past few years, the company’s IP business has been growing because customers want the Matrox Metagraphic cores and many other types of IP. Importantly, Matrox sees that this demand depends upon more than having a unique type of core. Another key is providing a highly functional product. In addition to providing firmware with the core, Matrox offers a wide range of software for compatibility. The company has the expertise to develop graphics drivers that work in twenty different operating systems—a highly valuable benefit for customers.
Going forward, this level of complex IP is likely to become increasingly desirable. As a result, an IP provider has to have a broad expertise to make the IP work the way customers want. That requirement makes it difficult for smaller players to enter the market. Vendors with big resources must be the IP providers.
Who are you calling ugly?—The view of the SoC integrator
If the rugged IP landscape is seen as the set for The Good, the Bad and The Ugly, SoC integrators sometimes feel like they have the ugly role of cleaning up the dirty work left by others. To meet the requirements of customers, integrators must deal with issues relating to the technology provided by the foundries and by IP providers. So it is fundamentally important for an integrator’s success to select IP of good quality. Otherwise, the cost of integration—the engineering time—would be huge. As a result, integrators constantly search for high-quality IP and good integration between IP and fabrication technology.
Further complicating this situation is the need to mix and match IP from different companies. This requirement raises issues of interoperability, as well as issues such as I/O ring connections, especially for analog IP.
Figure 1. Integrating an analog system on a chip
Because of these issues, an SoC integrator such as Accent feels a strong need for a good verification environment that is IP independent. With a validated software environment containing the IP used in previous projects, Accent can plug new IP into the verification environment and make sure it works with all the other IP. With customers always asking for new IP, this process is a never-ending story—again, primarily with analog IP. With digital IP, integrators can organize and handle the integration process reasonably well, using a verification environment based on standard bus connections, etc. For analog IP, the process can be potentially ugly.
Cleaning up the landscape, and the role of IP vendors
IP providers try to make this world less ugly by emphasizing quality. Quality, or “Total Quality” as described by Synopsys falls into three areas: functional correctness; ease of integration and usability; and support. In terms of a hardened macro, test chips need to be fully characterized. For standards-based protocols such as USB, PCI Express, serial ATA, and high-speed memory interfaces like DDR, electrical specifications are defined by compliance bodies, and IP vendors clearly have to meet those requirements. Going to interoperability and plug-fests is a good idea for supporting those requirements.
Another key perspective from the IP vendor’s side is to consider what SoC integrators expect in terms of IP use. The situation involves a complex piece of IP, a complex chip, and integration challenges such as a mixed-signal I/O ring. Another complexity is the need to ensure that ESD requirements are met, and these requirements differ depending on whether the chip has purely digital or mixed-signal outputs.
In such a complex situation with multiple parties, the responsibilities are not always completely clear. Is it the IP vendor’s responsibility to make sure that the end customer’s chip works? Or is it the integrator’s job? Given these uncertain boundaries, what can IP vendors do to make SoC design and integration easier?
Figure 2 Total quality
Certainly, the design views are getting more complicated. At one point, chip developers purchased stand-alone hard IP such as DACs and I/O buffers. Now people are buying high-speed SerDes interfaces, and that IP should come with the digital MAC such as an end-point (EP) controller. In the case of PCI Express, the IP includes a pipe interface or elastic buffer tied to the SerDes. Because the I/O works at such high speed, integrators do not want to interface to a black-box IP core with an ACE expander type of design, where sign-off is done at the Primetime level.
Verification has also become more complex because simple IP models are no longer enough. Now IP must also have a behavioral model that works well in high-level simulation as well as the rest of the verification environment. Designers need models for different types of tools and perhaps an assertion library to make sure that interface protocols are met and so on.
How much faith can integrators have that a behavioral Verilog model matches the actual implementation? Providers have to verify the steps they took to validate that match. Most providers are still rather primitive in the ways they do that, so IP use requires a lot of validation.
When things go bad
Because it can be difficult to trace responsibility for a chip not fully working, integration can seem like ugly work. Certainly in the end, the customer sees the SoC integrator as being responsible for everything. Integrators must deliver high quality and first-time silicon success. Whenever this does not happen, the integrator looks like the responsible party.
In principal, however, an integrator may be the last party who should be considered liable for problems. Often the problem relates to issues with the IP specification. Of course, no IP provider can think of all the possible ways in which each piece of IP might be used. Integrating IP with other IP creates corners or situations that the IP providers did not envisage.
One thing IP providers should be able to envisage is that IP users will need complete design views. In some cases, however, IP comes with only a short data sheet and a GDS description.
Beat the spec
The idea of beating the “local specs” of the IP can help integrators meet the SoC’s global spec. A protocol such as PCI Express has rigid electrical specifications defined by the PCI Express SIG. An IP vendor may aim to meet that specification, but when that IP is in an SOC, other factors could interfere with the way the IP works. The IP could be residing in a quiet, well-isolated part of the chip, or it could be next to high-speed I/O drivers. If the latter is the case, users may not see exactly the signal specified by the spec.
Figure 3 On-die Scope Example
To help avoid this problem, IP providers can allow some visibility into the PCI Express performance through on-chip diagnostics. It is also important to test the IP in worst-case environments through test chips. So the provider can put noise generators close to the IP on the test chip to create substrate currents and noise in the supplies. With the diagnostic capabilities, it is possible to look at the IP’s performance in this noisy SOC environment. For example, the vendor can pull out an eye diagram on the receiver of a XAUI or a PCI Express PHY and know exactly what is going on in the SOC.
This trend toward enhanced visibility and testing will grow because the IP is getting more complex and IP customers are requesting help with testing mixed-signal blocks in chips that are predominantly digital. These customers may not be eager to make heavy investments in mixed-signal production test equipment because they have bought a certain type of mixed-signal IP. Rather, the IP needs to provide support for easier testing in production and provide visibility into signal quality inside the IP. This visibility helps integrators address the global spec of the SOC and also helps the IP provider show that the IP is performing as promised.
A good example of visibility into IP is a XAUI core running at 3.125 gigabits per second that a customer integrated into a complex switch SoC
that included a large number of lanes. The chip was designed into the backplane of telecom equipment in a mezzanine-type configuration. The backplane setup was quite complex, so it was difficult to get an oscilloscope probe close to the receiver.
Fortunately, the IP included an oscilloscope function that enabled the end customer to look at the eye diagram from one of the XAUI channels. Unfortunately, the customer was shocked to see an eye that looked terrible! Naturally, the customer blamed the chip supplier for the poor performance. The chip supplier blamed the IP provider. Everyone was playing the finger-pointing game.
Everyone agreed that the eye diagram looked terrible, but the IP provider also noticed that one of the gain settings on the IP was not set correctly. When the customer changed the setting to the right level and looked at the eye diagram again, the IP was performing the way it was supposed to. By providing visibility to a complex piece of IP in a complex chip, the IP provider saved everyone a lot of grief.
Should IP providers fear that someone can look into the IP and see how well—or how not so well— the IP is performing? Certainly, Synopsys feels that the benefits far outweigh the risks, so customers should get full visibility into the IP’s performance.
The good, bad and ugly of smaller geometries
Another IP trend that affects the interaction of IP players is the aggressive push to smaller technology nodes. IP vendors have to scramble to make IP available to support the roadmap of the fabs. With the smaller features sizes comes a reduction in supply voltages and metal stack-ups that allow the use of different thicknesses of metal layers in chips. These changes are quite useful to chip designers and integrators.
From an IP vendor’s perspective, these opportunities are challenging. It used to be enough to offer IP targeted for one technology node, with variances for lower power and higher performance. Now vendors must consider that a particular technology has 1.8V, 3.5V, and 3.3V devices. When designing the IP, which voltage should they use? Vendors must also consider seven variations of metal thicknesses. Which ones do they use for the IP?
The list of options is long: Do customers want triple-nwell? Do customers want salicided blocks? Do customers want dual or triple oxide? Some customers want PCI Express with a core oxide and a 2.5V oxide for decoupling capacitors to reduce power. Other customers want dual oxide, but they have I/Os for DDR3-type memory that require 1.8V.
If IP providers go back and redesign IP for these features, can the IP provider charge a corresponding fee to customers? Nobody wants to pay that extra money, yet IP vendors are in the position of having to predict which I/O voltages and other features customers will be using.
Same shootout, different viewpoint
IP users face the same challenges as IP providers. An SoC design firm might look at the market and decide that the next five SoCs will include certain IP, some of which will be bought. Then the firm proves-out the IP’s value on the first SoC and wants to keep reusing that IP for the next four designs. But to do that, the firm has to begin the whole sequence of designs by looking at the available and upcoming process nodes and deciding what options will be useful—voltages, metal stack-up and so on. Changing the IP to take advantage of process tweaks means that the IP must be re-qualified, which increases risk.
These tradeoffs are becoming more difficult. Going to the 65 nanometer node, designers can no longer get a dual oxide, yet they cannot drop compatibility with external devices. Most external expansion devices work only at 2.5V or even 3.3V. In a common graphic specification, for example, channels are available that allow the monitor to tell the graphics card how to set itself up. That requires 3.3V signaling with 5V tolerance in some cases on the analog side.
Since the smaller technology nodes do not provide that type of tolerance, design firms have to make compromises, do much more board-level work, and actually reduce the amount of integration. In some cases, that is the only way to solve the problem. Otherwise, firms can limit this challenge by focusing on customers that do not need to use the latest and most advanced technologies—not necessarily a good strategy, but maybe not so bad, and far from ugly.
Good prevails
As for the various inhabitants of the IP landscape, it is clear that all the players meet the same challenges even if different players deal with those challenges in different ways. Even if every player tries to make good choices in dealing with those challenges, the tradeoffs they make will not suit everyone else equally well. By offering IP performance that beats standard specifications and providing visibility into that performance, IP providers can help make the tradeoffs easier. So everyone in the IP world can be good.
|
Synopsys, Inc. Hot IP
Related Articles
New Articles
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
- Synthesis Methodology & Netlist Qualification
- Streamlining SoC Design with IDS-Integrate™
E-mail This Article | Printer-Friendly Page |