.gitignore

@@ -4,4 +4,3 @@ public/
 resources/_gen
 .hugo*
 .fig/
-__pycache__

content/posts/2025/analog-verification.md

@@ -1,315 +0,0 @@
----
-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)

content/posts/2025/dynamic-search.md

@@ -1,30 +0,0 @@
----
-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)  |     |   
-         |         '---+----'     |   
-         |             |          |   
-          '------------*---------'    
-                   
-```

content/posts/2025/mixed-signal-simulation.md

@@ -1,68 +0,0 @@
----
-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

content/posts/2025/source/analysis.ipynb

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

content/posts/2025/source/models.py

@@ -1,153 +0,0 @@
-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)