1. TM
Need of AMS simulation in
Mix IP verification: benefits
and challenges

2. Mix IP
Need of AMS model for Mix IP
Verification.
Challenges in AMS Verification
Randomizing electrical signals
Basic Knowledge of AMS
Issues Caught because of AMS
simulation.
TM 2

3. In Mix IP we have two parts
Analog part:- which is purely analog in nature. It has
electrical and digital signal interface.
Digital part:-Around the Analog part there is a digital
wrapper which has purely digital interface and it drives,
control and collect the analog modules response.
Examples for Mix IP’s :- ADC, PLL, VREG, DAC
TM 3

4. Analog
Part
Avin
Digital Wrapper
Mix IP
TM 4

5. Digital part drives, control and collects the analog response.
So both parts becomes interdependent.
To verify analog part we need proper digital response.
Similarly to verify digital part we need proper analog response
Say if analog model is comparing two voltages and based on which
one is greater its sending a signal bit o/p
In this case in verilog model we can’t model it, and if this o/p is
supposed to be captured and responded back by digital block then
we can’t verify digital block with this model.
TM 5

6. SAR ADC
TM 6

7. Need of VAMS drivers in testbench
Randomization of Electrical signals.
Basic Knowledge of AMS for setting voltage domain and
controlling dumping of electrical signals.
Tool side :- AMS simulation requires fresh compilation and
elaboration every time. *
Sign off by qualification tools can’t be given because most of
them work on signal compilation concept.
Note :-
* Applicable on Cadence tools
TM 7

8. Electrical signals are represents by real numbers.
System verilog does not allows to randomize real number
directly.
So to randomize these real number we had to take a another
approach.
Where we randomized integer to X times the range and then
divide randomized values by X and assign to real number.
By this X we can decide how many bit after decimal is
expected in real number
TM 8

9. rand int P_CH_V_val_x100000;
real P_CH_V_real_x100000;
real P_CH_V_real;
constraint channel_voltage_range_P1
{ P_CH_V_val_x100000 inside {[0:MAX_V_x100000]}; }
P_CH_V_real_x100000 = P_CH_V_val_x100000;
P_CH_V_real = P_CH_V_real_x100000 / 100000;
In VAMS driver :-
output V_out;
electrical V_out;
analog begin
V(V_out,gnd_node) <+ transition(P_CH_V_real,10p,100p);
end
TM 9

10. For driving analog signals from Testbench we again
need VAMS driver.
In drive we pass the randomized real value and from
here this voltage is driven to the Testbench
Then we connect these drivers to the top level pins of
the design.
TM 10

11. For debugging we always need wave from.
These electrical signals are by default not dumped in the
data base.
We need to pass a .scs file to signify the voltage domain on
which a block is working.
The name of the .scs file depend on the hierarchy of design
For Example for hierarchy testbench.top we need a file with
name top.scs
After adding this file it will get the voltage domain
information and will start dumping wave from for all the runs.
To disable this dumping we have to set this option.
amsOptions options save=nooutput
Note :-
• Applicable on Cadence tools
TM 11

12. // analog control file: top.scs
simulator lang=spectre
amsAnalysis tran stop=1 step=1p errpreset=moderate
//amsOptions options save=nooutput
amsd {
ie vsup=3.0
}
// At top instance it will covert all the 1.2V signal to 3.0V
Note :-
* Applicable on Cadence tools
TM 12

13. TM 13

14. Analog Watchdog corner case issue caught :- When the
converted data and analog watchdog upper or lower limit
were matching digital part was giving a wrong result.
ADC offset issue:- It was again similar issue where in rtl in a
compare logic less then was used where it had to be a less
then or equal to .
Calibration sequence issue :- where we had to compare sum
of last two SAR result against some fix values and we had
taken only few bits of summed result in compare logic.
TM 14

15. Q&A
TM 15