Speeding Up Analog

Experts at the table, part 2: Modeling; spreading out tasks; digitally-assisted analog; don’t live in digital process nodes.

popularity

Semiconductor Engineering sat down to discuss analog design and how to speed up analog circuits with Kurt Shuler, vice president of marketing at Arteris; Bernard Murphy, CTO at Atrenta; Wilbur Luo, senior group director, product management for custom IC and PCB at Cadence; Brad Hoskins, director, IC design, microcontrollers at Freescale; and Jeff Miller, product manager at Tanner EDA. What follows are excerpts from that discussion. For part one, click here.

SE: On the functional side, how does the modeling issue come up?

Murphy: You have these signals that cross from the digital domain into the AMS block that are really critical — every signal should be critical in some sense — but if you get the parity wrong, that thing doesn’t work at all. But you can’t simulate an AMS model along with a 200 million gate SoC. How would you solve that? You’d put an assertion on that pin, and say, this thing had better be low so the PLL lock or the PLL reset needs to be in this state when I’m running functionally. That means that the analog designer has to create an assertion. Is that a reasonable thing to expect?

Hoskins: Yes. Generating views for some things that are rather obscure for an analog person to be developing is a bit forward, but things like assertions are a great one because that’s part of specifying the design intent and I think you want the designer to always specify and understand the design intent; the problem is when they’re generating something to enable tools to check it. What they’re trying to generate there is something that’s a very different skill and not necessarily the right ones to be doing that.

Luo: I think the nice thing about assertions is it could live alongside the design. From a reuse perspective, I don’t have to inherit the entire, crazy testbench that I have no idea who wrote but assertions, maybe on the ports of the block, could ride alongside. If something happens that fails that spec, something will get flagged which is a nice compartmentalized approach.

Hoskins: Then you’re giving away some of the secrets of the design, from the designers’ point of view. But assertions are great for that because you want everyone downstream to understand the intent; you want someone to look back and understand what was intended.

Luo: …without too much overhead of learning everything else.

Hoskins: There’s a real lack of that there, and it’s probably as important or more important in the analog quasi world where it’s not always clear what somebody is doing. It’s relatively easy to reverse engineer something digital, if you didn’t understand it. But in analog, I’ve fallen for this before where I thought I reverse engineered an analog circuit and I didn’t fully understand the intent — then you miss something.

SE: How does IP integration and the things that have to be done impact speed of the analog portion of the design?

Hoskins: I could say that the different data that needs to be provided to an SoC team certainly weighs down an analog designer: they spend too much time distracted by what they need to do for integration. There’s definitely that – and that slows down the analog design teams. We sometimes manage to take that weight and those tasks off and it does certainly provide a lot more focus on the design itself and it does speed things up.

SE: How do you take some of those tasks off?

Hoskins: Find someone else to do it — and spread the task. There are some levels of tasks in analog design. When I worked for Cadence, they were quite good at this, I have to say, of having guys who did schematics on whiteboards and paper virtually who were like fellows and very senior; then people who did simulations, and went and simulated that; and other people who went and did models for that, and they were fairly separate. The different level of design did the different one. The fellows drew schematics, the juniors would create some models, and the more junior folks would run simulations. You can tier it a bit, but often you have a block that just requires one designer’s worth — and it’s not always easy to split that.

Murphy: There is some aspect of digitally-assisted analog that might be relevant. There are things you can do purely in analog that are sometimes these days easier to do in digital. Of course there are challenges unique that particular solution but I’m still struggling with how much people are really doing this. I’m hearing that trimming is common — that’s a relatively simple thing to do, and that’s how folks are doing 28nm analog today. But the more advanced kinds of things where you say, ‘I’m going to replace a chunk of analog circuitry with a DSP,’ seem to be very specialized. It’s basically the guys who are doing modems, and there’s maybe two of them now, maybe? That’s about it. I could be wrong; there may be others. Maybe there are advanced GPS-type applications.

Hoskins: You do see a bit of that. PHYs are inherently more digital — you could sort of call them quasi-analog, but they are more and more digital. PLLs are becoming more digital; data converters have a huge amount of digital that goes to the algorithms to get good accuracy. Compiling digital is still getting there…

Murphy: …and it’s digital in the middle of analog, not digital front-ending the analog.

Hoskins: Yes, it’s part of the implementation.

Miller: I see part of that as a forced march down the process curve. The deeper you get in 28nm and beyond processes, the worse things get for analog. One of the differences that we see, because our market is targeted around primarily analog chips with some digital, as opposed to digital chips where the analog has to find a way to fit itself in. I think a lot of digitally-assisted analog is analog is so horrible down here, we will do anything to get out of it, even if we do a DSP.

Hoskins: It’s not cost effective at these nodes, and it doesn’t scale very well.

Shuler: There is stuff in automotive where they want more processing power, they’ve got all this existing analog stuff, and they want to try and munge.

Miller: The IoT space is like that too where you have sensors and actuators that work with real world voltages and these sorts of things and you want to get some RF and some digital logic on there — we’re seeing those go 90+nm, 130, 180nm — that’s where the analog guys are comfortable. That’s where things really work well so you see the Tower Jazzes and the XFabs of the world with these sort of analog focused process technologies. That’s one way to speed up analog: don’t try to live in the digital process nodes.

Murphy: Companies are going down to 28nm and the big cell phone guys started doing that. I wonder if also maybe if you get into high definition audio, you might start to see that kind of thing. You’re going out through multiple speakers and you get whatever surround sound is called these days, then you have to actually fake the effect of the sound coming from a band or orchestra in front of you, and that requires a lot of these interference games you can play with sound waves.