Experts At The Table: The Mixed Signal Challenge
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.
Tags: analog, Cadence, ciranova, Magma Design Automation, Mentor Graphics, Mixed Signal












July 11th, 2009 at 11:04 am
It would help a lot if the people with the problems would actually turn up at the committees and drive the process. The Verilog-AMS language has been stuck at Accellera for a decade when it should have been rolled into the IEEE Verilog efforts, in which case we would have a SystemVerilog-AMS language by now. As it is, a unified AMS flow is probably still some years off.
A top-down/bottom-up AMS design flow with IP reuse requires that things like back-annotation work correctly for behavioral descriptions, and as far as I can tell nobody is working on that problem for AMS. A related issue is how you handle power distribution/management, and that doesn’t seem to be making a lot of progress either in the HDLs, so people are resorting to defining external standards (LPF etc.). This has also led to people trying to add AMS assertions to SystemVerilog, while there is still no support for analog design in SystemVerilog!
So I would say “yes we can” automate mixed-signal design, but it’s going to require a lot of work on the low level tools and standards first.