Hi All:

When I run transient simulation for each individual verilogA block, the simulation time is pretty short (say around 0.01sec ~ 0.1sec for 3us transient). however, when I connect about 30 blocks together (most of them are verilogA model of digital gates, together with other models such as res, cap, comparator, switch), the total simulation time is about 40 sec for 3us transient. however, the full spice model will conclude within 10 sec. By looking at the output log file, it seems that verilogA model simulation takes much more iterations. I feel something wrong among the interface of blocks, but dont have much clue on what direction I need to debug. I tried to take care of discontinuity issue by feeding piece-linear output with transition filter, so the output didnt complain/warn about that.
As writing this post, I just have two ideas: 1. add large parallel resistance with capacitor, so that the node connecting the cap has DC ground; 2. change the discipline from electrical to voltage. But honestly I don't understand what's going wrong.

Could you please give some suggestions? I know it would be hard without seeing the code...

Thank you in advance
Erik

Erik,

  You don't really mention why are trying model a circuit that simulates in
only 10s. It does not seem like behavioral modeling is required to verify
the connectivity/functionality of the circuit. So the assumption is that you
are using the model to simulate a large more complex circuit. In that case,
you might want to consider the following. In general when using Verilog-A
for functional verification, it is useful to raise level of abstraction as you try
to model more complex functionality. For example, instead of modeling a
non-overlapping clock generator at the gate level, model it as a non-
overlapping clock generator, that is, simulate it as a block box.

  If you can't post the code, can you post a schematic. It would be useful
for understanding whether re-partitioning is an option.

                                                               Best Regards,

                                                                   Sheldon

Thanks all for the prompt response!

Stefan: the transient step I set for both spice and verilogA simulation is the same: .tran 0.1n 3.2u

Sheldon: I agree with you that the current ckt is not slow for spice simulation. I am currently just trying to mimic the behavior of the circuit (functionality and timing) so that the verilog-A block can be embedded in a larger model later. The thing I don't really understand is that I thought an accurate/more structural model will take longer time to simulation than a high level model, but it should still be faster than a pure spice netlist.. The main block that I am modeling is a comparator, two input sources are filtered with 1st RC filters before connecting to the input ports or the comparator. for one input source, it is selecting between two constant values through switches, whose control signal is the output of the comparator through some logic gates (so there are some feedbacks).

Geoffrey:
Could you be more specific on what you mean by smooth functions? I didn't deal with them before. I think what I am going to do now is to go back to the transistor ckts and replace blocks one by one as you suggested.

Thanks!
Erik

You wrote something about smoothing the piecewise linear outputs with the transition filter.  I'm imagining something like

if (x > 1)
 iout = 1u;
else if (x > 0)
 iout = 2u;
else
 iout = 5u;

I(out) <+ transition(iout, 1n, 1n);

So, right at x==1 and x==0, there are discontinuities in the current.  It would be better if you could write a function iout(x) that is continuous in x, and best if that function also had a continuous first derivative.

Erik -
Since you reported an increase in iteration counts, yes, I think the continuous one would be better; with the pwl, the simulator could be bouncing back and forth between two linear regions, neither one of which gives the correct derivative information for converging with Newton-Raphson iteration.

Of course, if the block-by-block replacement points to a different module, you may want to look at how smooth that block is.

I don't have any experience with $discontinuity; I don't know how (if?) simulator vendors have implemented it.  (Most of my experience is with "compact models," which are supposed to be at least C³, if not C^∞.)