Posts Tagged ‘ciranova’

Experts At The Table: The Mixed Signal Challenge

Friday, July 10th, 2009

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.

By Ed Sperling

SLD: Is there any progress in the verification of a mixed signal chip?
Filseth: Functional verification has been a challenge. It’s getting better, though.
Hershenson: Verification has come the longest way in the last 10 years. If you give an engineer $100,000 to buy any tool and ask them what they would buy, it would be a faster simulator. That’s what they want. But in analog design, simulation is not used only for verification. It’s used as part of the design cycle. In digital, there’s a clear differentiation. You write RTL, synthesize and then verify. In analog, you run an artificially high number of simulations because that’s how you design your chip.
Hum: In the digital world, the editor you use is like your simulator in the analog world. It’s your paint brush.
Hershenson: If you want a real breakthrough in analog, you have to reduce the number of simulations.
Filseth: We’ve seen people take a hammer to this problem by deliberately designing a circuit to run in two completely different technologies without resizing anything. They give up 25% area, but they say that’s an acceptable tradeoff. It reduces the amount of verification.
Hum: One thing we see in graduates coming out of school is less reluctance to use automation. Maybe their designs won’t be as good, but they’re much more willing to push the optimize button and see what happens. Maybe the tradeoff will be more area versus less design time. In the digital world that certainly happened. You can do any circuit design by hand and do better. It may take you 100 times as long and you may never get closure. In the analog world it’s been more of an optimize at all costs mentality.
Stabenow: It depends on the market. If you were doing 740 op amps then you would never make that tradeoff, because cost is everything. If you’re doing a 40,000-device SERDES on a 30 million-instance SoC, then you might well make that tradeoff.

SLD: We’re hearing about mixing older analog engineers with younger ones to come out with a better product.
Hum: There are paradigm shifts that could help. Time will tell, but there is definitely a different attitude among recent graduates.
Filseth: In classic analog design, you have to spend a dozen years before you build up the intuition to design this kind of stuff. The combination of this kind of expertise with someone who is more amenable to using tools may make sense.
Hum: In the EDA space, the lack of innovation in areas like optimization is also due to the lack of markets. You’re not going to invent something if no one is going to buy it.
Hershenson: The bulk of the work in analog optimization has been on speeding up the current flow. The fundamental problem for all these tools is that you need a good starting point for them to work. If you don’t have a good starting point, forget it.

SLD: Is there an opportunity to sell tools into this market?
Filseth: The real opportunity is to go after the 90% that’s now done manually and figure out what can be automated.
Hershenson: Optimization is not going to get you to the next level. You have to go back to abstractions and models and things that can encompass more than one job.
Filseth: The classic knock on automation tools is that it takes so long to set up the tool. You might as well do it by hand.
Stabenow: The new generation that’s coming out of school is more comfortable using these techniques. It’s a progression in analog design from the days of Fairchild until now. It takes generations to change attitudes about automation.
Stabenow: Layout tools have been around for years. The classic response is, ‘It just doesn’t look right.’ It simulates clean. But the response is, ‘It’s just ugly’ and so why use it?
Filseth: Some of it is on the tool side. But it has to be visually appealing, as well.

SLD: How important is commercial IP in this world?
Hershenson: Some people are using it for standard blocks like PLLs. But that’s not a very large percentage of the mixed signal market.
Filseth: The vast majority of mixed signal IP is in semiconductor companies.
Hum: Commercial IP is limited to areas where you don’t gain any advantage by doing it yourself. With USB 2.0, the worst thing you can do is do it yourself and get it wrong. That’s how you plug into everybody’s system, so there’s no advantage to creating it yourself. With that stuff, you go standard. The problem in the IP business is the shelf life is short and the margins are terrible. So you sell a bunch of copies, but the street price rapidly goes down.
Filseth: Lack of automation hurts that, too.
Hum: It could be that the IP industry settles out as groups of knowledgeable, experienced people who know how to do a certain thing, and analog IP becomes a service. There will be two sides of that. One side will be the standard stuff. The other side will be the embedded memory group and the power control group and the RF people.
Filseth: We think standard mixed signal IP coming out of the downturn is going to be a big deal. It’s non-differentiated IP that everybody needs. The guys who get their SoCs to market faster than the other guys are going to win.

SLD: How important is constraint-driven design?
Stabenow: We’re seeing it grow, both in importance and adoption. Maybe it’s not as fast as we would like, but the mindset that has been resistant to it is softening. If it takes longer to set the constraints up than design a circuit, then this is not of use. From a product perspective, we’re working to improve that. But then there’s also the way it’s adopted. Instead of a constraint-driven flow to produce analog synthesis, maybe it’s just the ability to have a designer at one location put intent onto the schematic electronically and a design adhere to it manually, and then have a way to reconcile that. It’s a constraint verifier approach.
Filseth: Automation and constraint-driven design go together like synthesis and RTL went together. One is an enabler for the other.
Hum: Constraints are everywhere. UPF (Unified Power Format) is a way of capturing constraints and how your power up/down stuff works. You have to capture that and get it right, but once you do that it’s easier downstream.
Filseth: The key to constraints is they have to be absolutely as simple as possible.
Hershenson: Yes, few and easy to enter.
Filseth: You want stuff that’s only related to design, too, and not the underlying technology. If you can do that, it takes you a huge step forward in portability because you’ve made your description independent of process technology.

Experts At The Table: The Mixed Signal Challenge

Thursday, June 25th, 2009

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.

By Ed Sperling
SLD: Analog has always been considered more art than science. How far has it come, and will it ever be automated?
Stabenow: It depends on your time frame. If you’re talking about the slide rule days, we’ve come a long way. If you’re talking about since 2001, we haven’t come that far.
Filseth: That’s right. The basic way of doing analog design hasn’t changed much over the last 15 years. The tools that support the original way of doing it have gotten incrementally better, but it certainly looks like we’ve hit a point of diminishing returns for how productive you can get the traditional methodology to be. The basic concept of how this is done—simulation, handcrafted layout, schematic layout, PDKs, parameter accels—have been there a long time. It isn’t likely to get twice as efficient under the current path.
Hershenson: The biggest change in the past 10 to 15 years has been in simulation and the capacity of the circuits it can handle today. But fundamentally it’s the same.

SLD: But how about the designs?
Filseth: They’ve changed dramatically. They are a lot more complicated. There are a lot more transistors in an analog/mixed signal design. We don’t see that much pure linear analog anymore. It’s all mixed signal.
Hershenson: The main tools for mixed signal are editors and simulators. That’s about it.
Filseth: If you think about the last major advancement, it’s shape-based routing, although arguably it’s used for assembly.
Hum: The digital domain has had the luxury of a unifying paradigm—RTL. That is the central idea that has driven abstract-to-specific automation. The digital side has parametrically focused on timing, but now that power has been added it’s getting more difficult. It’s hard to analyze timing and power. In the analog world there has not been, and there is unlikely to be, a unifying paradigm. The things that define phase lock loops are quite different from the things that make USB 2.0 PHY’s work.

SLD: So where will progress come from?
Hum: In the analog world, whatever progress there is will come from top-down, domain-specific approaches. What you used to do filter synthesis in the old days was a filter package. That doesn’t help for A-to-D conversion. In the analog world, the name of the game in automation is going to be tuned to vertical tracks, and it’s going to be pretty specific. In the next 10 years, there may not be any breakthroughs in this area. There is nothing happening in a coordinated way to create the automation for these small areas.
Filseth: That varies a little bit depending upon where you are in the flow. As you get closer to the architecture, you get more specialized. As you get closer to the silicon, things get more horizontal. And the level of horizontal-ness increases as you get closer to tapeout.

SLD: Is there room to do the different pieces separately?
Stabenow: It does have to be done together. We’re seeing mixed signal everywhere. But that doesn’t necessarily lead you to an analog automation path. You have this automation path on the digital side—things you can do with machines. But in the analog perspective, other than analog macros it’s all being done from scratch and by hand.
Hershenson: The A-to-D converters and phase lock loop are fundamentally different blocks, but they do share a lot of components. In a filter, a main block is a Gm cell or an Op Amp. It’s the same in some types of ADC. There is some commonality on the blocks being used in the different circuits. Otherwise in school we’d have to take 50 classes to become an analog designer. There are some concepts like linearity and gain that are common to different applications. The other thing we’re seeing is talk about integration shortening the design flow. It hasn’t happened. But one thing that has happened is that because of the complexity, there are many more data converters and PLLs on the chip. In digital blocks, high-speed I/Os have a ton of analog content.
Filseth: In the past half-dozen years there’s been a very interesting market split in analog/mixed signal. Traditionally, analog and mixed signal content was on a separate chip. If you were an analog/mixed signal IC company making data converters, you competed with another analog/mixed signal IC company on who had the best integral non-linearity spec on the data converter. Your chip would go onto a circuit board on an MRI system, and the lifespan would be seven years or more. In that sector, pure quality result is critical. Time to market was important, but not critical. You chose the best silicon technology for the job. If it was half-micron CMOS, that’s what you used. In the past half-dozen years, there’s been a different kind of analog/mixed signal chip. Anyone doing a networking chip needs a high-speed SERDES. People want to put PHY radios on a single SoC. The dynamics of the analog/mixed signal content is different. You’re not competing on specifications for your data converter. You’re competing on how fast you can get all this stuff out the door and will you be in time for Christmas? In this kind of market, what counts is good quality results. But top priority is getting all of this stuff integrated together. This is the part of the market that’s growing fastest.
Stabenow: I wonder if the automation won’t come in the form of macro IP. The big SoC guys will buy analog blocks. That means the design problem still exists back at the beginning where they’re generating the IP.

SLD: Is this a problem of people being used to doing things certain ways?
Hershenson: The new generation is different than the old generation. If you were working at Linear or Analog Devices and you got a 1% better gain in your Op Amp, you were king for a day. The major universities like Stanford and MIT have industry-funded programs to improve the analog design flow. Just having the core isn’t enough. You have to figure out how to put systems together. Systems are not just for cell phones. They’re for cars and bio-engineering. This is just beginning. It’s training analog designers plus CAD. The new people we interview know MATLAB and they’re not afraid of writing a Tcl script. I think that’s going to help a lot.

SLD: So what pieces can be automated?
Hum: There are several areas. There is a market developing for big D, little A, where little A is a hard analog block or some kind of malleable parameterized thing that’s a block generator. The problem is verifying that you’ve embedded the analog block and that it’s happy in its embedded location. We need the equivalent of analog assertions. In the digital world, you’ve got the digital assertion space, which looks at protocols between blocks. In the analog world, there is a set of assertions you can come up with. They’re clearly incomplete. Step one is to make sure it’s embedded right, that you understand the boundary and the handshake and transactions that go across it. Big D people wouldn’t know a transistor if it hit them. That’s not how they’re trained. They’re trained in finite state machines, complexity and how to do an 80-million gate design. All you want to know about your analog blog is that you’ve embedded it right. If you had a model that’s plus or minus 10% accurate, that’s enough.

SLD: So what’s the solution?
Hum: There are people working on these non-linear response surface models, which is one approach to it. There’s other work to look at automatic extraction mechanisms. Once you have a circuit and want to get a facsimile of that circuit in the digital domain, you need an interpolation function. There’s good work going on there in universities to generate interpolation functions. This is a different approach than synthesis. It’s de-synthesis. I have the polygons and the transistors and the SPICE mode

Making Analog Easier

Tuesday, April 28th, 2009

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).

Experts At The Table: The Mixed Signal Challenge

Friday, January 2nd, 2009

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.