The Designer's Guide Community Forum

The Designer's Guide Community Forum
https://designers-guide.org/forum/YaBB.pl
Modeling >> Behavioral Models >> Caveat macro-models
https://designers-guide.org/forum/YaBB.pl?num=1131031406

Message started by Visjnoe on Nov 3^rd, 2005, 7:23am

Title: Caveat macro-models
Post by Visjnoe on Nov 3^rd, 2005, 7:23am

Hi,

I'd like to pose a question about macro-models that has me puzzled a bit: already several people in this forum have stated that macro-models are the cause of many frustrations.

I myself also have had some bad times struggling with macro-models (e.g. introducing a hard non-linearity (clipping) in an opamp model caused simulator non-convergence...still not sure what caused this...).

My question now is as follows: how come? :)

I mean: why do macro-models cause these kind of simulator issues? Why do they pose more difficulties to the
SPICE algorithms than e.g. transistors models?

If anyone could provide some insight, this might lead to more efficient modeling and/or debugging :)

Kind Regards

Peter

Title: Re: Caveat macro-models
Post by jbdavid on Nov 3^rd, 2005, 9:16am

In my viewpoint,
1. Macro models were a way to get spice to do something it was not originally designed for..
behavioral modeling.
2. Spice is a poor language for describing behavioral models..
I took a liking to Spectre many years ago, because the simulator was designed to accomodate a good number of the issues that made macro models difficult to use in spice.. I assume spice has nearly caught up..
From the days that I started learning SpectreHDL, and then Verilog-A I stopped using macromodels, because
I now had a language where I could CLEARLY indicate my modeling intent.. and get the signals I wanted.

so for me, the difficulty of macro-modeling is similar to the difficulty of hitching up the buggy to the horse for the trip to the office..
NONE.. its not how I get things done any more!

Good luck!
Jbd

Title: Re: Caveat macro-models
Post by Eugene on Nov 3^rd, 2005, 10:11am

Jonathan,

I don't agree 100% with your position on macro models but that may have to do with what we call a macro model. I think of a macro model as a combination of behavioral models (SpectreHDL, VerilogA, etc.) and passive primitive models that follow the original architecture. Consider an active filter. The macro model might consist of a behavioral version of the op amp, surrounded with passive simulator primitive elements. By staying true to the original architecture, one can split the overall model into static nonlinear models and passive linear primatives. Such a marco model is usually more accurate and easier to build than a pure behavioral version of the complete filter.

Furthermore, if library of behavioral models must be pin accurate, it is often easier to model the building blocks behaviorally instead of building individual behavioral models of each separate combination of those blocks. This approach forces one to follow the original architectures using a library of simpler behavioral models. Again, models that follow the original architecture are what I call macro models.

Where I agree with you 100%, is in the application of the old fashion macro models build completely from simulator primitives, i.e. no VerillogA or SpectreHDL etc. I spent a lot of time doing that in the 80s. It was a real pain. There's actually a book on how to do it for power supplies. Modern behavioral languages have eased that pain considerably.

Visjnoe,
Ken's book on Spectre and Spice has a very good section (4.4.6) on macro modeling that I think will answer many of your questions.

-Eugene

Title: Re: Caveat macro-models
Post by jbdavid on Nov 9^th, 2005, 9:04am

A ha. if THAT's how you define macro-modeling, I do that every time I model input resistance with

module examplewithRin (inp, inn, ...);
parameter Rin = 300;
resistor #(.r(Rin)) RIN (inp,inn);
analog begin
...
end
endmodule

-- then to your original question.. why does it seem to cause so many to have problems? - I would suspect lack of understanding or mis-understanding of the simulator.. (agreeing that Ken's First book is a great resource here)

Why I don't do that more.. probably because each project I've worked on over the years was quite different from any other, and ALWAYS in a separate environment (the joys of being a modeler for hire) .. so it was easier to Re-use code fragments, than complete simpler models.. so far anyway..
AHDLlib, and (now) bmslib (in the Cadence packages) were places to START borrowing, but rarely used directly. (This is an area of dissatisfaction for me.. I want a better environment for writing models.. that's lets me be significantly more productive.. )
jonathan