验证环境发生卡死（stuck),如何调试

这两者都能帮助driver与rtl或者说interface进行同步，但是又有不同，cb（clocking block）仅会由上沿触发（或者说根据这个clocking block的敏感列表），而clk的双沿均会触发，错误地使用它们会使激励的发送节奏过快/过慢，导致循环不能正确结束，卡住整个用例的进程。简单来说就是在driver中发送激励时，使用了固定次数的循环，其中需要添加时钟保证发送的激励和rtl的时钟可以对上。如果使用了循环，又出现了用例卡死，不妨检查一下clocking block的相关代码~

1.在定义class时，new()函数的形参一定要指定缺省值，否则UVM会报错。如： class IdValChkseq extends uvm_sequence; `uvm_object_utils(IdValChkseq) function new(string name = ""); super.new(name); ...

第一步将执行控制语句加入到fork join_any的并行块中。引用和处理为同一个内存地址时，在多个forever语句内部的数据才是一致的，能够保证数据的及时和准确处理。2、在并行执行过程中，如果控制语句的执行是有时间的，需要将控制语句和其他语句放在并行执行的控制块中，保证控制指令一经下发，能够及时接收到数据，及时响应处理；1、在设计与forever有关的task时，采用ref方式生命参数变量可以有效的保证数据的一致性；今天在进行并行设计时，出现了在并行执行的前端，数据无法接收，后半段的数据可以正常接收。

gitlab-ci报错gitlab stuck问题解决

UVM dirver挂死问题

# DFT ## 为什么要做DFT 芯片生产过程中，导致的物理缺陷。 > DFT用来测试芯片质量，看是否在生产过程中，因为物理制造过程，导致芯片损坏的问题。即不是检查芯片的功能是否正常，只检查芯片的内部连线等等，是否都正确连接到。 > 以前想的是，可以直接设计一个功能测试脚本程序，如果脚本程序运行结果正确，同样可以检查出芯片是否完好。这样做的好处是，不用再在芯片内部插入DFT，简化设计，并且减少MUX等逻辑资源。

半导体测试作为半导体设计、生产、封装、测试流程中的重要步骤，是使用特定器具，通过对待检器件(DUT，Device Under Test)的检测，区别缺陷、验证器件是否符合设计目标，分离好品与坏品的过程。半导体测试可以确保生产芯片达到要求良率，减低成本浪费，同时提供有效的测试数据，改善设计与制造。根据电子系统故障检测中的”十倍法则“：若芯片测试未发现芯片设计制造的相关故障问题，那么在电路板(PCB)级别发现故障的成本则会升至芯片级别的十倍。以此类推，成本也会以指数式增长。半导体测试基本工作机制为：

通过Sqlplus 访问数据hang死在登录界面，且不能通过Ctrl+C取消。

问题背景： 测试对平板 系统进行monkey压测时，出现了应用界面卡死的情况。 测试脚本：monkey --ignore-crashes --ignore-timeouts --kill-process-after-error --ignore-security-exceptions --throttle 200 -v -v -v -s 5 10000000 1>>/sdcard/log.log 2>>/sdcard/log_err.log 一边测试一边抓取logcat并.

【代码】解决UVM卡在driver的get_next_item问题。

在芯片验证过程中，死循环问题是一个常见的挑战。死循环，即无法靠自身的控制终止的循环，在编程和硬件设计中都可能导致严重的后果，如仿真器挂死、系统资源耗尽等。今天，我们了解一些技能，或许能够帮助深陷泥潭的我们，逃出困境。

xrun MSIE INTERNAL EXCEPTION

本章节对scan进行一个比较简要的介绍。

1.除了uvm_do 产生transaction，还可以使用uvm_create 与uvm_send 产生： 1）uvm_create 作用是例化transaction。可以做更灵活的处理。 2.可以不用uvm_create 宏，直接调用new 进行例化： 3.uvm_send_pri：