The Designer's Guide Community
Forum
Welcome, Guest. Please Login or Register. Please follow the Forum guidelines.
Jun 30th, 2022, 12:40pm
Pages: 1
Send Topic Print
Modeling for System level Verification (Read 11659 times)
rajdeep
Senior Member
****
Offline



Posts: 220
UK
Modeling for System level Verification
Jun 26th, 2007, 3:22am
 
Hi all,

I have some questions regarding the 'detailing' required in an behavioral model for running system level verification. According to my small experience the models for running a system level verification need not be that accurate!!
But this is still very vague to me. What to model and what to leave.
Say, if my system is a power management unit with 7-8 LDO and 3 buck, charger, a huge digital controller, plenty of bias generation blocks, my primaty objective will be to model the principal behavior of all these blocks, particulary the regulators, bias blocks, and the oscillator block. I have done this also, and got tremendous speed up. But, what still makes me doubtful is the accuracy of these models. Following are my list of doubts and the possible answers that I can think of. Please rectify me, add your comments as much as possible.

Q1. What need to be modeled?
A: I think apart from some mandatory things, rest depend on what behaviors are required for a top level verification plan. The mandatory behaviors are:
i) Pin accurate model
ii) capture the primary I/O relations. No secondary effects. For example, when the bias connections are proper, and the enabled, an LDO output shoots to its steady state voltage level.
ii) Signal Bounds: Every design assumes some operation range at every input pin. These need to be obeyed. Any violation of these are to be flagged as an error message to the user. These make the models more useful than transistor level view. Correspondingly, the model must guarantee that the output signal levels also remain with the specified bound.
iv) Finite impedence: Only the dc part need to be modeled.

Rest depends on verification plan. For example, LDO output cannot just shoot up, or rapidly pull down. Some startup and shutdown delays should be modeled. But is it necessary to model the exact load transient or load regulation? If I try to model these things modeling will take up some time, with no help in a functional verification of a PMU.

Q2: Only model for transient simulation?
A: I think we only need to build models for transient simulation since a large PMU is verified by running a transient simulation only. Do I need to model the frequency behaviors also?

Q3: How can I say, yes my model is complete?
A: There must be one testbench to test both the circuit and the model. Both of them should match. When the design is not ready, the specification should act as the benchmark.

Back to top
 
 

Design is fun, verification is a requirement.
View Profile   IP Logged
Eugene
Senior Member
****
Offline



Posts: 262

Re: Modeling for System level Verification
Reply #1 - Jun 26th, 2007, 8:06am
 
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.

Back to top
 
 
View Profile   IP Logged
rajdeep
Senior Member
****
Offline



Posts: 220
UK
Re: Modeling for System level Verification
Reply #2 - Jun 26th, 2007, 11:36am
 
Can you please elaborate on the filtering effect? I missed this point in the list of mandatory behaviors.

Thanx,
Rajdeep
Back to top
 
 

Design is fun, verification is a requirement.
View Profile   IP Logged
Eugene
Senior Member
****
Offline



Posts: 262

Re: Modeling for System level Verification
Reply #3 - Jun 26th, 2007, 2:04pm
 
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.
Back to top
 
 
View Profile   IP Logged
rajdeep
Senior Member
****
Offline



Posts: 220
UK
Re: Modeling for System level Verification
Reply #4 - Jun 27th, 2007, 4:41am
 
Thanks a lot Eugene!
I just have one more question on what is the state of the art of such functional verification of a large misxed signal system. Using the models we can achieve speedup to carry out the verification. But then there are so many things to check!! Manual verification of so many behaviors (which are very similar may be) has a potential threat of human error. Lips Sealed

Rajdeep
Back to top
 
 

Design is fun, verification is a requirement.
View Profile   IP Logged
Eugene
Senior Member
****
Offline



Posts: 262

Re: Modeling for System level Verification
Reply #5 - Jun 27th, 2007, 3:29pm
 
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.
Back to top
 
 
View Profile   IP Logged
rajdeep
Senior Member
****
Offline



Posts: 220
UK
Re: Modeling for System level Verification
Reply #6 - Jul 13th, 2007, 6:14am
 
Hi Eugene/all,

I still think it is very much fuzzy in deciding what need to be modeled and what not.
I was modeling an LDO (linear dropout voltage regulator) and a buck regualtor circuit.
Both of these are part of a bigger circuit, a power management unit.
Since, I want to verify the whole PMU and not the LDOs or bucks (these are designed and verified),
I tried to keep my model 'simple' .  For example, I modeled LDO as a set of macro states with transition conditions, defined for the transitions. This helped me to make a model which is independent of the circuit topology!!! This is of great advantage. I did not even model the feedback loop!!! Why I should model the feedback, when there is no need to model the stability of LDO. Remember I'm not verifying the LDO, but the whole system!! But somehow it feels like something very important I missed  :-/    
For the buck I could not follow this method, as its startup behavior is not easy to model by writing equations. I followed a traditional approach. Modeled some of the subblocks and connected them properly. I even had to stabilize the model using compensation. I would have loved to follow the state based approach, because I did not have the extra pain of stabilizing my LDO model.  But then...it was hard.
I would really appreciate some comments from you. Do we really need to model the stabilty/feedback loop of these ckts? I don't see this is helping any way in a system level simulation where I'm verifying the integration rather than the individual modules. Also, feedbacks tend to slow down the simulators. Why model them when not required (except in cases like buck) ???

Rajdeep


Back to top
 
 

Design is fun, verification is a requirement.
View Profile   IP Logged
Eugene
Senior Member
****
Offline



Posts: 262

Re: Modeling for System level Verification
Reply #7 - Jul 13th, 2007, 8:03am
 
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.
Back to top
 
« Last Edit: Jul 13th, 2007, 10:05am by Eugene »  
View Profile   IP Logged
Pages: 1
Send Topic Print
Copyright 2002-2022 Designer’s Guide Consulting, Inc. Designer’s Guide® is a registered trademark of Designer’s Guide Consulting, Inc. All rights reserved. Send comments or questions to editor@designers-guide.org. Consider submitting a paper or model.