分享记录一下工作中遇到的相关知识

有时我们需要通过或者testname来区分跑的场景，从而控制某些配置/config。

（1）表达式a ##[1:$ ] b #̲#[1:$] c表明，如果信号a为高，那么从下一个时钟周期开始信号b最终将为高，接着在下一个时钟周期开始信号c最终也会为高。intersect构造要求两个序列必须在相同时刻开始且在相同时刻结束，即：两个序列的起始点和结束点都要相同。（3）最终属性P62的含义为：从序列的开始有效点（信号a为高）到序列成功的结束点（信号c为高），一共经过2~5个时钟周期。（2）使用1[*2:5] intersect来加以约束，1[*2:5]表示1持续2~5个周期。

太大，那就少dump点呗。

1. VCS起效的时间是time 0,VC formal起效的时间是reset完成，reset完成的时候，其他信号不做特别约束的情况是，会是从x态到0或者1，这样会误引入这个信号的下降沿或者上升沿，个别不健壮的assertion写法可能会fail。

Cache很小，主存很大。如果Cache满了怎么办？——对于直接映射，我们只能放到特定位置。如果这个位置原来已经有数据了，只需要把原来的数据替换掉，所以采用直接映射方式不需要考虑替换算法到底要替换那一块的问题，因为只能放到固定的位置Cache的四种替换算法：随机算法（全相联映射）Cache块满了的话，随机选择一块替换CPU进行访存时，若未命中，则先访问对应的主存块，并把信息调入/复制到对应的Cache块中。（每访问一个主存块就一定需要把这主存块立即调入Cache）

但是目前的情况是一个芯片规模非常大，导致对整个芯片进行gate仿真不现实，这种情况下可以使用xprop，这是xprop 仿真模型的用处所在。3. xprop的功能就是提前在rtl仿真的过程中可以提前发现gate-level仿真中的一些bug。在芯片前端开发的后期，验证工程师需要进行xprop仿真验证，之前我只是简单的打开xprop的功能，去回归一些case看会不会fail并进行debug。1. xprop 仿真适用于前期的rtl仿真，对于gate-level仿真是没有任何作用的(下面的例子我会讲到)

在使用VCS进行仿真时，工程师们常常会面对一个极为重要且充满挑战的问题——X态传播行为。X态信号代表了未知或不确定的逻辑值（或者高阻Z态），可能会在设计中引入意想不到的问题，因此如何处理X态成为了芯片设计与仿真中的一个关键议题。VCS提供了仿真选项-xprop=vmerge/tmerge/xmerge来处理和扩散X态传播问题。本文将深入探讨仿真中的X态传播行为，着重于不同仿真选项对X态传播的影响，以及应对X态隐匿和扩散的一些方法。进一步查询可以明确，不加入-xprop选项时默认的仿真行为是vmerge。

举个简单例子，假设在银行的服务器上，一个进程负责处理某个用户的账户余额，如果别的进程也来修改这段的数据，那么就需要一定的机制保证这段数据不会乱掉。其中一个比较常见的算法是CAS（Compare And Set），顾名思义，就是读出某段内存地址的数据，如果跟期望值一样，那么就改写该数据，如果与期望值不一样，就认为此次操作失败。对应到处理器端的操作，最简单的机制是先读出数据，计算新的数据值，再次读出该地址数据，如果与第一次读出的值一样，就认为这段时间内没有其它访问，可以把新数据写回，完成此次操作；

但是如果缓存中的数据（可能）不唯一，就牵扯到了缓存一致性，修改它的处理器必须通知其它也拥有该拷贝的缓存控制器并得到响应，要么无效掉（invalidate）其它的拷贝，要么更新（update）其它的拷贝，这些就是高速缓存的“写无效”和“写更新”策略，忘了的同学可以看看前面讲cache的文章《必须对其它缓存的该缓存行进行无效后，获得U态后才能将该缓存行进行改写。UCE：Unique Clean Empty，该缓存行的数据只在当前缓存中，但是所有的数据都是无效的，可以不知会其它RN就对该缓存行的数据进行修改。

当Completer对request进行retry，它需要记录该笔request的来源，也需要决定和记录Protocol Credit的类型，因为后续PCrdGrand的P-Credit type要和RetryAck中的一致。对于访问Non-cacheable或Device memory的read transaction，RespSepData或CompData响应可以保证对同一端点地址范围的transaction会被任何agent随后的transaction观测到，端点的地址范围取决于具体实现；

通过node ID可以在ICN路由，RN和HN，HN和SN之间有不同的通道，每个通道有自己字段（fields），对于transaction request，data，snoop request和response来说，包含的字段不一样。也可以直接跳过HN，返回数据给原始Requester，这样可以减少读数据的延时。在基于CHI的系统中，处理器的读请求可以通过很多种来源得到数据，比如：互连中的cache（一般是last level cache），SN（存储设备）或者其它的RN-F（拥有该数据的缓存行）。

CHI协议支持的NodeID字段宽度在7~11bits之间，由具体实现决定，且一个系统中所有组件的NodeID字段宽度必须一样，至于每个组件的NodeID值也是由具体实现决定的。首先，CHI协议规定，系统中的每个节点必须有一个节点号（Node ID）。链路层，基于flit。CHI的通道，有收/发两个方向，在发送方向上，有三个通道分别是REQ，WDAT和SRSP；我们知道在AXI和ACE协议中，处理器和ICN，或者ICN与从设备之间的数据传输是通过通道（channel）完成的，同样在CHI中也有通道的概念。

目前常用的SoC互连是下图中的方式：交叉开关（crossbar），这种结构相对简单，互连部分延时小，多用于数量不多的组件互连，缺点是如果互连组件太多，这种结构的内部走线会非常多，不利于物理实现，比较常见的crossbar类型IP如ARM公司的NIC-400；二维网格（mesh），这种拓朴结构可以提供更大的带宽，而且是可以模块化，通过增加网格的行或列来增加更多的节点，ARM的CMN-600就是基于mesh的互连IP。除去自夸部分，首先我们能看出来，从CHI开始协议分层了，这是跟以往的总线协议不同的；

一致性总线接口（CHI）是AXI一致性扩展（ACE）协议的演进。它是Arm的AMBA总线的一部分。AMBA是一种免费可用、全球采用的开放标准，用于SoC中功能模块的连接和管理。它有助于一次性正确开发具有大量控制器和外设的多处理器设计。CHI适用于需要一致性的各种应用，包括移动、网络、汽车和数据中心。AMBA CHI旨在维护组件数量和流量不断增长的系统中的性能。CHI旨在实现可扩展性，用于构建小型、中型或大型系统。

我们在开发环境或者debug环境的时候，经常需要在不同的路径下的不同file中切换，一种可行的方法是开多个vim窗口，并排放着，需要开哪个的时候点哪个，但是打开的file很多的时候就不太方便了，这里推荐一个vim 插件：MiniBufExplorer。下载安装方法比较简单，有很多教程，我就不介绍了，使用方法也有人提到，但是不够清晰明了，这里梳理一下，以备所需。

断言作为声明被执行的验证函数的断言语句出现。

到处到文本中后，我们就可以利用gvim相关命令简单处理成方便对比的形式，比如文本排序sort等。1.数据只在跳变的时候写出。

【代码】[UVM] 寄存器模型相关method详解。

我们在看别人的代码的时候，一定看到过有人的代码看起来非常的美观，缩进对齐这些都非常的工整，这里推荐一款自动对齐的插件，经过实测，简单方便又好用。

现在我们需要instance 4份dut(dut_0-3)，那么端口上对接的信号就会有16个req_x,req_0-3对应dut0 .req_4-7对应dut_1,以此类推，在手动连完dut_0之后，怎么快捷完成其他几个的连接呢，这里介绍宏录制的方法：（以dut_1连接为例）c.光标定位到my_req_0中的数字0上面，依次按下4和Ctrl+a(功能是执行+4，0变成4)d.移动光标到下一行的my_req_1中的数组1上面，然后按下q，结束宏录制。b.按下x,x是宏的名字，可以是其他字母。