《UVM实战》24小时问答

doogo

之前读过张强的《UVM1.1实践与源代码分析》电子版，受益颇深。现在看到这本书正式出版真是可喜可贺！
在此 ...
estshooter 发表于 2014-9-19 15:39

                               
登录/注册后可看大图

1. 对于这种情况，在新书的10.3.3节有一个类似的例子。唯一的解决办法是保证get到key的sequence会释放这个key。我不清楚你那边为什么会没有释放key，我猜应该是类似disable fork之类的把这个进程干掉了。如果是这样，那么在干掉这个进程前，请等待key被释放。2. 虽然你描述的比较完整，但是不太清楚具体的细节。建议：
  （1）是否可以不使用sequence来实现slave agent的功能？解决问题的方式有很多种，sequence有时并不是唯一的选择。我们的目标是使用最方便最灵活的方式。我在新书中在这个上面阐述了不少。
  （2）如果一定要使用sequence，那么“但如果driver已经采集到命令信息再通过sequencer传给sequence的话，这个时候命令phase已经结束了”这句话估计是你的slave drive写的稍微有点问题。从理论上来说，如果slave driver得到命令再马上传回给sequencer的话，sequence做出响应，把transaction传递回driver，这个过程是完全不需要消耗时间（$time打出来的时间）的。因此，命令phase并没有结束。你可以修改你的slave drive来实现这一点。
3.  你可以这样做，如果依然不能解决问题的话，那么可以多例化几个RAL好了。一个master对应一个RAL，一个RAL里面只需要一个map就可以了，当然了，这种解决方式并不是那么优雅。

doogo

之前读过张强的《UVM1.1实践与源代码分析》电子版，受益颇深。现在看到这本书正式出版真是可喜可贺！
在此 ...
estshooter 发表于 2014-9-19 15:39

                               
登录/注册后可看大图

1. 对于这种情况，在新书的10.3.3节有一个类似的例子。唯一的解决办法是保证get到key的sequence会释放这个key。我不清楚你那边为什么会没有释放key，我猜应该是类似disable fork之类的把这个进程干掉了。如果是这样，那么在干掉这个进程前，请等待key被释放。2. 虽然你描述的比较完整，但是不太清楚具体的细节。建议：
  （1）是否可以不使用sequence来实现slave agent的功能？解决问题的方式有很多种，sequence有时并不是唯一的选择。我们的目标是使用最方便最灵活的方式。我在新书中在这个上面阐述了不少。
  （2）如果一定要使用sequence，那么“但如果driver已经采集到命令信息再通过sequencer传给sequence的话，这个时候命令phase已经结束了”这句话估计是你的slave drive写的稍微有点问题。从理论上来说，如果slave driver得到命令再马上传回给sequencer的话，sequence做出响应，把transaction传递回driver，这个过程是完全不需要消耗时间（$time打出来的时间）的。因此，命令phase并没有结束。你可以修改你的slave drive来实现这一点。
3.  你可以这样做，如果依然不能解决问题的话，那么可以多例化几个RAL好了。一个master对应一个RAL，一个RAL里面只需要一个map就可以了，当然了，这种解决方式并不是那么优雅。

estshooter

回复 52# doogo


    感谢及时回复。关于问题1和问题2我之前描述的可能不够清楚，在这里补充一下：
1.先get到key的sequence没有释放key是因为它发出的读写某个寄存器操作被优先级更高的中断sequence里面的grab操作锁住了，所以还没有完成，也就无法释放key。而此时运行到中断sequence里面读写与上述相同的寄存器时，就get不到key了。所以发生了死锁。看cadence关于UVM的示例中中断sequence都是采用grab的方式来控制程序跳转的，不知是否还有其他方法？
2.（1）之所以要采用sequence来实现是为了实现中央集权控制（整个激励的产生都是通过顶层的virtual sequence来统一控制调度）的验证环境，当然如果有更好的集中控制方式，也可以对现有方式进行改进；
（2）之所以说“如果driver已经采集到命令信息再通过sequencer传给sequence的话，这个时候命令phase已经结束了”，是因为只有driver采到有效的command ack握手信号，才能认为采到的命令信息是有效的吧？这个时候命令phase是不是可以认为已经结束了？所以我的疑惑就是类似于command ack相对于command vld的延迟cycle数这种响应信息是不是没办法通过slave sequence来控制？
3.如果例化多个RAL，应该是可以解决驱动这个问题的，但是跟实际情况似乎有些不相符：因为每个RAL是相互独立的，某个master对某个RAL的操作对其他master是不可见的，而实际上这些寄存器肯定是每个master共同访问的。另外按照你的理解，UVM可以引入多个uvm_reg_map的机制是不是就是为了适应这种多master访问的场景？

doogo

回复 53# estshooter


1. 为了避免grab的情况，那么只能在先得到key的sequence中也使用grab了，这样后面的grab会等前面的grab完了再做操作。2. 还是不明白。slave driver为什么会需要采集command ack？我的理解是master（DUT）发一个command，同时发一个command vld，slave driver回给master一个ack。
3. 多个reg_map的一种应用场景：一个DUT有两组总线接口，这个DUT做为slave。对于DUT中的一个寄存器来说，可以分别从两个接口访问，且这两个接口访问的地址不一样。

estshooter

回复 54# doogo


    非常感谢你的耐心解答！
    关于问题1，还有一点疑惑：我的初衷是中断seqence（interrupt sequence）的优先级比先get到key的sequence（normal sequence）高，所以我希望检测到中断时，能把normal sequence里当前操作执行完（现在的问题就是找不到这样一种机制），然后先执行interrupt sequence里的操作，再执行normal sequence里剩余的操作。如果在normal sequence里也加入grab的话似乎不符合我的意图。
    关于问题2，是我的理解有问题，如你所说应该可以通过修改driver的方式来解决；
    关于问题3，我理解了你的意思，这种多master访问block寄存器的最佳机制我可能还需要继续尝试和探索，如果后续有新的思路，请随时指教！

doogo

回复  doogo


    非常感谢你的耐心解答！
    关于问题1，还有一点疑惑：我的初衷是中断seqence（in ...
estshooter 发表于 2014-9-20 00:35

                               
登录/注册后可看大图

关于问题1，并不是整个sequence都要grab，而是如下的方式grab：normal_sequence
//some code
grab();
reg_model.write();
ungrab();
//other code
endsequence


即把grab的粒度降低，只在真正在读写寄存器时才grab。这样应该能够满足你的要求。

seabeam

大作拜读中，实际操作中phase跳转会遇到一些问题，而且mentor并不建议使用这一功能，这个怎么看？

iooiniu

我是初学者，看书后有3个问题想问下：
1.看书中写的 ：所有的config一般直接从uvm_object中派生， 这个“一般”用词是不是意味着我从uvm_component或者uvm_sequence_item中派生也没问题吧，只要是我自己调用得当。(之前和同事研究uvm的时候，讨论了下这个，还是不太确定)

2. 是关于blocking_get端口的，书中图4-11 控制流顺序为：B_port-->A_export--->A_imp；数据流顺序相反：在B的代码中 是直接用B_port.get(tr);我想问的就是你怎么就能确定get函数一定能get的到tr呢？万一是空状态呢？

3.还有一个也是关于port的，blocking_peek这个端口不太懂  peek本来就是阻塞的，加个blocking是什么情况啊？ 另外 blocking_get 和nonblocking_get 这个阻塞具体体现在什么地方？ get函数会在什么情况阻塞？ 阻塞的时候是不是上面第2个问题中的 get到空状态了？

问题有点多，有劳强哥费时间了。。。

doogo

大作拜读中，实际操作中phase跳转会遇到一些问题，而且mentor并不建议使用这一功能，这个怎么看？
seabeam 发表于 2014-9-20 12:53

                               
登录/注册后可看大图

是的。能避免还是避免吧。

doogo

我是初学者，看书后有3个问题想问下：
1.看书中写的 ：所有的config一般直接从uvm_object中派生， 这个“一 ...
iooiniu 发表于 2014-9-20 16:50

                               
登录/注册后可看大图

   1、在OVM时代有人就使用component做config。但是因为各种各样的问题，在UVM时代这种用法后来被丢弃了。2、get是阻塞性质的，要在A中实现一个阻塞的get。如果为空，就一直等待。
3、(1)peek跟get类似，是阻塞的。从理论上来说，它跟get的区别是。如果从一个fifo或者queue中，peek过后，原来的数据一直在那里，但是get过后，数据就被取出了。所以最终实现的peek要符合这个规范。但是你完全可以把peek做的跟get一样，只是这样不是好的代码风格。
(2)blocking和nonblocking体现在blocking必须要实现get的任务（以get为例），而nonblocking则是can_get和try_get。get必须是阻塞的，而can_get和try_get都是非阻塞的，所以从而有blocking和Nonblocking。
(3)get任务最终是你自己实现的，即4.2.7节中A的get任务，如果这个任务你实现成非阻塞的，也没有人管你。从理论上来说，get必须是非阻塞的。你如果实现了非阻塞的get，虽然语法上没错误，但是一段代码的正确性并不只是由语法来保证的。