Top-Down Modeling and Analysis of Analog Mixed-Signal Systems
In this presentation, we will talk about a top-down approach to analog mixed-signal architectural modeling using the Mixed-Signal Blockset™. This session will cover usage of the Mixed-Signal Blockset to model mixed-signal elements such as phase locked loops and analog-digital converters. It will also illustrate the capabilities of bringing in impairments and validate the performance of the PLL and ADC using test benches and measurement blocks. It will also cover interfaces to the Cadence Virtuoso IC implementation system.
Recorded: 6 Nov 2019
So the talk today is about top-down modeling and analysis of analog mixed-signal systems, so it's everybody's favorite topic these days. So here's the agenda. So we'll go over what is top-down modeling and analysis.
Why is top-down relevant to analog mixed-signal systems? We'll refer to analog mixed-signal as AMS-- pretty clear there. Also, we'll walk you over some tools flows and methodologies to support a top-down AMS workflow, and hopefully, we'll be able to show you some examples in terms of how to implement a top-down AMS workflow to model things like phase locked loops, analog to digital converters.
You saw a very detailed talk from Barry Katz about SerDes, so we'll really not talk about SerDes. But feel free to come and talk to me offline or feel free to visit the AMS booth that we have, and we can show you a lot of interesting stuff there. So let's get going with that.
Before we get into top-down, let's talk a little bit about what's bottoms-up? So that's an example of a charge pump implemented as a sea of transistors, as you see there. So that's an example of a bottoms-up design.
So when you say you want to analyze something like this, you basically run your favorite simulator, any Newton-Raphson based detail simulator. In this particular case, this happens to be Virtuoso from Cadence. You'll probably run something like a Specter to simulate it, and essentially, you'll build such systems in a bottoms-up manner.
You'll start assembling your transistors, [INAUDIBLE], diodes, capacitors, resistors, so on and so forth using your various analog mixed signal building blocks. And it turns out-- yeah, actually, you probably can barely read it at the bottom. I apologize for that.
But the simulation time for such circuits is not a big deal. It can run into some seconds depending upon how much details you want to simulate, how many corners you want to go through, what kind of Monte Carlo analysis you're doing. Might run into maybe a few minutes. Not a big deal.
But a charge pump is a building block. I mean, let's say you want to use the charge pump as part of a more detailed analog mixed-signal system. It might be a PLL. Maybe you want to use it for a transmitter or a wireless receiver or a wired transmitter or receiver. So how about a video cable equalizer?
So if you use a bottoms-up technique here-- so depending on what you do, I mean, I'm sure some of you have seen this, but your simulation time can run into hours, possibly days, sometimes weeks. You just have to be patient. Make sure there's no convergence issues. [INAUDIBLE] comes back after your two week vacation, and then hopefully, things get going there. It's one scenario, but probably not very practical.
So some of the pitfalls, other than the obvious performance issues in terms of simulation time, when you look at bottoms-up, how do you deal with complexity? The picture that you saw, that video equalizer there-- I mean, that's a complex analog mixed-signal system. I mean, you have digital circuitry there. You have analog circuitry.
You have different kinds of interfaces. You have interactions between the analog and the digital. So how do you make sure that you analyze all of those effects and make sure that you tape-out something that matches with your specifications?
So certainly, complexity's a big deal. They show that limited design abstractions [INAUDIBLE], how do I do various tradeoffs? Let's say, if you're implementing a PLL with a certain version of a divider, how do you make sure you bring in a different architecture, for instance?
Quality-- I mean, that's a big deal. I mean, everybody faces pressures in terms of tape-out deadlines. Boss wants this product to be taped out over the weekend, so Monday morning, it needs to be taped out. But how do you make sure-- you've got to assure the boss that, I'm about 99% confident. Can you do that? Really? I mean, I think there are very few teams who can do that with using bottoms-up techniques.
Specification isolated from verification, and this is really a big deal there, because how do you make sure that-- as you're making these minor changes to account for the bugs that you find along the way, how do you make sure it always tracks with your specs? And finally, efficiency and reuse-- you have these various tools that you have to run. You have to make sure that you don't have issues of convergence between these various simulators that you're using.
But also, how do you ensure that you have the maximum productivity? If you're running global design teams, how do you make sure that your design team in Bangalore is in sync with the folks in Santa Clara or in Dallas? So there is this aspect of IP reuse. How do you make sure everything goes smoothly as planned, and you hit that tape-out date? So I think there are some pitfalls here in terms of using a bottoms-up approach.
So what is top-down modeling? So let's start with a simple example here. How do you integrate a pulse train? As simple as it gets.
So you see this bunch of pulses coming in. That's why you call it a pulse train. You have some amplification here. We're amplifying it by a factor of 10. It's amplitude amplification.
And then you have an integrator. We run an integrator, and you basically-- we call this a system level model. And this could be at a fairly high level of abstraction, and this is really the thought process that you need to have when you're designing that video equalizer.
As complex as the system gets, you need to start thinking big picture. What is my overall system looking like? What is the testbench that's looking [INAUDIBLE] that'll drive the system? What is expected output, and am I adhering to my specifications all the time?
So in this case, of course, we ran that simulation at that level of abstraction. We got that staircase waveform. This is all cool. We integrated a pulse train.
So in terms of top-down modeling, so it would be nice to actually go down into each of these block. So let's say you drill down into that stimulus block. You want to have a testbench model.
You drill down into that amplifier model. You want to have an amplifier model. And then you have an integrator, you have an IO model, and eventually, it would be good if you can actually get it down to that level of implementation. You want to be able to have that single version of truth that you start out with in terms of your high level system model, and then you want to implement the same thing because you want to make sure that you're designing to your specifications.
So essentially, that, in a nutshell, is top-down modeling and analysis. You start with a system model. You create a behavioral Netlist. Then you create a schematics netlist, and then you go through your regular tape-out process.
So you think top-down. Barry talked about shift left in the previous talk. You want to make sure that all the bugs get detected as early as possible during your design-- during your overall design.
So boiling that down in terms of what is analog mixed-signal design-- so I'll take this quotation from EE Times. So these are some-- if you're not [INAUDIBLE] these gentlemen, Ken Kundert and Henry Chang, I think they run a consultancy service that's pretty cool. We all relied on them, and when I was at National NTI, I worked with them quite a bit. But basically, they are saying that, in a top-down approach, the architecture of the chip is defined as a block diagram and simulated or optimized using a system simulator, such as MATLAB or Simulink, and then from this high level simulation, requirements for the individual circuit blocks are derived.
So if you look at this picture, you see this specification, and then you see, at the stage, it really should be-- should not matter what is analog, what is digital. You you're just modeling your entire system. And then of course, when you start implementing it, you start divulging, there might be some specific tools that you might run for doing a digital implementation.
You might want to say, I have this RTL. I'm going to go with an RTL flow. And then you have schematics for your analog portions, and then I'm going to go with the schematics [INAUDIBLE] flow. And then finally, there is that integration and tape-out.
So this is giving you an idea, in terms of what might be the tools that might be [INAUDIBLE]. What-- it's-- for implementing this, we don't want it to be a pie in the sky. But there are specific tools out there to help you implement a top-down framework for doing mixed-signal design.
So you start with something called a mixed-signal block set. So this is a product that we announced earlier this year, and essentially, it gives you an ability to explore various architectures off various analog mixed-signal blocks. We'll talk about that in a little while.
What [INAUDIBLE] care about, in terms of trying to model things at a high level of abstraction, there's issues of impairments, non linearity. You want to capture as many of them as possible, because remember, you want to make sure that your system that you're implementing starts to work at a high level at a very early stage. You want to be able to do fast what-if analysis. You want to trade off one block with the other and see what's the effect of that on the overall system.
And then you obviously have Simulink. I think a lot of you might have actually run Simulink. It's a way to make sure that whatever models that you-- as part of your tradeoff, as part of your what-if analysis from the mixed-signal block set-- you can validate those models in Simulink with a continuous time simulation. So it's going into a little bit of detail, but you're still at a fairly high level of abstraction there.
And then you want to do something like, I'm pretty happy with the way my analog mixed-signal system looks like, but now, I'm going to start going into my implementation environment. And this is where we have some capabilities that can export out this information in your favorite behavior language. In this case, it happens to be a SystemVerilog, and we can take the SystemVerilog, export it out, and then you can actually start doing the simulations in a virtual environment using something like AMS Designer or Specter or UltraSim or whatever it might be.
And once you're in Virtuoso, it's all about, you started with this behavioral modeling netlist that you had created in Simulink, and even before that, you created in mixed-signal block set. And then you want to start driving down the implementation detail, so you drill down those schematics. You might want to think about how I'm going to extract the parasitics once you go into your layout.
And then once you extract-- once you simulate that, there's this whole process of how do I do this block by block implementation, but I still want to be able to simulate the whole system. So the way you can do it is by a co-simulation process. So essentially, have this entire system running in Simulink, and each block might be getting refined, and each block might be running a detailed simulator there. So that's one way, through superposition, you can go block by block, and eventually verify this whole complex system.
So let's drill down a little bit into what-- how you can do top-down design and modeling and analysis for PLL. So what we are-- what we are showing here is a top level view of what a mixed-signal block set looks like. So what you see here is, at a high level, you have a PLL testbench, and then you have one implementation or one model of a PLL. So in this case, it's a fractional delta sigma-- it's a PLL with a fractional delta sigma modulator.
So what you can see here is, you have a stimulus driving that particular design [INAUDIBLE] test, and then you have different ways of showing things like phase noise analysis. You can do open and closed loop analysis. You can actually start modeling a lot of the impairments into this high level representation of the PLL.
And last but not the least, these models are fully white box. So what it means is, you pretty much can drill down into that, and you know exactly what that architectural model looks like. And you can go and modify it, and you can do what-if analysis. And you can run things at a high level, and then you can go to your next level of abstraction there.
So in terms of exploring various PLL architectural models, the mixed-signal block set-- there's a growing list here. We started out with a few, but there is a bunch of things going on in the R&D pipeline there. But in this particular case, for example, you can replace this dual modulus prescaler with anything else that you might want to use, and maybe a flash ADC or a SAR ADC perhaps, and then see what it does to the rest of your system.
And we talked a little bit about the impairments, and this is a pretty powerful feature actually. I mean, it-- you can pretty much bring in a lot of these impairments that are built into the mixed-signal block set-- for example, things like jitter. It could be a bunch of jitter. It could be phase noise.
It could be things like PLL lock time. Phase noise-- you can bring in phase noise profiles into the system. And on top of this, if there is anything else you want to bring in, there's always MATLAB running under the hood. There are ways and means that you can actually bring in all those impairments at this level.
And then you basically configure each PLL component and run. So in this particular case, you have this phase frequency detector. You have this charge pump. You have this VCO prescaler loop filter, et cetera, et cetera.
So you can actually go and configure each of these in terms of the specific parameters that you want to specialize in. For example, you can say, this is-- you can specify some system specs. You can say, there is in a loop bandwidth. You can define what your phase margin should be, just as an example.
You can also bring in various loop filter types. In this particular case, this is a third order passive filter. And by the way, that could be designed using a filter designer that's available within the Simulink environment, so you can bring in those filters there.
And you essentially are running a pretty fast simulator here, which is actually much faster than Simulink. There's some mathematical magic going on behind the scenes. So you get almost the same accuracy, but a large speed up, so that you can do this tradeoff in terms of what-if analysis. And then you validate that architecture in Simulink, and this is where you run a more detailed solver in the continuous time domain.
Once you have this capability of-- once you have said, you have validated that model in Simulink, the next step is you want to start thinking of exporting that model into something like Virtuoso, or it could be maybe a synopsis environment. It could be a [INAUDIBLE] graphics environment. As far as we're concerned, we're pretty agnostic in terms of what [INAUDIBLE] implementation environment you choose, and the reason is as follows.
So we generate standard SystemVerilog, and that should be applicable to pretty much any simulator downstream. It should be something that can be read by a [INAUDIBLE], by a VCS, by an AMS designer, and you should be up and running. So in this perfect example, you see this PLL, and the first step is to actually generate C code.
This is something that we are very, very good at. We are very mature at generating C code from Simulink blocks. Our C code can be targeted to various platforms.
It could be NVIDIA GPUs. It could be FPGAs. It could be various other environments out there, including targeting something like a SystemVerilog, in this case, as we'll see that.
And this kind of code has gone into the Mars Rover. It's gone into all automobiles that you might be driving out there. So it's very, very tried and tested C code that gets generated here.
Once we generate the C code, we compile it into a shared object or a dynamically linked library, whether you're running in a Linux environment or Windows environment. And we have the ability to wrap a SystemVerilog wrapper around it. The main purpose of that is to make sure that the SystemVerilog can drop into your verification environment directly without any modifications. And finally, you run-- in this case, I'm showing that you're running AMS Designer, which-- incisive, whatever you want there.
So you've got to a point where you have this behavior netlist in Cadence. Now, you start-- imagine that you're starting to drill down in the implementation of each block in Cadence, but you still want to keep-- you need to know how your system simulations go there. So we have this ability to do a co-simulation.
So essentially, in this particular case, what we are doing is, there was a charge pump here, where we are replacing it with something we call a coupler. So a coupler is essentially a-- it's an element, which deals with moving the data back and forth. So as you can imagine, there would be similar coupler on the Cadence side, which is implemented as a Verilog AMS module, and as the simulations go, so there is co-simulation happening between Simulink and AMS Designer.
So this is a detailed representation of that, in this case, you see this Cadence coupler here, and this is the charge pump. And you can see the overall PLL that's actually being simulated in Simulink, and then that particular block is getting simulated within-- in this case actually, within Inspector, but you can simulate it in AMS Designer as well. So there is that handoff that's automatically taken care of. We have a deep partnership with Cadence, so we've been able to implement this.
And it is particularly useful as you go-- as your systems get more and more complex, you want to go [INAUDIBLE], where you can actually take each block and then do a code simulation, making sure that you have the overall system's perspective in mind. And that's actually a very, very powerful feature. Talk to me offline. I've seen this happen in real life. I think it can be very, very effective.
So we probably won't have time to talk about the details about the ADC, but feel free to talk to us or visit us at the booth. We can show you a demo of how to do the ADC here. But it's a similar process here.
So you explore the architecture using mixed-signal block set. You validate the model using Simulink, and then you export out the model into Virtuoso. And then you do a code simulation between Simulink and AMS Designer.
And there's this last piece that we've not really talked about, have we? How do you define the model? So it's a little bit of a change from what our main topic is, which is top-down. So you gotta do a little bit of bottoms-up. I mean, it can't be always ideal.
So there is some bottoms-up going on there, which because the inherent nature of [INAUDIBLE] design, as you all know, is iterative. There is top-down, but you do want to have iterations. So that's what this enables, and we'll talk a little bit about that.
So essentially, what we have is we have a pretty fast data exchange infrastructure between Cadence and MathWorks. So it can pretty much suck all the simulation data and then take it into the MATLAB environment. And then once you're in the MATLAB environment, you can do various things with that data. You can-- the simplest thing you can do is make use of our very rich visualization capabilities. But you could also, through a whole slew of post-processing features that we have in MATLAB and Simulink [INAUDIBLE], including model refinement.
So there are a couple of ways that you can run this infrastructure. One is, you can be in your Maestro environment designing your testbenches. And then [INAUDIBLE], a lot of you doing this work would be familiar with how to do-- how to create measurements. You could do it in scale. You can create it in Ocean, and you can create in MATLAB.
So if you have a MATLAB-- so it supports a full MATLAB syntax there, and you could-- and once you run it, your MATLAB can run in the background. Brings back the results, and then it'll be just like any other results that you look from your Maestro environment. Or you could be running Vivo at the end of the day to visualize the results all within the Cadence environment.
But what you could also do, which is actually a very powerful feature, is you could hit that button there, which that's the M button. So you bring up MATLAB in the foreground. So what it does is it essentially creates an object within the MATLAB workspace, and you pretty much now can do whatever you want-- you've been doing with MATLAB using that object. We call ADE info object.
And this is the whole slew of stuff that you can run, things like you can do machine learning. You can do stats. You can design a neural network. You can do various control systems, algorithms. There's no end to it in terms of what you can do there.
This is an example one of our customers, Texas Instruments. I know these folks very well. I actually worked with these guys when I was at TI.
What they've done is, they've actually taken the simulation results coming from the Specter run using Maestro, brought it back into MATLAB, and then they actually created these surrogate models. You heard about surrogate models if you were there at the talk by Chris Chang, HP Enterprise. So this is one way to create the surrogate models.
You have a lot of simulation data. You take it back into MATLAB, create surrogate model using machine learning, and then what these folks did at TI was they actually used some global optimization tool box. And they were actually able to optimize certain analog circuits. They were able to effectively size transistors, for instance, and then they were able to say, we will migrate that particular analog block to work in a different process node.
So process migration is a pretty key thing. It's a mundane task. You don't want designers to be spending their cycles on that, so you have the automation to do that.
So in terms of summarizing, what's a top-down AMS tool flow methodology? So you start with SerDes tool box. Barry talked about that earlier. There is the mixed-signal block sets, so whether it's an equalization block, whether it's blocks like a PLL or ADC for instance. You explode the architecture, and then you validate in Simulink.
You export it out as SystemVerilog. And by the way, this supports real number programming in SystemVerilog. So if you know what that is, you can actually run event driven simulators in the Cadence environment, like [INAUDIBLE] or VCS and synopsis, but then you still get the analog effects. That's the key behind real numbers. So all that is fully preserved there.
And then you run it in Cadence, and then you go through your Simulink Specter co-simulation to make sure that you have verification coverage at the top level. You don't want to do this bottoms-up. I mean, it'll take weeks to run it, and you can't have coverage. So this is one way to verify the entire chip. And by the way, this is the path to get back that simulation data with your post layout results, post layout simulation, back into MATLAB so that you can go and further refine and optimize those behavioral models that you started with.
So there's a couple of things I want to leave you with. So this is AMS and MathWorks, so we're putting a stake in the ground. I mean, we are going to be a serious player in analog mixed-signal. We have a strong partnership with all the EDA vendors out there, but this is a place to start as your mixed-signal system start to get more and more complex.
So [INAUDIBLE] batteries included, you run either SerDes tool box or mixed-signal block set. You have full access to all of this collateral. For example, you look at the PLL, you have a full tutorial there, and you have various behavioral models included along with impairments. And that's true for things like ADCs.
You saw Barry's presentation with respect to equalization, and there's also switchboard power supplies. We don't have full support for that in mixed-signal block set yet. That's the future direction we are going. We want to make sure that you can be provided with all of the analog mixed-signal building blocks, so that you can start designing complex AMS systems at a high level of abstraction.
So some other resources, I'll leave you with. Some of them are self based learning, so there are MATLAB and Simulink for you know mixed-signal systems. There's a very, very detailed website. There's Onramp courses available online completely, Simulink and MATLAB.
And we can come to your site if you want to do a full fledged hands-on workshop either on SerDes or AMS or anything that you saw today between this talk and Barry's talk. And we have regular consulting pilots, support, whatever it takes to make you successful. Thank you very much.
Related Products
Learn More
Featured Product
Mixed-Signal Blockset
Select a Web Site
Choose a web site to get translated content where available and see local events and offers. Based on your location, we recommend that you select: .
You can also select a web site from the following list
How to Get Best Site Performance
Select the China site (in Chinese or English) for best site performance. Other MathWorks country sites are not optimized for visits from your location.
Americas
- América Latina (Español)
- Canada (English)
- United States (English)
Europe
- Belgium (English)
- Denmark (English)
- Deutschland (Deutsch)
- España (Español)
- Finland (English)
- France (Français)
- Ireland (English)
- Italia (Italiano)
- Luxembourg (English)
- Netherlands (English)
- Norway (English)
- Österreich (Deutsch)
- Portugal (English)
- Sweden (English)
- Switzerland
- United Kingdom (English)
Asia Pacific
- Australia (English)
- India (English)
- New Zealand (English)
- 中国
- 日本Japanese (日本語)
- 한국Korean (한국어)