 Oh, here we go. Very boring title slide here. Anyway, I'm going to talk about GNU-CAP, the GNU-Circuit Analysis Package, and I'm also going to talk about how analog simulation works to some extent, to the extent that I can do it within the allotted time. So, let's start out with about, well, all right, here's the outline. So, let's start out with how analog simulation works. All right, analog undergrad circuit theory. Everybody remember the Circuits I course, the DC analysis, where you have nodal analysis? That's the basic idea here. Now, in the case of how a simulator works, you take that principle and you'd apply the principle of superposition to stamp the numbers into a matrix. So, if I have a circuit, let's make a current source here and let's put a resistor here and let's put a resistor here. I have two nodes and let's make this resistor 100 ohms and let's make this R2 and let's make that 50 ohms. I would stamp these. If you're doing a nodal analysis, you'd write the equations. If you're doing a simulation, what we do is we go over the net list and you stamp it in. You apply the principle of superposition. So, R1 goes from 1 to 2, so I would take 1 over 100, put it here in the matrix, 1 over 100, put it here in the matrix, column 1, 2, row 1 and 2, column 1 and 2. So, node 1 corresponds to this spot in the matrix. Node 2, this spot. And the connections between them would be on the off diagonals. And so, this resistor would kind of shove that into the matrix. If you actually look at writing the equations, you'd come up with this. And likewise, the second resistor here, this goes from node 2 to ground. I just add it here. So, here's the matrix that I'd solve to do a DC analysis. And this is basically how it all works. We're starting with undergrad circuit theory and taking a component at a time, take this component, this component, this component, and you add it up to the matrix. And then we solve it. And now, in terms of the status of how many simulators got this far, hey, this is something I'd give as a homework assignment. Nonlinear DC analysis, it gets a little more complicated here. What we do is we'll substitute a linearized equivalent. You didn't give me an eraser. You substitute a linearized equivalent here. And if I have a diode characteristic, you know what a diode looks like. I'll essentially make a resistor that makes the tangent line at my guess at the operating point. And I'll stick that in the matrix. And so I'll have a resistance. And the intercept here, or is it this intercept? I forgot which one it is. It gets put on the right side as a constant. And since I kind of guessed where to put this, I might have guessed wrong. So if I guessed wrong, I'm going to try again and try again and try again until I get it right. And that iteration is called Newton's method. That's the way we do it. And pretty much every simulator does this with a DC analysis. And it's kind of standard. The AC analysis is essentially the same thing except with complex numbers. Where we'll do a, if you have a resistor, it's pretty much the same. If you have a capacitor, you do the j omega c thing. And you get the complex number to stamp into the matrix. And so it's solved for every frequency. And now, in the case of a linear AC analysis, that's pretty much what it is. In the case of a nonlinear circuit, like we have transistors or diodes or something like that in the circuit, you get this operating point. You get the actual slope. Because the slope of this curve is essentially the resistance or the actual value of resistance, capacitance, whatever you're going to use. You get that from the DC analysis, from the iteration of the DC analysis. So it comes as a byproduct of computing the operating point. And so when you have an AC analysis, the AC is a linear analysis. But for a nonlinear circuit, you get the linear approximation at the operating point. Every simulator does this pretty much. Now, a transient analysis, you can think of it as being like DC, but you step it in time. We're going to do a DC analysis, and then we're going to do another DC analysis, and then we're going to do another DC analysis. We just keep moving ahead in time. But in terms of something like capacitors, we'll use a finite difference approach to computing what to put in for capacitors. And what that pretty much means is that if we look at the map here, we have the, well, the definition of a capacitor, I equals CDVDT. Now, I can approximate this by, instead of the actual having the derivative, I'm going to make some approximation of the derivative. And I've chosen here to make a very crude approximation of the derivative, where I just take v0 is the voltage we're solving for, and v1 is the voltage at the previous time point divided by the time we're solving for and the time of the previous time point. So this difference here is the time step. And so I can make that substitution as an approximation of the derivative. And mostly they use a better approximation than this one, but I think, but this is a good one for a classroom because it's simple. This one is called Euler's Method. But so if I take this expression and I rearrange it a little bit, I can get it into this form where I have i equals c over h times v0 minus c over hv1. H is the time step. And this part here is a, let's call it a time-dependent constant, meaning that for this particular time point, it's something I computed from the previous time point. So I can treat it as a constant for now. This part here, this v0 is the voltage I'm solving for, and this c over h, hey, that looks kind of like a resistor. So a capacitor is a resistor in parallel with some kind of a current source or maybe a resistor in series with a voltage source. Take your pick, they're really equivalent. And as I step through in time, I just keep updating this source to represent essentially the initial condition or not really the initial condition but the condition at the previous time step. But this resistor part is what I stamped into the matrix. And now inductors are similar in the sense of how you can essentially substitute a resistor and a source for an inductor at a particular increment. Of course, it gets updated every time step giving you the transient analysis. So anyway, the transient analysis is essentially like DC in the sense that it's real numbers. Stepping in time will use a finite difference approximation. And the number that I've called h there is the step size, the difference between the size of the time step. And there's usually some kind of automatic control over the step size. That is, you can just specify a step size and say we're going to use this step size but every let's call it professional grade simulator will make some attempt to compute a step size and just go and use its own. There is a difference in quality of how well the various ones work. This is one of the advantages of GNU cap over the others is that GNU cap, you don't have to give it any clue of what step size to use. It can figure it out. Others, NG spice, you have to give it something to start with and it'll figure something out and it still doesn't always get it right. But Quax tends to be a more steady state stepping that it's fine for small simple circuits but if you give it something tricky it messes up. I mean, just giving you an idea of how the various ones compare here. So anyway, most simulators do this, the quality varies, the flexibility varies. What I mean by the flexibility varies is that some simulators, when you do a transient analysis they always start over at zero and there are some others that, well in GNU cap you can tweak it. I can start it, run it for a while at this time, run it for a while with rough accuracy then stop it, tighten up the accuracy and run it some more, stop it, tighten up the accuracy and run it some more. I can tweak it and interact with it more. Enhancements, one of the things that we haven't, one of the enhancements that, well over the basics that just about everything does, if you look at a large circuit these matrices can get very large and so just about all of the simulators that you'll ever work with use some sort of sparse matrix techniques where they only store the active parts because if I have a circuit with a thousand nodes or what I remember my boss for a while was referring to as a small circuit only a hundred thousand nodes you end up with mostly zeros in this matrix and so generally they'll use some sort of sparse matrix techniques to minimize the storage and so that you don't have to operate on all those zeros. Another enhancement that something specific to GNU-CAP is an incremental solver that since a transient analysis is solving the same thing over and over and over now it's not a transient analysis it's not just solving for every time step but remember it's non-linear so it's also iterating on every time step so you might end up with let's say on the average maybe five solutions per time step and so that's a lot of solutions one thing that GNU-CAP does that the others don't do actually this is the original fast spice the original spice accurate fast spice is that GNU-CAP has an incremental solver so that it doesn't actually solve the whole matrix every time it'll just solve pieces of it in terms of time step control there's a number of things that they look at to determine what time stepping to use almost all of them use use something called truncation error as a means of time step control so remember when I said that we're going to make this approximation that a capacitor is like a resistor and a source that is an approximation and if you want accuracy you've got to make it small enough that the error that's introduced by this approximation is small and so the error that you get from this approximation they call that truncation error and so just about everything uses that as part of the basis for time stepping time step control and other methods that some simulators use one thing that GNU-CAP uses and also the cadence simulator specter uses is that the time step is controlled for curve smoothness so that if you have a let's say essentially how you would control an interpolation algorithm so that the time step is controlled based on the idea that hey assume I want to know the voltage halfway between these two time steps I didn't calculate it but I want to know what it is then anyway how accurate is that and there's a way that you can get a bound on how accurate that is by taking the next derivative and anyway GNU-CAP does that specter does that SPICE does not and it'll tend to give you a smoother curve another thing that some of them use for doing time step control is discrete events or what Verilog A might call cross events that is if I have a voltage cross is a certain point the time it crosses is accuracy controlled and GNU-CAP does that SPICE does not and there are very few simulators that actually do that and it makes a big difference in speed and accuracy if you're doing switching circuits alright S parameter simulation this is one of the big points about quarks one of the things that makes quarks great because it does that and most SPICEs don't and GNU-CAP does not it's kind of like AC analysis but it's based on power it's a linear analysis like AC but it's based on the ideas that you have two port blocks that you give the S parameters of the blocks and it makes a calculation based on that and it's used by RF designers mostly and quarks has it I think Zeiss has it GNU-CAP and NG-SPICE don't we're working on it another type of analysis you might see is something called harmonic balance another thing that GNU-CAP does not have it's a steady state non-linear basically you do the you figure out the non-linear parameters like you would in a transient analysis you figure out the non-linear characteristics at an operating point but not just the first derivative you figure several of the derivatives of it at an operating point and then you do something like an AC analysis that computes harmonics not just the fundamental frequency that you're looking at but also harmonics and it gives you an idea of the distortion in the circuit it's kind of an approximation of the distortion in the sense that it gives you well, harmonic distortion and so you don't get the effect of let's say clipping distortion you get the effects of distortion when you're in the proper operating region of the devices but you don't get the effects of the distortion that you get when you traverse into different regions but it's used a lot by RF designers digital simulation works completely different in terms of the principles of it we don't look at nodal analysis at all we don't look at voltages at all and in terms of time stepping time stepping is completely variable there is no notion of any kind of steady state but rather it's event driven and what I mean by event driven is something happens you compute and something happens might mean that I have an input that changes state and I compute all right what's the effect of this input that changes state and I'm going to queue it up I'm going to say well this is going to be the effect but it's not going to happen right away because in digital devices there's always a time delay going through a device so you don't have any simultaneous equations to solve at all in a digital simulation basically you just say all right here's a change that occurred what does that do and I look at the devices that were directly impacted by those changes and I calculate them and I queue that up and say that well in 15 nanoseconds I'm going to change that and so I got another so I make a note saying that at 15 nanoseconds this note is going to change state well it's going to have some effects too so it's going to propagate and so that's the way digital simulation works and since it's event driven since it only makes calculations when something is changing it only calculates the devices that change it runs a lot faster than analog simulation a lot faster and it's how long it takes to run depends not at all on the size of the circuit but it depends on the number of transactions so because if you have a big part of your circuit that isn't active that nothing is changing nothing is happening the simulator doesn't have any work to do mixed signal analog and digital together you know some people will put gates in their analog library gates and flip flops and stuff in their analog library they'll make a model of it that puts out voltages and stuff and they say hey we have mixed mode that's not so mixed signal simulation means that you have a simulator that actually does the digital that I was just talking about and the analog that I was talking about before that together and it makes a conversion between them and so the conversions between them between the analog and digital one type of conversion is you have analog to digital and digital to analog that is the analog to digital means hey we have voltages we need logic states and the digital to analog means we have logic states we need voltages and so in mixed signal simulation it means you have some mechanism for making those those changes that interface and depending on how sophisticated you want to get some of them will do it automatically some of them you make interface devices and stuff like that GNU CAP actually does it automatically which GNU CAP has always done it automatically and it's something that as far as I know very few others actually handle that part automatically another issue that comes up is the time synchronization and that is since the digital is only actually active at certain times you synchronizing the analog and digital parts can get kind of tricky and but this is one of those things one of those areas that GNU CAP is actually at the lead in the sense that it actually had this feature before even the commercial ones had it because it was a research project in the area which is how the project kind of originated but anyway on the mixed signal I really have to point out just having gates in the library that's not real mixed signal even though a lot of people claim it is Fourier analysis is another type of analysis you'll find in a simulation and basically what this means is that we're going to run a transient analysis to get the results in the time domain and then we'll do a Fourier transform on the results so that you see frequency data and it's good for measuring distortion things like that and so and well Spice has it it's pretty common to have it but the quality of it varies a lot including how useful it is and a lot of what really affects the quality of it is how good your time step control is in the transient analysis because if the time step control and the transient analysis is poor you're going to get noise in the transient analysis and the noise is going to show up big time when you do the Fourier transform of the noisy signal and so this is an area where GNU caps better time step control actually results in a better Fourier analysis because actually well for one another impact on the time step control is not just not just what the signal is doing but what do you want and so if we're going to do if we're going to do a Fourier analysis and let's say I have a let's say I want to know the distortion of an oscillator there's a good one and I have a fundamental frequency of let's say it's one kilohertz and I want to measure up to the I want to measure the harmonics up to 10 kilohertz well okay Nyquist sampling theory I need to run the sampling rate at 20 kilohertz in order to get that accuracy regardless of anything else so that means that I'm going to be running a time stepping a time stepping frequency of 20 kilohertz 1 over 20k is a time step minimum time step just to get the accuracy that I need for the Fourier analysis because I might get a pretty looking picture if I don't do that but but if I don't have that time stepping in the transient I'm just not going to get that accuracy I can print out the numbers but you don't necessarily believe them and so knowing what you're going to do with a transient analysis that is in this case the Fourier analysis is something you have to feed back to the transient analysis to influence the time steps so that you get good results because if you're going to do a Fourier analysis you want it to actually do the time stepping at the points you want the points the Fourier transform wants to have if you do it as a completely wobbly time step where the time step can essentially float and then you interpolate or re-sample to get the time steps your Fourier transform wants you're going to lose accuracy periodic steady state is actually a variant on well it could be a variant on harmonic balance or it could be a variant on the Fourier analysis the popular method that you see a lot is actually something they call a shooting method which is based on the transient analysis and the Fourier analysis and as far as the status who has it, NG SPICE actually has a command to do this GNU CAP doesn't have a command built in but you can write a script to do it and the GNU CAP in terms of accuracy I don't I haven't had good luck in getting good accuracy out of NG SPICE maybe let's say 40 or 50 dB but I've gotten 100 dB in GNU CAP in terms of the noise floor, the accuracy and one thing about it is to give you an idea that one of the if you look at the transient analysis one of the parameters that you get to tweak on a simulator is something called rail tall if you've ever worked with SPICE and had to tweak it you might have noticed the relative tolerance and typically out of the box you'll look at the number for rail tall this relative tolerance that is between iterations how close iterations have to be to be accepted for convergence and they'll give you a number for rail tall let's say the number might be .001 one tenth of one percent you think tenth of a percent that's good well tenth of a percent that's 60 dB so if you're going to use a rail tall of .001 the most accurate noise floor is going to be in the 4A analysis is 60 dB just based on that alone if you want 100 dB you're going to have to use a rail tall tight enough to give you 100 dB noise floor and now of course when I say the .001 to give you 60 dB that's the noise just from that one source of noise you're not going to really get that good so anyway the idea of the shooting method of periodic steady state is that there's a number of steps in this it's essentially a transient analysis basically you start up a transient analysis and you let it run for a while that is you want to let it run long enough for the thing you're simulating to reach steady state because if you're trying to do something like an oscillator or something like that you turn on an oscillator and it's going to take a while for the oscillation to start for it to build up and for its own limiting to come into account so you actually get to steady state so you let your transient analysis run as whatever the thing is you're simulating you reach a steady state and then once you're there you give it a shot you say hey I think the consistency of this oscillator is one kilohertz it's seven kilohertz but I'm not going to tell anybody but I think it's one kilohertz so I'll start out and run it for a while I'll run it with the parameters that I think are right for one kilohertz and then it says no it's not one kilohertz it's six and a half kilohertz and so you're going to go through a few cycles of that so there's an extra iteration process where you get the length of transient with the time stepping to get something and eventually you'll home in on the length of time to run the time stepping to run so that you're going to get so that you'll get something at the frequency that you really care so you're going to have to you try it a few times that's what they call shooting and then once you've reached a point where it makes sense then you tighten up the tolerance and actually make a run at those settings to get your parameters for the Fourier transform that's pretty much what a periodic state entails complex models so far everything I've talked about has been something I can do with resistors and capacitors the complex models are really resistors and capacitors you take basically you take your device and you make a sub-circuit of it resistors and capacitors, some diodes non-linear stuff, well diodes really just a resistor and you make up your equivalent circuit and you figure out the formulas, the non-linear formulas to plug in and so now you have a model and years ago people would code these models in Fortran or C or whatever but lately lately what most people try to do is avoid that and code the models the best thing to use now really is Verilog A for writing your model code and so for that we'll use a model compiler and ADMS is a free open source model compiler that will generate models for just about all of the simulators something that's common with them all GNU-CAP model gen actually is the old GNU-CAP model compiler which I'm trying to update to make it actually work with Verilog see what happened there is that the GNU-CAP model compiler actually predated ADMS but when Laurent was working on the ADMS I figured that hey I got other things to do if he's working on that go ahead go for it I'll move on to something else and so I put mine on the side and then realize after a while Laurent says I'm through with this I want to move on and besides that it didn't do what I wanted to anyway I guess I have to pick it up again so that is once again become a work in progress okay what what is there about GNU-CAP the basis of GNU-CAP is that it was essentially a fast spice mix mode simulator it kind of came out of my PhD research but the basis is spice like it's based on the same theory that runs spice with enhancements to do mixed signal including smart nodes so that it can actually handle the conversion between digital and analog effectively and then also there is there are changes to the transient analysis algorithms essentially the original fast spice including including the use of cues and a fast incremental solver what is there about GNU-CAP that is unique is the use of plugins it was kind of a shot in the dark at the time when I first started doing it but having done it it's something that every free software project should do this is convert as much as possible to plugins and because it's a way of somebody says hey I have this improvement I have a new device model that you should include in your simulator I look at the code it sucks but still there is some good stuff in there and I want to be able to make it available so here is a trade off do I say no I make it not available when it really is worth making available or do I include this code that to be honest isn't very good and it's going to be a maintenance headache well the idea with plugins is that I don't have to make that choice and so GNU-CAP actually lives the actual repository the development of GNU-CAP is on Savannah it's on the GNU site but if you go to GitHub you can just get your account on GitHub you can develop a plugin for it anybody can do this and the plugins are just like native in terms of how they work in fact all of the all of the device models and simulation algorithms and a lot of stuff in GNU-CAP is all plugins even what appears to be native is all plugins it's one of the rules is that anything that can be a plugin must be a plugin and the project practices what it preaches in the sense that all of these devices are all plugins and another thing about the plugins that's neat is that you can have wrappers to be able to use foreign as plugins and one of the neat wrappers that GNU-CAP has is one that lets it use spice models as plugins and by spice models it can use the old Berkeley spice models it can use NG spice models as plugins don't have to modify them at all just kind of wrap it and it works yeah that's what I was just talking about plugin is basically shared object model with a dispatcher which is a lookup method and so so you can have as many of these plugins as you want there's no code in the core that says you're going to have a plugin of a particular type it's just so you can load it up with models so device models are all plugins the simulation methods are all plugins all of the commands are plugins the file formats that it reads are all plugins which means that it has a choice of file formats it will read spice format specter format and verilog out of the box and Felix is working on the Quix format and we have one another plugin that reads a g-schem schematic file directly and these can all be loaded and unloaded by the user interactively and if you have it installed in like an academic lab condition you can let's say the system administrator installs the basic a new cap but anybody who's using it can make whatever plugins essentially make your own custom version but they use a standard DL open interface and it's basically C++ derived classes is essentially how it works and I'm not going to I could go into some detail here but I think I'm going to save this one another thing that makes it work is something that I call the dispatcher that is when you load a plugin just loading it registers it with a dispatcher so that it knows that it's there like I might load a plugin the plugin might be a resistor model and it registers it saying this is a resistor and I make another one that says this is a diode model and it registers it and that's done when you load it and so that's basically a C++ map where associative array type of thing look up the name and it gives you a pointer to it and so in terms of devices you have a essentially a single instance as a plugin and so you can locate devices to build up a netlist it clones it makes copies of it some more code the plugin type some of the things that can be made into plugins devices commands I was just talking about parameter functions for the like you can have inspice.param with some expression those functions can all be plugins measurement functions and behavioral modeling languages and outputs it says here but we don't really have outputs completely working because it's hard almost there and then I already mentioned about wrappers like the spice wrapper that wraps a spice model so that GnuCap can use the C models written for spice as if they were native more wrapper code some of the work in progress in GnuCap one of the hot items going on right now is we call this the GnuXator project the GnuXator project is essentially a merger of the GnuCap and Quixator Quix simulator essentially hoping to bring because when I look at the two side by side there's good stuff either way and both of them can use what the other one has so we're trying to bring them together so that GnuCap would get the RF oriented analysis and models that Quix has and Quix could get the high performance of GnuCap and also the plugins and things like that that's one hot topic these going on another one is updating the GnuCap model compiler to take the verilog input language so that it can be a replacement for ADMS and one of the reasons for that is performance because we're not getting the performance that we like out of ADMS and then output plugins and another thing about the plugins is I'm calling them just in time plugins just in time means that you have something in your command file that might generate something and say hey compile this and so something like let's say the the spice B behavioral source in spice it's interpreted in GnuCap it would feed this off to a compiler which would compile it and give you C++ code back which would run a lot faster but anyway that's pretty much what I have so questions yeah he says we do frequency and main analysis and wants to know if we do wavelet analysis at this point I think the answer is no I don't I'm not really sure but I'm not really sure what you're asking about I don't do anything consciously about it but I'm not sure what it would take to actually do it any other questions yeah the operating flow look like with GnuCap in terms of front ends and back ends that's actually one of the reasons for wanting to hook up with Quix because Quix has that nice user interface that makes it interactive we don't have anything like that usually usually what I would do is maybe use some schematic program that would export either export a spice net list or a verilog net list I'm trying to convince the schematic programs that they really need to be able to export a verilog net list not just spice so I might use something like that to generate a net list and then mess with it by hand and as far as the output I've used that's one of the things that's not real nice is the interface to some of the output viewers but it generates reasonably readable files that you take that and you pipe it to some of the tools there's one called GA I think it is that I've used that's a waveform viewer and I've used that one quite a bit to view the output of GnuCap there used to be something called G wave which hasn't been maintained GA is kind of somebody else essentially picked it up and it's maintaining something and that's what I've been using but this is one of the things that's leading to the working with the Quax project to improve that side Yes It's a niche application but some people modeling musical instruments in real time rely on that and the question was about have I considered modeling the circuits in a symbolic way and the answer is considered yes actually doing something that's another story there's a matter of the time it takes to do it but that kind of brings up one of the reasons for plugins is that it gives you an opportunity to play with it and make it available but also I'm not so convinced that it would necessarily make things faster but I have done a little bit of work with symbolic analysis and which actually brings up another related topic and that is the matrix solver in GnuCap is capable of solving symbolic matrices it's not just limited to true numerics it's a template class so that it'll solve it using anything that you can provide the right operators for and that actually makes it kind of neat for doing symbolic analysis I've looked into it but never carried it through never had the time to really follow through on it Yes Could you say something about system C that you run it? I don't run it but you know it's one of those things oh he asked about system C and I don't run it but it's something that I've looked at and I said wow this looks neat we need to support this and I look at it and say well this is not going to be difficult to support at all but I just never had the time to do it in fact actually one thing that I've considered again not had the time to do it is that system C mostly takes the code and it just what it would mean to support it is a wrapper actually which it looks like it would be actually a lot simpler than the spice wrapper and so given the wrapper hey it look I could make it so it runs system C native well if that's the case we get it to that point and now here's a way of supporting verilog in VHDL as you take verilog and convert it to system C and so I it actually looks pretty attractive but I haven't had the time to follow through with it and actually do it yeah yeah more in terms of the development side how much of the development is done by you and how much how large of a community is there contributing to it it's a fairly small oh he asked how much of the development is done by me and how large of a community there is it's actually smaller than I had hoped actually lately it seems that Felix has been doing most of the development because I've been wrapped up on other stuff but it so there's somewhat of a community that's doing development not as much as I would hope and not as much as I would hope the plugins would have brought on I I see stuff popping up on github that I that looks kind of interesting but so there is some but do you want to join the development community could use some help is the simulator multi-threaded now the answer to that one is the short answer to that one is no a more complete answer to that one is that the answer is no but the code is all re-entrant so that it's just a matter of specking out where to multi-threaded it should not be hard to multi-thread to make it multi-threaded but I haven't had the time to do it that's one one part of answering that another point related to the answer to that question is that even single-threaded the benchmarks that I've made it beats all the multi-threaded ones anyway it beats all the multi-threaded ones using multi-threads with canoe cap only having a single thread and canoe cap still runs faster and so so I I question sometimes how much it would actually accomplish answer your question anything else yes can you speak up a bit is it possible to do multi-domain simulation I'm not really sure what you mean by that um I'm not it does it does have built in conversion between analog and digital in that sense and it of course has the plugins which should make it at least possible to add that now in terms of multi-domain if you're thinking of something like the different disciplines in verilog that's really kind of a cosmetic thing um I'm not really sure how to answer that actually all right yes realistically model right the question is in the digital to analog conversion how are the digital devices modeled and the answer to that is that as of right now it's fairly simple essentially voltage source with resistance type of model with a parameterizable waveform in terms of what can be done though is if you look at verilog how that is done is defined in verilog AMS is something they call a connect module and one of the one bit of work that's a bit lagging because I've had pressure to do other things is to make the connect module itself be a plugin and if the connect module itself thinking of that as a plugin you could write the code to do anything you want but in terms of what's actually built in I mean what actually comes with it is is pretty much the is a fairly simple model oh yeah yeah and yeah that's true and one thing that Canoecap does that's actually beyond the verilog spec is that it can actually the architecture is actually designed around the VHDL concept of separate entity architecture where it can have multiple architectures for an entity and it does have the provision for switching between architectures on the fly which can kind of handle some of that stuff but that's something that really it's something that I was working on pretty seriously a bunch of years ago and it kind of got dropped kind of got pushed aside alright