From b28ec4e15aa0cabcde3aff9925cc48bf6cf4a3f6 Mon Sep 17 00:00:00 2001 From: Lieuwe Leene Date: Thu, 6 Feb 2025 18:58:23 +0100 Subject: [PATCH] update on hugo posts --- content/posts/2025/analog-verification.md | 315 ++++++++++++++++++ content/posts/2025/dynamic-search.md | 30 ++ content/posts/2025/mixed-signal-simulation.md | 68 ++++ content/posts/2025/source/analysis.ipynb | 22 ++ content/posts/2025/source/models.py | 153 +++++++++ .../energypercycle-c-best-hthv.png | Bin 0 -> 2053 bytes .../energypercycle-c-best-htlv.png | Bin 0 -> 2125 bytes 7 files changed, 588 insertions(+) create mode 100644 content/posts/2025/analog-verification.md create mode 100644 content/posts/2025/dynamic-search.md create mode 100644 content/posts/2025/mixed-signal-simulation.md create mode 100644 content/posts/2025/source/analysis.ipynb create mode 100644 content/posts/2025/source/models.py create mode 100644 static/images/posts/verification/energypercycle-c-best-hthv.png create mode 100644 static/images/posts/verification/energypercycle-c-best-htlv.png diff --git a/content/posts/2025/analog-verification.md b/content/posts/2025/analog-verification.md new file mode 100644 index 0000000..2e846f8 --- /dev/null +++ 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) \ No newline at end of file diff --git a/content/posts/2025/dynamic-search.md b/content/posts/2025/dynamic-search.md new file mode 100644 index 0000000..c253a79 --- /dev/null +++ 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) | | + | '---+----' | + | | | + '------------*---------' + +``` \ No newline at end of file diff --git a/content/posts/2025/mixed-signal-simulation.md b/content/posts/2025/mixed-signal-simulation.md new file mode 100644 index 0000000..6fe793d --- /dev/null +++ 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 \ No newline at end of file diff --git a/content/posts/2025/source/analysis.ipynb b/content/posts/2025/source/analysis.ipynb new file mode 100644 index 0000000..7ad2046 --- /dev/null +++ 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 +} diff --git a/content/posts/2025/source/models.py b/content/posts/2025/source/models.py new file mode 100644 index 0000000..a0bd535 --- /dev/null +++ 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) diff --git a/static/images/posts/verification/energypercycle-c-best-hthv.png b/static/images/posts/verification/energypercycle-c-best-hthv.png new file mode 100644 index 0000000000000000000000000000000000000000..2ab3ff44f74ad6ef3f015e87def3fde7a5bdb3a8 GIT binary patch literal 2053 zcmeHIYc!kL8vfGJFlkF`RoZE_Xfx)Bh^{7xOOq-pgrJ0wIKd1K zn}mi005D|xc)EvVRKA)DAnx9@7+f3^EVo2Ek%UIIW)t@{fq@A3?yO5&PJieMg$G5t z8C1bcCag@m4ZU`9E+OU*nVBZ?Djc`{>)QuWo}IMibfaOyPK4TZL!E7dg|~tpGHnEDHcuX$DRC^e(oSzrR1*+v$f1M%`4sNB7f=Kcclkht*5nRe%9M=^=2&A zIVMepWZ>Q0=+aDM6O%oqW?v3qaX4y5wVySwhlMPA^6=sLxVShNgVZ2lvRGj_b2JmZ z?rIcTh)Y#`MXq*h)M(C9!op6^{#Y`3`}2|f(jW%omO>F%Qc|+9*jYW7kds6AzIag9 z5j*rNuC%+mTRJ{|Z#zOn%gf8_ zO4TZv?Xj$7B3RAKNdoEJw|~D(BH>TnWnHJ9Dm-EJ>RB&M$%(jv#bEfCFJInTbl`?Z z8}dF#`||9diA*N5V{U$Sw2_FY%W!M``RCBIv@|oJKbg#w2`Gi$9v%gVMuEUr`&urU z>^z8!fkB(y7eXEPv&>=!1dTl!4jB<8eQ}pNHkX5OTB18C`W*@BPS&#!HOO*6B2@sUaP!Yi3)2B@pVdmIto6F0`jFwX#=eESi@X1 zdNkxnK@_D;uh-XNm1|6gs(ILqHAsC%?A5kF5aAz5XpxP|<$@?_Ky8pv2uq zY<0ND@geP0RBmzZ(($%Oe)yWOLzhPv77`y1g1&BjX=)d;J)aWiHX>PAXof6r z&8LWB+NqYcHfO_a+V6NCF@m47xfy%ohbN|@BNoj$c!soNuJ7KK)$pA|zDgcx2y~j~ zq4xP%gB6V6hv{pU;>JqxTt&_Uc30&aT&aEIe9m>JK)N=cz9>D$S=j6XA^v`PjU-7!3zvZ%1VejD?@Jj}KyvUxdC!+Fy1C8jb Axc~qF literal 0 HcmV?d00001 diff --git a/static/images/posts/verification/energypercycle-c-best-htlv.png b/static/images/posts/verification/energypercycle-c-best-htlv.png new file mode 100644 index 0000000000000000000000000000000000000000..274c75ce1e27469aeea9c5a12fd58918256dd77a GIT binary patch literal 2125 zcmd^ATR7Wk9{#s86N;G{E$S4et0y5^lvIs#L~4d?9TFjgX-1VwkW{4(9j$iBQ=W=L zHBBu+LP8Q{s5%S}O=;5>AzCz5Ll&vSkUH1?=VJGAFZN<@_Tv4%_u_kg-|zXo@ArN= z7=P5)TE(d#piTtO)_v3t>%z;C6>QmK?=XItCL|2_aGC&k#FAWUb1MfOpALz4kuf7GAY!*k=t z0)R#<+S?=O>VuDCk-mYu=8|Q3(B@2(A5;H3hr3_>%E+?ZH#nPp5ce0Ao#=0KPZ@vb zcQaIn^;-AmTKps066tjQyDqD^Mr+*y_^oe;Lsr*x?>lQX?9^v$?Nln(;#!Bu9g>wj z%IJse{KcW)XWxi7{@6&10Eq6$8V%sO0x9Z$HvPP0SSGWSBp&?c_Gtv7<^3twvVgp) z>V#IV_H`p#xkLEnYR z$1rSt5Q#*ZOvGa4S@vcwS22=2vn|p~Za`TrpU)SCAd%T1(avY~Rr>h&1cildxye5+ zE@DwANt>|h{D~d4Jo0{NX($C=2<@^u;N|7zoUz>kk7(n~&c;r((){=#b(?iR1=bW+ zbGhpE<)3<|5((|}CXukZ+Q;7Be&yHAO*(q;;rG`XFONB`hkJT% z=9!+U(1(RQOEjgWr0~V!#2W6Bq^Ys-qIzzazVzN>GA_s4Q;ZYb42(LZ8Deyg#Tr^) zZ^4I!G4M)I68id5IatvkErCE_8=II6kB#xin#ruIe$y)(jd61L5xsrrL6u72gF+da zT`Byg%j%0Vx6F}zbGINYwz+bOGr-&X%k}O_(c8CgWfK#GQK!?Vt3cj8^7^#}x|YX# z4NBQ~%Vl>5;;oXtAegLD4CsAOsYI>dof*Bd|$L$cs%VgT zEPy)mqO{@_s(^m&+MhS5#vcbBIB;Ndb(X1@^CcGhR99e!2@bB3vYcQ==k%Liw$kPs zGj}s4+ESATBnfXCkXxTV4n2x_m3x0OU}bCP5}7QYc#=X>zBF5iH1Yzq>0=(FeNu%U zVWOo{>1;2+0%qeK;%c{EPc#vO>`N%FFV4 z0!)?P8{L{Xb?b_1w7j;qR?k1T_mAZPQy_$r{nc+eS;0>s5J*Pq*)_%3+M>eGPVOe9 z&dF*DUVLeC)lc&`oq7>)&*ML!>zG?fdAuV`PGdwIJEUWEP%HK1w;~r^0qH19YNeNR zyyUrld+`+F9CyfDn{@kkRL8Tg2Ner>7bqMc@sj)CPsPmzSCf~7(&Rp*4sA1g&XK`?Hf)n zG+->L0j+FC(Xw~F$Z)Nza(7(Y?I}l)mDy*VS}Yce+bXw5NAKN^!9m;T?A-J_Z4Y|+scoVMpVN08hOoGQIoMFm8e_l! z+l7@vnC)(Ks45um%#Lt$vyWK*@IbJQ94&dJT&aTY1u`_urF)2wuD$;io^}Ed&kgpd Su~r)RwF79RzjwVSG3%c