I usually model basic functionality first: on/off, digital controls, and gain. For the first cut I even ignore filtering effects. That way you can at least test the complete system to some extent before tape out. As for anything beyond that, I found that it depends on 2 things:
1. How much time you have before tape out.
2. How well the design is "frozen". My experience is that the modeling team is usually too busy chasing design changes to worry about adding new features to the most basic behavioral models.

I build models of RF transceivers these days. All receiver and transmitter chains have baseband filters. For example, a receiver chain might have a 7th order Chebyshev filter to remove jammers before they hit the ADC. I've never come across a system level functional test that included a jammer. Consequently, I've never had a system simulation that required anything but the proper gain and on/off behavior from the filter block. Why bother modeling the finite bandwidth of the filter if no one will notice? Furthermore, we want observable symptoms of offsets between the LO and incomming carrier. For functional behavioral modeling, we usually sample the incoming modulated carrier at the rising edges of the LO so that if the carrier is offset from the LO, we can see the beat frequency in the unfiltered output. This gives us some idea of when the PLL has settled and if it has settled to the expected frequency. If it has, synchronous sampling produces the baseband signal. If it hasn't we see an unwanted IF.

One can model the filters without too much trouble but since the system model is usually implemented in Verilog or C, the analog filters must often be modeled as equivalent digital filters. If the carrier was 2GHz, you will see 4GHz at the output of the downconversion (direct conversion). Nyquist then puts the sampling frequency of the filters at 8GHz or higher. This can slow the simulation, especially if we must increase the sampling frequency to deal with harmonics excited by nonlinear behavior. My point is that the filters do not come for free, they take some care and can slow run times. That is why I don't include them unless there is a specific system test that requires them. I only model in-band behaviors such as gain and on/off.

I have not performed an exhaustive tool search by any means but my experience is that while digital verification is very mature, analog and mixed signal verification has a long way to go. For speed reasons, we mostly use digital simulators and model everything in Verilog (or VHDL). VHDL has a lot more features for modeling analog blocks. It's too bad we can't use them in the Cadence environment. Cadence only supports VHDL features common to Verilog. So why bother switching to VHDL if you must use Cadence?

Verilog pretty much sucks at modeling analog blocks but for a variety of reaons, many of us are stuck with it. The biggest problem is in passing real numbers between blocks.  There are work arounds but they are all fairly cumbersome in my opinion.

There are lots of modeling languages but as far as I know, only VHDL and Verilog help you verify your high level schematics.

As for tools to automate verification, I have seen a lot of tools advertised but have not yet had the chance to try them.

Since we must still build the Verilog or VHDL models of analog blocks by hand, there is plenty of room for human error. I don't see any way around that for now.

The good news is that I don't see anyone automating my job before I retire.

Rajdeep,
You are quite right about the decision of what to model being fuzzy. It is always a judgement call. I often find the decision driven by schedule more than anything else.

My initial comments were aimed at communications systems. There, stability is important but it is not necessarily a key integration issue. (Probably the biggest stability risk in a receiver chain for example is unstable interactions between common mode feedback loops, and I would like to find a good way to assess that risk.)

I think the situation is different for power systems, especially if you are connecting a lot of power supplies to a common bus that is also controlled with a feedback loop. In that case, stability is definitely a risk that should be assessed and I think behavioral models are fully capable of doing the job. When you have one supply driving others, the others present a constant power load to the main supply. About an operating point, the constant power load looks like a negative resistance, which can cause instability. Furthermore, usually the load supplies have input filters to keep them from corrupting the main bus with switching noise. If the aggregate impedance of those filters dips below the bus impedance at any frequency, you can have system level oscillations at that frequency. If you can identify the worst case configurations, you can simply analyze those modes separately. However, if want to be sure you did not miss the true worst case condition that may arise as you simulate full system operation, you should include all the dynamics in your system level simulation.

If you have a large number of supplies, brute force simulation may be impractical and you may have to build state space averaged models. If you want to run the system through all loading conditions, you may have to use dual-mode state space averaged models, models that automatically switch between continuous and discontinuous conduction modes.

You are also right about simulating a large dynamic system with feedback loops being hard, especially if you use behavioral state space averaged models, and esepcially if they are dual-mode models. You may have to solve some convergence problems.

One other thing to keep track of when assessing distributed power systems is common mode emi filters. They can have a large differential mode component that can affect stability too.

The bottom line is risk. If you can be reasonably sure you have identified and assessed the worst case conditions individually and perhaps even in a way that lets you analyze the blocks separately, you can ignore dynamics when simulating system level functionality. If not, then I would go for the dynamic system level model.

Also, if you are dealing with a large power bus, you should also consider simulating fault tolerance. For example, if you apply a short and a fuse blows, you will see a large voltage spike that could damage components. This is very difficult to model accurately because the spike involves parastic inductances. But it may be worth checking to make sure the system recovers, assuming nothing is damaged. Fault simulations should include dynamics.