本发明涉及先进可扩展接口(advancedextensibleinterface、axi)总线技术领域，具体涉及一种bufferable模式的验证方法。
背景技术：
bufferable模式是高级微控制器总线结构(advancedmicrocontrollerbusarchitecture，amba)axi总线协议为提升写操作的效率和性能而提出的一种解决方案，具体为：当一次写请求发生时，将awcache[3:0]的最低位设置为1，指示该次写请求为bufferable模式，则系统将允许该次写请求可在任意时刻后完成。在cache一致性系统的设计中，当发生写请求时，通过使用该方案，可提前将写response返回，通知写请求发起者该次写操作完成，可进行下一次请求的申请。
随着芯片技术的高速发展，市场上对芯片的性能与速度有了更高的需求，单个芯片上的处理核数量也在不断增加，与memory单元的交互也愈发频繁，通常情况下，写memory的过程相对缓慢，所以越来越多的设计者选择在系统中使用bufferable模式来写memory，提高写操作的效率；该方法确实能提高整个芯片的性能，但却给验证平台的在数据的校验上带来了困难。
传统的验证平台中，当写操作返回通道获得相应的response时，即认为该次写操作完成，之后验证平台进行数据对比或发起其他类型的操作。而实际上，该次写操作并未真实得到完成，数据被暂存在总线的buffer中，若此时进行memory数据对比，则会出现使用写通道的新数据和memory中的旧数据进行对比的情况；更有甚者，若一致性系统设计中包含了多个master的写通道，且bufferable与non-bufferable同时被使用时，在未经处理的情况下，验证平台无法进行正常的数据对比工作。
技术实现要素：
本发明旨在至少解决上述技术问题之一。
为此，本发明的目的在于提出一种bufferable模式的验证方法，使得验证平台更方便进行数据对比。
为了实现上述目的，本发明的实施例公开了一种bufferable模式的验证方法，包括以下步骤：s1：将待测设计的写地址通道、写数据通道直接与验证平台相连,写响应通道通过转换模块后再与验证平台相连；s2：根据验证需求进行参数定义，并在所述验证平台启动前进行参数初始化；s3：利用时钟进行采样，保存master端写请求的信息和slave端写响应通道上的信息；s4：建立响应通道转换模块，并将所述slave端保存的信息进行整理后返回给master端；s5：master端将信息传递给记分牌中，所述记分牌以获得返回的时刻点作为数据对比的触发条件，通过地址信息和id信息进行写请求的数据对应，然后与相同地址下slave端的数据进行对比，验证数据正确性。
根据本发明实施例的bufferable模式的验证方法，通过采样slavememory写返回通道的握手信号，组合成一组新的返回信号，并将该组信号进行管理后返回给验证平台，将bufferable模式下的原返回通道用新通道进行替换，使得验证平台更方便进行数据对比。
另外，根据本发明上述实施例的bufferable模式的验证方法，还可以具有如下附加的技术特征：
进一步地，步骤s1中，与所述验证平台相连的信号包括：所述写地址通道和所述写数据通道中的所有信号，以及所述写响应通道中的bready信号。
进一步地，根据所述验证需求定义的参数包括：顺序控制参数、延时控制参数、队列中特定id值选择参数、保存slave端返回的transaction的id队列参数、保存slave端返回的transaction的bresp队列参数和保存master端发送的transaction的address队列参数。
进一步地，在步骤s4中还包括：将所述slave端保存的信息进行整理后返回给master端之后，删除所述slave端保存的transaction的id队列信息和所述slave端返回的transaction的bresp队列信息。
进一步地，根据保存slave端返回的transaction的id队列参数索引写请求发出的写数据，根据保存master端发送的transaction的address队列参数索引所述slave端中的数据，并将所述写请求发出的写数据和所述slave端中的数据进行对比，实现写操作数据对比机制。
本发明的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。
附图说明
本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：
图1是本发明一个实施例的bufferable模式的验证方法的流程图。
具体实施方式
下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能理解为对本发明的限制。
在本发明的描述中，需要理解的是，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性。
参照下面的描述和附图，将清楚本发明的实施例的这些和其他方面。在这些描述和附图中，具体公开了本发明的实施例中的一些特定实施方式，来表示实施本发明的实施例的原理的一些方式，但是应当理解，本发明的实施例的范围不受此限制。相反，本发明的实施例包括落入所附加权利要求书的精神和内涵范围内的所有变化、修改和等同物。
在介绍本发明的具体实施方式之前，先对相关技术中对bufferable模式验证存在的原理性问题进行说明。本申请的发明人通过大量研究之后，发现通过直接监视总线上master的输入和输出的方法，即使在输出端可以识别出该操作是否为bufferable模式，但是在输入端监视到的仍是没有真实完成的写response信号，所以不能解决bufferable模式的写操作数据对比机制的问题。现有技术存在的关键性问题是没有对待测系统的输入端进行相应的处理，获取真实的写操作完成时刻点，单纯靠监视器是无法实现该功能的。
以下结合附图描述本发明。
图1是本发明一个实施例的bufferable模式的验证方法的流程图。如图1所示，一种bufferable模式的验证方法，包括以下步骤：
s1：将待测设计的写地址通道、写数据通道直接与验证平台相连,写响应通道通过转换模块后再与验证平台相连。
具体地，将待测设计(designundertest，dut)的writeaddresschannel(写地址通道)和writedatachannel(写数据通道)中的所有信号均与验证平台相连，dut的writeresponsechannel(写响应通道)通过转换模块后再与验证平台相连。其中，writeresponsechannel(写响应通道)共有四个信号：bvalid，bready，bid和bresp。bready信号与验证平台相连，其余信号不需要接入验证平台中。
s2：根据验证需求进行参数定义，并在所述验证平台启动前进行参数初始化。具体参数包括：
order_bit：指示返回的response是否按顺序进行返回。
tr_id[]：保存master端发送的transaction的id队列。
tr_addr[]：保存master端发送的transaction的address队列。
tr_size[]：保存master端发送的transaction的数据宽度队列。
tr_len[]：保存master端发送的transaction的数据长度队列。
tr_type[]：保存master端发送的transaction的操作类型队列。
tr_wdata[]：保存master端发送的transaction的写数据队列。
tr_wid[]：保存master端发送的transaction的写id队列
tr_wstrb[]：保存master端发送的transaction的写数据有效位队列。
b_id[]：保存slave端返回的transaction的id队列。
b_bresp[]：保存slave端返回的transaction的bresp队列。
s3：利用时钟进行采样，保存master端写请求的信息和slave端写响应通道上的信息。
具体地，以时钟上升沿为触发条件，当awvalid和awready同时为1时，表示地址通道上的写请求被dut接收，将当前时刻点的address保存到tr_addr[]，将id保存到tr_id[]，将size保存到tr_size[]，将length保存到tr_len[]，将type保存到tr_type[]。当wvalid和wready同时为1时，将wdata保存到tr_wdata[],将wid保存到tr_wid[]，将wstrb保存到tr_wstrb[]。写地址通道中各队列元素的数量和顺序时一致的。写数据通道中，tr_wdata[]和tr_wstrb[]的数量和顺序是一致的，tr_wid[]和tr_id[]数量是一致，但tr_wid[]与tr_wdata[]的数量关系与tr_len[]有关，tr_len[]指示了该id时数据的个数。使用systemverilog为队列操作提供的函数push_back，即可实现队列保存的功能。
在slavewriteresponsechannel加入监控，以时钟上升沿为触发条件，当bvalid和bready同时为1时，表示返回通道的请求被dut接收，memory写操作完成，将当前时刻点的id保存到b_id[]队列中，将bresp保存到b_bresp[]队列中。
s4：建立responsechannelswitch(响应通道转换)模块，并将所述slave端保存的信息进行整理后返回给master端。
具体地，新建responsechannelswitch模块，该模块输出端连接验证平台的masterwriteresponsechannel，共三个信号：bvalid，bid，bresp。输入端连接slavewriteresponsechannel的监控端。
判断验证平台初始化order_bit的值，若order_bit为1，返回前不需要对队列中的顺序进行重排序，直接按队列的保存顺序，从b_bid[0]开始向验证平台的masterwriteresponsechannel端进行返回，b_bresp的输出顺序与b_bid的输出顺序保持一致；若order_bit为0，则需要将队列中保存的值进行重排序输出，实现的方法为：首先定义一个新的32bit整型参数send_id，send_id的随机范围为(0，b_id.size-1)，每一次输出b_id前，均需要对send_id进行随机，然后将b_bid[sned_id]发送给验证平台。需要注意的是，当使用重排序功能时，需保证b_id.size至少大于等于2，否则输出的结果与正常顺序相同。为保证b_id.size大于等于2，所以在随机send_id之前，需要对b_id.size进行判断，size的大小即为乱序的最大深度。在返回过程中，需同时将bvalid拉高，待与bready握手成功后，再拉低bvalid信号即可完成传输或进入下一次传输过程。在输出b_id之前加入delay_cnt，delay_cnt以时钟进行计数，随机范围可按系统需求进行设定，当满足delay_cnt值时，方可进行返回操作。如delay_cnt为20，则本次b_id将在20个周期之后才被输出到masterwriteresponsechannel端。
在本发明的一个实施例中，在步骤s4中还包括：在传输完成后，使用systemverilog为队列操作提供的函数delete，将使用过的b_id[send_id]和b_bresp[send_id]删除。
s5：master端将信息传递给记分牌中，所述记分牌以获得返回的时刻点作为数据对比的触发条件，通过地址信息和id信息进行写请求的数据对应，然后与相同地址下slave端的数据进行对比，验证数据正确性。
具体地，，验证平台获得写请求的完成信号，并被mastermonitor监测到。scoreboard(记分牌)根据获取到的b_id，找到相对应的tr_id和tr_addr，进行可以找到tr_wstrb和tr_wdata，并将tr_wdata进行有效位匹配，形成对应地址下的tr_data；然后再以tr_addr地址对应slavememory中的地址，获取相应的slave_data，将tr_data与slave_data进行对比，即可验证数据的正确性。
根据本发明实施例的bufferable模式的验证方法，不仅可以对bufferable模式的写操作进行验证，还可以验证non-bufferable模式的写操作；能够灵活的控制返回的顺序以及返回的延时，组成特定的测试场景；也能够对其在限定范围内随机，使得验证环境更贴近于真实的测试场景。由此可见，本发明同时具备可控性和随机性，验证的灵活性高。
另外，本发明实施例的bufferable模式的验证方法的其它构成以及作用对于本领域的技术人员而言都是已知的，为了减少冗余，不做赘述。
在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。
尽管已经示出和描述了本发明的实施例，本领域的普通技术人员可以理解：在不脱离本发明的原理和宗旨的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由权利要求及其等同限定。