By Ed Sperling
System-Level Design sat down to talk about design at future process nodes with Naveed Sherwani, president and CEO of Open-Silicon; Charles Janac, chairman and CEO of Arteris; Frank Schirrmeister, group director of product marketing for Cadence’s System Development Suite; Behrooz Zahiri, vice president of marketing at Magma (and currently director of marketing at Synopsys), and Charlie Cheng, CEO of Kilopass.

SLD: SoCs have always been on the high end of the cost curve. Will that change as they become more mainstream?
Schirrmeister: There are FPGA SoCs, which may have a dual A9 subsystem on which you can run Linux. And you also have 4 million gates in the large version where you can put your own RTL into it. That’s what’s approaching the ASIC side. You can get it pre-defined and add your components in RTL into the programmable fabric. And that’s already integrated into the system level with virtual platforms and high-level synthesis. Those are making these designs accessible to different markets.
Cheng: There will not be generic SoCs replacing ASSPs. Cost is very high at the system level, and every integration point costs something. It’s hard to say a generic SoC has a place. Every SoC I know is slated for a specific market.

SLD: We start doing different tradeoffs as we move down the curve, right? Time to market is arguably as valuable as paying an extra dollar for a chip.
Janac: Mobility SoCs are selling in huge volumes. That will continue to grow. But they’re designed for a specific purpose. What we’re starting to see is people building FPGA co-processors that can manage the functionality of the SoC at a very low cost because they are in huge volumes and there are very big contracts that can drive the price down. They are using those co-processors to take the SoCs into markets that they were never intended for. The FPGA business is getting very interesting.

SLD: Does software change, as well? Do we move away from a general-purpose operating system, or do we still have a big operating system and many little ones?
Janac: Virtualization allows you to run multiple operating systems at once, invisible to the user and the application software.
Schirrmeister: I was at an automotive conference recently and one executive was talking about a hypervisor to switch between different operating systems even in the car. They’re looking at things like that. But if you look at some classic semiconductor companies making application processors, they’re starting to differentiate in software. Android democratizes everything, and then you add other software. The differentiation can be in hardware and software.
Zahiri: One area that hasn’t been tapped is software controlling the power. Our high-end customers are doing 50 to 100 power domains, mostly for mobile processors. We’re enabling people to design this way. And yet there’s not a significant way from a software point of view where, if you’re dialing your phone, another part of the chip should be shut down. There’s nothing software has done in a big way to control the power.
Janac: It’s a cultural problem. The software people don’t understand the hardware and they don’t want to use the APIs that are available. There is a gap. Computer science graduates want to write Java.
Schirrmeister: When engineers write their iPhone app for the hardware, there is one example where they ignored an API and it sucked the battery dry within an hour. Those are things that need to be validated. They’re an integration problem of hardware and software. I have seen software controlling power domains in the wireless world, though. There are power management ICs that can pull down areas of the processors and certain power areas to a lower voltage. That is software controlled. From my perspective, integration is a huge issue there at several levels. There is the software-hardware integration. There is the issue of verification that the application is running correctly on the chip, which has become so big at an advanced technology node. Then there is the subsystem integration and validation. It’s quite a challenge.

SLD: And from a verification standpoint, you’re never really done, right?
Schirrmeister: The designer has to be confident at the end of the day that it’s not the last thing he does in his career to tape out that chip.

SLD: As we move to 14nm and beyond, will we be involved with the chip at the same level or will it be more an integration of platforms?
Sherwani: We are already doing 14nm chips in development. I don’t see that happening. Our customers are willing to pay the money required, even though there will be fewer customers who do that. But even at 14nm there are still a whole bunch of companies doing chips. There are applications that need that.
Janac: But you do need more and more volume. At 90nm you needed about 100,000 units to break even. At 65nm you needed probably 6 million units. At 40nm, you needed between 10 million and 15 million units. At 28nm you need 50 million to 60 million. At 20nm you will need 100 million units. The markets to support those volumes are fewer and fewer, which is why I see the SoCs and 3D silicon will be prevalent in markets that don’t justify those very complicated deep-submicron dies.

SLD: But you may have a 14nm known good die that is part of that chip, right?
Janac: Yes, you become an assembler.
Sherwani: The other problem we see is that IP companies are not willing to warranty their IP. That’s one of the big problems of known good die. If I buy $5 million to $6 million in IP, one piece of IP out of 100 or 200 pieces that doesn’t work can force me to re-spin that chip. Yet, most IP vendors do not warranty their work. They are not willing to pay us a re-spin cost even if we can prove their IP is the problem. That means I have to go to a model where I can save myself from that problem, but at the same time Open-Silicon has to warranty the chip. That’s why we want to go to known good die. Once IP is proven in a piece of silicon I don’t want to re-integrate again and again. Every time I re-integrate it, I have a chance that I have missed a problem. The world is moving toward 3D kinds of chips that will allow us to address smaller markets but still have high volume for chips. The same chip will go into multiple 3D chips.

SLD: You basically define what a derivative chip is, right?
Sherwani: Yes.
Janac: About 25% of our revenue comes from being able to link die together inside a system in package. It becomes one of the key enablers. You don’t have to be part of the 28nm or 20nm problem because some things like analogs and modems don’t require it. You maintain Moore’s Law by stacking the die.

By Ed Sperling
Synopsys completed its $523 million acquisition of Magma. It noted that Magma CEO Rajeev Madhavan will not join Synopsys, but will be available in an advisory capacity. Synopsys also announced its results for fiscal Q1. Revenue was up 16.7% to $425.5 million, compared with $364.6 million in the same period in 2011. On a GAAP basis, net income was $56.7 million, compared with $48.2 million in 2011, an increase of 17.6%.

Mentor Graphics expanded its support for UVM to make it easier for teams to transition from their existing verification environment to the new standard, which is now supported by all three of the major EDA companies. UVM Express simplifies the migration or co-existence, while UVM Connect provides cross-language communication.

Tensilica rolled out its LTE-Advanced baseband processors and a strategy for reducing power while increasing performance for the Level 1 PHY. The company also inked a deal with Sensory for a complete speech recognition subsystem, and it announced that Arkamys‘ Audio Enhancement Software will be ported to Tensilica’s HiFi audio DSPs.

Cadence rolled out its 40/100 gigabit Ethernet media access controller IP, which is aimed at large data centers and high-performance computing. This is particularly important in the cloud, where moving data quickly across servers and sometimes across data centers is essential.

Cadence’s Richard Goering looks at the completed Accellera-OSCI merger and what it means for EDA standards. There’s a lot at stake here.

Also on the subject on standards, Mentor’s Dennis Brophy takes a look at the IEEE standards awards and what’s getting the most attention. That should give you some idea of how things will progress.

Synopsys’ Eric Huang has found a new use for waterproof USB drives. You can stir your coffee with them.

DeepChip’s John Cooley looks at some of the reasons behind the Synopsys acquisition of Magma and what it could mean for Magma CEO Rajeev Madhavan.

Cadence’s Adam Sherer has come up with a gift idea for verification engineers: UVM training. Given the runaway complexity that verification now has to contend with, this is probably a good suggestion. Reactions may be mixed, though. “What, another gift card?”

And in case you missed the most recent Low-Power Engineering newsletter, here are some standout blogs to consider:

–Mentor’s Barry Pangrle looks at overclockers who don’t give a whit about conserving power.

–Synopsys’ Cary Chin proves it’s still possible to get a death grip on the new iPhone 4S to kill reception, even if it does take two hands. Warning: Don’t try this while driving.

–Cadence’s Luke Lang digs into power formats and what works, what doesn’t and what we don’t know.

–Apache Design’s Preeti Gupta unleashes part one of her look at power delivery networks for LP designs.

Synopsys said it has reached an agreement to buy Magma Design Automation, putting it on a collision course with Cadence over analog and with Mentor Graphics in the DFY/DFM arena. The analog is particularly strategic for the stacked die market, where most experts believe it will be decoupled onto a separate die or multiple die. There is no indication when the deal will be finalized.

Synopsys also reported its fiscal Q4 earnings. Revenue was $390.5 million, vs. $375.5 million for the same period in 2010. Revenue for the full year was $1.536 billion, up 11.2% from $1.38 billion in 2010. Net income for the quarter was $39.9 million, vs. $25.4 million in 2010. The company is targeting revenue of $412 million to $420 million in Q1 2012. That line certainly points in the right direction.

Fujitsu Semiconductor standardized on Mentor Graphics’ signal integrity technology for PCB co-design. Recon Instruments also used Mentor’s Android professional services to develop micro optics for sports goggles. The goggles provide info about speed, jump airtime, GPS location, distance traveled, temperature, altitude and time. Well, that should take the guesswork out of skiing. Tree ahead.

SMIC and ChipEstimate launched a portal for SMIC-compatible IP cores ranging from 40nm all the way up to 0.25 microns.

Tensilica added RacyICs to its list of design center partners, this one for its Xtensa processor line. RacyICs sells verification and implementation services for IC design.

By Clive “Max” Maxfield

I’m a digital design engineer by trade. All of those wibbly-wobbly effects that are characteristic of the analog domain make me nervous, and if something makes me nervous I tend to look the other way and hope it will go away. But analog isn’t going anywhere. On the contrary, the increasing amounts of analog/mixed-signal (AMS) functionality that feature in today’s System-on-Chip (SoC) designs are making AMS the gating factor to success.

For those of us who come from a digital background, it can be difficult to wrap our brains around what’s happening in the analog realm with regard to design and physical implementation. So, just to set the scene, let’s start by considering a high-level view of the digital SoC design flow; we’ll then contrast this with its traditional analog counterpart; and finally we’ll consider some incredibly cool “stuff” with regard to analog design and physical implementation that’s heading towards us like a runaway express train.

One of the things that characterizes the digital portion of a modern SoC design flow is the extreme amount of automation that’s involved. The whole process starts when someone gets a capriciously cunning idea as to “the next big thing,” as illustrated in Figure 1.

  

Figure 1. A high-level view of the digital design flow.

There are two main concepts that are central to the digital flow: the use of intellectual property (IP) and the combination of high-level representations and synthesis technology. Early in the process, for example, the digital design team will select a bunch of IP blocks from their grab-bag of goodies—perhaps a CPU and/or a DSP, maybe a handful of peripheral and accelerator cores, possibly some interface functions, and so forth. This IP can account for a very large piece of the puzzle in terms of the SoC’s overall functionality.

When it comes to the “secret sauce” that will differentiate this product from its competition, the digital design engineers typically describe the required functions at the register transfer level (RTL) of abstraction (the IP blocks will also typically be specified in clear, encrypted, or obstruficated RTL).

Following a quick functional simulation (yes, I really am glossing over the complexities), synthesis technology is used to translate all of the high-level blocks forming the design into their gate-level equivalents. We then have access to incredibly sophisticated technology to generate a floorplan and to place the gates. This is followed by mind-bogglingly clever automated routing and optimization. In turn, this is followed by parasitic extraction, from which values are used to further refine simulation, timing analysis, signal integrity analysis, and so forth.

Once again, the above is a very high-level and simplistic view of the process that is intended only to illustrate the extreme amount of automation that permeates the digital portion of the flow.

This style of working – the use of IP along with RTL representations and synthesis technology – makes it relatively easy to capture and implement the digital portion of the design. (By “relatively easy,” I mean as compared to doing everything at the gate-level by hand. Can you imagine capturing a large SoC design as a bunch of logic gates and then placing and routing these gates by hand? As we shall see, that’s what the analog folks have to do.)

Furthermore, this style of working facilitates one’s ability to migrate a design from one foundry to another and/or one technology node to another. If you have an existing design at 65 nm and you want to migrate it to a 45 nm process, for example, you just swap the cell library, modify your constraints, press the “Go” button, and let the synthesis, floorplanning, place, and route engines perform their magic (I know this process is nowhere like as easy as I’m portraying it here … but it would certainly appear to be this straightforward to any analog folks looking at this flow).

A Conventional Analog Design Flow

So, what do you think life is like on the analog side of the fence? What amazingly cunning tools do those guys typically have at their disposal? Honestly, when you discover the truth, it makes you want to cry. Let’s consider a high-level view of the analog portion of the flow as illustrated in Figure 2.

  

Figure 2. A high-level view of the analog design flow.

Here’s the way it goes: We start with someone having a bright idea (with regard to the analog portion of the SoC), and everyone jumps up and down saying how wonderful it is. So all we have to do is implement it.

Analog IP? Don’t make me laugh (at least not process-portable analog IP). The best we can hope for is that we might be able to re-use some transistor-level schematics as starting points for portion of the design. The rest of the design will be captured as new transistor-level schematics.

Simulation is performed using a SPICE-like simulator or a fast-SPICE equivalent; synthesis doesn’t come into the picture at all. Generating a floorplan and placing the transistors and other components is performed by hand. Similarly, routing the design is performed by hand.

If we peer back through the mists of time to the 1980s, parameters such as the sizes of the transistors and other components were specified by the circuit designers as attributes in the schematic. These attributes were then used by the SPICE simulator, and also by the layout designer, who literally generated the various components (and later the routing) at the polygon level. (Actually, this is something of a simplification, because some attributes were – and still are to this day – communicated to the layout designer as text annotations in the schematic, or via a separate text document, or by paper and pencil.)

Sometime around the early 1990s, Cadence introduced the concept of PCells (Parameterized Cells), which are described in a proprietary Lisp-like scripting language called SKILL. In this case, the circuit designers place PCell symbols in the schematic and then associated parameters with these entities.

Eventually, each PCell uses its associated parameters to automatically generate the preliminary layout for that cell. The reason I say “preliminary” is because some layout designers will eventually convert the PCell representations into their polygon equivalents (this process is known as “smashing”) and then start “tweaking” these polygons by hand. The layout designers also have to do a bunch of other stuff like abutting, well-merging, interdigitation, and row-stacking in order to create a more compact layout. And then they get to do the routing by hand.

To provide a sense of scale, if we had a 30,000-transistor mixed-signal SERDES block, for example, the complete layout for this block could easily take a team of one or two layout designers two to three months (two-thirds of this would be the placement; one-third the routing).

I don’t know about you, but this doesn’t strike me as being a lot of fun.

A Brave New World

Wouldn’t it be great if the analog folks could use some special language to specify a function at a high level of abstraction, automatically synthesize this representation into an optimized transistor-level netlist, and then automatically place and route this netlist? Well, yes it would, but we aren’t there yet, so what can we actually do today?

One technique that has been around for quite some time is to hand-create a transistor-level netlist, to somehow specify which parameters can be varied and over what range of values, to define some way to measure the “goodness” of the output(s) and other criteria like power consumption, and to then kick off a long series of simulations that sweeps the various parameters across their respective ranges. The problem is that this approach works only with relatively small circuits, and even so it can take a huge amount of time and computational resources.

One company that is doing some really exciting things in the analog/mixed-signal arena is Magma Design Automation, with its AMS design platform called Titan. Using Titan acceleration technology, designers can code AMS functions as equations. Once the equations have been captured, the user can specify a target process/technology and Titan will generate an optimized implementation for that function.

My understanding is that writing and testing the equations can add 20% to 50% to the overall design cycle, which is something of a pain. However, once you’ve done this the first time, you can re-use this function in future projects. This technique has several advantages, including facilitating architectural exploration and also facilitating the migration of functions from one process/technology node to another.

Another company that is well worth watching is Ciranova. A couple of years ago they came up with something called PyCells. These are the equivalent of PCells, except that they are captured in the open source Python language. They also have PyCell Studio, which provides a complete standalone environment for creating PyCells that can be used with any OpenAcess tool (including tools from Cadence).

Now your first reaction may be: “Ho-hum, what’s all the excitement PyCells?” Well, actually they are jolly exciting, because as part of their implementation the folks at Ciranova have managed to fully separate the design constraints from the implementation technology. And why is this important? Well, in 2008 Ciranova introduced a tool called Helix, which performs automatic floorplanning and placement of an analog design.

As part of this process, Helix automatically executes all of the tasks that layout designers traditionally perform by hand, including abutting, well-merging, interdigitation, and row-stacking… and the result is a correct-by-construction, production-ready, DRC-clean placement. (How is all this possible? Well, in addition to being fully multithreaded, Helix employs incredibly cunning genetic algorithms, but I can say no more about this because I am bound to secrecy.)

A design comprising a few hundred transistors can be fully placed by Helix in a minute or so; a design involving say 30,000 transistors might take a few hours (compare this to multiple layout designers slaving for weeks or months as discussed above). Quite apart from anything else, this dramatically changes the picture with respect to migrating an existing design to a new process/technology node as illustrated in Figure 3.

  

Figure 3. PLL netlist placed by Helix, transistors resized,

same constraints, two technology files, runtime 30 seconds.

But wait, there’s more, because I hear that, slaving away in their secret underground bunker, the boffins at Ciranova (“They don’t let us out very often…”) are currently beta testing what they are at pains to call a “Trial Router.” Basically, this Trial Router can auto-route a design comprising a few hundred transistors in just a few seconds; a design involving say 30,000 transistors might take 30 minutes or so.

Now I’m not saying that you would take the results from this Trial Router and proceed directly to tape-out. In reality, the layout designers may end up throwing a lot (or all) of the Trial Route results away and re-doing it all by hand.

So what’s the deal? Well, the point is that the designers need to get a feel for the electrical performance that can be achieved by the design and they need this information as speedily as possible. Thus, the reason this Trial Router technology is so exciting is that you can quickly extract highly accurate parasitic values for the circuit and get a real good feel for how the circuit will perform.

I mean, if you can take a design that would normally take two months to place and a further month to route by hand, and you can generate a production-ready placement in a couple of hours and then perform a first-pass Trial Route in 30 minutes. Tell me that this isn’t exciting (I won’t believe you).

And as for the future…

As the famous American inventor Charles Franklin Kettering famously said: “My interest is in the future because I am going to spend the rest of my life there.” So what will the future hold with respect to analog synthesis?

Well, some folks think that true, top-to-bottom analog synthesis is a pipe-dream. Over the years there have been some amazing failures in this area, with companies claiming all sorts of things that never came to pass.

What about the technique of specifying a transistor level netlist and then varying a bunch of parameters to determine the optimum circuit configuration? Well, this really falls under the heading of “optimization” rather than “synthesis”.

A slightly more sophisticated approach might be to specify a function in terms of its transfer function and to use a computer to sift through hundreds or thousands of different topologies playing with the parameters for each topology. (When you come to think about it, this is really just circuit optimization with the addition of a couple more parameters.)

I think that the folks at Magma are doing some very interesting work and have certainly solved part of the puzzle, but (trust me on this) they would be the last to use the term “analog synthesis,” which is regarded as bad karma by the majority of analog designers.

Meanwhile, the folks at Ciranova have taken the approach that computers are great at performing “grunt work”, so they’ve automated the drudgery of placement and (“Trial”) routing. Although this doesn’t sound glamorous, it’s actually a rather amazing achievement.

But as for the ability to create a high-level specification and then synthesize a circuit topology… well, I’m not so sure (please feel free to quote me on this).

System-Level Design sat down to discuss mixed signal design with Robert Hum, VP and general manager of Mentor Graphics’ Deep Submicron Division; Mar Hershenson, VP of product development in Magma’s custom design business unit; Eric Filseth, CEO of Ciranova, and John Stabenow, group director for solution and product marketing at Cadence. What follows are excerpts of that conversation.

SLD: Are we actually getting to the point where we can automate mixed-signal design?

Hum: We can’t automate design, but we have the tools to let the digital guys embed analog stuff without killing themselves.

Filseth: The abstractions in digital meant that designers didn’t have to worry about all the nuances of the silicon. Automation for analog/mixed signal has to do that, too. It has to take care of all the nuances so the designer doesn’t have to know all that stuff intimately.

Hum: Analog design is ugly enough as analog design. We’ve all sped up our simulators and we’re all multithreaded and everyone claims to be superlinear. But if you take your standard circuits that used to work three years ago and you move them to 45nm and you do an abstraction, all of a sudden the parasitic file is 10x as big as it used to be. So you run your model order reduction scheme, you find it’s not quite accurate enough and you back off a bit, but you still find your design is bigger than it used to be because at 45nm all the third-order effects are now first-order effects. Now you’ve got this problem where the parasitics are components and you’re now impacted by lithography. You’ve got proximity problems, stress effects and carrier mobility impact. All of a sudden your design has more parameters than you thought you had. As a community, we have to get better about what we model. It can’t just be thanking the designer for the design because we now have 10x more components in there, and that’s not helping. These third-order effects have to be modeled so you don’t impact the design cycle. There’s another abstraction level that has to come up from the silicon level through the photolithography problems and reflect back into the design cycles.

SLD: What else can be automated?

Stabenow: The fastest time to benefit for the users is in the initial parasitics and getting that fed back to the users. Automation is a scary word. I don’t think you can truly synthesis analog layout yet. We have a pretty good understanding of it, but that’s the first big improvement we can make. Model-based design is the way to get there from the designer’s perspective. Getting feedback about what’s actually going to go on silicon is critical to improving time to market.

Filseth: Clearly, a lot of layout can be automated. How close can these polygons be together? People do this today, they run DRC, it’s not correct. They move them, they run DRC, it’s not correct. They move them again. This is the kind of thing that cries out for computer aided design. So the first step is design rules. The second step is what we consider micro-geometry around devices—interdigitation, abutment, well manipulation, multiple kinds of wells. That can be automated, too. The third piece in analog is that these things need to be aligned, there needs to be symmetry and mirroring and matching. That’s circuit designer intent, and I don’t think that can ever be automated completely. You need an experienced person saying the power output stage on this side and the sensor input stage on this side have to be in a line of symmetry. You can’t infer that automatically. You need a designer to do that. But you can capture intent about, ‘I want that there and that there.’ Clearly you can automate most of layout, and you can assist circuit intent. At 45 or 32nm, that’s a gigantic improvement.

SLD: How about reusable IP blocks?

Hershenson: Hard IP has been tried for more than a decade and hasn’t been very successful. You need a slightly different data converter or a slightly different something else, and slightly different means you have to do it all over again.

Filseth: Or you want it in this footprint for this SoC and that footprint for another SoC.

Stabenow: It works for exactly one case.

Hershenson: That’s why IP companies have turned into services companies. The big semiconductor companies have their central IP groups that generate IP for the rest of the company, and they have the same problems as the companies that generate hard IP. What they’re implementing are soft IP technologies. They’re forcing designers to write analog assertions in the schematic or enter constraints. The thing we’re looking at is how to enable people to create this soft IP. It’s going to be domain-specific. So if it’s high-speed I/O, we’re going to offer ways to write soft high-speed I/O in a way that’s more efficient. I’ve been working for the past 10 years on model-based design and extracting information in a way that it can be optimized. There’s a lot less effort. Models allow you abstract proximity effects, parasitics, system effects, circuit effects and layout constraints all at the same level. This is by no means an industry standard, but there is some adoption.

Filseth: We’re seeing a pickup in constraint-driven design, as well. It’s a simple step forward. It’s not automation, but it’s a re-use of IP. It may be something as simple as, ‘What was the designer’s intent?’ The designer may have moved onto a new company, but at least the intent was there and it’s not in the form of a hand-written napkin.

Hershenson: Exactly. That’s the direction we’re all going. What’s going to be the next generation will be a platform where you can model your circuit in a unified way so you can use it for design, verification and visual model abstraction.

SLD: Can you potentially take analog and doing it in digital?

Hum: The other way of doing things is to use a DSP and do it in digital. But the world is conspiring against that because there’s a power tradeoff. It used to be that whatever was analog went digital, and whatever was digital went into software. Now the issue is that you have to run your processors so fast that you use up a lot of juice. You unbundle your processors and put digital co-processors there. Digital co-processors still use too much juice, so put an analog block there. There’s been a reverse trend of software goes to co-processor, co-processor goes to analog. There’s not a clear trend to turn analog into digital. The only advantage of a digital radio is being able to take two chips and turn them into one.

Hershenson: You still need a big data converter.

Hum: And you still need a gigahertz clock. And then you have to worry about the power. Technically, you can do it. But you need a car battery to go with the phone.

Hershenson: As long as you’re interfacing with the real world, there’s going to be some analog.

Hum: The big D, little A market is there. But there are other markets where there is big A, little D. These devices are smaller. They’re not at 45nm. Some of these things live in your car and handle 1 kilovolt and 50 amps. These are very different markets. In the big A, little D markets, you have to encapsulate the analog and make it safe to use.

Filseth: There are two problems. One is a system integration problem and the other is a design problem.