SystemVerilog调度机制与一些现象的思考

最新推荐文章于 2024-03-22 14:32:49 发布

置顶 kevindas

最新推荐文章于 2024-03-22 14:32:49 发布

阅读量1w

点赞数 59

分类专栏：芯片验证

本文链接：https://blog.csdn.net/kevindas/article/details/103449360

版权

芯片验证专栏收录该内容

37 篇文章 171 订阅

订阅专栏

文章内容主要来自于以下文档，然后对自己平时遇到的一些现象作出了思考。

1、IEEE systemverilog.std.1800-2012

2、SystemVerilog Event Regions & Race Avoidance & Guidelines

===================================悲伤的分割线===================================

零、前言

我们设计的硬件、仿真环境抽象意义上是可以并行运行的。但是在实际仿真时，不过是运行在cpu上的串行执行的程序而已（先不讨论多核）。systemverilog专门为这种并行到串行的转换定义了调度机制。但IEEE在制定规范时，并未规定一部分并行的事件执行的先后顺序，这点会引入不确定性（Nondeterminism）,这种不确定性往往会体现在不同厂家的仿真器上（因为不同的厂家采用的调度算法是不一样的），最严重的后果就是在不同仿真器上看到的最终结果是不一样的。所以作为一名合格的工程师，应该对sv仿真器的调度机制、确定性与不确定性有基础的了解。

一、event与time slot的介绍

systemverilog是为离散事件执行模型（discrete event execution）所定义的一种语言。怎么理解呢？离散指的是仿真时间（simulation time）上的离散性，仿真基于时间片（time slot）进行，只对有效的时刻点进行仿真。事件执行模型指的是仿真基于事件进行建模和整体的调度。

下面先介绍几个概念：

进程（Processes）是sv中并发调度的单元，比如：原语（Primitives）、initial过程块、always过程块、连续赋值（continuous assign）、异步任务（asynchronous tasks）、过程赋值（procedural assignment）等。进程是可以被执行的，有相应的状态标志（state，比如挂起）。进程会响应输入的变化并产生对应的输出。sv的描述的对象也正是这些进程。

更新事件（update event）：仿真中，net或者variable上每次的变化被认为是一次更新事件。

求值事件（evaluation event）：进程对更新事件敏感！当一个更新事件被执行时，所有对该更新事件敏感的进程都会被求值，但是顺序是任意的。进程的求值本身也被认为是一种事件，即求值事件（evaluation event）。更新事件和求值事件的相互交替执行，推动了仿真时间的前移。

时间片（time slot）：这个真的没啥好解释的，知道仿真是基于离散的时刻点来进行的就可以了。只有在每个时间片上的仿真活动全部完成，仿真器才会进行下一个时间片，也就是说仿真时间是不可逆的。在早期的IEEE描述里面，time slot也叫做timestep，只不过现在不这么叫了。每个时间片都会被划分成很多个区域，下面会详细介绍。划分的目的是为了保证仿真执行的正确性和清晰性。

二、systemverilog中的Events Regions

再看sv的Event Regions之前，我们先看下verilog-2001里面定义的Event Regions。

嗯，看上去还不是很复杂。总共也就定义了4个regions（Active、Inactive、NBA、Postponed），而且一般对于我们而言，Inactive域是不会用到的（后面会解释）。

Active Region：

阻塞赋值。
计算非阻塞赋值的右侧表达式（RHS即Right-Hand-Side）。并且把相应的更新事件调度至NBA Region(NBA即nonblocking assignment，非阻塞赋值）。
连续赋值。
调用$display系统函数。
primitive计算。

Inactive Region：

#0延迟下的阻塞赋值。

NBA Region：

更新非阻塞赋值的左侧表达式。

Postponed Region：

调用$monitor和$strobe系统函数。

这里有两个有趣的东西：

1、非阻塞赋值其实是分成了两个步骤，先计算RHS，再更新LHS，中间会去完成其它事件的调度和计算。而阻塞赋值两步同时执行，不存在中间插入其它事件的情况。

2、有一些工程师喜欢用#0延迟去消除对同一变量赋值所引起的竞争，但是其实按照编码规范来，你就不应该在多个always对同一个变量进行阻塞赋值，所以理论上就不应该用到#0的阻塞赋值，所以也就用不到Inavtive Region了。

我们再来看看systemverilog-2005里面定义的Event Regions。

我第一次看到内心其实也是崩溃的，卧槽，数了下，总共有17个Event Regions。但是，如果把8个PLI（Programming Language Interface，用来调用其它语言的函数的接口，比如C/C++）的Event Regions剔除，看上去也还好。

Active Region、Inactive Region、NBA Region统称为Active Region set，这是专门为RTL代码执行所设立的区域集合（set），实际上就是上面介绍的verilog代码的区域，只不过在sv中需要限定一下事件是在module中定义的，而不是program中定义的（verilog不存在program）。在sv中，相对于为RTL代码设立的区域，还有专门为验证平台所设计的区域集合，Reactive Region set。包含了Reactive Region、Re-Inactive Region、Re-NBA Region。Observed Region则是专门为断言所设计的区域。

Preponed Region：

采样数据，为断言做准备。

Observed Region：

使用Preponed Region采样到的值来计算断言。

Reactive Region：

所有定义在program内的阻塞赋值。
执行断言pass/fail代码？（这个有点疑问）
所有定义在program内的非阻塞赋值RHS的计算，并将相应的更新事件调度至Re-NBA Region。
所有program内的连续赋值。
执行系统函数$exit及隐式的$exit命令。

其实仔细看下，和Active Region内执行事件是很类似的，只不过加了program的限定。

Re-Inactive Region：

program内#0延迟的进程。

虽然Inactive Region不推荐使用，但是Re-Inactive Region还是有一些独特的价值的，比如开一些后台fork时，你希望新开的子进程优先于父进程执行。

program test;
    initial begin
        fork
            process1;
            process2;
            process3;
        join_none
        #0;
        // parent process continues
    end
endprogram

Re-NBA Region：

执行Reactive Region调度过来的LHS更新事件。

Postponed Region：

调用$monitor和$strobe系统函数。
收集利用strobe采样的功能覆盖率。

比较一下，systemverilog的Postponed Region比verilog的Postponed Region多了功能覆盖率的收集功能。

三、编码Guideline的一些解释

Guideline #1：时序逻辑使用非阻塞赋值。这样才可以保证时序逻辑的代码在NBA Region执行，sv才能正确地建模。
Guideline #3：用always块写组合逻辑使用阻塞赋值。这样可以保证代码是在Active Region执行的，仿真时行为是组合逻辑的行为。
Guideline #6：不要在多个always块中对同一个变量赋值。显然，这样做会引起冲突，导致最终结果的不确定性。
Guideline #8：在过程赋值时不要使用#0的delay。这条在上面已经解释过了。
Guideline #7：使用$strobe函数观察非阻塞赋值的结果。参考前面函数调用的位置就知道为什么了，$display函数观察到的不是我们想要的结果。但是这里我有一个疑问，假如always内非阻塞赋值有`U_DLY，观察到的结果又是怎么样的？

四、关于#1step

#1step是systemverilog引入的一种新的能力，主要为了解决采样的问题。step时间单位其实就是我们定义的最小的时间精度，换句话说，这也是仿真器在时间上进行调度的最小单位，在#1step的delay时间内，是不存在事件的。

IEEE定义了#1step延迟会在当前time slot的Preponed Region进行采样，但这样实际上的效果和在上一个time slot的Postponed Region采样是一样的（有可能两个time slot之间差了无数个#1step）。所以个人猜测，很多EDA的厂家会对这里进行优化，但最终呈现的效果是在当前time slot的Preponed Region采样的就行。

在时钟块（clocking block）里面默认的input skew就是#1step，而output skew是0。

五、平时遇到的一些问题的思考

Q1：interface中应该怎么去定义`SETUP和`HOLD时间比较好？

A1：

可以参考我的另一篇文章：systemverilog中interface时钟块的时序控制
而且Guildline也明确建议我们在clocking block里面使用#1step的input skew。

Q2：整个仿真所消耗的CPU时间和定义的`timescale有没有关系？

A2：个人观点：如果改变`timescale能够减少我们的time slot数量或者总的事件量，那么对仿真时间就是有收益的。

Q3：为什么设计写代码时不建议采用always@(*)的方式赋常值，而是建议使用assign的方式给常值？always@(*)赋常值在仿真时的行为是什么样的？

A3：参考下图，sv标准里面写了，连续赋值语句会在0时刻进行触发，以便传递常值；而always的阻塞赋值没有这个效果。

Q4：ucli中，按下ctrl-c后程序是停在了哪里？

A4：没有找到明显的答案，这里只是一些猜测。ucli交互时我们需要看到的是一个明确的结果，所以程序不应当处于设计代码的迭代的过程中，因此，可以排除是Active Regions。

Q5：systemverilog引入program块的意义？

A5：引入了Reactive Region set（Reactive、Re-Inactive、Re-NBA），将验证代码和设计代码区域区分，减少了竞争冒险。

Q6：有时候写代码时会加入#0的延迟，有什么作用吗？

A6：参考文章，设计中不要使用，验证时可以使用来对事件执行先后进行调度。

Q7：uvm的run_test()在应该在module里面例化，还是应该在program里面例化？

A7：两种例化方式都是可以的。在module中例化就相当于没有了program块，自然也就没有了program块相关的Regions，如果你的代码风格不是很诡异的话，当然是完全没有问题的。事实上cadence也是推荐我们在module中例化run_test()，而synopsys则建议我们在program块内例化run_test，利用program块来对设计代码和验证平台进行区分。曾经有人也说过program块完全是多余的垃圾，因为对于代码风格良好的设计而言，即使没有program块也是不会存在验证的竞争冒险。所以个人观点，萝卜青菜，各有所爱，你习惯用哪个就用哪个。

Q8：uvm中的函数uvm_wait_for_nba_region()有什么作用？

A8：顾名思义，这里需要等待NBA Region之前的进程被执行完。源代码有解释，如下：

===================================悲伤的分割线===================================

写在最后：

1、双11撸了一台腾讯云主机（真良心价！2C4G 3M 3年只要688），已经基于xfce+vnc装好图形界面，试了下vcs和verdi都可以正常运行。而且手机上的vnc viewer也挺好用的。开心。

2、其实搞验证搞了这么久，觉得最有用的资料还是IEEE的标准和软件的user guide，其它的知识点很多都是衍生出去的（有一种天下武功出少林的感觉），建议大家有空还是多看看。

3、TMD，周天还要让我去公司协助定位问题，真是够了，能不能给人留点私人时间啊。

kevindas

关注

59
点赞
踩
225

收藏

觉得还不错? 一键收藏
15
评论
SystemVerilog调度机制与一些现象的思考

文章内容主要来自于以下文档，然后对自己平时遇到的一些现象作出了思考。1、IEEE systemverilog.std.1800-20122、SystemVerilog Event Regions & Race Avoidance & Guidelines===================================悲伤的分割线==================...
复制链接

扫一扫