RISC-V 原子指令的内存语义+Hypervisor Type+axi vip的事务控制+ trap 被委派后的IE清零+Create_item, start_item, finish_item not declared Issue in UVM+ACE5-LiteDVM

RISC-V 原子指令的内存语义

https://tinylab.org/riscv-atomics/
sc 指令在把 rs2 值写到 rs1 地址之前，会先判断 rs1 内存地址是否有设置保留标记，如果设置了，则把 rs2 值正常写入到 rs1 内存地址里，并把 rd 寄存器设置成 0，表示保存成功。如果 rs1 内存地址没有设置保留标记，则不保存，并把 rd 寄存器设置成 1 表示保存失败。不管成功还是失败，sc 指令都会把当前 hart 保留的所有保留标记全部清除。其中 w/d 分别对应 32 位/64 位版本。

aq 标志位会限制所有后面内存访问指令，
rl 标志位会限制所有前面内存访问指令，
而 aqrl 是前两者的效果叠加。分别使用 aq 和 rl 标志位，可以人为的划定一个范围，把这两者之间的内存访问指令框起来。

Hypervisor Type

可以本地安装并直接在物理主机上运行的Hypervisor称为Type 1 Hypervisor。Type 1 Hypervisor可以直接安装在裸机系统或物理主机上。VMware ESXi、Citrix Hypervisor和Microsoft Hyper-V是Type 1 Hypervisor的一些示例。
无法本地安装且需要操作系统才能在物理主机上运行的管理程序称为Type 2 Hypervisor。Type 2 hypervisor 不能直接安装在裸机系统或物理主机上。VMware Workstation Player、VMware Workstation Pro和VirtualBox是Type 2 hypervisor的一些示例。

axi vip的事务控制

data_before_addr：数据在写事务的地址之前开始的指示，为1表示开启

reference_event_for_addr_valid_delay：定义参考事件，指定addr_valid_delay应该从何处开始：
● first_wvalid_data_before_addr：data_before_addr需要设置为1时候生效，表示参考事件为当前事务的第一个wvalid
● prev_addr_handshake：参考事件是之前读写地址的握手
● prev_addr_valid：参考事件是之前的awvalid或arvalid

response_request_port.peek获取req_resp，修改req_resp后返回自定义的响应
● enable_interleave为1使能交织传输
● interleave_pattern
○ 为EQUAL_BLOCK，交织传输为等量的块模式，等量快模式的块长度，由equal_block_length控制
○ 为RANDOM_BLOCK，交织传输为随机的块模式；随机的块大小，由random_interleave_array控制https://blog.csdn.net/hh199203/article/details/146315331

reordering_priority，优先级配置，需要在reordering_algorithm配置为PRIORITIZED的时候有效。指示的优先级，是和read_data_reordering_depth和write_resp_reordering_depth指示的事务队列中的事务进行比较，当reordering_priority_high_value是1，那么更高的值有更高的优先级；当reordering_priority_high_value是0，那么更低的值有更高的优先级。同优先级按照队列顺序传输。

get_read_data_from_mem_to_transaction读取mem读事务信息

put_write_transaction_data_to_mem放置写事务信息到mem

trap 被委派后的IE清零

当一个 trap 被委派到 S 模式时：
● scause 寄存器 会被写入 trap 的原因；
● sepc 寄存器 会被写入触发 trap 的那条指令的虚拟地址；
● stval 寄存器 会被写入与异常相关的特定数据；
● mstatus 寄存器的 SPP 字段 会被写入 trap 发生时的当前特权级；
● mstatus 寄存器的 SPIE 字段 会被写入 trap 发生时 SIE 字段的值；
● mstatus 寄存器的 SIE 字段 会被清零。
而 mcause、mepc、mtval 寄存器 以及 mstatus 寄存器的 MPP 和 MPIE 字段 不会被写入。

Create_item, start_item, finish_item not declared Issue in UVM

`uvm_do 宏用于sequence方法内部。
我们不建议使用这些宏，而是推荐使用一致的 Sequence API start 方法，
该方法在测试中和其他sequence中的工作方式相同。
https://verificationacademy.com/forums/t/create-item-start-item-finish-item-not-declared-issue-in-uvm/38543

ACE5-LiteDVM

DVM（分布式虚拟内存，Distributed Virtual Memory）消息可以通过一次或两次事务（transaction）进行发送。若消息中包含地址信息，则采用两次事务的方式进行传递。

单阶段 DVM 消息（One-part DVM Message）

单阶段 DVM 消息包含一次请求传输（request transfer）和一次响应传输（response transfer）。
该消息由发起端的 Manager（管理器组件） 通过 AR 通道（读地址通道） 发出，
并通过 AC 通道（Snoop 地址通道） 分发给所有参与的 Manager。
各个 Manager 可在运行时通过 一致性连接信号（Coherency Connection signaling） 来选择是否接收 DVM 消息。
DVM 消息的传递流程如下：

1. 消息发起：
   发起端 Manager 组件在其 读地址通道（AR channel） 上发出 DVM 消息请求。
2. 消息分发：
   互连组件（Interconnect）通过合适的 Snoop 地址通道（AC channel），将请求分发给所有参与的组件。
3. 避免自发送：
   该请求不会被发送回发起该事务的组件自身。
4. 参与组件响应：
   每个参与的组件在收到消息后，会通过 Snoop 响应通道（CR channel） 对消息进行确认。
   对于 ACE5-LiteDVM 接口而言，这种响应不得依赖于 AR 或 AW 通道上任何事务的进度，
   即响应必须独立完成，不受其他事务阻塞。
5. 响应汇总：
   互连组件收集来自所有参与组件的确认信息，
   并通过发起端 Manager 的 读数据通道（R channel） 返回对原始 DVM 请求的响应。

双阶段（two-part）DVM 消息

包含 两个请求传输（request transfers） 和 两个响应传输（response transfers）。
在双部分 DVM 消息中，每个事务都会产生响应：
— 一个在 探测响应通道（snoop response channel） 上；
— 另一个在 读数据通道（read data channel） 上。

DVM 同步消息（Sync）

具有响应，但同时还会引发一个 DVM Complete（完成）事务，用于指示同步过程已完成。该过程如下：

1. 发起阶段：
   发起的管理器（Manager）在其 读地址通道（read address channel） 上发送 DVM Sync 消息。
2. 分发阶段：
   互连组件（interconnect component）通过相应的 探测地址通道（snoop address channel） 将 DVM Sync 分发给参与的各个管理器，但不会将该事务发送回发起的管理器。
3. 确认阶段：
   每个参与的管理器通过 探测响应通道（snoop response channel） 确认已收到 DVM Sync。
   对于 ACE5-LiteDVM 接口，该响应不能依赖于 AR（读地址）或 AW（写地址）通道上事务的前进。
4. 同步响应阶段：
   互连组件收集所有确认后，通过发起管理器的 读数据通道（read data channel） 对最初的 DVM Sync 进行响应。
5. 完成触发阶段：
   每个接收的管理器在完成所有必要操作后，必须发出 DVM Complete（参见第 D13-336 页的 DVM Complete 说明）。
   该 DVM Complete 在相同管理器的 探测地址通道 上完成与对应 DVM Sync 的握手之后，通过其 读地址通道 发出。
6. 完成响应阶段：
   互连组件可以立即通过发出 DVM Complete 的管理器的 读数据通道 对该 DVM Complete 事务作出响应。
7. 全局完成阶段：
   当互连组件已收到所有参与组件的 DVM Complete 后，它会通过发起管理器的 探测地址通道 发送一个全局 DVM Complete。
8. 最终确认阶段：
   发起的管理器通过其 探测响应通道 确认收到该 DVM Complete。
   ——整体而言，此流程确保了所有参与的管理器在同步事件中状态一致，DVM Sync 的发起与完成都能被严格确认。