企业官网建设流程全解析

几个月前，我带一个DMA控制器的验证项目，第一次sanity仿真就翻车了。DMA从SRAM搬运数据到外设，仿真结束后检查外设侧接收到的数据，发现前两个字节正确，从第三个字节开始全部错位。盯了一天波形，最后定位到罪魁祸首——Synopsys AXI VIP的wstrb配置。sequence里一个不起眼的默认赋值，让写数据选通信号在窄传输时输出了全1，DUT把无效字节也写进去了。这个经历让我意识到，wstrb虽然只是AXI写通道上的一个附属信号，但在VIP配置和验证环境搭建中，它往往是所有隐蔽问题的源头。这篇文章把我在项目里用Synopsys AXI VIP处理wstrb的实战经验整理出来，包括协议要点、配置项、常见误区和几个很值得一试的技巧，希望能让正在做AXI验证的同路人少踩几个坑。

1. wstrb为什么会成为验证盲区——协议要点与常见忽略

1.1 一比特对应一个字节通道，wstrb本质是数据掩码

AXI协议中，WSTRB[n]对应WDATA[8n+7:8n]，n从0到数据总线宽度/8-1。也就是说，每个bit控制一个字节通道。当WSTRB[n]为低时，这一拍总线上对应的那一个字节被视为无效数据，从设备不需要把它写入目标地址；当WSTRB[n]为高时，该字节才被真正接受。

用大白话说，wstrb就是写数据通道上的“数据合格证”。一个WDATA相当于8个送检样品，wstrb就是贴在每个样品上的合格标贴，标贴为0的样品，从设备直接扔掉。

这个信号的存在，让AXI总线可以在一拍内只传输部分字节。最常见的两种情况：

• 窄传输（narrow transfer）：总线宽度64位，但软件只写16位数据到某个地址，wstrb上的有效位就只出现在对应的字节位置。
• 非对齐访问（unaligned access）：传输宽度和总线宽度一致，但起始地址没有对齐到总线宽度边界，wstrb必须屏蔽掉起始地址之前的低位字节。

没有wstrb，AXI就无法支持CPU对不同宽度寄存器的访问，也无法支持DMA搬运非对齐数据包。

1.2 为什么这个信号在验证阶段最容易变成“盲区”

我见过很多刚接触AXI验证的同学，上手第一件事就是从VIP的sample sequence里抄一段代码，跑通波形就认为没问题。而sample里最常见的一个偷懒写法，就是把wstrb固定成全部为1：

constraint wstrb_c { wstrb == '1; }

这个写法在总线宽度和数据宽度一致的传输里确实没问题——全宽传输的时候，wstrb本来就该全1。问题在于，一旦后续约束中出现了窄传输（AxSIZE小于总线字节宽度），或者地址约束开始覆盖非对齐的场景，wstrb固定全1就直接违反协议，DUT的行为也会跟着错。

但为什么很多人一开始发现不了？因为全宽传输在很多应用里占了绝大多数。CPU写32位寄存器、DMA搬64位数据，wstrb全1都能正常工作。只有当你开始测8位/16位外设寄存器、测DMA的非对齐搬运、测PCIe的TLP拆包回放时，wstrb的错误才会突然暴露出来。这个时候往往已经快到项目收敛期，返工成本特别高。

1.3 握手过程中wstrb的行为约束

wstrb不是任何时刻都可以变。在AXI写数据通道中，WVALID和WREADY同时为高的那个时钟沿，WSTRB和WDATA被接收端采样。在被采样之前，wstrb必须保持稳定，不能出现一个周期一个值的情况。换句话说，wstrb与WDATA同生命周期：一旦进入握手，这一拍的数据和选通一起被锁定。

这个约束在sequence层面经常被忽略。有些人习惯在事务级模型里把wstrb写成一个每次调用都会重新计算的值，结果两个周期之间wstrb跳动，导致VIP的protocol checker报错，或者DUT采样到错误的字节选通。正确做法是：在一个写事务的每个beat中，wstrb一旦确定就不能再变；不同beat之间可以变化，比如INCR burst在跨数据总线边界时，wstrb的位模式可能循环移位。

2. Synopsys AXI VIP配置wstrb的关键项梳理

2.1 配置对象里和wstrb直接相关的参数

用Synopsys系列VIP时，通常会在testbench的build_phase里通过configuration对象来控制agent行为。wstrb相关的配置逻辑，首先要从数据总线宽度开始。

wstrb的位宽等于数据总线宽度除以8。一个64位总线的AXI接口，wstrb就是8bit；32位总线就是4bit。VIP configuration中设置data_width后，wstrb位宽也随之变化。很多sequence的transaction类里直接用data_width/8来声明wstrb，这个做法是合理的，但要注意：如果VIP版本中transaction类把wstrb定义成固定位宽（比如32bitlogic [3:0] wstrb），而你又把data_width配成了64位，就可能会出现位宽不匹配或者束缚。

另外，协议类型也会影响wstrb的语义：

在VIP配置中，还需要关注窄传输支持相关选项。有的VIP默认只允许AxSIZE等于总线宽度，叫“full-width only”模式，这种模式下wstrb永远是全1，可以理解为一个简化的总线模型。而真实场景中，AXI接口上的CPU侧、DMA侧都会出现不同size的访问，所以最好把VIP配置成支持任意AxSIZE的模式。具体参数名因VIP版本而异，在Synopsys VC AXI VIP的configuration类里通常是类似support_narrow_transfer的开关，实际项目里以文档为准。

2.2 配置注入的基本框架

下面给一个通用的配置注入示例，展示wstrb相关配置在UVM环境中的位置。

class axi_vip_cfg extends uvm_object; rand int data_width = 64; rand bit support_narrow_transfer = 1; rand bit enable_wstrb_check = 1; // 其他配置... endclass class axi_base_test extends uvm_test; axi_vip_cfg vip_cfg; function void build_phase(uvm_phase phase); super.build_phase(phase); vip_cfg = axi_vip_cfg::type_id::create("vip_cfg"); vip_cfg.data_width = 64; vip_cfg.support_narrow_transfer = 1; vip_cfg.enable_wstrb_check = 1; uvm_config_db#(axi_vip_cfg)::set(this, "env.*", "vip_cfg", vip_cfg); endfunction endclass

在真实的Synopsys VIP项目里，configuration类名和参数名会带上svt_axi_前缀，但整体套路是类似的：先创建configuration对象，再通过uvm_config_db往下传，agent里的driver、monitor、sequencer会从config_db里读取。

有一个很容易踩的细节：如果同时存在多个agent（Master/Slave），或者同一个agent被复用到多个接口，一定要确认config_db路径写对。我就犯过把master_agent的配置路径写成了slave_agent，结果master侧wstrb的行为完全没改过来，问题定位折腾了一整天。

2.3 一个可复用的wstrb计算函数

无论你是写sequence约束还是在reference model里推断wstrb，最终都需要一个根据“地址+传输宽度+数据总线宽度”计算wstrb的函数。下面这个函数在我的多个项目里复用，逻辑不算严谨到覆盖协议所有边界，但作为基础模板够用：

function logic [7:0] calc_wstrb( logic [63:0] addr, int data_bus_bytes, // 数据总线字节数，如64位总线=8 int transfer_bytes // 本次传输的字节数，由AxSIZE决定 ); logic [7:0] wstrb; int offset; offset = int'(addr % data_bus_bytes); wstrb = '0; for (int i = 0; i < transfer_bytes; i++) begin if (offset + i < data_bus_bytes) wstrb[offset + i] = 1'b1; end return wstrb; endfunction

这个函数的核心逻辑就是：计算出当前beat在数据总线上的起始字节位置（addr对总线字节数取模），然后从该位置开始，连续放置transfer_bytes个有效位。当传输跨越总线边界时（offset+i超过总线字节数），剩余的数据会在下一个beat中体现——但对于当前beat，wstrb只标记总线范围内的字节。

实际使用还要结合AXI协议中“beat地址”的概念。在一个INCR burst中，每个beat的地址等于AxADDR加上该beat相对于burst起始位置的数据量。所以wstrb的计算需要在每个beat上单独做，而不是burst开始时算一次复用到底。这一点在后面误区分析里还会展开。

3. 最容易踩的五个wstrb配置误区与复盘

在展开之前，先给一张速查表，五个误区各有各的表现和修复逻辑。下面逐一展开。

3.1 误区一：固定wstrb=全1，窄传输直接翻车

先说这个我最常遇到的坑。很多sequence模板里会有这样一行：

wstrb = '1;

如果你只在全宽传输（AxSIZE等于总线宽度）的用例里跑，确实没问题。一旦用例里出现了16位写、8位写，或者CPU通过AXI桥访问一个只支持字节使能的外设，全1的wstrb会让从设备认为这一拍所有字节都有效，于是DUT把WDATA上的无效字节也写进了目标存储。

一个真实案例：某个带SRAM控制器的SoC，CPU通过AXI总线写一个16位的外设寄存器，sequence把wstrb设为4'b1111，相当于写32位。结果寄存器的高16位被写入WDATA的高16位，而WDATA高16位的值是上一拍留下的垃圾数据，所以寄存器回读出现了不确定的随机值。问题间歇出现，非常有迷惑性。

复盘下来，根因不在DUT，而是激励模型和真实CPU行为不一致。CPU的16位访问必然产生wstrb=4'b0011或4'b1100（取决于地址），而不会全1。验证环境最重要的事情是贴近真实，这行偷懒的wstrb='1把整个总线模型变成了一个全宽总线，掩盖了DUT中真正可能出现的字节选通逻辑。

修复方式很简单：别在sequence里硬编码wstrb，而是从driver或者VIP的层次去根据AxSIZE自动生成wstrb。如果确实需要在sequence里显式控制，至少改成约束，并且约束里关联AxSIZE和地址。

3.2 误区二：scoreboard直接比较整个WDATA，忽略了wstrb屏蔽

这个坑主要出现在data checker里。很多团队的scoreboard写得很直接——从monitor抓到一笔写事务，和reference model生成的期望数据做全字比较：

if (mon_wdata !== exp_wdata) begin `uvm_error("DATA_CHECK", $sformatf("data mismatch: %h vs %h", mon_wdata, exp_wdata)); end

当wstrb不是全1时，这种比较方式会产生一堆误报。比如64位总线上，DUT执行了一次16位写操作，WDATA中只有低16位有效（wstrb=8'b00000011），高48位可能是任意值。reference model期望高48位保持不变，而monitor抓到的WDATA高48位是总线上实际存在的值——可能是驱动残留，也可能被随机化约束成了其它值。全字比较必然失败。

但为什么有的项目跑了很久都没发现？因为很多初期的用例全宽传输居多，wstrb全1时WDATA的所有字节都有效，比较自然能过。一旦加上窄传输场景，误报突然增多，大家开始怀疑reference model，白白浪费了很多时间。

正确做法：在比较之前，先把WDATA和期望数据按wstrb做字节屏蔽。可以写一个mask_data函数，把无效字节置成同一个值，再比较：

function bit [63:0] mask_data(input bit [63:0] data, input logic [7:0] wstrb); bit [63:0] masked; masked = data; for (int i = 0; i < 8; i++) begin if (!wstrb[i]) masked[i*8 +: 8] = '0; end return masked; endfunction

然后比较时使用：

if (mask_data(mon_wdata, mon_wstrb) !== mask_data(exp_wdata, exp_wstrb)) `uvm_error("DATA_CHECK", ...);

注意，期望侧的exp_wstrb也要由reference model生成，不能直接拿mon_wstrb去mask exp_wdata——那等于告诉你答案再让你核对，检查形同虚设。

3.3 误区三：wstrb约束没有关联AxSIZE和地址，随机化后违反协议

有些团队意识到了wstrb不能固定全1，于是在transaction里加了一个随机约束：

rand logic [7:0] wstrb; constraint wstrb_valid { wstrb inside {8'b00000001, 8'b00000011, 8'b00001111, 8'b11111111}; }

约束本身没问题，它限制了wstrb只能出现1、2、4、8字节有效的模式。但真正的漏洞在于：wstrb的有效位位置应该由地址决定。同样是16位有效，当地址是0x0时wstrb=00000011，当地址是0x4时wstrb=00110000，当地址是0x6时wstrb=11000000。如果约束只限定wstrb的取值集合，不关联地址，随机化出来的wstrb很可能与AxADDR矛盾——数据显示的有效字节和地址指向的字节位置不一致，DUT按照wstrb把数据写到了错误的位置。

从协议检查器的角度看，这种错误属于wstrb与AxSIZE/地址不匹配，很多VIP的checker能抓出来。但如果你在早期没启用checker，或者只是手工查看波形，很容易漏掉。

正确的约束方式，是把地址、AxSIZE和wstrb放在一个constraint block里同时随机化。但最省心的方式是用calc_wstrb函数，在post_randomize里计算：

function void post_randomize(); super.post_randomize(); wstrb = calc_wstrb(addr, data_bus_bytes, size_bytes); endfunction

这相当于由地址和尺寸推导wstrb，约束简单、结果可控，也更容易debug。相比之下，用约束求解器去推导wstrb的bit位置，在需要考虑跨总线边界时会非常复杂，验证成本高，还容易陷入求解失败。

3.4 误区四：认为burst里wstrb保持不变，第二个beat开始地址变了wstrb还在沿用

这个问题隐蔽性更强。有一个项目里，sequence产生了一个INCR burst，起始地址0x0，AxSIZE=2（4字节），总线宽度64位，burst length=4，一共16字节。sequence里在第一个beat用calc_wstrb算出wstrb=00001111（低4字节有效），后面几个beat直接复制第一个beat的wstrb。

前两个beat地址0x0和0x4，wstrb=00001111都正确。第三个beat地址变成0x8，仍然正确（因为0x8低3位是0）。第四个beat地址0xC，低3位是4，start offset=4，传输4字节，wstrb应该变成11110000（高4字节有效），但代码里还在用00001111——数据被打到了低4字节，与地址0xC处的字节选通完全不匹配。

这类场景在DUT的写入逻辑上表现为什么？如果是一个SRAM，很多SRAM会把wstrb当作byte enable，数据就会落在错误字节位置。如果是寄存器，可能看起来像“写丢失”或“写覆盖”。

不要以为INCR burst每次地址增加AxSIZE字节，刚好不会跨越总线边界。很多用例中burst length很长、AxSIZE较小，地址会不断“回绕”到新的总线对齐边界，wstrb每跨越一次总线边界就必须重新计算。

正确做法：在每个beat上重新计算wstrb。driver发送每个beat前，根据该beat的地址、AxSIZE、总线宽度重新算一遍wstrb。如果使用VIP的transaction模型，通常在driver内部完成，你只需要确保transaction里的beat地址是正确的。

3.5 误区五：VIP的协议检查没全开，wstrb违规在仿真阶段完全没暴露

前面几个误区，理论上都逃不过协议检查器的眼睛。但很多时候项目里的VIP协议检查并没有全部开启，导致wstrb违规在仿真阶段没有任何提示。

我见过一些项目的VIP配置是从早期的sample代码改来的，里面把协议检查等级设成了LOW，或者把某些具体检查项关掉了。一开始可能是为了减少仿真噪声、快速跑通用例，但后面没人记得恢复。结果就是sequence里wstrb写到天上去，VIP既不报错也不提醒，直到DUT上板后在寄存器回读时发现了功能错误，大家才开始怀疑激励的正确性。

这是教训：VIP不是“连上就有检查”。Synopsys VIP通常提供protocol checker、coverage collector等组件，需要在configuration里显式打开并设置合适的检查等级。wstrb相关的检查包括：

• wstrb与AxSIZE的一致性检查
• wstrb与地址对齐的检查
• 握手期间wstrb稳定性检查
• burst中wstrb与beat地址的匹配检查

建议在项目的VIP配置模板里明确打开这些检查项，并定期运行一个“负向用例”来验证检查器真的在工作——故意制造一个wstrb违规的sequence，确认checker会报错。这样比等到DUT功能错了再回头找原因要高效得多。

4. 让wstrb成为验证质量倍增器的四个隐藏技巧

4.1 技巧一：把无效字节随机化，逼出DUT字节选通bug

很多sequence在构造写数据时，习惯把WDATA里wstrb屏蔽掉的字节清零：

if (!wstrb[i]) wdata[i*8 +: 8] = '0;

这种做法有个隐患：它把“无效字节上的数据”固定成了0，如果DUT错误地把无效字节也写入了存储，在仿真初期可能看不出问题——因为写入的是0，回读出来也是0，和期望值没有差异。

更狠的验证方式是：让无效字节保持随机。也就是说，WDATA的每个字节，无论wstrb是否有效，都随机化。这样如果DUT在wstrb处理上有一点疏忽，比如某个条件下漏掉了wstrb的屏蔽，写进存储的就是一个随机数，scoreboard立刻就能发现mismatch。

当然，做这个技巧的前提是scoreboard和reference model已经按wstrb正确处理了有效字节比较，否则会有一大堆噪声。

在一个DMA验证项目中，我在无效字节上保留了随机值，结果真的抓到一个DUT bug：DMA在配置为16位搬运时，地址没有按2字节对齐，导致wstrb的bit位置偏移了一位，每条4字节的写数据里总有一个字节落错位置。这个bug在全0无效字节的环境里很难发现，因为落错的字节如果恰好是0，就不会造成数据差异。

4.2 技巧二：基于wstrb的scoreboard数据检查范式

前面3.2里提到了按wstrb屏蔽后再比较。这里再给一个更完整的范式，便于直接用到项目里。

Reference model这边，不只生成期望的WDATA，还要生成期望的WSTRB。Scoreboard从monitor收到写事务后，拿期望WSTRB和实际WSTRB做一致性检查，再按WSTRB屏蔽WDATA做数据检查。这一步可以发现两类问题：

• WSTRB错了，数据全不对；
• WSTRB对，但WDATA中有效字节的数据错了。

class axi_write_scoreboard extends uvm_scoreboard; `uvm_component_utils(axi_write_scoreboard) function void check_write_transaction(axi_write_transaction tr); bit [DATA_WIDTH-1:0] mon_data, exp_data; logic [WSTRB_WIDTH-1:0] mon_strb, exp_strb; mon_data = tr.wdata; mon_strb = tr.wstrb; exp_data = get_expected_wdata(tr.addr, tr.data_len, mon_strb); exp_strb = get_expected_wstrb(tr.addr, tr.data_len); if (mon_strb !== exp_strb) `uvm_error(get_full_name(), $sformatf("WSTRB mismatch: mon=%b exp=%b", mon_strb, exp_strb)); if (mask_data(mon_data, mon_strb) !== mask_data(exp_data, exp_strb)) `uvm_error(get_full_name(), $sformatf("WDATA mismatch with wstrb mask: ...")); endfunction endclass

这套范式在我的项目里用了很久，最直接的好处是：数据比对失败时，先看wstrb有没有错，再看数据哪几个字节错。排查问题的路径短了很多。

4.3 技巧三：把wstrb当“探针”，统计总线真实使用模式

wstrb除了做协议信号，还能告诉我们总线上的真实有效信息量。在monitor里统计wstrb的bit count，可以得到每个beat实际传输的有效字节数。

比如一个64位总线接口，某些时段平均wstrb只有4bit而不是8bit，说明总线虽然跑64位，但大多数事务都是32位访问。这个信息在做性能分析和功耗评估时非常有用。

更直接的做法是把wstrb的不同模式做成coverage bin，再用它去检查是否覆盖到了每种字节选通模式。一个队列接口，如果永远只出现wstrb=11111111，说明窄传输场景完全没有覆盖到；如果wstrb每次都是低位连续有效，说明非对齐到高字节通道的场景没覆盖到。

covergroup wstrb_cg with function sample(logic [WSTRB_WIDTH-1:0] wstrb, int unsigned axsize); wstrb_cp: coverpoint wstrb { bins full = {8'b11111111}; bins low16 = {8'b00000011}; bins high16 = {8'b11000000}; bins low32 = {8'b00001111}; bins high32 = {8'b11110000}; bins single_byte = {8'b00000001, 8'b00000010, 8'b00000100, 8'b00001000, 8'b00010000, 8'b00100000, 8'b01000000, 8'b10000000}; } axsize_cp: coverpoint axsize; cross wstrb_cp, axsize_cp; endgroup

这样的覆盖率数据，比简单统计“跑了多少个burst”更能反映验证是否覆盖到了DUT的字节选通逻辑。

4.4 技巧四：用路径约束构造“高难度”wstrb场景

如果你想真正考验DUT的字节选通逻辑，可以主动构造一些wstrb偏移较大的场景。一个很实用的路径约束是：把访问地址约束在总线边界附近，迫使wstrb出现在高字节通道。

以64位总线为例，这些约束都是合法的：

• 地址约束为0x...06，16位传输，wstrb=11000000，有效字节从第6字节通道开始；
• 地址约束为0x...04，32位传输，wstrb=11110000，有效字节落在高4字节通道；
• 地址约束为0x...01，8位传输，wstrb=00000010，有效字节落在第1字节通道。

这类场景能够验证DUT对高字节选通的处理是否正确，尤其是某些DUT内部逻辑只用到了低32位wstrb，高32位的wstrb被错误忽略。如果不做这种定向约束，靠纯随机很久都碰不到一次wstrb出现在高字节通道的情况，DUT在高位的字节选通逻辑就始终处于未验证状态。

构造这类场景时要注意：约束AxSIZE和地址时必须满足协议对齐要求，比如16位传输时地址低1位必须为0，32位传输时地址低2位必须为0。可以在sequence里用randomize with轻松实现，例如：

assert (req.randomize() with { addr[0] == 1'b0; // 16位对齐 addr[2:1] == 2'b11; // 让起始地址落在第6字节通道 size == 2'b001; // AxSIZE=2字节（16位） burst == AXI_INCR; });

这样一轮跑下来，wstrb高字节通道的覆盖就能补上。

5. 一次真实项目中的wstrb问题排查全记录

5.1 现象：CPU 16位写寄存器，回读时高16位被清零

那是一个带APB桥接的SoC验证环境，CPU侧走AXI总线，通过AXI-to-APB桥访问一个32位的控制寄存器。某个用例中，CPU执行了一次16位写操作，目标地址偏移0x2，写入0x1234。按照寄存器的定义，低16位（偏移0x2~0x3）应该变成0x1234，而高16位（偏移0x0~0x1）保持不变。

用例在仿真结束前回读整个32位寄存器，期望值是预设初值的高16位拼接0x1234，实际回读值却是0x00001234，高16位被清零了。

5.2 排查链路：断言拿到WSTRB证据，波形确认sequence问题

一开始大家怀疑AXI-to-APB桥的写地址译码有问题，因为高16位清零很像地址译码把高位地址也算进了写使能。但在AXI侧加了一条断言，监控CPU发起的写事务的WSTRB，结果发现CPU发出的WSTRB根本不是16位写应有的模式：

• 地址0x2上的16位写，WSTRB应该是4'b1100（32位总线，高2字节有效），但断言抓到的是4'b1111，整个32位都被选通了。

这个结果让怀疑重点立刻从DUT转向了激励。打开VIP的sequence代码，发现每个写事务在构造时都做了wstrb = 4'hF的赋值。因为整个用例里只有这一处CPU访问，所以没有任何掩盖，wstrb直接反映到了APB侧——APB桥看到32位有效，把高16位也写成了WDATA上的值，而WDATA高16位在这个用例中是0。

仿真波形上能清楚看到：地址0x2上出现了一个AxSIZE=2的16位burst，但WSTRB=1111，这个组合本身就是协议违规的。如果VIP的protocol checker开着，仿真当场就能报出来。但当时配置里的检查等级没调高，所以一直拖到功能比对阶段才暴露。

5.3 修复与事后改进

修复分两步。第一步，把这个sequence里wstrb的硬编码去掉，改成由事务的addr和size自动计算：

this.wstrb = calc_wstrb(this.addr, 4, 2); // 32位总线、16位传输

第二步，在环境的VIP配置里把协议检查等级调高，确保以后再出现wstrb与AxSIZE不一致时，仿真当场报错。

事后我在team里补了一个检查清单，专门针对AXI写事务：

• sequence里wstrb是否被硬编码？
• 如果wstrb是随机约束，有没有关联addr和AxSIZE？
• scoreboard里比较WDATA时，有没有处理wstrb屏蔽？
• VIP的协议检查项是否处于打开状态？
• 是否跑过窄传输的覆盖场景？

这个清单后来在多个项目里复用，帮助团队提前拦截了很多相似的wstrb隐患。

做AXI验证这么多年，我的体会是：wstrb这种不起眼的信号，恰恰是验证环境最需要“较真”的地方。它不像VALID/READY那样是握手主干，但它的每一个bit都在定义“哪部分数据才是真的”。很多DUT的功能bug，根源不在DUT内部逻辑，而在激励侧把wstrb写错了，或者检查侧把wstrb忽略了。最后再分享一个带新人的小技巧：如果team里有刚接触AXI验证的新同学，我会让他先跑两个case，一个是64位总线的全宽传输，wstrb全1；另一个是16位非对齐传输，wstrb只在个别字节出现。让他亲手把wstrb的波形在Verdi里找到，和地址、AxSIZE对照着看一遍。看完这两个波形，他对AXI写数据的理解会立刻上一个台阶，后面写sequence、写checker时也不会再踩wstrb的坑。

这个15分钟的小练习，比讲一堂协议课有用得多。