A **differential equation-solving analog device** is a reconfigurable computing platform that leverages the physics of the underlying substrate to implement dynamical system computations. Internally, these devices contain collections of digitally configurable analog blocks that may be routed together with digitally programmable interconnects to form a variety of analog circuits. Typically, the end-user is interested in executing a dynamical system computation on an analog computing platform.

The last article described how to automatically derive an analog circuit that implements a target dynamical system computation. This article will discuss how to transform an analog circuit to respect the operating range and frequency restrictions imposed by the hardware, compensate for manufacturing variations, and attenuate the effects of quantization error and noise on the computation. The original dynamical system dynamics can be recovered from the transformed circuit’s dynamics at runtime by applying a statically derived recovery transform. This circuit transformation, dubbed the **circuit** **scaling transform**, enables the accurate execution of dynamical systems on analog hardware.

**Overview**: We first summarize the analog behaviors present in the HCDCv2 reconfigurable analog device. We next present a *directly mapped* circuit that maps the harmonic oscillator dynamical system to the HCDCv2 without considering these analog behaviors. We then explain why such a circuit would produce inaccurate results on the analog hardware. We then introduce the **scaling transform **and demonstrate how to use the scale transform to scale the circuit and recover the original dynamical system dynamics at runtime. Finally, we describe how to derive this scaling transform from the directly mapped circuit and a specification of the hardware’s analog behavior.

## Analog Behavior in the Hardware

The HCDCv2 analog blocks are subject to several analog behaviors and physical restrictions (presented above), which affect their operation.

**Operating Range Restrictions**: The analog blocks work with signals and values within a predefined operating range — violating these operating range restrictions may cause the block to produce incorrect results or damage the analog hardware.

**Example:**The**MUL**block in**mm**mode accepts analog signals between**[-2,2] μA**at port**u**,**v**, and**w**and digital values between**[-1,1]**at data field c.**Frequency Restrictions**: The analog blocks may impose restrictions on the computation speed to reduce the effect of frequency-dependent unwanted behaviors on the computation.

**Example**: The**OBS**block limits the computation speed to**100800 Hz**. This is 0.8x (**100800 Hz/126000 Hz**) the HCDCv2’s baseline integration speed of**126000 Hz.****Noise**: Each analog signal is affected by analog noise. We model the noisy signal at each analog port as the noiseless signal added with a normally distributed noise distribution**N(0,σ)**, where the**σ**term may be port-specific.

**Example:**the**COPY**block introduces noise with the distribution**N(0,0.005) μA**to the analog signals at ports**a**,**b**, and**c**.**Quantization Error:**Each digitally settable data field has limited precision and is, therefore, subject to quantization error. We define the quantization error of each data field as the maximum distance between two consecutive digital values.

**Example:**The**z0**data field in the**INT**block has a quantization error of**0.01**.

### Manufacturing Variation-Induced Behavioral Deviations

In addition, the HCDCv2 is sensitive to process variations introduced during device fabrication. This sensitivity to hardware variations causes the behavior of individual block instances to deviate from the block input-output relations described in the hardware specification. The figure above summarizes the input-output relations implemented by a subset of configured HCDCv2 block instances post-fabrication. These input-output relations also vary from HCDCv2 device to HCDCv2 device.

**Example: **Recall from the first article that the **MUL** block is designed to implement the input-output relation** w=c • u** when in **mm** mode. However, if we characterize the behavior of the **MUL** block at location **(0,0)** on the fabricated HCDCv2 device that we have on-hand, we would find it implements the input-output relation **w = 0.97 • c • u**. Note that different instances of the same block do not necessarily implement the same function. For example, the **MUL (0,1)** block implements w = **0.92 • c • u**.

## The Directly Mapped Circuit

The above circuit directly maps the harmonic oscillator computation (introduced here) to the HCDCv2 analog hardware without considering the analog behavior or physical limitations present in the analog device. In this circuit, the analog currents in the wires with the labels **P** and **V** implement the position and velocity of the oscillating mass.

The above circuit directly maps oscillator properties to physical signals: **1 μA** of current on wire **P** corresponds to **1 meter** of displacement, and **1 μA** of current on wire **V** directly corresponds to **1 meter/second** of velocity. This circuit also directly maps dynamical system time to hardware time:** 1 unit** of dynamical system time corresponds to **1 unit** of hardware time, and **7.936 μs** (**1/****126000 Hz**) of wall-clock time.

In the harmonic oscillator dynamical system, the oscillator position ranges from **[-10,10] m**, and the oscillator velocity ranges from **[-5,5] m/s.** Therefore, to faithfully model the harmonic oscillator, the above circuit would need to support analog currents with a range of at least **[-5,5] μA** on most wires (interval annotations). The above directly mapped computation cannot be executed on the HCDCv2 since it violates several physical restrictions imposed by the analog hardware:

**Analog Operating Range Violations**: Almost all of the analog signals in the above circuit violate the operating range restrictions of the analog ports in the circuit. The signal range annotations that violate operating range restrictions are highlighted in red.

**Example:**The analog signal provided to port**x**of the**INT (0,0)**block has a range of**[-2.5,2.5] μA**. This signal violates the port’s operating range since port**x**only accepts currents between**[-2,2] μA**.**Digital Operating Range Violations**: The**10.0**,**5.0**, and**1.66**values violate the operating ranges of the digitally settable data fields in the circuit and therefore cannot be written to the analog hardware.

**Example:**The above circuit sets data field**z0**of**INT (0,1)**to**5.0**(yellow callout). This value cannot be written to the device because data field**z0**only supports digital values between**[-1,1]**.**Frequency Violations**: The computation speed of the directly mapped circuit violates the frequency restrictions imposed by the analog hardware.

**Example:**The**OBS**block supports a maximum computation speed of**100800 Hz**, but the directly mapped computation speed is**126000 Hz**.

In addition, the above circuit does not consider the effect of process variation, noise, or quantization error on the computation. Even if the directly mapped circuit had respected the physical restrictions of the hardware, it is unlikely the dynamical system computation would have evolved as expected.

## The Scaled Circuit

To account for the analog behavior present in the hardware, we scale the signals and values in the directly mapped circuit. The resulting scaled circuit respects the device’s physical restrictions, compensates for process variation-induced behavioral deviations, and reduces the effect of noise and quantization error on the computation. We derive a **scaling transform** that can be applied to the directly mapped circuit at compile-time to produce a scaled version of the circuit. The original dynamical system dynamics is then recovered from the scaled circuit dynamics at runtime by applying a statically-derived recovery transform.

The above figure presents the scaling transform (blue and purple values) for the directly mapped harmonic oscillator circuit. The scaling transform is composed of magnitude scale factors and a time scale factor:

**Magnitude Scale Factors:** The magnitude scale factors scale the data field values and analog signals by constant coefficients (blue/purple numbers). These scale factors change the value ranges of the analog signals and digital values to respect the operating range restrictions imposed by the analog hardware. These scale factors also scale up signals to reduce the effect of noise and quantization error and compensate for manufacturing variation-induced behavioral deviations.

**Example 1:** The scaled circuit writes the scaled value **0.60241•1.66= 1.00** to the data field** c** of **MUL (1,0)**. This is within the data field **c**‘s operating range of **[-1,1]**.

**Example 2:** Port **a** of **COPY (0,0****)** is supplied with a scaled analog signal that has a range of **0.06291****•[-10,10] μA = [-0.6291,0.6291] μA**. This is within port **a**‘s operating range of **[-2,2] μA**.

**Time Scale Factor:** The time scale factor changes the execution speed of the computation to respect the frequency limitations of the analog hardware. To scale the speed of the computation, we leverage a property of first-order ordinary differential equations. If we multiply all the derivatives in a system of first-order ODEs by **𝛕**, the resulting time-scaled dynamical system will evolve at **𝛕** times the speed of the original dynamical system.

**Example****:** The above circuit scales the computation speed by a time scale factor of **0.55576** (upper-left corner). The computation speed of the scaled circuit is therefore **0.55576•126000 Hz = 70025 Hz. **This circuit therefore respects the computation speed restriction of **100800 Hz** imposed by the **OBS** block.

### Using the Scaling Transform

Using this scaling transform, we can derive a scaled circuit from the directly mapped circuit at compile-time and recover the original dynamical system dynamics from the scaled dynamics at runtime:

**Applying the Scaling Transform**: To apply the scaling transform, we multiply each data field value by its respective magnitude scale factor. This automatically scales all the analog signals in the circuit by their respective magnitude scale factors and scales the execution speed of the circuit by the time scale factor (**0.55576**).

**Example:** Applying the scaling transform changes the value written to port **c** of **MUL (0,0)** from **0.25** to **4.0****•0.25 = 1.0**.

**Recovering the Original Dynamics**: The scaling transform guarantees that the original dynamical system dynamics can be recovered from any measured signal in the scaled circuit at runtime. To recover the magnitude of the original signal, we divide the amplitude of the measured signal by its respective magnitude scale factor. To recover the dynamical system time, we divide the time samples, measured in wall-clock time, by the amount of wall-clock time required to execute one unit of dynamical system time in the scaled circuit.

**Example:** To simulate the harmonic oscillator for **20 units** of simulation time, we run the analog circuit for (**20)•7.936 μs/(0.55576)=285.62 μs** of wall-clock time and divide each measured time sample by **7.936 μs/(0.55576) = 14.281 μs**. To recover the oscillator position from port **m** of the **OBS (1,0)** block, we divide each analog current measurement (in μA) by the port’s magnitude scale factor **0.03676**.

## Deriving the Scaling Transform

We formulate the problem of finding a scaling transform as a geometric programming problem. A geometric programming problem is a constrained optimization problem that can be efficiently and optimally solved with a convex solver. This problem formulation enables us to find an optimal scaling transform with respect to some optimization criteria and to definitively determine if a satisfying scaling transform exists for a given directly mapped circuit. We generate the scaling problem from the directly mapped circuit’s structure and the analog behavior described in the hardware specification.

The geometric programming problem (GP) minimizes a posynomial, subject to a set of inequality constraints over posynomials and equality constraints over monomials. All geometric program variables resolve to positive, non-zero, real values. The GP formulation of the circuit scaling problem is defined as follows:

**Geometric Program Variables**: The scaling problem defines the magnitude scale factors**α****(block,loc,port)**and the time scaling factor 𝛕 as geometric program variables. Each magnitude scale factor**α(****block,loc,port)**scales the amplitude of the signal at a**port**of a**block**instance at a hardware location**loc**.**Objective Function**: The objective function describes the circuit metric to optimize. We minimize the**1/𝛕**expression to maximize the simulation speed of the scaled circuit.**Constraints**: The geometric program constraints ensure that the scaled circuit can be physically implemented on the analog hardware (physically realizable) and ensure that the original dynamical system dynamics can be recovered from the scaled circuit dynamics at runtime (recoverable).

### Deriving the Physical Realizability Constraints

The physical realizability constraints ensure the scaled circuit respects the frequency and operating range constraints present in the hardware and reduces the effect of noise and quantization error on the computation. In this section, we overview the subset of constraints that ensure the scaled circuit respects the frequency and operating range limitations imposed by the HCDCv2.

**Operating Range Constraints**: The operating range constraints ensure that the dynamic range of each scaled signal or value respects the operating range restriction imposed by the port or data field.

**Example:** The following constraint ensures the scaled signal provided to port **x** for the **INT (0,1) **block falls within the current range **[-2,2] μA**. The range of the signal in the directly mapped circuit is** [-5,5]**:

**α(INT,01,x) • [-5,5] ⊆ [-2,2]** **μA**

**Frequency Constraints**: The frequency constraints ensure the execution speed of the scaled dynamical system computation respects the frequency restrictions imposed by the analog blocks.

**Example:** The following constraint ensures the execution speed of the scaled circuit **𝛕 • 126000 Hz** is less than the maximum supported frequency of the **OBS (1,0)** block:

**𝛕 • 126000 Hz ≤ 100800 Hz**

### Deriving the Recoverability Constraints

The recoverability constraints ensure the original dynamical system dynamics can be recovered from the scaled dynamical system dynamics at runtime. These constraints also ensure the scaling transform reduces the effect of any process variation-induced behavioral deviations on the computation.

**Connection Constraints:** The connection constraints ensure that if two ports are connected together, the signals at those ports are scaled by the same amount.

**Example: **The following constraint ensures that the signal at port **z** of **INT (0,1)** and the signal at port **a** of **COPY (0,0) **are scaled by the same amount:

**α(INT,01,x) = α(COPY,00,a) **

**Factor Constraints**: The factor constraints ensure that the original signal dynamics can be recovered from the scaled signal dynamics at each output port by dividing the signal amplitude and time samples by constant factors. The factor constraints also ensure the scaling transform compensates for any manufacturing variation-induced behavioral deviations present in the fabricated block instances.

**Example: **The following factor constraints ensure that the dynamics of the scaled signal at port** z **of ** INT (0,1) **can be written as the original, unscaled signal dynamics of port

**z**multiplied by the magnitude scale factor

**α(INT,01,z)**of port

**z**:

**α(INT,01,z) = 0.95 • α(INT,01,x)•(1/𝛕)
**

**α(INT,01,z) = 0.89 • α(INT,01,z0)**

The above constraints contain both scale factors (**blue**) and coefficients that capture the effect of manufacturing variations (**red**) on the behavior of the ** INT (0,1)** block in the device on hand. These constraints ensure that we can factor out the magnitude scale factor

**α(INT,01,z)**from the scaled dynamics of the signal at port

**z**(left column) to obtain the original, unscaled dynamics of the signal

**(**

**, right column):**

**[**…**]**

Scaled Dynamics | α(INT,01,z) • [ Original, Unscaled Dynamics ] |
---|---|

α(INT,01,z) • z = ∫ 0.95 • 0.10 • (α(INT,01,x)• x)•(1/𝛕) dt | α(INT,01,z) • [ z= ∫ 0.10 •x• dt ] |

α(INT,01,z) •z(0) = 0.89• 2.0 • (α(INT,01,z0) •z0) | α(INT,01,z) • [ z(0) = 2.0 • z0 ] |

To do so, We first use the factor constraints to replace the ** 0.95 • α(INT,01,x)•(1/𝛕) **and ** 0.89 • α(INT,01,z0) **expressions in the scaled dynamics with the magnitude scale factor **α(INT,01,z)**. We then factor out **α(INT,01,z) ** from both relations to recover the original, unscaled dynamics of the signal (** [ … ]**).

## Conclusion

This concludes the series on compilation for dynamical system-solving analog computing platforms. If you are interested in working with a dynamical system-solving analog hardware prototype, please reach out.

**Bio**: Sara Achour is an Assistant Professor in the Electrical Engineering and Computer Science Departments at Stanford University.

**Disclaimer:** *These posts are written by individual contributors to share their thoughts on the SIGPLAN blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGPLAN or its parent organization, ACM.*