电子发烧友App
AXI 总线功能建模可简化Zynq-7000 All Programmable SoC 组件及子系统的验证工作。本文以赛灵思工具链为基础，通过逐步指导实例，详细介绍了该验证方法。
赛灵思在ZynqTM-7000 All Programmable SoC 中内置了功能强大的双核ARM®Cortex ™ A9 处理器，能让用户使用单个芯片即可构建自己的高性能片上系统。这样软件工程师可以充分利用包括GNU/Linux 在内的丰富的ARM软件生态系统，而硬件设计人员则可以在可编程逻辑架构中添加协处理器和数字信号处理功能。现在的问题在于验证和调试这样的片上系统，尤其是软硬件之间的接口。例如，接口一边受器件驱动器控制，一边受中断服务程序控制。
随着ARM CPU 的问世，高级微控制器总线架构（AMBA®）以及更为重要的高级可扩展接口（AXI）已成为连接FPGA 内部各组件的事实标准。AXI 并非传统意义上的总线，而是使用交叉开关矩阵和仲裁，在多个主从机模块间实现基于事务的互联。AXI 有三种类型，分别是AXI4（ 常规类型）、AXI4-Lite和AXI4-Stream。赛灵思ISE® 14.2 版本和Vivado ™ 2012.2 版本设计工具套件配套提供v1.06a AXI 互联功能，同时可与AXI3 和AXI4 相兼容。
总线功能建模（BFM）是一种非常适用于片上系统设计的电子系统级验证方法。BFM 的价值在于能够抽象总线互联并提供高级API， 以实现用于激励RTL 模块的测试平台，从而帮助用户节省宝贵的时间。BFM 可帮助设计人员验证与Zynq-7000 器件的处理系统相连接的RTL 模块。在赛灵思ISim 这样的RTL 仿真器内部运行时，BFM 可帮助用户按照自下而上的设计流程，一次验证一个或多个模块。赛灵思与Cadence 通力合作，提供了一种在业经验证的行业标准基础上构建的验证环境（AXI BFM）。AXI BFM 已经投入市场将近两年时间，近期已升级到2.1 版本。
下面深入了解这种强大的系统级验证方法及采用这种方法所涉及的步骤。首先列出构建一个能够工作的BFM 验证环境所需的工具和组件，其中包括一个能够为使用BFM 的新手提供帮助的文档列表。然后介绍使用AXI BFM 验证RTL模块的验证流程。
工程师掌握这种方法最好的方式就是参考实例，所以最后本文将一步一步地介绍使用赛灵思ISE 设计环境的详细情况。本文选择的实例是一个由一个AXI4 主模块和一个连接BRAM 的存储控制器组成的简单设计，可作为下一个BFM 验证项目的起点。这个实例可通过下列网址，从Missing Link Electronics的开发人员专区下载： 。
使用步骤
总线功能模型（BFM）能够显著降低SoC 设计验证阶段的工作量。这种方法可帮助您直接将RTL 模块作为一个被测器件（DUT）连接到BFM，激励并核对高抽象层面上DUT 的响应，整个过程无需探究AXI 互联的细节。赛灵思和Cadence 共同推出的AXI BFM 的一大主要优势在于可以避免开发用于匹配AXI4-Lite IP 接口（IPIF）的代码，也无需手动编写RTL 模块测试台。AXI BFM紧密集成在FPGA 设计环境中。使用赛灵思Platform Studio（XPS）就可为嵌入式系统生成顶层HDL，并为BFM 仿真项目生成大部分必备文件。XPS 还可免除为DUT 正确连线的负担。您可使用“fush.sh”脚本将BFM 项目与赛灵思ISim 集成在一起，完成最终测试程序的编写。
DUT 由一个或多个构成RTL 模块的VHDL 或Verilog 文件组成。RTL 模块的AXI4 接口（ 可以是AXI4、AXI4-Stream 或AXI4 - Lite ） 通过Verilog“Testbench.v”内部的AXI BFM连接，然后与顶层设计文件“Test.v”中的测试程序合并。该测试程序用于驱动和检查DUT。这样做的好处在于可以不探究AXI4 的所有细节。用户可以使用分区在功能API 和通道API 两个抽象层面上的简便易用、丰富多样的API 编写自己的测试程序。
这种API 采用的是Verilog HDL 语言。不过很快就可以发现，这种API 不仅适合HDL 设计人员，而且也非常适用于有固件或驱动程序开发经验的软件工程师。甚至更好的是，由于AXI BFM 完全理解AXI4、AXI4-Lite 和AXI4-Stream协议，它会执行额外的检查，而且在仿真过程中，可以看到一旦RTL 模块“误解”AXI4，就会发出告警。这个过程能够在很大程度上帮助用户成长为AXI4专家。
AXI BFM 环境不局限于验证单个RTL 模块，而且能够高效地验证多个模块。因此建议使用AXI BFM 验证组件、子系统乃至整个片上系统，并且使用AXI BFM 进行回归测试。但是需要提醒一下的是，在所有复杂的验证项目中，往往出现“只见树木，不见森林”的情况，所以应该和同事共同核查（或自己核查）仿真过程中测试的功能与硬件中使用的功能是否相同。
AXI4 BFM 和XPS
AXI4 BFM 不仅可用于验证单个RTL 模块内核的总线接口，也适用于仿真整个嵌入式设计的总线事务。AXI BFM 为AXI3、AXI4、AXI3-Lite、AXI4-Lite 和AXI4-Streaming 主从模块提供模型。
根据不同类型的RTL 模块的需要，可定制不同的AXI 接口。虽然常规的AXI3 和AXI4 接口是基于突发模式，可允许使用不同的数据宽度和乱序事务处理，对只有来自软件的寄存器式访问的较简单RTL 模块，AXI3-Lite 版本足以使用。用于处理面向信息流的数据（比如来自摄像头接口的视频数据）的硬件，往往采用AXI-Stream 协议，因这种协议与常规的AXI 接口相比，更适合管理流数据的特征。不过本文介绍的实例的重点是常规AXI4 接口以及AXI4 总线的BFM 的使用。在XPS 中使用其它类型的AXI 接口测试RTL 模块的工作流程完全一样，读者可将本文的介绍当作使用这些接口进行测试的指南。
下面将展示如何在XPS 里设置
BFM，从而有效地生成HDL 代码，用于实例化DUT 和BFM，并在她们之间建立互连。这种方法可以最大限度地减轻手动编写互联HDL 代码的工作量，这种工作极为耗时。生成的测试系统由待测试的外设和提供总线激励的BFM 共同组
成。这样，使用BFM 主模块，就可以仿真系统中总线主设备一般会发起的总线传输，然后检查连接的RTL 从模块，看是否行为正确。另一方面，可以使用从BFM 验证采用AXI 主接口的RTL 模块的行为正确与否。
在本文接下来的内容中，将创建一个由一个从模块和一个AXI4 Master BFM 组成的简单系统，后者用于为从模块提供激励。
AXI4 架构简介
在开始介绍实例之前，先简单了解一下AXI4 总线架构，有关详细介绍请参阅AXI 总线规范。［2］ AXI4 总线系统分为五个独立的事务通道：写地址通道、写数据通道、写响应通道、读地址通道和读数据通道。地址通道除了传输实际的源地址或目标地址外，还传输发生在相关数据通道上的突发传输的类型信息。信息的内容包括突发的传输数量、数据的大小和突发的ID。对每一次突发，从模块都会利用经地址通道传输的ID 向主模块发送响应，通知主模块本次事务处理是否成功。
在这五条通道上， 由READY 和VALID 握手信号对来控制实际的数据传输。正如这两个信号的名称意义所示，当总线上的数据有效时，发送侧断言VALID。当接收侧做好接收数据的准备时，接收侧断言READY。实际的事务处理发生在总线时钟的上升沿，此时READY 和VALID 都处于高电平。在自行实现对AXI 总线的访问时，务必记住VALID 信号的断言不能取决于READY信号，否则会陷入死锁。
在XPS 中创建简单测试系统
现在我们已经对AXI4 总线系统有了基本的理解，可以开始在XPS 中创建简单测试系统了，并观察BFM 和AXI总线的行为。这个系统由一个AXI4Master BFM、一个Block RAM控制器、一个Block RAM 和一个用于连接所有组件的AXI 互联组成。下面是创建这个AXI BFM 实例所需的工具列表：
• 赛灵思ISE 14.2 版本或更高版本，配备XPS 14.2 版本
• 赛灵思ISim（14.2 版本）
• AXI BFM 的许可证密钥（部件号码DO-AXI-BFM）
• 赛灵思DS824，“AXI BFM2.1 版本”（替代赛灵思UG783）
• 赛灵思DS768，“LogiCORETM IP AXI 互联（1.06a 版本）”
• AXI BFM 实例项目， 网址：
和用XPS 创建任何新的嵌入式设计一样，先从创建一个新的空白项目开始，将其命名为“bfm_system”。不过这里没有使用MicroBlaze® 处理器或Zynq-7000 All Programmable SoC，而是实例化一个AXI4 Master BFM，用于在AXI4 总线上发起事务处理任务。可以在XPS 中IP 内核树的验证节点上找到AXI4 Master BFM。
下面添加一个在“Bus and Bridge”分类下的AXI4 Interconnect IP，再添加一个AXI BRAM Controller 和一个相关联的Block RAM，你可以在XPS IP 标签中“Memory and Memory Controller”分类下找到这两个IP。在XPS 的Bus视图中将这些IP 组件相互连接，让系统看上去与图2 所示的一样。
在XPS 的Ports 标签中，将AXI 互联的时钟和复位端口配置成external，将BRAM 控制器和Master BFM 的时钟端口也连接到外部时钟端口。可让AXIBRAM 控制器的“ECC_Interrupt”和“ECC_UE”端口保持未连接，因为不需要使用ECC 功能。设置时钟端口的频率为100MHz。最终系统应和图3 所示的一样。
接下来在XPS 的Addresses 标签中设置BRAM 控制器的地址范围。这样还可以确定BRAM 模块的大小。这里创建一个32K 的Block RAM，起始地址为0x00000000。
现在基本系统设置已经完成，点击工具条左边的“Generate HDL Files”就可以让XPS 生成HDL 代码。这样可以在XPS 项目文件夹中创建一个名为Simulation 的目录。如果想在XPS 中修改系统，重新生成HDL 代码，务必将手工添加到文件夹中的文件进行备份，否则XPS 在生成仿真文件时，这些文件将被完全覆盖。在Simulation 文件夹中名为 “behaviorial”的文件夹里，我们可以找到与XPS 设计名字完全相同的Verilog 或者VHDL 文件（根据配置设置中选择的语言）， 该文件名为“bfm_system.vhd”。这就是我们系统的顶层，其中包含刚刚在XPS 中实现的所有实例化组件和连接。
运行仿真
根据AXI BFM 说明书的建议，应在提供了时钟和复位信号的测试顶层模块中例化该系统，再从独立的测试模块发起AXI 总线上的事务处理任务。（这种方法的结构见图1 所示）。在总线上发起事务处理的方法是从AXI BFM API 调用对应的Verilog 任务。API 分为通道层和功能层。使用通道层API 可在不同的通道上发起传输，比如读地址和写地址通道，这样我们就能单独控制写突发或者读突发的每一个阶段。使用功能层API 可方便地启动整个数据传输，比如读突发或者写突发。另外功能层API 还提供可改变BFM 设置的Verilog 功能，比如修改ISim 控制台上的输出冗余。DS824 详细介绍了该API，并提供一个编程人员参考。
使用Verilog 的“。”运算符，通过引用BFM 实例，在测试程序中调用API的函数和任务。图4 就是这种函数调用的例子。完整的代码包含在与本文配套的项目包中，并提供shell 脚本，用于编译实例并运行ISim 查看波形。请阅读项目包中的README.txt 文件了解如何使用该脚本。运行该脚本即可打开ISim 主窗口。加载ISim 中的“axi_waveforms.wcfg”文件，仿真系统15 微秒，即可查看AXI 总线各通道上的信号。
测试程序首先对Block RAM 发起256 个32 位字符组成的写突发，然后读回数据。通过搜索上升时钟沿（在写地址通道，s_axi_awready 和s_axi_awvalid 信号同时处于高电平），我们可以看到用于描述突发流向的信息被发送给Block RAM 控制器。主机通过断言s_axi_wlast 信号为突发的最后一个字符做上标签。跟随写突发，从模块——即这里的Block RAM 控制器——会通过写响应通道（图5）发出事务处理成功的信号。
可针对读突发检查相同的结构。描述突发的信息通过读地址通道发送，实际数据通过读数据通道发送。与写突发不同，这里没有单独的读取响应通道。但从模块会对读传输中的每一个字断言读响应信号s_axi_rresp，以说明目前的读取是否成功。
当然，对这个使用现成组件的小型实例系统来说，所有的总线事务处理都是成功的。不过在开发RTL 模块时，需要判断RTL 模块是否符合AXI 标准。BFM 提供协议检查功能，用于确保连接的RTL 模块行为的正确性。例如，主机BFM 会检查连接的RTL 模块是否在复位后为输出端口应用正确的复位值。在ISim 的控制台可以检查这一行为。总线控制模块的协议检查API 还能提供更多功能。AXIBFM 产品说明书 对此也有深入介绍。
强大的工具
赛灵思和Cadence 已经为Zynq-7000 All Programmable SoC 设计人员提供了一种极为强大的片上系统验证工具——
AXI4BFM。通过在方便的功能API 之上编写测试程序，我们可以在设计之初和回归测试中验证RTL 模块。
Missing Link Electronics 采用预先验证的IP，在专家提供的应用支持下，开发针对嵌入式系统的解决方案，可将市售FPGA 器件与开源软件相结合。Missing Link Electronics 是赛灵思联盟计划的认证成员，也是Zynq-7000 系列All Programmable SoC 的早期使用合作伙伴。
工商网监
评论