探讨：toffee 框架扩展以支持模拟/混合信号验证

[LewisLiuLiuLiu]

起因

toffee 的核心理念是"让软件人员不需要懂硬件也能写验证"，通过 Bundle/Agent/Env/Model 的分层抽象，把硬件细节封装在 Agent 内部，测试用例只和业务语义打交道。

这套抽象在数字验证中已经验证可行。但实际芯片中大量存在模拟和混合信号模块（LDO、ADC、PLL、Comparator 等），这些模块目前仍然依赖手工 SPICE 仿真 + 人眼看波形，没有自动化回归能力。

我想探讨的是：toffee 的现有抽象体系能否自然地扩展到模拟/混合信号领域？需要做哪些改动？

toffee 现有抽象的适用性分析
toffee 的分层设计：

TestCase → Env → Agent → Bundle → DUT (picker 编译的 .so)

对于模拟扩展，这套分层关系基本成立，但每一层都需要处理模拟域的新问题：

Bundle 层 — 信号类型扩展
数字 Bundle 中的 pin 是离散的 0/1。模拟域需要引入连续值信号：

• 电压 pin（浮点值，而非 0/1）
• 电流 pin
• 以及一个关键问题：同一个 pin 在不同场景下需要不同视角

典型例子是 comparator 的输出：模拟侧它是连续电压（0.1V~1.7V），数字侧它是逻辑 0/1。当输入差分接近零时，输出处于不定态——既不是稳定的高也不是稳定的低。

我的想法是引入 AnalogSignal：

class AnalogSignal:
   @property
   def voltage(self) -> float:
       """模拟视角：原始电压值"""

   @property
   def digital(self) -> int:
       """数字视角：阈值判定后的 0/1"""

   @property
   def is_marginal(self) -> bool:
       """是否处于不定态区间"""

这样同一个信号，comparator 的 Agent 用 .voltage 做模拟断言，下游数字 Agent 用 .digital 做逻辑断言，框架自动处理视角转换。

Agent 层 — 驱动方式的根本差异
数字 Agent 驱动的是 picker 编译的 .so，操作是读写 pin、推时钟。模拟 Agent 驱动的是 SPICE 仿真引擎（ngspice 共享库），操作是：

• 读节点电压/电流
• 通过 alter 命令动态修改电路参数（电阻值、电容值、电压源值）
• 触发不同类型的分析（DC/AC/Tran/Noise）

但对上层 Env 和 TestCase 来说，Agent 的接口应该是一致的——这正是 toffee 分层的价值。测试用例不需要知道底下跑的是 Verilator 还是 ngspice。

Agent 层 — loading effect 的处理
这是模拟验证中一个核心问题：模拟模块的输出驱动能力有限，负载会影响电路行为。
经过思考，结论是：负载是 netlist 中的真实 R/C 元件，但其参数值通过 Agent 调用 alter 动态修改。这样可以在不同测试用例中 sweep 负载参数，找到电路的 spec 边界：

@pytest.mark.parametrize("c_load", np.linspace(1e-12, 200e-12, 50))
@toffee_test.testcase()
async def test_ldo_stability(ldo_env, c_load):
   await ldo_env.agent.set_load_param("C_load", c_load)  # alter 修改负载电容
   is_stable = await ldo_env.agent.check_stability()
   assert is_stable

这里的关键认识是：alter 修改的是 netlist 中已有元件的参数，负载始终是真实的电路元件（有阻抗特性），不是抽象的"参数"。早期验证阶段后级电路还没有时，用理想 R/C 做负载 + sweep。 找边界，这本身就是模拟工程师的标准做法。

Agent 层 — 内部节点的诊断
数字验证中，Agent 只看端口信号。模拟验证中，失败时经常需要深入到内部节点（比如 LDO 内部的 vref、vfb、verr）才能定位问题。

我的想法是在 Agent 中引入三级诊断：

1. 日常回归：Agent 只断言端口行为（输出精度、建立时间），速度快
2. 失败诊断：Agent 预埋少量关键内部节点到 .save 中，失败时自动读取输出诊断信息
3. 交互式 Debug：保存完整波形文件，人工查看任意节点

class LdoAgent(Agent):
   DIAGNOSTIC_NODES = ["v(x_ldo.vref)", "v(x_ldo.vfb)", "v(x_ldo.verr)"]

   async def diagnose(self):
       """断言失败时自动调用，输出内部节点快照"""
       for node in self.DIAGNOSTIC_NODES:
           val = await self.spice.read(node)
           logger.info(f"  {node} = {val:.6f}V")

这不改变 toffee 的分层——诊断逻辑封装在 Agent 内部，测试用例不感知。

Env 层 — 混合信号组合
MixedSignalEnv 组合数字 Agent 和模拟 Agent，核心新增的是同步机制：

• 数字仿真是事件驱动的（ns 级），SPICE 是连续时间的（ps 级步长）
• 通过 ngspice 回调（GetVSRCData/SendData）实现事件驱动同步
• 设置最大同步间隔作为兜底，防止时间漂移

这一层对 TestCase 透明。TestCase 只是同时操作数字 Agent 和模拟 Agent，Env 负责保证它们的时间一致。

分析结果层 — 新增抽象
数字验证中没有"分析类型"的概念。模拟验证中，DC/AC/Tran/Noise 的结果格式和断言方式完全不同：

• Tran：事件驱动协同仿真，需要同步机制（最复杂）
• DC/AC/Noise：一次性运行，调用后等结果（相对简单）

需要引入 AnalysisResult 体系，各子类提供专用工具方法：

# AC 分析
ac = await opamp_env.agent.run_ac(1, 1e9, 20)
assert ac.phase_margin("v(vout)") > 60

# Tran 分析
tran = await ldo_env.agent.get_tran_result()
assert tran.settling_time("v(vout)", target=1.2, tol=0.01) < 10e-6

与 pytest 生态的结合
PVT Corner 和 Monte Carlo
PVT sweep 和 Monte Carlo 天然适合 pytest.mark.parametrize：

PVT_CORNERS = [
   PVTCorner("tt", 1.8, 25),
   PVTCorner("ff", 1.98, -40),
   PVTCorner("ss", 1.62, 125),
]

@pytest.mark.parametrize("corner", PVT_CORNERS)
@toffee_test.testcase()
async def test_ldo_accuracy(ldo_env, corner):
   await ldo_env.load_corner(corner)
   vout = await ldo_env.agent.measure_vout_dc()
   assert abs(vout - 1.2) < 0.012

Monte Carlo 的每次 run 独立，直接用 parametrize + xdist 并行：

@pytest.mark.parametrize("mc_run", range(200))
@toffee_test.testcase()
async def test_ldo_mc(ldo_env, mc_run):
   await ldo_env.set_mc_seed(42 + mc_run)
   vout = await ldo_env.agent.measure_vout_dc()
   mc_collector.record(mc_run, "vout", vout)

拟定的实施路线

阶段	目标	验收标准
Phase 0	ngspice 共享库 Python 绑定（独立于 toffee）	RC 电路端到端测试通过
Phase 1	toffee 集成：AnalogBundle、AnalogAgent、MixedSignalEnv	toffee 风格的 LDO 测试通过
Phase 2	数字-模拟协同仿真同步机制	ADC 混合信号 demo 通过
Phase 3	多分析类型 + PVT/MC + AnalysisResult 体系	OpAmp AC + PVT sweep 通过
Phase 4	并行化 + 分层 CI	xdist 并行执行正确

[yaozhicheng]

如果底层能提供模拟信号给到 toffee ，对toffee改动应该不大

[yaozhicheng]

@Miical @Makiras 两位可以评估一下

[LewisLiuLiuLiu]

从目前的方案来看，是不会对数字部分的代码做任何修改。相当于是在数字部分的外面增加一个模拟的agent，模拟的bundle（因为涉及到具体的电压值，压摆率）。
最顶层会因为增加模拟部分，导致需要修改，但是不会触碰数字部分。

问题的本质
考虑一个 ADC 的混合信号验证：

数字侧在 clk 上升沿采样 comp_out，但模拟侧的 comp_out 是连续变化的电压。如果两侧时间不一致，数字侧可能采到一个"还没稳定"的值。

ngspice 共享库的回调机制
ngspice 共享库提供三个关键回调，这是实现同步的基础：

// 1. SPICE 每个时间步开始时调用，请求外部电压源的值
// → 数字侧在这里把输出 pin 的值"注入"到 SPICE 中
int GetVSRCData(double *voltage, double actualTime, char *nodeName, int id, void *userData);

// 2. SPICE 计算出结果后调用，输出节点数据
// → 数字侧在这里"读取" SPICE 的输出
int SendData(pvecvaluesall vecData, int numStructs, int id, void *userData);

// 3. SPICE 在每个时间步询问：是否需要在某个时间点暂停？
// → 数字侧在这里告诉 SPICE "请推进到下一个时钟边沿就停"
int GetSyncData(double actualTime, double *deltaTime, int id, void *userData);

同步策略
基于这三个回调，同步分两层：

第一层：事件驱动同步
数字侧有事件（时钟边沿、信号变化）时，通过 GetSyncData 告诉 SPICE "推进到这个时间点就暂停"：

在每个同步点：

1. SPICE 暂停，调用 SendData → 数字侧读取模拟输出（comp_out 的电压）
2. 数字侧执行逻辑（SAR 寄存器更新、状态机跳转）
3. 数字侧更新输出 → SPICE 通过 GetVSRCData 读取新的数字输入
4. SPICE 继续推进到下一个同步点

第二层：兜底同步

不是所有时刻都有数字事件。比如 LDO 稳压过程中，数字侧可能长时间没有动作，但模拟侧一直在求解。如果完全不同步，两侧时间可能漂移很远。

兜底策略：设一个最大同步间隔（如 10ns），即使没有数字事件，也定期交换一次数据：

class SyncController:
   def __init__(self, max_interval: float = 10e-9):
       self.max_interval = max_interval
       self._next_digital_event: float = float('inf')

   def get_sync_delta(self, current_time: float) -> float:
       """GetSyncData 回调中调用，返回下一个同步点的 delta"""
       next_event = self._next_digital_event
       next_fallback = current_time + self.max_interval
       return min(next_event, next_fallback) - current_time

   def schedule_event(self, time: float):
       """数字侧注册一个事件（如下一个时钟边沿）"""
       self._next_digital_event = min(self._next_digital_event, time)`

同步精度与性能的权衡
同步越频繁，精度越高，但 SPICE 被频繁打断会影响求解器效率（自适应步长被迫切断）。这里需要区分场景：

场景	同步频率	原因
SAR ADC 逐次逼近	每个比较周期同步	每次比较结果决定下一次输入
LDO 稳压过程	低频兜底即可	数字侧无动作，模拟侧自由求解
PLL 锁定	每个参考时钟边沿同步	鉴频鉴相器需要数字/模拟交互
纯模拟测试（DC/AC）	不需要同步	一次性运行，无数字交互

框架应该让 Agent 声明自己需要的同步粒度，而不是用一个全局策略：

class AdcAgent(AnalogAgent):
   sync_mode = SyncMode.EVENT_DRIVEN  # 每个数字事件都同步

class LdoAgent(AnalogAgent):
   sync_mode = SyncMode.PERIODIC      # 周期性兜底同步
   sync_interval = 100e-9             # 100ns 一次

Xyce 的对比
如果后续切换到 Xyce 引擎，同步机制会更精确。Xyce 提供 xyce_simulateUntil(requestedUntilTime, &achievedFinalTime)，可以明确要求仿真推进到某个时间点并返回实际到达的时间。相比 ngspice
的回调式被动同步，Xyce 是主动式精确控制。但 ngspice 的方案足以覆盖大多数场景，Xyce 作为可选后端。

在 toffee 中的位置
同步机制封装在 MixedSignalEnv 内部，对 TestCase 完全透明：

@toffee_test.testcase()
async def test_adc_conversion(adc_env):
   # 测试用例不需要知道同步细节
   adc_env.digital_agent.start.value = 1           # 触发转换
   await adc_env.digital_agent.clk_edge()           # 等一个时钟
   adc_env.digital_agent.start.value = 0

   await adc_env.wait_for(
       lambda: adc_env.digital_agent.done.value == 1,
       timeout=10e-6
   )

   result = adc_env.digital_agent.data.value         # 读转换结果
   expected = int(adc_env.analog_agent.read("v(vin)") / 1.2 * 4096)
   assert abs(result - expected) <= 2                # ±2 LSB 

所有同步复杂度都在 Env 层处理，测试用例只表达业务意图。这与 toffee 数字验证中"TestCase 不感知时钟驱动细节"的理念一致。

[LewisLiuLiuLiu]

目前看来唯一会对Toffee底层改动的地方，分析结果如下：

核心耦合点

1. asynchronous.py 中的 __clock_loop — 最关键的耦合点
   asynchronous.py:161-174:

async def __clock_loop(dut):
   while True:
       await execute_all_coros()
       dut.Step(1)          # ← 硬编码：推一个时钟周期
       dut.event.set()      # ← 硬编码：通过 dut 的 event 通知所有等待者
       dut.event.clear()

这是整个 toffee 的"心跳"。每个循环做三件事：

1. 执行完当前所有可执行的协程（execute_all_coros）
2. 推一步时钟（dut.Step(1)）
3. 触发 event 通知所有等待者

问题：dut.Step(1) 是 picker 编译出的数字 DUT 的方法，直接调用 Verilator/VCS 推一个时钟周期。模拟仿真没有这个概念——SPICE 的时间推进是连续的，不是按时钟步进的，这里需要考虑。

2. Bundle.step() — 等待机制依赖 clock event
   bundle.py:669-682:

async def step(self, ncycles=1):
   if self.__clock_event is None:
       critical("cannot use step in bundle without a connected signal")
   for _ in range(ncycles):
       await self.__clock_event.wait()

Bundle 的 step 等的是 __clock_event，这个 event 来自 DUT 的 XPin 的 signal.event（bundle.py:1153-1154）。XPin 是 picker 生成的数字信号对象，它的 event 在 dut.Step(1) 时被 set。
模拟 Bundle 没有 XPin，也没有这个 event 来源。

3. triggers.py — 全部依赖 pin.event.wait()
   triggers.py 中所有触发器（ClockCycles, Value, RisingEdge, FallingEdge）都通过 await pin.event.wait() 等待，而这个 event 的来源同样是数字 DUT 的时钟。

4. Monitor 的驱动循环
   _base_agent.py:238-240:

async def __monitor_forever(self):
   while True:
       await self.agent.monitor_step()  # ← 等一个时钟步
       ret = await self.func(self.agent)

monitor_step 来自 agent.py:28：self.monitor_step = bundle.step。所以 Monitor 也是每个时钟周期执行一次。

5. Agent 构造函数
   agent.py:15-28:

class Agent:
   def __init__(self, bundle):
       if callable(bundle):
           self.monitor_step = bundle
       else:
           self.bundle = bundle
           self.monitor_step = bundle.step  # ← 绑定到 bundle 的 step

Agent 初始化时绑定了 bundle.step 作为 monitor 的推进函数。

6. Env — 无耦合
   env.py 本身不包含任何时间推进逻辑。它只是 Agent 的容器 + Model 注入/匹配机制。这层不需要改。

7. Model — 间接耦合
   Model 继承自 Component（asynchronous.py:318-338），Component.__main_wrapper 等待 global_clock_event：

async def __main_wrapper(self):
   while True:
       loop = asyncio.get_event_loop()
       if hasattr(loop, "global_clock_event"):
           await loop.global_clock_event.wait()
           break
   await self.main()

Model 只是等 clock 启动后才执行 main，这是个一次性等待，影响不大。

总结：影响范围

文件	耦合程度	需要改动
asynchronous.py	强 — __clock_loop 硬编码 dut.Step(1)	需要抽象时间推进接口
bundle.py	强 — step() 依赖 XPin 的 event	模拟 Bundle 需要不同的 event 来源
triggers.py	强 — 所有触发器依赖 pin.event	模拟侧需要自己的触发机制
_base_agent.py	中 — Monitor 循环依赖 bundle.step	模拟 Agent 需要覆盖 monitor_step
agent.py	低 — 只是绑定 monitor_step	允许模拟 Agent 传入自定义 step 函数即可
env.py	无	不需要改
model.py	低 — 只等启动信号	基本不改
executor.py	无	纯调度逻辑，不涉及时间

核心结论
耦合确实存在，但集中在一个链条上：
__clock_loop (dut.Step) → dut.event.set() → XPin.event → Bundle.step() → Agent.monitor_step
这是一条从"时间源"到"等待者"的单向链。数字侧的时间源是 dut.Step(1)，模拟侧的时间源是 SPICE 仿真引擎。

需要做的改动是把这条链的"源头"抽象化，具体来说：

1. 抽象时间推进器：__clock_loop 不直接调用 dut.Step(1)，而是调用一个可替换的 time_driver.advance() 接口。数字实现调 dut.Step(1)，混合信号实现同时推 DUT 和 SPICE，纯模拟实现只推 SPICE。
2. 抽象 event 来源：模拟 Bundle 不从 XPin 获取 event，而是从 SPICE 同步点获取 event。可以在 AnalogBundle 中覆盖 event 来源。
3. Agent 已经有注入口：Agent.init 已经支持传入自定义的 monitor_step（agent.py:21-23 的 if callable(bundle) 分支），所以模拟 Agent 传入一个基于 SPICE 同步点的 step 函数即可，不需要改Agent 基类。

对现有数字用户的影响：如果用抽取接口 + 默认实现的方式做，现有数字代码不需要任何修改。__clock_loop 的默认行为保持原样（dut.Step(1)），只有创建混合信号 Env 时才替换时间推进器。

改动量估计：主要集中在 asynchronous.py 中约 30-50 行的重构，加上新增 AnalogBundle 和 AnalogAgent 子类。现有代码的行为不变。

[LewisLiuLiuLiu]

@yaozhicheng @Miical @Makiras
这是我的修改方案中的核心改动点

[LewisLiuLiuLiu]

关于时间同步，还有一种模式，根据场景不同，可以选择，具体讲解如下：

lazy模式是zero ASIC组织的开源repo“switchboard”中的数模交互的方式，它是以数字为主，模拟为辅的一种交互方式。SPICE 仿真引擎不会主动往前跑。只有当数字侧需要读模拟数据时，才检查 SPICE 是否跑到了对应的时间点，没到的话就推进到那个时间点。

用一个例子说明：
假设数字侧时钟周期是 10ns，SPICE 侧是一个 LDO 电路，非 lazy（事件驱动回调模式）如下：

而Lazy模式呢：

SPICE 从 0 直接跑到 40ns，中间不停顿、不回调、不和 Python 交互。求解器的自适应步长完全不受干扰，效率最高。

整个 lazy 模式只有三个原语：

1. put(name, time, value) — 写入，不推进

   • 数字侧: "在 t=5ns 时，把 enable 脚设成 1.8V"
   • 发生的事: 只是记录了一条 (t=5ns, 1.8V) 到队列中SPICE 没有动
   • 相当于在纸上记了一笔账："到时候给 SPICE 用"。

2. get(name, time) → value — 读取，按需推进

   • 数字侧: "告诉我 t=40ns 时 v(vout) 是多少"
   • 发生的事:
     1. 检查: SPICE 当前跑到哪了？ → t=0ns
     2. 发现: 0ns < 40ns，需要推进
     3. 把之前 put 记录的所有值告诉 SPICE
     4. 调用 simulateUntil(40ns) → SPICE 一口气跑到 40ns
     5. 读取 v(vout) 的值 → 返回 1.198V

3. advance_to(time) — 纯推进，不读不写

   • 数字侧: "确保 SPICE 至少跑到 t=100us"
   • 发生的事:
     如果 SPICE 已经跑过了 100us → 什么都不做（"懒"的体现）
     如果还没到 → simulateUntil(100us)

总结一下上面所有讨论的的区别：

	Lazy（switchboard）	事件驱动（ngspice 回调）
谁主导时间	数字侧主导，SPICE 被动跟随	SPICE 主导（每个时间步回调）
数据流方向	Pull — 数字侧 get 时才拉数据	Push — SPICE 每步推数据
推进粒度	按需推进，可以一次跳很远	每个 SPICE 内部时间步都同步

Lazy 模式和 toffee 的协程模型天然契合。
toffee 的 __clock_loop 是：

async def __clock_loop(dut):
   while True:
       await execute_all_coros()  # 执行所有就绪协程
       dut.Step(1)               # 推进时间
       dut.event.set()           # 通知等待者
       dut.event.clear()

如果用 lazy 模式，扩展非常自然：

async def __clock_loop(dut, spice_session=None):
   while True:
       await execute_all_coros()
       dut.Step(1)
       if spice_session:
           # lazy: 只在需要时推进 SPICE 到当前数字时间
           spice_session.advance_to(current_time)
       dut.event.set()
       dut.event.clear()

不需要改造 toffee 的异步框架。ngspice 回调模式要求 SPICE 在每个内部时间步调用 Python，这意味着要把 Python 协程调度嵌入到 C 回调中——跨语言的协程交互非常复杂。Lazy 模式完全在 Python侧控制流程，回避了这个问题。

Lazy 模式的真正问题
问题不在于"懒"本身，而在于它是纯 pull 模式——SPICE 不能主动通知数字侧。

考虑一个场景：comparator 的输出在两个时钟沿之间翻转了。

如果 SB_CLK 频率不够高，数字侧会延迟感知模拟侧的事件。这对某些场景不是问题（LDO 稳压、缓慢变化），但对另一些场景是致命的（SAR ADC 的比较器结果必须在当拍用）。

因此toffee 可以同时支持两种模式，让 Agent 声明自己需要哪种：
场景 1：Lazy 模式适合的

• 纯模拟测试（DC/AC/Noise）：根本不需要同步，一次性 run 完读结果
• 低频交互（LDO 负载瞬态、Power-on sequence）：数字侧偶尔写几个控制信号，然后等很久，期间 SPICE 自由求解
• 参数 sweep：改一个参数，跑完整个仿真，读结果。天然是 lazy 的
  对这些场景，lazy 模式的好处是巨大的——SPICE 不被频繁打断，求解器效率最高。

class LdoAgent(AnalogAgent):
   sync_mode = SyncMode.LAZY

   async def measure_vout_dc(self):
       # 推进 SPICE 到足够远，让 LDO 稳定
       await self.spice.advance_to(self.current_time + 100e-6)
       return self.spice.read("v(vout)")

场景 2：Lazy 模式不够的

• SAR ADC 逐次逼近：每个比较周期数字侧必须立即知道 comparator 结果，再决定下一位
• PLL 鉴频鉴相器：数字分频器输出和模拟 VCO 输出必须在同一时刻比较
• 任何数字逻辑依赖模拟结果做实时决策的场景

这些场景需要更紧密的同步。但这里有个关键洞察：即使是这些场景，也不需要 ngspice 回调级别的逐步同步。实际上它们需要的是——在特定时间点精确同步，也就是 Xyce 的 simulateUntil 模式。

class SarAdcAgent(AnalogAgent):
   sync_mode = SyncMode.STEP_EXACT

   async def compare_one_bit(self, dac_code):
       # 设置 DAC 输出
       self.spice.put("v_dac", dac_code * self.lsb)
       # 精确推进到比较完成的时刻
       await self.spice.advance_to(self.current_time + self.compare_period)
       # 立即读 comparator 输出
       comp_out = self.spice.read("v(comp_out)")
       return comp_out > self.threshold

这仍然是 lazy 的变体——不是 SPICE 主动推数据，而是数字侧在需要时精确推进到目标时间。和 switchboard 的区别只是推进粒度更细（不是按 SB_CLK，而是按逻辑需要的时间点）。

场景 3：真正需要 SPICE 主动通知的
模拟电路信号突破阈值，数字接受为异步信号，但这不属于lazy模式，可以由别的模式来完成

因为验证的驱动权始终在测试用例（Python）手里。测试用例知道什么时候该读数据。不像真实芯片中模拟侧会产生异步中断——在仿真环境中，测试用例控制着时间推进，它总是可以选择在合适的时间点去 get。

ngspice 的回调模式（GetVSRCData/SendData/GetSyncData）真正有用的场景是：数字仿真器和 SPICE 在同一个进程中作为对等的仿真引擎并行运行，谁也不从属于谁。但在 toffee 的架构中，Python是"上帝视角"的控制者，它不需要被动接收 SPICE 的回调。

结论
Lazy 模式应该作为 toffee 模拟扩展的主要同步策略，而不是之前讨论的 ngspice 回调模式。理由：

1. 与 toffee 协程框架兼容性最好——不需要跨语言回调与协程调度的交互
2. 对现有代码改动最小——只需在 __clock_loop 或 Agent 层加一个 advance_to 调用
3. SPICE 求解器效率最高——不被频繁打断，自适应步长充分发挥
4. 覆盖绝大多数验证场景——测试用例控制时间推进，总是知道什么时候该读数据

具体实现上：

class SpiceSession:
   def advance_to(self, target_time: float):
       """Lazy 推进：如果 SPICE 已经到了，什么都不做"""
       if target_time > self._current_time:
           if self._engine == 'xyce':
               xyce_simulateUntil(self._obj, target_time, ...)
           elif self._engine == 'ngspice':
               # ngspice 共享库也可以做类似的事：
               # 设置断点时间，调用 run，让它跑到目标时间停下
               self._cmd(f"stop when time >= {target_time}")
               self._cmd("run")

   def put(self, name: str, value: float):
       """记录值，不推进"""
       # Xyce: updateTimeVoltagePairs
       # ngspice: alter 或 VSRC 数据注入

   def get(self, name: str) -> float:
       """读值，必要时先推进到当前数字时间"""
       self.advance_to(self._digital_time)
       return self._read_node(name)

之前的 ngspice 回调方案和xyce时间同步方案可以作为可选的高级模式保留，供那些确实需要 SPICE 内部每步都参与的极端场景（比如自定义的非线性器件模型需要与数字侧实时交互）。但对于 toffee 的 Phase 0~Phase 3，lazy 模式足够了，而且实现简单得多。

这也意味着 Phase 0 的 ngspice 绑定可以更简单——不需要一开始就实现复杂的回调注册，只需要能 source、run（跑到指定时间）、read、alter 即可。

[LewisLiuLiuLiu]

整体来说改动不大，只需要把同步时钟那里做出一个选项即可，数字还是数字，模拟这边是模拟的。模拟和数字之间交互是新增加的，交互会数字对数字侧的逻辑没有改动

[yaozhicheng]

看着可行，具体开发我们可以协同

[LewisLiuLiuLiu]

那什么时候可以开始呢？需要腾讯会议一下吗？

[yaozhicheng]

我们找找这边有没有同学对模电感兴趣