Derivative Designs Demand Discipline

By Ann Steffora Mutschler
By and large most designs today are derivatives, meaning they don’t start from a blank slate. And while that gives engineering teams a starting point, it also can make adding new IP blocks or changes to the design problematic, with the potential for increased routing and timing issues along with considerable pain to back-end engineers and delays in chip schedules.

Derivatives can be split into a number of categories, depending on the market or the evolution of technology at any point in time.

“Let’s say in a chip there is a certain amount of embedded memory and they want to remove it,” said Kalar Rajendiran, senior director of marketing at eSilicon. “Maybe the memory block they had was not efficiently implemented and it was taking too much space, so they only put in 1 megabyte. They release a product and then they may say they want to do a derivative product to increase memory capacity to run more programs. That’s a simple change conceptually–add more memory to it–and you would call that a derivative design because it is slightly different from the previous one.”

Other types of derivatives can involve changing the interface or functionality, regional adjustments to support different temperature conditions, or variants in terms of geography that would support differences in TV broadcast compliance, for example.

Neil Hand, group director of marketing for Cadence’s SoC realization group, observed that the definition of a derivative design has fundamentally shifted over the last couple of years. In the past, an engineering team could sit down, design a chip and develop five derivatives of it for each different market by swapping out the IP blocks and tweaking the system for each of those markets.

“That definition of derivative is dead because you can’t afford to do it,” Hand said. “If you look at how people approach it today, they use more of a platform. They put all of the IP they need for all the different applications on the design and then they’ll package it appropriately, depending on the target market, or will turn things on and off in software or hardware in order to make it fit that application. A good example of that is if you look at what Apple does with the A4 and the A5. It’s one design that targets multiple devices, whereas in the past that would have been multiple different chips.”

The stakes get higher along with Moore’s Law, too.

“With 40 and 28nm nodes, these are getting to be quite expensive from an SoC development perspective,” said Navraj Nandra, senior director of marketing for DesignWare Analog and MSIP at Synopsys. “What we are seeing at 28nm especially with our customers is they are developing an SoC but you can almost consider it an application platform and it is designed for a couple of market segments. The two big ones are smart phones and tablets.”

The methodology from an SoC perspective and the IP requirements to address those applications are similar but not exactly the same. “In order to ship the products out quickly to market and because the typical development cost of a 28nm SoC is at least $100 million now, if you want to get one of these chips out to market you’re going to have to invest at least $100 million—and that’s just on the SoC side. You’ve got way more costs on developing the software on top of that. So the expenditure is significant,” he continued.

Power consumption is often addressed in derivative designs. When the initial excitement about a product has gone away, customers want more battery life. Derivatives can focus on reducing power consumption, which in turn can have an effect on how you put your SoC design methodology together and how you develop the IP, Nandra said.

A recent customer visit illustrated this perfectly. “I was in Korea a couple of weeks ago and met with a company that develops TVs. I met the design team, and this particular design team develops the chipsets for the high-end TVs. Their SoC had all the latest IP requirements. The technology was designed with a very fast data path to do a lot of number crunching. This team now is looking at getting into the low-cost digital TV market, so they want to build a derivative chip that needs to have similar functionality to the high-end chip but that needs to be cheaper,” he added.

Managing complexity
As design platforms get bigger, and engineering teams must dealing with more IP blocks, the story really becomes about how to manage these huge IP platforms talking to each other, said Cadence’s Hand. “In the old days it was one monolithic design—easy to manage, no real problems, and it was a relatively small die. Then you got to the first realm of where we are today where you had tens of IP blocks and you could use relatively simple interconnects and the dies were relatively small. Now you look at the modern designs and every thing about them has become big.”

As a result, a holistic view must be taken of what it means to throw these connections together. “You can’t do necessarily what’s easiest for the system guys to the exclusion of the IP and the silicon. You can’t just do what makes the silicon guys happy because that may mess up your system performance. And you have to have that holistic view of cross all the realizations: silicon, SoC and system,” Hand added.

One of the most important considerations of starting with a baseline product with the intention to expand it in the future is time to market. Getting the chip out there, winning sockets and getting it into the customer’s hands so they can start working with it is critical.

“In some cases you can imagine going into a program development and at the beginning having very good intentions about designing in features, designing in configurability, parameterization, things like that to enable those future expansions to happen,” said Mike Berry, senior director of engineering at Open-Silicon. “But sometimes you can end up making tradeoffs as you go through the design flow. You may be losing some of that or not making it quite as robust as was originally envisioned by the product marketing guys or the architects of the program. Then, when you go to do that next version there could be some things you have to deal with, some warts that may, if they had been implemented in a slightly different way, have made the expansion a little bit easier. So you might have to go back and do some rework, either within the RTL or within the test environment to effectively roll in those new features.”

Sometimes however, the biggest challenges that come up with derivatives are not related to the technology but rather, the market.

“The bigger problem they run into is a market problem,” said Bernard Murphy, CTO of Atrenta. “So you build the super chip in anticipation that you’ll be able to do the low-cost version and the low-power version and the future phone version and then you find the super chip wasn’t that much of a home run so the derivatives become irrelevant. But that is not a design problem. I had somebody at one company tell me that happens 9 times out of 10. But how many home runs do you really see?”

Planning ahead
When an engineering team knows they will be doing derivatives, it makes sense to plan ahead to make it simpler to make the changes down the road….but do they?

“Yes and no,” said Kurt Shuler, VP of marketing at Arteris. “When they draw that block diagram and they create their internal roadmap slides and they have a block diagram of a chip and the derivatives, they have it tied together with a bunch of lines on the chart. You think that anything is going to be fine. But depending on the interconnect technology you use, each time you create one of those derivative chips can almost be like creating a whole new chip, and the reason is because of the back-end problems. To the SoC architect who is creating drawings of stuff, then the chip designers and the chip engineers are creating RTL, that then gets synthesized down into gates and eventually gets placed on the chip.”

Things don’t usually work out that smoothly, however.

“There is a disconnect between the architect’s drawing of a nice, clean, pretty picture of the chip, and nice, clean, pretty RTL and then when you go and try to design it in a chip, it looks like hell–you have all kinds of timing problems and what have you and you have to futz with it forever,” Shuler continued. “That is the biggest issue. A lot of companies say they are doing ‘the platform approach’ and are creating all these derivatives based off of this thing but are not seeing the benefits they expect. When you talk to the back-end people you find out the derivatives can take as long as the original chip did. That should be a red flag. If you don’t look at the platform holistically you’re going to be disappointed.”