lieuwe/hugo-site
1
0
Fork 0
mirror of https://github.com/lleene/hugo-site.git synced 2025-03-09 21:42:44 +01:00
Code Issues Packages Projects Releases Wiki Activity

update on hugo posts

Browse Source
This commit is contained in:
Lieuwe Leene 2025-02-06 18:58:23 +01:00
parent daf108c6db
commit b28ec4e15a
Signed by: lieuwe
GPG Key ID: 7428510669EA7EF4
7 changed files with 588 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

315
content/posts/2025/analog-verification.md Normal file
View File

@ -0,0 +1,315 @@
---
title: "Analogue Verification"
date: 2025-02-03T09:52:41+01:00
draft: false
toc: false
images:
tags:
- circuit-design
- methodology
- verification
- analog-circuits
---
This page briefly discusses aspects for planning and structuring analogue
verification and some of the inherent issues related with coverage. Most of
the examples will reference Cadence design tools which is common place but
alternative with similar flavors exist. This is somewhat specific to analogue
simulation that validates design from a functional point of view. This ties in
with the construction of the test bench that will probe various aspects of the
design to confirm that is operates as expected.
## Design Sign-Off
Sign-off for an analogue design could can imply a multitude of things depending
its dependency. An exhaustive list of delivery items is shown below. Many of
these are only relevant at certain points in the hierarchy but standardizing
the flow for creating each item is essential for systematic design. This
should allow you develop a check-list automated or manual for certain aspects
in each deliverable that ensure quality.
- Specification Table
- Schematic
- Spice Netlist ✔
- Verilog Netlist ✔
- Layout
- GDSII ✔
- DRC Report ✔
- ERC Report ✔
- LVS Report ✔
- LEF Abstract ✔
- Testbench
- Design Documentation
- Verification Report
- Design Review Checklist
- Digital Timing Model
- Test/Trimming Plan
Fortunately many of these items (✔) do not necessarily require manual intervention
and can for the most part be part of a automated flow that sanity-checks
different aspects of the design.
## Design Flow Automation
Several components in the industry analogue design flow are illustrated below
with their relative association. The verification process only touches a small
part in the overall picture but provides key indicators for many other aspects
of the design flow such as project planning, lab work, and software development.
```mermaid
graph LR
external@{ shape: notch-rect, label: "3rd Party IP" }
requirements@{ shape: notch-rect, label: "Design\nRequirements" }
design@{ shape: cyl, label: "Cadence\nDesign Database" }
reports@{ shape: docs, label: "DRC/ERC/LVS Reports\nCircuit Netlists" }
abstracts@{ shape: cyl, label: "GDSII\nLEF/DEF Abstracts" }
simulation@{ shape: docs, label: "JSON Database\nVerification Reports\nCircuit Documentation" }
labwork@{ shape: docs, label: "Measurement Reports\nRoot-Cause Analysis\n" }
webdocs@{ shape: procs, label: "**Documentation Portal**\nUsage Guide\nDesign Theory\netc."}
spotfire@{ shape: cyl, label: "Characterization Data"}
external ==> design
requirements ==> design
design == NVAFLOW ==> reports
design == NVAFLOW ==> abstracts
design == RDBDOC ==> simulation
simulation ==> webdocs
labwork ==> webdocs
```
Here I have highlighted two integration tools that automate and assist in
generating various aspects of the design sign-off. Some of which are not user
facing such as GDSII and LVS results which are handled by NVAFLOW and is
closely tied to the process-development-kit (PDK). The other tool is RDBDOC
which assists parsing the cadence database in order to generate and template
reports.
The point here being is that when we sign-off at top-level it is not unusual
for a large number of designs to be incorporated. Each of which should be
checked while it is frozen for external delivery. Such a tool can rigorously
generate all outputs systematically while also performing a series of sanity
checks to grantee design quality.
## Verification Plan
Planning analogue verification in a structured manner is challenging primarily
because one must often carefully consider what is important when simulating a
design. It is very easy to exhaustively simulate without actually gaining
confidence in the design.
Typically one would setup a test bench that checks for both specific
performance metrics such as phase-margin in a amplifier and generic performance
metric such as off-state leakage. Here is it good practice to have a base-line
of checks reflecting best-practices. A few examples of design-agnostic checks:
- Supply sensitivity
- Bias sensitivity
- Nominal current
- Leakage current
- Peak-to-Peak current
- Off-state / grounded controls
- Assertions for illegal states
- Distortion / Linearity
- Calibration/Configuration edge cases
- Debug coverage
- Output/Input impedance
It is important to keep in mind that these metrics are a baseline for evaluating
performance at a distance. One can obviously run a simulation an study the
transient waveform in detail but it is usually not feasible to do this over 500+
simulation points. This is why it is important to derive metrics for performance
that accurately reflect underlying characteristics with one or several numbers
that can be judged over corners and montecarlo.
Now as example a typical verification plan is presented that varies
process parameters in order to expose variations and weakness in the design
such that we have a good expectation of what post-silicon performance
characteristics will look like. This plan is divided into three steps with
increasing simulation effort.
``` markdown
This is a baseline where the designer must recognize the best way to stress
aspects of the design and adjust the plan accordingly.
```
### Simulation Corners
Generally there are three aspect to simulation corner definition:
Front-End-Of-Line (FEOL), Back-End-Of-Line (BEOL), Voltage+Temperature. These
parameters are very closely tied to the process and qualification standard the
circuit aims to achieve. Naturally the more demanding our qualification the harder
it is to guarantee performance over coreners. For example we can target a
temperature range of 0° 70°, -40° 85°, -40° 125° depending if we consider
consumer, industrial, or grade-1 automotive qualification in the JEDEC standard.
We distinguish between FEOL and BEOL because these are two different sets of
process parameters that are affected during fabrication that do not correlate
with one another. FEOL generally relates to device characteristics such as
threshold voltage, off-leakage, transconductance, and current drive while BEOL
relates to interconnect and Metal-Oxide-Metal passives such as capacitors and
inductors. A process will specify bias for FEOL and BEOL while the designer
will specify a bias for temperature and voltage. Together a collection of
parameter biases are grouped as corners and used to simulate circuits under
various post-silicon conditions.
FEOL corners will come in a variety of flavors for different purposes and
should be studied carefully. Analog circuits are generally not that interested
in worst-case leakage corners but a worst-case noise corner maybe available.
Analogue is generally interested in FF and SS extremities, sometimes called
total corners not to be confused with the global corners FFG and SSG, to if
trim ranges and bias ranges are sufficient to meet performance requirements.
Separately we should study BEOL corners. This is usually somewhat easier as the
extremities simply best and worst case capacitance as CWORST/CBEST or best and
worst interconnect time-constants as RCBEST/RCWORST. The designer should know
which set of extremes is worst. Typically low frequency analogue will suffer
most from CWORST/CBEST variation. High freuquency analogue and custom digital
may opt to use the RCWORST/RCBEST corners.
Verification can be planned and separated into three levels of confidence,
each with increasing simulation time. It is always advised to select corners
to find the best and worst case process conditions for our circuit.
### Level 1: Corner Simulations
Level 1 focuses on total corner simulation without montecarlo. The purpose here
is to demonstrate a brief overview of passing performance with DFM checks such
as EMIR and Aging. There maybe some back-and-forth with the layout and design
at this point as verification results are checked.
| **VT Corner** | **High Voltage** | **Nom. Voltage** | **Low Voltage** |
|---------------|------------------|------------------|-----------------|
| **High Temp** | | |FF/SS + CBEST/CWORST|
| **Nom Temp** | |TT + CBEST/NOM/CWORST| |
| **Low Temp** |FF/SS + CBEST/CWORST| | |
Total Simulations: 11 + EMIR + Aging
With these preliminary set of results one can pass some judgement over
circuit performance during design review. By including the DFM simulations
here (i.e. EMIR and Aging) the layout will be relatively close to the final
result.
### Level 2: Montecarlo Simulations
Level 2 focuses on presenting a typical distribution of performance metrics
using montecarlo methods. Here we must make an important choice of which mc
corner is used. Generally foundries will recommend to use the global corners:
FFG, SSG, FSG, SFG, and only apply local mismatch. This will yield good
statistical distributions in our testbench metrics and allow use to make
gaussian estimations to limit the number of simulations runs of the same
confidence interval opposed to a unknown distribution. A alternative here is
to use the typical corner and enable both local and global process variation.
| **VT Corner** | **High Voltage** | **Nom. Voltage** | **Low Voltage** |
|---------------|------------------|------------------|-----------------|
| **High Temp** | | |FFG/SSG+CBEST/CWORST|
| **Nom Temp** | |TT+CNOM| |
| **Low Temp** |FFG/SSG+CBEST/CWORST| | |
Total Simulations: 225 with 25 mc runs per corner
### Level 3: Completion
Level 3 is intended to be the target set of corners used to validate a design
across corners using montecarlo methods. This is an exhaustive simulation
job and doesn't quite cover all possible scenarios when combining FEOL+BEOL+VT.
Generally however it will a good representation of post-silicon results with a
high quality testbench.
| **VT Corner** | **High Voltage** | **Nom. Voltage** | **Low Voltage** |
|---------------|------------------|------------------|-----------------|
| **High Temp** |FFG/SSG+CBEST/CWORST| |FFG/SSG+CBEST/CWORST|
| **Nom Temp** | |FFG/TT/FSG/SFG/SSG+CBEST/CNOM/CWORST| |
| **Low Temp** |FFG/SSG+CBEST/CWORST| |FFG/SSG+CBEST/CWORST|
Total Simulations: 775 + EMIR + Aging with 25 mc runs per corner
This set of results ultimately feeds into the test program for the device.
The distributions can be used to set limits and measurement inferences
when binning and sorting fabricated devices.
## Verification Report
Reporting on our verification results should provide a overview on what the
circuit targets where, where the senstivities lie, and how non-idialities
manifest in circuit behavior. Lets discuss a general report structure and
provide an example.
- Design Files
- Simulator Setup
- Target Specifications
- Simulation Parameters
- Simulation Notes
- Results and Statistical Summary
- Distributions
- EMIR/Aging Results
With a ADE result database from Cadence we can export the data using skill
and generate a generic database file that can be parsed and post-processed by
python. This allows us to make a clean report that need minimal user input
while providing a good overview on simulation results external to the Cadence
environment. A cut-down version of such a report is detailed below. Notice
the designer should still contribute certain annotations to the report such
that it is self explanitory.
> # Verification Summary: MYLIB divider_tb
>
> lieuwel 2018-01-01
>
> ## Test Description
>
> This is a preliminary verification report for the divider circuit
> which is a 8-bit reconfigurable clock divider operating on the RF clock
> after the 4x clock divider from the counter module. This test bench
> is intended to verify correct operation for all divider settings.
>
> ## Test: Interactive.2:MYLIB_divider_tb_1
>
> Simulation started on 1st Jan 2018 and ran for 2035 minutes.
> The yield for this test is 100% to 100% (1675 of 1675 points passed)
> Verification state: 1/3
>
> ### Design Setup
>
> Library Name: MYLIB
> Cell Name: divider_tb
> View Name: schematic
> Simulator: spectre
>
> ### Parameters
>
> |Name|Expression|Values|
> | :---: | :---: | :---: |
> |clk_sr|15p|1.5e-11|
> |clk_pw|clk_pd/2|3.333333e-10|
> |clk_pd|4/6G|6.666667e-10|
> |div|0|0:255|
> |vdd|1.1|1.045, 1.1, 1.155|
>
> ### Specifications
>
> |Output|Specification|Pass/Fail|
> | :---: | :---: | :---: |
> |EnergyPerCycle|< 1p|Pass|
> |div_err|-100m - 100m|Pass|
> |div_meas|-|Info|
> |dly_out|< 100p|Pass|
> |fin|1.5G ±1%|Pass|
>
> ### Output: EnergyPerCycle
>
> Sample presents a mixed distribution. Using < 1p as specification requirement.
>
> |Corner|P0.16|P0.5|P0.84|Pass/Fail|
> | :---: | :---: | :---: | :---: | :---: |
> |C_BEST_HTHV|193f|193f, 193f|193f, 193f|Pass|
> |C_BEST_HTLV|168f|168f, 168f|168f, 168f|Pass|
>
> {{< figure src="/images/posts/verification/energypercycle-c-best-hthv.png" title="C_BEST_HTHV" width="250" >}}
> {{< figure src="/images/posts/verification/energypercycle-c-best-htlv.png" title="C_BEST_HTLV" width="250" >}}
>
> ## Summary
>
> Tests pass with good margin
>
> EMIR - pass (pre-TO)

30
content/posts/2025/dynamic-search.md Normal file
View File

@ -0,0 +1,30 @@
---
title: "Single-Bit Heuristics"
date: 2025-01-13T12:31:02+01:00
draft: true
toc: false
images:
tags:
- signal-processing
- digital-circuits
- python
---
``` goat
.
.-. |\ .-.
Vin -->| Σ +--+⨍+------*------->| Σ +--> Digitized Sequence
'-' |/ | '-'
^- ' v ^
| .--------. |
| | H(z) | |
| '---+----' |
| | |
'------------*---------'
```

68
content/posts/2025/mixed-signal-simulation.md Normal file
View File

@ -0,0 +1,68 @@
---
title: "Mixed Signal Circuits & Digital Simulation"
date: 2025-02-04T10:46:19+01:00
draft: false
toc: false
images:
tags:
- circuit-design
- methodology
- verification
- mixed-signal
---
These days it is not usual even for "analogue" chips that we perform digital
integration at the top-level. This is mainly because the digital integration
flow is very well versed in 3rd-party IP integration and providing confidence
in the result assuming well defined constraints. Here I will outline a various
aspects for co-simulation of hard-macro analogue sub-modules in the digital
design flow. Note that in this context full-custom-digital is often also viewed
as analogue as from a integration point-of-view they are effectively equivalent.
## Design Views
As we progress through the analogue design flow, progressively more of the digital
design views can be delivered at each stage. As shown here, first
a functional definition can provided with a behavioral model. This can be in
the form of a verilog netlist where ports are well defined and the underlying
functionality is described using HDL statements. This requires us to discretize
aspects of the design and choose what functionality is implemented
as the end-goal here is digital integration testing.
```mermaid
graph LR
A2(Schematic)
A3(Layout)
A4(Simulation)
A2 --> A3
A3 --> A4
D1(Verilog Netlist)
D2(Abstract View)
D3(Timing View)
A2 --> D1
A3 --> D2
A4 --> D3
style D1 fill:none, stroke:none
style D2 fill:none, stroke:none
style D3 fill:none, stroke:none
```
Subsequently an abstract is generated based on the layout. Naturally
this is used for floor-planning and place & route tools that realize a physical
design. There are some minor nuances here such as pin definition and keep-out
areas that will constrain the digital tools. However the key checks are simple:
are all pins defined and accessible, and is there sufficient clearance to the
boundary to avoid metal spacing violations.
Finally a timing view can be generated depending on how the underlying circuit
is constructed. This process is slightly different when looking at a
circuit where we interface directly with custom digital or transistor level
elements. It is advisable to avoid this specialized part of the flow because
it will require us to resimulate and perform our own characterization of the
timing data using Cadence Liberate. If the digital interface is limited to
standard-cell we can rely on standard-library defined timing-characterization
and the associated digital corners that are used with the rest of the design.
## Innovus Flow
## Liberate Flow

22
content/posts/2025/source/analysis.ipynb Normal file
View File

@ -0,0 +1,22 @@
{
"cells": [
{
"cell_type": "code",
"execution_count": null,
"metadata": {
"vscode": {
"languageId": "plaintext"
}
},
"outputs": [],
"source": []
}
],
"metadata": {
"language_info": {
"name": "python"
}
},
"nbformat": 4,
"nbformat_minor": 2
}

153
content/posts/2025/source/models.py Normal file
View File

@ -0,0 +1,153 @@
from sympy import Symbol, log, sin
from scipy import constants
from quantiphy import Quantity
import control as ct
eval_constants = {
"k": constants.k, # Boltzmann contant
"T": constants.convert_temperature(25.0, "Celsius", "Kelvin"),
"q": constants.e, # Elementary charge
}
_pi = constants.pi
_kT = constants.Boltzmann * constants.convert_temperature(25.0, "Celsius", "Kelvin")
class Crystal:
def __init__(self, frequency: float = 4.8e7, noise_floor_dBc: float = -160):
self.frequency = frequency
self.noise_floor_dBc = noise_floor_dBc
## TODO low-frequency jitter offset contribution
def xtal_jitter(self, bandwidth, ref_frequency):
"""XTAL jitter estimate over bandwidth"""
return Quantity(
(
2
* 10 ** (self.noise_floor_dBc / 10)
* bandwidth
/ (ref_frequency * 2 * _pi) ** 2
)
** 0.5,
units="s_rms",
)
class Oscillator:
"""
VCO Phase-Noise Model of LC Oscillator
Bandwidth upper limit is set by the refence clock
Back off by 10x in sampled systems for stability
More accurately take xtal into account and equate jitter
Reference B. Razavi, "Jitter-Power Trade-Offs in PLLs,"
in IEEE Transactions on Circuits and Systems I: Regular Papers,
vol. 68, no. 4, pp. 1381-1387, April 2021, doi: 10.1109/TCSI.2021.3057580.
"""
def __init__(
self,
f_center: float = 5e9,
vout_max: float = 1.0,
ibias: float = 5.0e-3,
q_factor: float = 10,
eta: float = 2.4, # noise excess factor (1+gamma)
):
self.R = _pi * vout_max / ibias / 2
self.f_center = f_center
self.vout_max = vout_max
self.q_factor = q_factor
self.ibias = ibias
self.eta = eta
@property
def vco_alpha(self):
"""Oscillator Noise Figure alpha"""
return (
_kT / (self.q_factor**2) * self.eta * (_pi / self.ibias) ** 2 / self.R / 8
)
def pll_phase_noise(self, pll_bandwidth):
"""Estimate on a LC oscillator phase-noise as alpha/f**2"""
return self.vco_alpha * (self.f_center / pll_bandwidth) ** 2
def pll_jitter(self, pll_bandwidth, ref_frequency):
"""PLL jitter estimate due to VCO"""
return Quantity(
(
4
* self.pll_phase_noise(pll_bandwidth)
* pll_bandwidth
/ (ref_frequency * 2 * _pi) ** 2
)
** 0.5,
units="s_rms",
)
def opt_bandwidth(self, ref_xtal: Crystal):
"""Optimal PLL bandwidth for matching reference noise."""
f_ratio = self.f_center / ref_xtal.frequency
eff_ref_noise = 2 * 10 ** (ref_xtal.noise_floor_dBc / 10) * f_ratio**2
return Quantity(
(4 * self.vco_alpha * self.f_center**2 / _pi / eff_ref_noise) ** 0.5,
units="Hz",
)
def jitter_tol(self, adc_tol_db: float, adc_resolution: float, adc_clock: float):
"""Jitter tolerance calculation for m-dB penalty in ADC performance"""
return Quantity(
(
(10 ** (adc_tol_db / 10) - 1)
/ (3 * _pi**2 * adc_clock**2 * 2 ** (2 * adc_resolution - 1))
)
** 0.5,
units="s_rms",
)
# LC Tank Parameter Selection
# E. Hegazi, H. Sjoland and A. A. Abidi,
# "A filtering technique to lower LC oscillator phase noise,"
# in IEEE Journal of Solid-State Circuits,
# vol. 36, no. 12, pp. 1921-1930, Dec. 2001, doi: 10.1109/4.972142
# A. Mazzanti and P. Andreani,
# "Class-C Harmonic CMOS VCOs, With a General Result on Phase Noise,"
# in IEEE Journal of Solid-State Circuits,
# vol. 43, no. 12, pp. 2716-2729, Dec. 2008,
class Divider:
# Error-Feedback Topology
# https://www.youtube.com/watch?v=t1TY-D95CY8&t=4373s
ω = Symbol("ω")
def __init__(self, order: int = 2, fb_int:int = 100, fb_frac:float = 0.1337):
self.fb_int = fb_int
self.fb_frac = fb_frac
self.order = order
@property
def noise_function_approx(self):
return (_pi / 3 / self.ω) ** self.order
@property
def noise_function_exact(self):
return (2 * sin(self.ω / 2)) ** self.order
@property
def psd_out(self):
return self.noise_function_exact**2 / 12
@property
def modulator_c2p(self):
return ct.tf([0,1],[1,-1],dt=True)*(2*_pi/(self.fb_int+self.fb_frac))
@property
def pll_ntf(self):
pass
@property
def modulator_response_ss(self):
return ct.tf2ss(self.modulator_c2p) * ct.tf2ss(self.pll_ntf)

BIN
static/images/posts/verification/energypercycle-c-best-hthv.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.0 KiB

BIN
static/images/posts/verification/energypercycle-c-best-htlv.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.1 KiB