In many texts and online articles that I have read, there are discussions about the value of behavioral models. The discussion normally goes something like this: Analog design is basically a bottom-up process. The circuit is designed, and when simulations get too slow, due to the integration of additional pieces of the system, it is decided that a behavioral model should be created. This is normally done when the project is facing pressures, and there is little time in the schedule for model creation.
Additionally, the circuit designers are not always very good at creating these models — they are difficult to verify and maintain, and in many cases, they don't run that much faster than fully accurate models. We all know many of the fallacies contained in this story, the principle one being that if you never planned on the creation of the model and made sure that the right resources were available at the point in the process where the model would be useful, then your failure to plan was tantamount to failure before you ever started.
There is another group of people who believe that analog design should be top-down, and that the behavioral model is the first thing that should be created. The argument goes that this is the only way in which proper system-level planning can be performed. In addition, integration issues between the various analog parts and the digital circuitry can be verified even before the first transistor is laid down.
But, the problem here is that an analog circuit can easily be specified and modeled behaviorally that is impossible to build. Thus, the model provides questionable value. As the design progresses, the behavioral model will quickly become out of date and so the only purpose it has provided it is an executable version of an ideal, possibly un-implementable, specification.
Taken alone, there are clearly plusses and minuses to both approaches, although the pendulum appears to be moving from the former to the latter as the preferred way to do things. The issue here is that the models created in the two cases, while both behavioral models, are very different and have different attributes about them.
When a model is being used for system-level exploration, the details about implementation are unknown. In many cases, it is the design tolerances that are being worked out, and an attempt to allocate budgets in a realistic manner. This planning step, while based on experience, is not being done in the dark. However, these models are not encumbered with having to model the implementation exactly. In many cases, this is taken as a requirement when doing a bottom-up model creation. The behavioral model has to match one specific implementation.
On the other hand, a top-down model is modeling the possible behavior of an implementation, which makes it easier and faster to write. Probably just as important is that the integration of this model into a system-level model has created a testbench into which an implementation model could be placed so that it is possible to see how the system behaves with the intended implementation.
My point is that it's wrong to consider these two models as being the same thing, or for it to be possible to morph one into the other. Do not be fooled by both of them being called behavioral models. They are very different, come from a different initial perspective, and are written in different ways. A model needs to be fit for its purpose and only that purpose. To pretend that a single model can be used for everything is expecting too much and will result in a model that fails in every way.
Which kind of behavioral models do you write, use, or think has the most value?