analog-ready — per-op break-even economics + CI gating, designed to sit beside aihwkit

[demirelo]

Hi all — I just open-sourced analog-ready (Apache-2.0, PyTorch) and want to be upfront about positioning: it deliberately does not redo aihwkit. The noise/drift modeling follows the family your ecosystem established (the drift model is the same power-law form as PCMLikeNoiseModel, and the docstrings credit that); what it adds is the layer I couldn't find elsewhere — per-op break-even economics (converter energy, reuse amortisation, ENOB gates), a fail-closed regression gate for CI, and per-field profile redaction so vendors can share reports without leaking coefficients.

The obvious bridge is importing aihwkit RPUConfig / device presets as analog-ready profiles. Before I build that, I'd value a maintainer's view on where the seam should live — and whether aihwkit-lightning changes the answer.

github.com/demirelo/analog-ready

[PabloCarmona]

Hello @demirelo, thanks for reaching out! Your work looks very interesting and promising. You can import and use the aihwkit library and his presets as long as you follow our license rules and credit accordingly, like I saw you are doing in the docstrings.

Can you explain us a little bit more what you're trying to achieve and mostly how in terms of the integration of our RPUConfig and presets in your tool? That way we can guide you better.

Also in terms of the aihwkit-lightning, we don't have any noise models or presets there, they come from aihwkit. I don't know if this respond to your answer.

Waiting for you response, thanks again for using out toolkit!

[demirelo]

Thank you, Pablo - both for the license guidance and for actually reading the docstrings :) Keeping the credit trail visible was a design goal, so I'm glad it shows.

What analog-ready is trying to achieve:
aihwkit answers "how accurate is this model on analog hardware, and how do I train for it?"

analog-ready deliberately doesn't touch that. It answers the two questions around it:

• "is analog economically favorable for this workload, per op?" (converter-energy / weight-reuse / ENOB break-even gates), and
• "does the model still clear a threshold at end-of-life, as a fail-closed CI gate?" (programming noise → drift → ADC composed, re-run on every model/profile change, with per-field redaction so vendors can share reports without leaking coefficients).

Since our noise physics is intentionally the same family as yours, the integration goal is simple: aihwkit stays the source of truth for device physics, and analog-ready imports rather than re-invents it.

Concretely, the importer I have in mind (living entirely on our side — our existing optional aimc extra already declares aihwkit, so there's zero maintenance burden on you) would map an InferenceRPUConfig + noise model into an analog-ready profile:

• forward.out_res → enob_avail (steps → effective bits; our quantizer is a symmetric 2^b−1-level model, so the mapping errs conservative)
• forward.out_bound (+ bound management) → our fixed-range ADC adc_full_scale (saturation model)
• forward.out_noise → our output Gaussian-noise sigma (closest counterpart; your value lives in normalized tile-output units, so the importer owns the scale conversion)
• Drift: your ν is conductance-dependent (and t_0=20s), while our model is a scalar drift_nu + drift_sigma_nu spread at t₀=1s — so the importer would fit an effective scalar ν and spread from your model and rebase the power-law reference, recording the approximation
• drift_compensation → recorded in the profile, since our reports explicitly document whether compensation is assumed
• Programming noise, same philosophy: your prog_coeff is a polynomial in normalized conductance (Σᵢ cᵢ(gₜ/g_max)ⁱ via g_converter), while our model is proportional + read floor in weight space. Rather than a lossy closed-form conversion, the importer would sample apply_programming_noise on a reference weight tensor and fit our two-parameter form empirically, storing the fit residual in the profile's per-field uncertainty and the origin (e.g. aihwkit PCMLikeNoiseModel v1.1) in its source field — so every imported number carries where it came from and how good the approximation is.
• Fields aihwkit doesn't define (per-op energy coefficients, array geometry for the cost model) stay literature defaults, with the per-field source metadata making the split visible in every report.

Three questions where your guidance would genuinely change the design:

1. Is the empirical-fit approach (for programming noise and the effective drift ν) the mapping you'd endorse, or is there a canonical conversion via g_converter you'd recommend instead?
2. What's the right way to interpret out_bound relative to typical tile-output scale for a saturation model — is there a convention you use internally?
3. Which noise models/presets would you consider the canonical starting set for the importer, so it begins where you'd point your own users?

And understood re: aihwkit-lightning - importer targets aihwkit proper.

Thanks for the clarification, and again for the welcome!

[PabloCarmona]

Thanks a lot @demirelo for your work, only as a request we think along all reference and usage you're doing of the aihwkit would be very important to us that you add a link to the project somewhere else either in docs, README, etc.

Answering your questions:

1. I think here we are confusing 2 concepts. The g_converter is what we use to map the weights of the network with the conductance values on the chip and the empirical fit is the way we use the different noise models. So those are two separate concepts. Then, I don't know exactly what is your doubt here.

2. The way we use and visualize the out_bounds clips is the scale that is applied prior to the output_scale bound values (that normally range between -1, 1). If the value is outside the range of the bound values we clip it and get the ADC output for each tile.

3. I think at the start you can go with:

• StandardHWATrainingPreset (aihwkit.simulator.presets.StandardHWATrainingPreset) — start here. It's our standard AIMC noisy-inference evaluation setting for comparable benchmarking.
• StateIndependentNoiseModel — device-agnostic, same functional family as yours, exact import. Best default for a vendor who has characterised numbers but isn't on PCM.
• PCMLikeNoiseModel — fitted and characterised on real PCM.

Even do I advice you to look at our notebook examples to check what other types and devices or noise models we have and how you can affect the inference or training of the networks.

• Full list of presets: https://github.com/IBM/aihwkit/blob/b5037ef723730e98603803cb6cf6818d2225d65e/src/aihwkit/simulator/presets/__init__.py
• Full list of noise models: https://github.com/IBM/aihwkit/tree/b5037ef723730e98603803cb6cf6818d2225d65e/src/aihwkit/inference/noise

I hope this helps, if you need any further discussion or doubts, please follow along here or open a new discussion if it's a different topic.