VHDL测试台等待时钟沿的实现方案及潜在问题咨询

现有1ns等待方案的隐藏风险 #

你当前使用的wait for 1 ns ; wait until rising_edge( clock ) ;写法存在多个不可忽略的隐患：

• 可移植性极差：如果后续时钟周期调整为≤1ns的场景，或者该procedure被复用至其他更快的时钟域测试逻辑中，会直接漏采时钟上升沿，导致功能错误
• 边沿对齐风险：如果时钟模型的边沿并非整数ns对齐（比如PLL输出带小数偏置的时钟、跨时钟域建模的异步时钟），1ns的固定延迟可能刚好落在时钟跳变沿上，引发采样竞争，出现随机的仿真结果异常
• 降低仿真效率：额外的1ns时间等待会增加仿真器的事件调度开销，大规模测试用例下仿真耗时会明显上升

关于连续wait until语句合并的误解 #

你担心两个连续wait until rising_edge(clock)语句被合并的情况，不符合VHDL 93的标准仿真语义：每个独立的wait语句都会触发进程挂起，下一次唤醒后执行到后续wait语句时，必须等待新的触发条件满足，即使两个wait语句之间没有任何信号赋值操作，连续两个wait until rising_edge(clock)也会正确等待两个连续的时钟上升沿，不存在合并执行的情况。你之前碰到的类似现象大概率是代码逻辑错误，或是特定版本ISIM的偶发bug，不是标准行为。

delta延迟需求的标准实现方式 #

等待一个delta延迟的需求在VHDL 93中完全可以实现，且不需要消耗任何实际仿真时间，标准写法是使用wait for 0 ns;：该语句会让当前进程在当前仿真时间点挂起，等待当前delta周期的所有信号更新完成后，在下一个delta周期恢复执行，完美符合你的需求，且不存在任何时间相关的隐患，ISIM仿真器完全支持该语法。

推荐的procedure封装方案 #

你可以直接使用以下两种符合标准的封装，不需要添加1ns固定延迟：

1. 基础版本，仅等待下一个时钟上升沿：

procedure wait_next_clk is
begin
  wait until rising_edge(clock);
end procedure wait_next_clk;

2. 带delta延迟的版本，等待上升沿后所有同步信号更新完成再返回，避免采样到旧值：

procedure wait_next_clk is
begin
  wait until rising_edge(clock);
  wait for 0 ns;
end procedure wait_next_clk;

内容的提问来源于stack exchange，提问作者Theodore Norvell