TokenSPICE Design & Verification Flows
The History of SPICE for Electrical Engineering as a Guide for Token Engineering
1. Introduction
TokenSPICE is a tool that simulates tokenized ecosystems via an agent-based approach. It can help in Token Engineering flows, to design, tune, and verify tokenized ecosystems. Here’s the article introducing TokenSPICE.
This article aims inform and inspire, by drawing a parallel to the simulation work at the heart of the semiconductor industry.
First, it gives a history of the SPICE simulator. SPICE has been used ubiquitously in electrical engineering for decades. It reviews manual and automated flows, for both design and verification tasks.
Then, this article describes how TokenSPICE is to Token Engineering, what SPICE is to Electrical Engineering. For everything we’ve seen around SPICE, there is a similar opportunity around TokenSPICE. It describes manual and automated flows for both design and verification. It also describes how cadCAD simulator is complementary to TokenSPICE.
2. SPICE & Analog Electrical Engineering
2.1 Personal Context
I describe this section drawing on my background in Electrical Engineering (EE). I began studying EE in 1994, and was in the field until I went full-time in blockchain in 2014. I focused on analog CAD (computer-aided design), creating AI/ML-based CAD tools for design and verification of analog / mixed-signal circuits. I did this work via two startups (ADA, Solido) and a PhD, with two textbooks as key academic output.
2.2 EE context
Chips are everywhere. They power your phone, your car, and your vacuum cleaner, not to mention every blockchain on the planet. Chips are the key output of the $400B semiconductor industry. Electrical engineers design these chips. Inside each modern chip are billions of components — transistors, capacitors, resistors and inductors. EEs also design the Printed Circuit Boards (PCBs) that stitch together many chips with discrete resistors, capacitors, and power supplies.
The complexity means it’s not easy to design these chips and PCBs. So, engineers use CAD tools. Even with tools, it’s not typically tractable to design chips “flat”, so engineers organize components hierarchically, and use off-the-shelf building blocks wherever possible. Let’s review these blocks and parse digital vs. analog.
2.3 Digital & Analog Blocks
Some building blocks are purely digital: they (a) abstract the signals to True/False and (b) abstract time to clocked timesteps. Digital circuits include NAND gates, adders, multiplexers, and arithmetic logic units (ALUs).
The remaining building blocks are analog in nature, (a) the signals are continuous in value, not abstracted; or (b) time is continuous, not abstracted. This includes analog blocks like current mirrors, amplifiers, and lowpass filters. It also includes RF blocks to handle receiving / transmitting radio waves, memory blocks like bitcells, custom digital circuits where you need to design at analog fidelity, and mixed-signal circuits which combine a mixture of analog and digital blocks.
2.4 The Problem of Analog Design
Let’s focus here on analog circuits. Below is a CMOS OTA — an amplifier, basically. The designer aims to optimize some metrics (e.g. minimize power consumption) and meet metric constraints (e.g. total area < threshold), in an context of environment (temperature range, load capacitance C_L).
To meet these goals, the designer needs to determine the width and length of each transistor (and if needed, changes the structure of the circuit itself).
How might an analog electrical engineer design this circuit, and verify it? There are a few possible ways, at increasing levels of automation. Let’s review.
2.5 Pure Manual Analog Design
Analog circuits have a long history, including usage in practical electric telegraphs (1833), telephones (1876) and phonographs (1877). Bell and Edison were electrical engineers! In those days, theory was thin and systematic design processes almost nonexistent.
Since then, practices have continually improved. For example, in 1994 Laker and Sansen published this book showing a systematic analog design practice; Sansen published this follow-up in 2006. Their practices have spread to top universities and industrial labs throughout the world.
I had the great fortune to study analog circuit design under Willy Sansen, and work with other excellent analog engineers. Here’s a summary of Willy’s approach to design analog circuit.
- Write down the equations for the circuit, based on Kirchoff’s Current and Voltage Laws (KCL, KVL) which preserve voltage in a loop and current in and out of a node, respectively. It’s ok to use approximations, in order to keep equations to a manually tractable size.
- Then, write equations for higher-level metrics like power consumption or gain-bandwidth.
- At this point, the design is still under-determined: there are more free design parameters than there are equations. Your goal is to chop down the free parameters. You do this by adding in constraints, such as (area < threshold). Each new constraint reduces the degrees of freedom (DOF) by one.
- Keep going until you have one DOF left. Choose that value by optimizing against the objective function (e.g. minimize power consumption), aka Figure of Merit (FOM).
The image below shows that approach in action, for designing an OTA. Top-left shows the equations from (1)(2); middle-left values for I_B etc show the additional constraints (3); and bottom-left shows the FOM to optimize against (4).
2.6 History of SPICE
The previous section described a pure manual approach analog design. What about verifying it? For decades engineers relied solely on equations. But like everything manual, that was labor-intensive and error-prone. So there was a long-standing dream to automate it.
The answer was SPICE. Let’s explore how SPICE came to be.
In 1971, Berkeley Professor Ron Rohrer corralled his students to collectively build a rudimentary circuit simulator, called CANCER. Users would specify a “netlist” (set of components, wired together). The components had built-in models of the semiconductor physics; users did not have to write FORTRAN to create their own models — a huge leap for the time. CANCER combined these model equations with KCL and KVL equations (derived from the netlist), and ran a solver to find found voltage and current values which respected the equations. The first good numerical simulator was born.
Larry Nagel was one of Rohrer’s students. He took on the simulator full-time as his master’s project. Job one was to give it a less contentious name, and “SPICE” was born. SPICE = Simulation Program with Integrated Circuit Emphasis.
SPICE was presented to friendlies in 1972, and publicly in 1973. The rest was history.
“I don’t think anyone had a clue of the impact of that paper or the computer program it described. While we all had modest expectations for SPICE, what happened was truly phenomenal. Within a few years, SPICE had achieved acceptance at almost all electrical engineering schools and had started a cottage industry to supply SPICE derivatives to the rapidly expanding integrated circuit industry.” -Larry Nagel
I can confirm this from personal experience. While was studying undergraduate EE in the mid 1990s, and as an EE PhD in the mid 2000s, SPICE (and its brethren) was the ubiquitous circuit simulation tool used by all professors and students.
The “cottage industry” described by Larry had become a $500M industry by the 2000s, driven by SPICE successors like HSPICE (Synopsys) and PSPICE (Cadence). Large analog design houses had even developed their own simulators: TI had TI-SPICE, Analog Devices had LTspice, Freescale (née Motorola) had Mica, and more.
I had the fortune to get to know both Ron and Larry: Ron as a competitor with the utmost class (you are missed, Ron), and Larry as a wonderful collaborator in reviewing advances in circuit simulation and CAD for CICC.
2.7 Core SPICE flow
SPICE operates simply as: text netlist in, run SPICE solver, text simulation results out. One can get fancier with a schematic editor for graphical entry of netlists, and a waveform viewer to plot simulation results. But the essence remains the same. The figure below illustrates, for a diode clamp circuit. (A circuit that “rails” outputs to within a max or min using a “diode”.)
2.8 Manual Design + Basic SPICE Verification
This is performed by putting the core SPICE flow into a manual design context, as shown below.
In the first step (image: top), the designer selects a circuit structure (topology) then follows a systematic analog design flow (a la Sansen) to choose circuit design variables. Then (image: middle), they enter the design as a netlist, via a schematic editor or text editor. Finally (image: bottom), they to run SPICE to get simulation results, which they inspect manually and plot in a waveform viewer. If the design meets their goals, they stop; otherwise they go back to the first step and make changes to the design and repeat.
Below is an example of a SPICE netlist, from this excellent SPICE tutorial. It’s for the same diode clamp circuit of the previous two images.
- The first few lines specify voltage source V1, wired up from node 0 to 1. It’s the component that’s actuating on the circuit, against which the other devices respond.
- The next few lines specify a capacitor C1, diode D1, and resistor R1, each wired up. The diode has a fancier semiconductor model under it, specified via “.model dclamp”.
- The bottom portion of the netlist specifies three different analyses to run: DC (what does the single solution for KCL and KVL look like?), AC (what does the frequency spectrum look like?), and transient (how does the DC solution look over time?)
2.9 SPICE-in-the-Loop Flow
By the late 90s, SPICE simulators were sufficiently good, and computers sufficiently fast, that one could reasonably consider using them “in the loop” for verification or design. Below is the general flow. The initial design is performed manually (image: top). Then, a design tool or verification tool is run, which automatically invokes tens, hundreds or thousands of SPICE simulations (image: bottom).
In design tools, the tool wiggles controllable design variables (e.g. resistances, capacitances) and measures performance metrics (e.g. power consumption). In verification tools, the tool wiggles uncontrollable variables (e.g. temperature, manufacturing variations) and measures metrics. Tools may be more purely-manual (e.g. design sweeps), purely automatic (e.g. optimization), or a mixture.
The SPICE-in-the-loop concept was a big “unlock”. It enabled a huge variety of tools, some have become ubiquitous in the industry. Let’s explore some example tools from my own experience.
2.10 SPICE-in-the-Loop for Design Space Exploration
The image below shows a tool for fast design space exploration called Fast Design Sweep, by Solido. It aims to solve a long-standing tension between automated and manual design.
- On one hand, many designers don’t want automated design (optimizers), for legitimate reasons. Yet it’s a shame in that optimizers have powerful engines for exploring the design space.
- Designers do accept variable sweeps, however, because they can retain manual control. However, simple variable sweeps can’t both (a) capture variable interactions and (b) scale to a large number of variables.
The tool solves this tension by giving “superpowers” to manual design. It uses optimization-style sampling & SPICE simulation, towards building a model of increasing fidelity. The tool plots the model’s predicted metrics alongside SPICE-simulated metrics. This allows the designer to interactively explore the design space and relation to metrics (including interactions).
2.11 SPICE-in-the-Loop for Worst-Case Verification
The image below shows a tool called Fast PVT, by Solido. It aims to solve the the problem of worst-case verification, as follows.
- A modern chip design must work in all possible combinations of power (P), voltage (V), temperature (T), load, manufacturing variations (e.g. FF/SS) and parasitics (unwanted devices that emerge when putting the schematic into silicon). For simplicity, let’s say there are 10 possible values of each (it’s actually worse).
- Then there are 1⁰⁶ = 1 million possible simulations. If a single simulation takes 10 minutes (typical), that’s 10 million minutes of simulation, or 19 years. Run on a thousand machines in parallel and it will still take 1 week. That starts to get feasible but it’s still tying up massive resources for a week, for just this one circuit. And there are other circuits.
The tool solves this verification problem by casting it as a global optimization problem. It optimizes for worst-case performance (e.g. maximize power), to basically try to “break” the circuit. It uses a scalable solver that chooses points in PVT space, then simulates the points with SPICE, measures the metrics, and repeats. It keeps going until it’s confident that it has found the worst PVT point.
2.12 SPICE-in-the-Loop for Knowledge Extraction
The image below shows the CAFFEINE tool. It helps augment expert analog designers who love to work with equations (this is a large group). CAFFEINE takes many samples in the design space, SPICE-simulates each sample and calculates metrics, then automatically builds a symbolic model (equation) that maps design variables to metrics. This is a form of knowledge extraction.
Designers can inspect these equations to build intuition, and manipulate them equations directly for further design or verification.
2.13 SPICE-in-the-Loop Structural Synthesis
The image below shows results from the MOJITO design tool.
- Typical automated design tools do optimization: they search across the space of parameters: resistances, capacitances, and transistor sizes.
- MOJITO goes further and does structural synthesis: it searches across the space of possible structures: what components are used, and how they’re wired together (plus their parameters).
The larger design space makes this problem harder. But what makes it pernicious is that SPICE can get tricked! SPICE was developed for human circuit designs, and synthesis engines can find circuits that SPICE thinks are good, but in reality are useless.
MOJITO counters this by constraining the search space to a library of analog building blocks. Any sample (circuit) in this space is sane. Yet because of the combinatorial explosion of building blocks, the search space is still huge and interesting. MOJITO can search across this space with impunity, and return results useful to designers. As a bonus, it’s more efficient finding good designs because it doesn’t lose time in useless design regions.
2.14 Summary of SPICE tools
Here’s a summary of SPICE tools in the circuit CAD field. All are in industrial use except *. We give more detailed descriptions later, in the section on possible high-level tools for TokenSPICE.
- Core flow: design entry, waveform viewer.
- SPICE-in-the-Loop Verification: system identification, corner extraction, worst-case verification, 3-sigma verification, high-sigma verification, behavioral modeling.
- SPICE-in-the-Loop Design: sensitivity analysis, sweep analysis, fast design sweep, local optimization, global optimization, structural synthesis*.
3. TokenSPICE and Token Engineering
3.1 Overview
SPICE creator Larry Nagel describes SPICE as:
“SPICE is a general purpose circuit simulation program that is used by electrical engineers in the design of integrated circuits”
Then:
“TokenSPICE is a general purpose token simulation program that is used by token engineers in the design of tokenized ecosystems.”
TokenSPICE is to Token Engineering, what SPICE is to Electrical Engineering. For everything we’ve seen around SPICE, there is a similar opportunity around TokenSPICE.
Just as SPICE is used for both circuit design flows and circuit verification flows, TokenSPICE can be used in both token design and token verification flows.
And, just as SPICE is not a panacea, TokenSPICE is not a panacea either. It will not solve all the problems. It is simply a tool; hopefully it is useful to some!
3.2 Token Engineering Meta-Flow
In Towards a Practice of Token Engineering, I laid out this TE flow:
- Formulate the problem in terms of objectives & constraints
- Try to fit an existing TE pattern to it, and
- Design something new, if needed.
We’ve used this flow several times with success in Ocean Protocol since 2017.
In this flow, design exploration happens in both step (2) and step (3). Verification also happens inside (2) and (3).
Accordingly, TokenSPICE can be used in design or verification work of step (2) or (3). It tends to be later-stage design and verification work, because there is setup effort to write the netlist, etc.
3.3 Token Verification with TokenSPICE
TE Verification is about evaluating the token-based system to find out whether it meets the specified requirements.
There are three groups of verification tools:
- Human-based verification. Example: Le Grand Jeu board games.
- Software-based verification.
- Economics-based verification / risk management. Example: Kusama “canary” network for Polkadot.
TokenSPICE fits into (2). It’s complementary to tools for (1) and (3), and other software-based tools (2) like cadCAD or Google Sheets.
3.4 Manual + Basic TokenSPICE Verification
This flow is like the EE version: Manual Design + Basic SPICE Verification.
In the first step (below image: top), the token engineer follows a systematic TE design flow (e.g. like given above) flow to select a structure and initial parameters.
Then (image: middle), they enter the design as a netlist, via a token schematic editor or text editor.
Finally (image: bottom), they to run TokenSPICE to get simulation results, which they inspect manually and plot in a waveform viewer. If the design meets their goals, they stop; otherwise they go back to the first step and make changes to the design and repeat.
The image below shows snippets of a TokenSPICE netlist. On the left is a top-level netlist that wires together agents, written in Python. Each agent can be arbitrary Python code; all that an agent needs is a “takeStep()” function.
Furthermore, the Python itself can link to other stacks. TokenSPICE has already been extended to link to EVM. Accordingly, Solidity code defines lower-level agent behavior. Below right shows a snippet of Solidity from a Balancer V1 “BPool.sol” pool. It’s wrapped by a BPool.py driver, then a Pool python agent.
3.5 TokenSPICE-in-the-loop
TokenSPICE is sufficiently general, and computers sufficiently fast, that we can reasonably consider using it “in the loop” for verification or design. Below is the general flow. The initial design is performed manually (image: top). Then, a design tool or verification tool would be run, to automatically invoke tens, hundreds or thousands of TokenSPICE simulations (image: bottom).
In token design tools, the tool wiggles controllable design variables (e.g. % burn, % fees) and measures performance metrics (e.g. network revenue, TVL).
In token verification tools, the tool wiggles uncontrollable variables (e.g. agents’ behaviors, network latency, network gas price) and measures metrics. “Agents’ behavior” is the concatenation of all uncontrollable variables of agent 1, agent 2, .. , agent n.
Tools may be more purely-manual (e.g. design sweeps), purely automatic (e.g. optimization), or a mixture.
Just as SPICE-in-the-loop was a big “unlock” in circuit design, we have high hopes for TokenSPICE-in-the-loop to be a big “unlock” for token design.
3.6 Potential TokenSPICE-in-the-Loop Tools
The previous section on SPICE for analog design described several SPICE-in-the-loop tools for design and verification. These included specific tools for design space exploration, worst-case verification, knowledge extraction, and structural synthesis.
SPICE-in-the-loop tools for analog design map 1:1 to TokenSPICE for token design.
Here’s how the previous examples from SPICE, map to TokenSPICE.
- Fast design space exploration: for “superpowers” in manual token design. Use optimization-style sampling & TokenSPICE simulation, towards building a model of increasing fidelity. Plots the model’s predicted metrics alongside SPICE-simulated metrics. This allows the token designer to interactively explore the design space and relation to metrics (including interactions).
- Worst-case verification: run a global solver to find the conditions to try to “break” the token design (cause worst-case performance). E.g. is there a combination of {agents’ behaviors, network latency, gas costs} that causes TVL to plummet?
- Knowledge extraction: automatically draw many samples in token design space, simulate each with TokenSPICE, and automatically build symbolic models that map design variables (e.g. tx fee, % burn) to metrics (e.g. TVL).
- Structural synthesis: evolve Solidity code! This could be extra interesting in the MEV wars.
The “Higher-Level Tools” document in the TokenSPICE repo gives a more thorough list of possible tools around TokenSPICE.
3.6 TokenSPICE <> cadCAD
cadCAD has emerged as a popular tool in the Token Engineering community.
TokenSPICE is complementary to cadCAD. Let’s elaborate.
A simple answer: cadCAD is best for earlier-stage design, before you get to smart contracts. TokenSPICE is most optimized to design & verify smart contracts.
A more analog CAD-y answer: In analog electrical engineering, there is a class of simulators known as symbolic analysis tools. ISAAC, created in the late 1980s by Georges Gielen, is perhaps the most famous. It inputs a text netlist and auto-extracts first-order symbolic models that relate variables to metrics. It’s like the Willy Sansen-style equations I described earlier, but generated automatically. ISAAC directly inspired the creation of Maple and Mathematica software. Once again I was fortunate: ISAAC creator Georges Gielen was my PhD supervisor. The link to Sansen methodologies is no coincidence: Willy was Georges’ PhD supervisor.
cadCAD is a bit like ISAAC, but there’s an even closer analogy…
Analog design has tools around behavioral modeling. A behavioral model is is explicitly written as a higher level of abstraction than the high-fidelity silicon-level models of SPICE. Designers use Verilog-AMS or VHDL-AMS modeling language to specify models. Behavioral simulators like Spectre AMS Designer simulate these models. They can simulate large circuits 100x+ faster than SPICE. It’s a tradeoff of speed vs fidelity; both have their uses.
SPICE, symbolic analysis, and behavioral modeling form three key branches of a broader approach to performance space estimation, as shown below. This paper elaborates.
Let’s summarize. TokenSPICE is complementary to cadCAD.
- cadCAD for earlier-stage design, TokenSPICE for smart contracts.
- TokenSPICE is like SPICE, and cadCAD is most like behavioral modeling. As of this writing, cadCAD’s also much more mature than TokenSPICE. TokenSPICE and cadCAD are driving forward Token Engineering together.
4. Conclusion
Electrical Engineering drives the global semiconductor industry. To design chips, electrical engineers use SPICE simulation and related CAD tools. This article described the history of SPICE, and SPICE-based flows for design and verification. Then, this article described how TokenSPICE is like SPICE, but tuned for Token Engineering. It then described flows for token design and verification. Finally, it described how TokenSPICE and the cadCAD simulator are complementary, together growing the field of Token Engineering. Onwards:)
Want to learn more? The next article is “How to Model with TokenSPICE EVM Agent Simulation: From a quickstart to deeper understanding of agents and netlists architecture, by example”. Or, jump right in and start using TokenSPICE.
