请教UVM问题，sequence切换问题

AnswerLJ

本来就只能保证获取这个信号值的过程是没有消耗仿真时间的；
对于验证平台来说，从下发激励到DUT开始 到 从DUT获得输出的过程 已经属于latency，而不再是delay了，你能控制这部分的时间吗？不能吧；
具体的场景也只有楼主知道，我仅仅是按照常规的连续发激励，且作用在相同的interface上的场景来考虑的；

AnswerLJ

1. 
   
2. task wait_signal_ready();
   
3. fork
   
4. #SYSCLK reg.read(status,addr,value,UVM_BACKDOOR);
   
5. if(value == TRUE)
   
6.     send = 1;
   
7. else
   
8.     send = 0;
   
9. join_none
   
10. endtask
    
11. task send_pkt();
    
12.     Packet1 pkt1;
    
13.     Packet2 pkt2;
    
14.     fork
    
15.         if(send) begin  
    
16.              pkt1 = new();
    
17.              assert(pkt1.randomize());
    
18.              transmit1(pkt1);
    
19.         end else begin
    
20.              pkt2 = new();
    
21.              assert(pkt2.randomize());
    
22.              transmit2(pkt2);
    
23.         end
    
24.     join_none
    
25. endtask
    
26. 
    

复制代码

这段代码的效果跟上面那段代码有什么区别？这里的backdoor读 跟 @(posedge clk)(...)有什么区别？
这里的问题压根就不在于即时把信号的状态获取出来好吗

hover99

@（posedge clk)是时间同步的，你的#sysclk不是时间同步的，最坏的情况下有1个时钟周期的delay.

lyu

不错的资料

grow

回复 8# hover99


    用@ （posedge vif.signal）呢？