The Downside Of Derivatives

By Ann Steffora Mutschler
From a planning perspective, creating derivative chips seems a straightforward task, but the process is much more complex than simply replacing or adding a peripheral—it starts with identifying the right team of engineers to perform that process.

“One of the needs in the market is somebody to have vertical expertise to do derivative design and yet be cost-effective,” observed Naveed Sherwani, co-founder, president and CEO of Open-Silicon. “Then, depending upon the vertical markets, you need to have many, many such derivative teams. A derivative team that can do router designs and switch fabric kinds of designs is not the one that can do a home gateway and is not the one that can do a WiFi chip and not the one which can do something else. You can pick your number—you can call it 15 or 30 verticals—and while there is some commonality between them, the front end of this may not be as common,”

As such, derivative teams must be very good at looking at somebody else’s design and making changes to that design. Specifically, the derivative team must be able to quickly pick up the architecture of the chip and understand the changes requested.

“Sometimes people say it is a derivative, but really it’s a brand new chip,” he pointed out. “Other times it is a true derivative—one that does not touch or alter the architecture of the chip in any significant way, does not change the data flow of the chip in any significant way, and which also doesn’t require you to re-time the whole circuit. As long as it is removing some IP, changing the number of ports, adding some functionality, that doesn’t change the architecture and the dataflow of the chip. Those are true derivatives.”

Another challenge that derivative teams face concerns how much data knowledge can be captured from the original team and how much of the original team is available to consult with the derivative team. In some cases the original team is very accessible, which makes it much easier. In other cases it is not.

“If the design team doing the derivative wasn’t involved in the original design, they do not necessarily understand the details of the formula that made that chip work (the so-called recipe),” said Mike Gianfagna, vice president of marketing at Atrenta. “That includes things like difficult-to-route areas, timing constraints, false paths, and placement restrictions for performance-sensitive digital blocks or analog modules. So you need a solid methodology for the original design that contemplates the outsourcing of the derivative. If you approach it that way, you can capture all the implementation recipe details as meta-data for the design which can then be part of the handoff. Capturing this meta data starts at the architectural level. This approach helps a lot.”

Further, truly understanding market needs and demands is critical. Drew Wingard, CTO of Sonics, said he has observed lots of people struggling to understanding that some of the interesting markets for SoCs—mobile phones, TVs, set-top boxes, tablets, automotive infotainment and telematics—change really fast. “So the idea that you’ve got the right smarts in your platform so that you can cover a couple of years’ worth of derivatives without changing any of your base assumptions has gotten increasingly difficult.”

Also, he noted that it is not uncommon to see a proposed derivative program get canceled in the first couple months. Once it gets to a certain critical mass, it seems more likely that it will continue through to the end. “We do see a lot of derivative-oriented design starts pop up and get started, and either the targeted end customer goes away or the speed with which the team is able to roll onto this derivative from that other program, which would have been the platform design or one of their other derivatives—happens a little too late. Suddenly that market window looks like it’s not as wide open as it was before.”

There may even be a loss of competitive capability when doing derivatives. Atrenta’s Gianfagna noted that doing a design from scratch will always yield the best fit for a given set of product requirements. Using the derivative approach will necessarily involve compromises, but as software becomes a larger and larger part of the system’s value, this downside decreases, he concluded.