Reproducible Emulation of Analog Behavioral Models

REPRODUCIBLE EMULATION OF
ANALOG BEHAVIORAL MODELS
Frank Austin Nothaft
fnothaft@broadcom.com, @fnothaft
Broadcom Proprietary and Confidential. © 2012 Broadcom Corporation. All rights reserved. 1

INTRODUCTION
Several trends are impacting mixed-signal ASIC design:
1. SoC integration drives more features per chip chip size is getting larger
and designs are getting more complex.
2. Analog functionality is moving into the digital domain and digital functionality
is moving into software
3. Software bring-up now takes more time than hardware bring-up.
Traditional AMS simulation techniques do not scale to large ICs.
Even if simulations did scale, they’re too cost-prohibitive to use for
“simulating” software running on top of hardware.

FIXING VERIFICATION SCALABILITY
Hardware simulation is moving away from AMS simulation engines.
Mixed-signal IC verification is becoming a digital problem:
Abstract analog behavior with detailed behavioral models.
Digital verification environment has much higher throughput and allows much
richer test setup and modification
Digital achieves high coverage, while analog simulation is used for targeted
cases.
Verify software using an emulation platform:
This is a traditional approach for digital systems and requires synthesizable
RTL.
Analog behavioral models, however, are not synthesizable.
Rewriting analog models as synthesizable code is time-consuming
and error-prone.

HOW IS MODERN AMS VERIFICATION RUN?
Setup: large (“big-A, big-D”), highly interconnected design.
Analog:
Analog top-level only runs DC and transient simulations.
Directed simulation of “important” modes.
Simulation time and convergence difficulty limits further use.
MC, PVT, and extracted simulations run at “block” level (e.g., LNA).
AMS:
Varies a lot; for us, use is generally limited to specific subblocks (ADC/DAC).
Digital:
Digital teams are running a lot of mixed signal verification.
Use behavioral models to make analog useful in the digital environment.

ASIDE: ANALOG BEHAVIORAL MODELING
Use the SystemVerilog real number type to represent the behavior
of analog systems:
Decompose systems into “digital-ish” abstractions (e.g., an IIR filter).
Can be both similar to and highly divergent from Verilog-A/AMS…?
module filter (
input real in,
output real out,
input rval
);
real r = 10e3 + rval ? 10e3 : 0.0;
real c = 1e-12;
real T = 1e-9;
// Use Tustin transform @ 1 GHz
logic clkSamp;
real n0, n1, d0, d1;
real a0, a1, b0, b1;
// assign filter coefficients
assign a0 = (T / (r * c)) / b0;
assign a1 = a0; // symmetric
assign b0 = (2 + T / (r * c))
assign b1 = (2 - T / (r * c)) / b0;
// generate clock
initial begin
clkSamp = 1'b0;
forever begin
#0.5 clkSamp = ~clkSamp;
end
end
// IIR filter
assign d0 = (n0 * a0 + n1 * a1)
- (d1 * b1);
always @(posedge clkSamp) begin
n0 = in * gain;
n1 = n0;
d1 = d0;
end
endmodule
For a large design, the RF model is approx. 100k LOC, 350 modules.

BEHAVIORAL MODEL
SYNTHESIS

BARRIERS TO SYNTHESIS
1. Working with floating point code:
Floating point IP is expensive, if it is even available.
If you can’t use floating point IP, what do you do? Convert to fixed point!
2. Timing constraints, redux:
The faster you sample your analog datapath, the slower you simulate.
3. Clock propagation:
Behavioral modeling generally relies on generated clock sources.
Where do these come from?

FLOATING FIXED POINT
Much work has focused on the problem of converting systems from
floating to fixed point.
In general, this is difficult: when is it acceptable to trade off accuracy?
In the verification context, a key observation:
We know how much accuracy we need!
And we know where accuracy is key.
Approach:
Use pragmas to set sensitivity requirements:
//{!} sensitivity –signal inp –max 1.2 –min 0.0 –resolution 0.01
Once sensitivity is identified, use pragmas to annotate gains, and solve the
constraint satisfaction problem.

TIMING FOR IIR FILTERS
The majority of clocked blocks in analog models are IIR models of
filters.
May run very fast (1 GHz) to achieve accuracy on high-bandwidth filters.
The parallelization of FIR filters is simple; extend this to IIR.
Use a pragma to detect the IIR filter, then k-parallelize to reduce the
sampling rate below the constraint without trading off accuracy:

PERFORMANCE
Large speed-ups:
3.6Mx speed-up vs. analog top-level simulation.
121x speed-up vs. RTL-level simulation.
These numbers represent running at 1/3000
th the speed of real life.
Speed-up is limited by the clock period:
With optimization to behavioral models, ~4-5x further gains can be achieved.
Performance enables capabilities:
Not performance for performance’s sake! (Although, that is good too…)
Able to perform end-to-end, closed-loop verification of firmware running on
an ARM core through a modem, which was controlling a 500k transistor RF
transceiver.

LIMITATIONS
A limited range of arithmetic is supported:
Cannot support division or arbitrary exponentiation at run time.
Generally okay; most blocks that need this can leverage precomputation.
PLLs:
Detailed PLL models run very fast, O (50-100 GHz).
Assertion: should be able to move PLL model into phase domain for emulation.
RFPLL loop bandwidth in phase domain is generally 100 KHz, which meets
timing requirements.
However, we still haven’t been able to get this to work in practice for emulation:
How to handle ΣΔ-modulators?
Clocks become phases. How do you drive digital blocks?
Open questions here…

SIDE COMMENTARY

FUTURE WORK
Verifying PLLs is still very difficult:
For RF, there is a huge state space to check.
A closed-loop system makes it hard to verify components in isolation, and is
slow to verify the whole loop put together.
There is increased interaction with software, but it’s difficult to emulate.
Decreased use of AMS simulation:
AMS simulators are difficult to use, and not performant.
AMS HDLs work poorly with the digital environment.
SVDC: does this signal the end of Verilog-AMS?
Cosimulate earlier:
Most big, bad bugs are at the interface of analog and digital.
Can HLS-like techniques be applied to analog?

CHOICE OF PLATFORM
Proprietary vs. FPGA?
1. Cost (money)
2. Cost (time)
A proprietary platform simplifies debug and test setup saves human time.
FPGAs are generally faster (approx. 50-75 MHz simulation clock vs. 1 MHz).
3. Cost (capacity)
If you can’t fit your design into a single FPGA, multi-FPGA systems are
difficult to use.
General sweet spot:
FPGAs are really good for high-coverage testing of synthesized logic
(running vectors through DSP).
Proprietary platforms are really good for broad system simulations.

ACCURACY
SPICE-level accuracy is not important for (most) behavioral models:
1. Closed-loop simulations are done to verify gross system behavior. E.g.:
Does the firmware sequencing trigger in correct order?
Can DC calibration get a filter out of deep saturation?
2. System models struggle to achieve accuracy within several dB…
3. …because ASICs are used in many different configurations.
LTE cellular has a ballpark of 64k different RF channels.
It’s impractical to characterize distortion in a transceiver across 64k RF channels.
If you can’t characterize error, how do you quantify accuracy?
4. Top-level SPICE struggles to achieve accuracy!!!!!
It’s very difficult to run top-level sims with extraction, across PVT corners, etc.
Horowitz et al. proposed a method for proving the validity of an
analog model via checking linearity vs. a circuit:
The method is limited to linear circuits. What if the non-linearity is important?
What if I’m concerned about response time or other dynamics?
That being said…

YOU DO NEED TO BE CLOSE ENOUGH…
We don’t see real value to formally proving validity, but a wrong
model is a dangerous model.
General premise is, what does “correct” actually mean?
To borrow from the digital world, we use an assertion-driven
method to regress models against designs:
Mixed-signal verification is a game of tradeoffs: be as accurate as
necessary, and not a smidge more.

ACKNOWLEDGEMENTS
Luis Fernandez contributed significantly to implementation and
automation/reproducibility of emulation system
Stephen Cefali contributed work towards PLL control loop
Nishant Shah and Jacob Rael have led RF modeling methodology,
contributed to early prototype design
Luke Darnell built significant early FPGA prototypes
Thanks to Paul Mudge, Igor Elgorriaga, Alireza Tarighat, Bob
Lorenz, Raman Dakshinamurthy for discussing and motivating
implementation

Reproducible Emulation of Analog Behavioral Models

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Reproducible Emulation of Analog Behavioral Models

Similar to Reproducible Emulation of Analog Behavioral Models (20)

More from fnothaft

More from fnothaft (14)

Recently uploaded

Recently uploaded (20)

Reproducible Emulation of Analog Behavioral Models