mixed-凯发k8网页登录

welcome to this mathworks webinar titled "mixed-signal designed with matlab." i've heard this event is run across quite a few different times zones, so thank you all for taking the time out to join. just to introduce myself, my name is ganesh raj rathinavel. and i work from the mathworks office in the netherlands as a pan emea application engineer specializing in our analog mixed-signal design and signal integrity workflows. i closely work with all of our semiconductor customers and partners in this domain.

this talk is intended to give you guys an overview of what is possible through matlab and simulink when applied to mixed-signal design. hence, this talk will be a broad stroke across many intricate features and workflows. my email id is placed on the first slide. so in case you have any questions of today's presentation or need more information on something that you find interesting in today's talk, please feel free to send me an email.

before we start, i would like to make a few logistical announcements. you will receive in a few days an email with a link of these slides. the examples and features that i will guide you through are based out of our latest release of 2020b, which has been released recently. i would strongly prompt everyone to upgrade to it if possible to make the most out of our tools.

your phone lines are muted. please post your questions in the q&a panel, which is indicated by a question mark at the top of screen in your webex window. at intermediate intervals, we will take a few moments to review these questions and have time reserved for a live q&a at the end of the presentation. please stay online.

here is the outline of the entire talk. we will initially discuss to do a quick recap of some fundamental types of mixed-signal designs, which are developed with a well-defined workflow, after which we see what matlab, and more importantly, simulink can be used to coherently construct a system design and see how that can be used later. we would then investigate some prominent modeling approaches that we can use within simulink, and more interestingly, see some live examples of these approaches being deployed. in the second part, we look into how these system models can be used in multiple ways with other eda platforms, and finally, discuss some dedicated solutions at this domain.

just to do a quick recap of a few basic definitions for the broader audience here, when i say mixed-signal systems, i basically mean systems that have both analog and a digital subsystem, which might also be carefully coordinated together over an algorithm. these mixed-signal systems exist everywhere. the microprocessor, also considered to be the holy grail of artificial design-- modern-day chips have a wide range of unique mixed-signal components integrated within them.

just to give you a few examples, a phase-locked loop or clock synthesizers are the beating heart of the entire system, as they create the timing schemes for all the operations. such systems also have a high-speed i/o port, which is responsible to move around large volumes of data from a peripheral, which i will dive into much more detail next. while quite many mixed-signal systems are integrated together, an effective power management solution is also needed to create the right power supply inside all of these subsystems.

another interesting example which is quite needed in modern-day technologies is to have an integrated thermal sensing solution which can typically control your clocking scheme and your power supply to converge the right balance for maximizing the performance when the temperature of the core goes up or down, while, of course, non-volatile memory and data converters are used to store configuration data and convert signals, respectively.

to have a closer look into the high-speed i/o ports mentioned before, we would subsequently call them serdes systems, which is short for serializer deserializer, which is slightly a special case of a mixed-signal system incorporating some aspects of rf and dsp system. but typically, these serdes systems attempt to push parallel data in a serial fashion at very high speeds, almost up to a few gigasamples per second. also, in most cases, only the data is sent. and the clock has recovered or extracted from the data on the receiver side.

as you can imagine, electrical lines, when a binary or a quantized signal is parsed at such high speeds, there are bound to be some losses in the channel. and many rf effects make it much more tricky to decipher it in the end of the signal chain. hence, a lot of engineering is done to design smart algorithms to immunize the signal to enter this channel, and especially while reading it back, which is done in the form of equalization algorithms. a few prominent examples are ethernet, usb, ddr, and pci.

to have a quick glance on how these systems are made by a well-defined workflow for these different subsystems-- while, initially, when a new mixed-signal system needs to be designed for a certain functionality against a specification, there is a phase of performing system design to analyze and consider the right architecture for the system, after which, specifications for sub blocks are estimated and the system is then bifurcated or separated into distinct sub blocks. the algorithmic part is usually done in a language like c or c . and the additional part is about creating an hdl-- either a verilog or a vhdl code to describe it.

the code is then fed into a semi-automated workflow to synthesize to get a gate-level description. and then a layout is made based on the area that is available, while on the analog side of the mixed-signal system, a schematic is constructed. and then a wide range of detailed spice-based verification is done, and which the layout is then manually laid out.

after all of these separate components are created in these distinct or separate workflows, later, their first partially merged and then later fully merged together. and a top-level verification test bench is needed to see whether, overall, the system works as desired. and this is where it gets quite complicated.

and it is considered to be one of the most time-consuming steps that happens in such a design flow. once you typically notice a few corrections that need to be done in the top-level simulation, there is a huge amount of iterations that are done to change different subsystems. so hence, it becomes quite crucial to do system design effectively before anything is implemented.

here is what we notice when we interact with a lot of our customers, is the fact that a lot of effort is spent in doing top-level verification. and it can be significantly lowered by emphasizing on creating the right specification for each block in the system design phase. hence, the notion of shifting left or moving the verification much earlier in the design cycle is a strong trend that we notice. as different design strategies affect more than one requirement, rapid prototyping is also key.

however, the design space explodes as systems become more complex as embedded algorithms become ever-more increasingly congruable for to operate in different conditions. finding the optimal design by the means of prototyping is also very time consuming. and it's hardly scalable.

and through our platforms, we create the space for enabling designers to do a good job in the system design development phase. by spending more time in developing system-level models in the design phase, you can gain much more insight, deeper insight in understanding the specifications and trying to verify alternate architectures. also, with a lot of automatic code generation capabilities, we enable export of these models well coupled with the implementation workflows such that the entire design can be tied up to the top specification. the coordination routines between these distinct subsystems can also be anticipated well in advance.

quite a lot of times, most design teams also find this a very cumbersome exercise, because this adds delay to the start of the actual implementation process. however, time spent in the beginning phase greatly pays back by shorting the implementation and the verification phase. in this talk, most of the features shown in the right is what we will look in a more detailed fashion in subsequent slides. as summarized by kundert and chang, inventors of the cadence tool inspector, profess in this article that top-level design, especially implemented with matlab and simulink, can be greatly beneficial in managing complex mixed-signal designs.

so what do we mean by top-down design? we basically mean to incorporate a central modeling-based design approach, in other words, leveraging the part of behavioral modeling. and how this is done is we start off with a very simplistic abstract-level model and then later keep incorporating imperfections in to estimate the right specification.

and why is simulink perfect for doing all of this? simulink creates the notion of time and has an extremely sophisticated time-handling engine which gives it a lot of speed in computation of these time-domain simulations. simulink also has a huge legacy to be used in designing feedback networks. and it can be also quite easy to create multi-domain scenarios, as you can choose between a wide range of modeling approaches. more importantly, it integrates well with mainstream implementation workflows, which we will see later in much more detail.

a few modeling approaches you can use within simulink are you can describe your model through sequential code or create a signal flow schematic from blocks in the exhaustive simulink library. also you can assemble a physical model, which is very similar to what has been done in spice, when which you can create parts of a system with a circuit. also, another prominent workflow is to be able to create flowchart-based definitions of a finite state machine.

over the past decade almost, we have been supporting our customers with a wide range of examples in a library, which touches upon all important design products that i spoke about in the first phase of this talk. it is quite a good compilation of plls, adcs, switched-mode power supplies, and of course, serdes. systems. i encourage you guys to have a look by going through the link below the slide if you're using an older release or through the add-on tab on matlab if you are using a release that's much more recent.

let me open matlab and quickly show you a few key examples to illustrate these modeling approaches from the library. go to add-ons. and type mixed-signal blockset models to arrive at the right install link for this library.

here is a model of successive-approximation-based adc. here you will notice the type of solver picked in the simulation by default is a variable-step solver. in this architecture, there is a tag in the feedback loop to converge at the right output quantization level, while which the inputs are twin sinusoid signals which are placed as a stimuli for the system.

the logic part of this system is in the feedback loop described as a pseudo code within this block, which is correlated based on the signals that actually drive it and the transitions based on the construction of this diagram. this block can be easily transformed as hdl code when needed for implementation, but is also extremely easy to share among other colleagues to get a better understanding if there are more than one people contributing to this particular state machine.

moving on to one of my favorite examples from this library is a buck converter from the smps catalog of this library in which a feedback loop attempts to drop 12 volts to 1.5 volts at the output. notice that there are three main components in the system tailored with three different modeling approaches. the switching part of the system is defined with a physical model that switches capacitors and inductors, while the pid controller represents a transfer function. and finally, the clocking part is built purely from simulink blocks.

this other block on the bottom does something extremely interesting, as it injects a small chirp signal along one end of the feedback loop and reads it out of the other side of the feedback loop to construct a transfer function while doing the transit analysis. once we measure such a response, we can insert a state space representation to the measurement and then load the data to control system designer, indicating the difference between what is coming from the pid controller and what is coming from everything else in the system. on doing so, we can in fact modulate the coefficients of the pid controller to improve the stability of the entire loop.

this can be automatically done by asserting specifications as well. once we have these new values, we can later feed them back in the original design and verify this change in the entire transient simulation, hence making it very easy to tune components like this in a feedback loop mechanism. here are the official product names for these modeling approaches so that you can investigate more in our documentation. first, of course, is matlab. second is simulink, the third being simscape, and the last one being stateflow.

another interesting example of applying these modeling approaches is a model that we created for analog devices, transceiver ad9361. this model includes a wideband transmitter, a receiver, and also an observer receiver to enable dpd. you can download this model through the mathworks website by using the link on the left. this model has actually been live validated, making it quite realistic to the actual implementation. the link on the slide can guide you to the right model.

in this part of the talk, we will take a closer look into how matlab, or more specifically, simulink can be used to integrate with eda implementation workflows. cadence design systems, being an important partner for mathworks, i will demonstrate how all of these workflows can be integrated well with the cadence suite. but in principle, few of these options are independent of which environment you might want to use them in.

first, we shall see how simulink models and testbenches can be exported as system verilog models. secondly, we shall see how these models can be simulated together with cadence virtuoso. thirdly, this is a more recent option. it's a more bottom-up approach in being able to import a spice netlist and then map it internally with simscape or simulink. and finally, we shall see how matlab can be invoked with cadence ade explorer such that simulated data can be used within our platform.

as stated in the previous part of this talk, we mentioned that simulink models can be exported as c code and then subsequently wrapped by a dpi wrapper which can then be imported as a standard system verilog module. as you already guessed, to achieve this, we must convert this model into a fixed time step before the export, as the dpi wrapper is used to execute the c code in the right time frame.

as c code has no notion of time, the dpi wrapper must be finely sampled such that the error is insignificant. this makes the model easy to translate as the behavioral model quickly, rather than recreating it in another language manually. as these models are executed in native system verilog blocks, they run much faster than spice equivalents.

the generated code is independent on which platform that you might choose to run it. also the automatic code generation relies on a mature conversion engine to provide real-number models at the interface, thus making it very suitable for testbenches and ic verification for regression testing. the signals supported are both discrete and continuous time, but under the hood, it is discrete in nature of the c code executed, which emulates a finely sampled behavior of the model that you see in the simulink. hence, it works just as fast and just as accurate as a quote in simulink.

another popular method of integration is co-simulation in time domain, here in which an interface block is used in both the platforms performs real-time handshaking to transfer signals seamlessly within both these platforms. the example shown in the diagram is a shipping example in the library mentioned earlier, in which the charge pump and the loop filter of the pll is described in cadence, and everything else is in simulink. upon running such a well-coupled setup, all of the detail effects of the charge pump and the loop filter are factored in into the entire loop response, while maintaining the same timeline.

having high-speed blocks like the vco, or the voltage-controlled oscillator, described as a behavioral model makes it possible to run a top-level simulation setup like this much faster. this is a much needed functionality, especially if you're evaluating minor changes in your design. also, the non-obvious effects of the charge pump and the loop filter later can be used to refine the system-level model without incorporating too many mathematical assumptions.

also a system like this, when it runs in feedback, the entire loop signal converges with an internal co-simulation block, making the use case of such a setup quite relevant when the simulink block cannot be readily used for co-generation. one limitation that i must point out to you here is that we don't support advanced maneuvers like ac analysis. but once you have a good feel for the non-idealities in the block, you can deduce them in a system-level perspective.

another key option that is often requested is to be able to support or import legacy implementation of different blocks. and the most obvious way to do so is to convert these entries of spice netlist blocks within simscape, as both of these approaches are of the same modeling approaches of doing physical design. the command used is subcircuit to ccsc, which converts the subcircuit definition to simscape language components. newer versions of simscape does this transition directly.

a very recent workflow that has been a part of simulink now, recently launched in 2020b, is to enable the notion of bottom-up verification, as it needs to be complete, accurate, fast, and easy to use. in that spirit, we've come up with a new feature called linear circuit visit, in which a netlist derived from a physical spice model can be imported through the wizard.

it is internally solved in closed-form equations, transformed to a bicode filter, and then later on in simulink as a state-space representation. this comes quite in handy when you have to create or validate things like a loop filter for a pll, and even t coils, that are very commonly used in serdes links to post the throughput of the link. the linear circuit wizard is shipped with both of these examples, gives you an excellent starting point to understand this workflow better.

and finally, i would like to also mention how matlab can be invoked by pressing the m button on the latest version of ade explorer and ade assembler, which is once matlab is started, it automatically points to the database of the recently completed simulation. this avoids the manual steps involved in moving the waveforms from multiple scenarios, which can get quite complicated to handle. also, matlab expressions can automatically be launched to post process these results even further.

once these data is imported in matlab as tables, it opens up huge possibilities to analyze and mine data to deduce useful information. we can fit curves, create automatic reports of these results through scripts, employing a wide range of matlab functions to further automate the process of refining the behavioral models and create extensive reports which can be shared with other personnel or even customers. all of the similar features also exists with pspice, particularly useful for pcb designers using matlab separately to do various tasks.

now moving to the last part of the talk, we will have a closer look at some newer products which are dedicated to mixed-signal design and serdes design, respectively. firstly, for folks already on 19a or beyond, we have a new product called mixed-signal blockset, which comprises of simulink libraries of all possible architectures of plls and adcs. these models are all white-box models, which basically means that you can look into them, see how they're implemented by our development team, and then choose to customize them, if necessary. these models are built from building blocks which already inherit well-known impairments in them. and finally, the product also has dedicated measurement blocks and testbenches for characterizing these models and even the external data.

just to give you a brief glimpse into these building blocks of a pll, we have charged pump, pre-scaler, divider, loop filter, phase frequency detector, and a voltage-controlled oscillator, imparting important impairments like phase noise, current imbalance, leakage, finite rise and fall time of signals, a purge editor, and other noise sources like thermal noise and quantization effects.

similarly, the test bench, mentioned earlier, for characterizing these designs, can do a wide range of measurements for plls, things like log time, phase noise profile. and for adcs, we can usually measure non-linearities in the form of inl, dnl, and perform ac and dc measurements for both adcs and dacs described in the block set.

to show you guys how that might look like in practice, here i have an example of an integer and dual model pll, which also is characterized by the pll testbench. parameters for this pll have been asserted by a value prescribed in a commercially available pll from skyworks of the same architecture. as you can quickly verify, the measured phase noise for this model is exactly the same as mentioned in the post-silicon result measurements. the important metric like the vco parameters like sensitivity, phase noise, are all simply extracted from this data sheet with all the rest of the parameters. the example is also shown as an example in the mixed-signal blockset, you can find the description of the entire process in our solution page.

you can find many application-specific examples to get started with everything that is available within the blockset, both for the testbenches and the design architectures. for the serdes designs, again, in 19a, we launched a new product called serdes toolbox which is used to design and analyze transmitters and receivers within the serdes designer app. here i would like to mention is that the tool-- that this is a toolbox and not a blockset. hence, all the components within the toolbox are described as functions of matlab and not constructed with simulink like the mixed-signal blockset.

the serdes toolbox is used to develop equalization algorithms with matlab system objects and contains pre-built blocks like feed forward equalizer, decision feedback equalizer, containers time linear equalizer, et cetera, which are used to perform statistical analysis and time-domain simulations. later, serdes toolbox is used to generate dual ibis-ami models which can run in any third-party channel simulators. this product is shipped with quite a lot of reference designs for high-speed i/os like ethernet, ddr5, and pci gen 3.

to start with, the serdes toolbox is done through an app, which is used to quickly construct the signal chain, and more importantly, do a first check of the architecture and the statistical results. you can also import metrics like back and come. and later, it's exported to matlab, or simulink, or even ibis-ami directly.

recently, an important dimension has been added in 2020b to this app for which the architectures-- the architects can insert jitter parameters in the form of duty cycle distortion, random jitter, deterministic jitter, and sinusoidal hitter, both at the receiver and the transmitter. here you can see the panel which opens up once you press the jitter dialog button on top. now let's see how this works. blocks from the top panel of this app insinuated.

and the plot can be added to see the statistic line. when we select the block, in this case, the dfe cdr, to modulate and change the mode of adoption-- add a few tabs and see the effect in the ber block. the ctle parameters like peaking frequency can be changed to estimate the specifications that we might need for the ctle and how it can improve the cycle workflow.

from the add plot button, we can visualize the pulse response. once we have a working signal chain for our specification, we can later export that in simulink. once we have the export to simulink, we can later go into detailed customizations of each of these blocks. as each of these blocks inherit properties through the app, it gives you a convenient starting point for doing all of these customizations.

you will also find in the top-left corner a configuration block which stores all the global parameters for the models, which will be later used to create the ibis-ami model. the channel model can be changed, as i will show you in the next slide, while all the equalizer blocks are white box. and they can be opened, and understood, and need customized based on user needs.

coming to what is possible with respect to channel model, we can convert a single-ended s parameter file from even measurements exactly like the process shown with the switch mode power supply example earlier. we can use a rational fitting curve for getting a state-spaced representation. hence, we can deduce the impulse response and the poles and zeros from this representation, and later get, an accurate impulse response of the entire signal chain. this can also then be imported into simulink or even the serdes toolbox app.

applying the same concept for the ctle parameters if you have frequency response of an existing implementation, rational fitting can be done to extract the gpz matrix for that ctle, which can then again be fed back to simulink and even the serdes toolbox app. further nonlinearities can be easily constructed with the saturation amplifier at the output of the block.

you can find detailed explanations of both of these aspects in our documentation. also, these examples are published under serdes documentation within matlab. a live script is present to understand this process much better. and this can be later fed into the mask of the ctle in simulink, which leads up one step closer in creating the right amount of customizations that we might want to do before we create the ibis model for our system.

so to do a quick recap, to better understand the origin of the ibis-ami model, the analog part contains details about the drivers, the channel, and the input buffer to create the .ibis file, while the algorithmic part of the model is used to create the .ami file and the dll level which is executed the entire model is run in the channel simulator. as this app is used to verify the statistical part of the system, it is well correlated with the time-domain simulation that is done in simulink. hence, once we have this setup ready, we can easily create a dual model, if required, as both-- for both the setups, the init and getwave for both sides of the signature are available. also, running this analysis, we can do a quick first pass with the statistical simulation and then do a deeper dive with the time-domain simulation, accounting for nonlinearities, until it's introduced by the cdr.

we can then use both of these representation and then create a standard compliant init and getwave based ibis-ami model. later, ami parameters can be inserted through the ami wrapper in case additional parameters are needed. once the ibis model is created, it is standard compliant. and it can run in any third-party channel simulators for correlation and regression testing. this will be done to verify all possible corners or a large family of channel models and ami configurations.

the integration of serdes toolbox-based ibis-ami models with sisoft qcd and qsi through the sisoft link creates a very convenient bidirectional link between these two platforms. and qcd/qsi project can be automatically created from serdes toolbox, thus to back annotate the channel model, stimuli, ami parameters is done seamlessly.

just to see all of this in action, we can take a quick peek into the workflow. here you can, if you double click on the configuration in sisoft export, you would see the ibis and the ami section log. once we have the right parameters, we create the dll, which can complete the models export. we can then see how size of link is used to create a qcd project.

once in qcd, you can control all of these parameters, sweep and run across all relevant corners with a more accurate representation of the channel. once we identify failure cases across a few set of simulation configurations, we can then selectively import them back to simulink, and reproduce the errors in simulink, and look for ways to-- methods to fix this, if possible. to summarize the entire workflow, we start with architecture but the serdes app, perform statistical analysis, then after which we perform and export to simulink for relevant customizations and do verification in the time domain against the specification. then sisoft link can be used to bidirectionally move data and models across these platforms.

in the release of 2020b, we have also added an example of 802.3ck adc-based serdes signal chain, which includes an adc and all the other blocks mentioned in the earlier examples. the ibis-ami model can also be readily exported of this model. this year, earlier in january, our team also published this workflow at designcon 2020 along with folks from intel corporation. here is a link to a video presenting that work from one of the team members from intel at a mathworks conference.

so just to summarize, one, or possibly the most important point that i would like for you guys to take back is that simulink is a perfect platform for doing top-level top-down design approach. the idea is always to start with something ideal and then keep on adding real-world impairments. these system-level models help in optimizing the design before they can be implemented. and as we consistently saw, we can leverage a wide range of modeling approaches to model our system, then subsequently use model export, forming a well-constructed, connected workflow overall.

thank you for your patience. we can now move on to the q&a part of the talk. please post your questions on the q&a panel. and we will take a few moments to review them and come back online to answer your questions. thank you.