采样和数据驱动

竞争问题

 为了避免在RTL仿真行为中发生信号竞争问题，建议通过非阻塞赋值或者延迟来解决同步问题

• 同样地在仿真行为中，为了尽量避免时序电路中时钟和驱动信号的时序竞争问题，我们需要给出尽量明确的驱动时序和采样时序。
• 默认情况下，时钟对于组合电路的驱动会添加一个无限最小时间(delta-cycle)的延迟，而该延迟无法用绝对时间单位衡量，它要比最小时间单位精度还小。（该延迟仅在仿真上有意义）
• 在一个时间片(time-slot)中可以发生很多事情，例如在仿真器中敲入命令"run o"，即是让仿真器运行一个delta-cycle的时间。

forever #5 clk1<=!clk;
...
always @(clk1) clk2<=clk1;
...
[email protected](posedge clk1 or negedge rstn)begin
    if(!rstn) d1<=0;
    else d1<=d1+1;
end
...

波形和打印的不一致，打印的更准确

• clk2和clk1尽管在波形上看起来是在相同时间起落的，但是clk2相比于clk1要晚于一个delta-cycle，这是由于always中的驱动所添加的，同时d1又晚于clk1—个delta-cycle，所以d2与clk2并没有相差delta-cycle，即它们之间是同时发生变化的。（如clk1采样45ns处，clk2采样45ns处其实表示45ns+delta-cycle）因此在45ns处，clk1要领先d1一个delta-cycle，采样出d1=1,而clk2与d1同时变化，即d1在变为2时，clk2也处于上升沿处，因此clk2采样d2=2。
• 
• 所以由于各种可能性，clk与被采样数据之间如果只存在若干个(0..N) delta-cycle的延迟，那么采样可能会存在问题，例如上面例子中clk1与clk2对d1采样，在同样的时刻中得到的是不同采样结果。采样数据中的竞争问题会成为潜在困扰仿真采样准确性的问题。

如何避免采样的竞争问题呢?

• 在驱动时，添加相应的人为延迟，模拟真实的延迟行为，同时加大clk与变量之间的延迟，以此提高DUT使用信号时的准确度和TB采样信号时的可靠性。
• 对于一些采样时依然存在delta-cycle延迟的信号，我们还可以依靠在采样事件前的某段时刻中进行采样，来模拟建立时间的采样要求，确保采样的可靠性。

接口中clocking

• 硬件世界和软件世界的连接可以通过灵活的interface来实现，也可以通过modport来进—步限定信号传输的方向，避免端口连接的错误。（clocking包括modport很重要的一部分）
• 也可以在接口中声明clocking(时序块）和采样的时钟信号用来做信号的同步和采样。（clocking不是interface独有，还可以在module中用）
• clocking块基于时钟周期对信号进行驱动或者采样的方式，使得testbench不再苦恼于如何准确及时地对信号驱动或者采样，消除了信号竞争的问题。

clocking [email protected](posedge clock1);   //定义clocking bus，由clock1上升沿驱动和采样
    default input #10ns output #2ns; //指出clocking块中所有信号，默认情况会在clocking事件 
                             （clock1上升沿）的前10ns来对其进行输入采样，在事件后2ns对其进行驱动
    input data,ready,enable;  //要采样的三个输入信号，作为输入，它们的采样事件采用了默认输入事件
    output negedge ack;  //要驱动的ack信号，而驱动该信号的事件是时钟clock1的下降沿，覆盖了原有默 
                           认输出事件
    input #1step addr;  //采用自身定义的采样事件，即clock1上升沿的前1step。这里的step会使采样发 
                  生在clock1上升沿的上一时间采样区域，即可以保证采样到的数据是上一个时钟周期的数据
endclocking

• clocking块不但可以定义在interface中，也可以定义在module和program中。
• clocking中列举的信号不是自己定义的，而是应该由interface或者其它声明clocking的模块定义的。
• clocking在声明完名字之后，应该伴随着定义默认的采样事件，即"default input/output event"。如果没有定义，则会默认地在clocking采样事件前的1step对输入进行采样，在采样事件后的#0（一个时钟片，相当于无穷个delta cycle）对输出进行驱动。
• 除了定义默认的采样和驱动事件，也可以在定义信号方向时，用新的采样事件对默认事件做覆盖。

（clocking [email protected](posedge clk)    --->    @ck == @（posedge clk)）

 

 

 无论是采样ck.vld还是采样vld，值的变化都发生在时钟上升沿

 

同样地，利用clocking块通过一种类似于"物理保持时间"的驱动方式，可以实现时钟沿叠加偏移量的延迟驱动效果。例如上面的例子，对于ck块中的grt赋值，是通过clocking块ck.grt来进行的。虽然赋值的时间点都是在clk上升沿触发的，然而grt值发生变化的时刻是在clk上升沿叠加偏移量的时间点。关于这一点，可以从输出结果以及驱动时序波形图中得到印证。
 

（在interface中，可以定义多个ckocking，同一个变量在不同clocking中可以声明不同方向）

• 为了避免可能的采样竞争问题，verifier应该在验证环境的驱动环节就添加固定延迟，使得在仿真波形中更容易体现出时钟与被驱动信号之间的时序前后关系，同时这样也便于DUT的准确处理和TB的准确采样。
• 如果TB在采样从DUT送出的数据，在时钟与被驱动信号之间存在delta-cycle时，应该考虑在时钟采样沿的更早时间段去模拟建立时间要求采样，这种方法也可以避免由于delta-cycle问题带来的采样竞争问题。
• 当我们把clocking运用到interface中，用来声明各个接口与时钟的采样和驱动关系后，可以大大提高数据驱动和采样的准确性，从根本上消除采样竞争的可能性。