update on hugo posts

2025-03-09 21:42:44 +01:00 · 2025-02-06 18:58:23 +01:00 · 2025-02-06 18:58:23 +01:00 · b28ec4e15a
commit b28ec4e15a
parent daf108c6db
7 changed files with 588 additions and 0 deletions
--- a/content/posts/2025/analog-verification.md
+++ b/content/posts/2025/analog-verification.md
@ -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)
--- a/content/posts/2025/dynamic-search.md
+++ b/content/posts/2025/dynamic-search.md
@ -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)  |     |   
         |         '---+----'     |   
         |             |          |   
          '------------*---------'    
 ```
--- a/content/posts/2025/mixed-signal-simulation.md
+++ b/content/posts/2025/mixed-signal-simulation.md
@ -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
--- a/content/posts/2025/source/analysis.ipynb
+++ b/content/posts/2025/source/analysis.ipynb
@ -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
 }
--- a/content/posts/2025/source/models.py
+++ b/content/posts/2025/source/models.py
@ -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)
--- a/static/images/posts/verification/energypercycle-c-best-hthv.png
+++ b/static/images/posts/verification/energypercycle-c-best-hthv.png
--- a/static/images/posts/verification/energypercycle-c-best-htlv.png
+++ b/static/images/posts/verification/energypercycle-c-best-htlv.png