0
  • 聊天消息
  • 系统消息
  • 评论与回复
登录后你可以
  • 下载海量资料
  • 学习在线课程
  • 观看技术视频
  • 写文章/发帖/加入社区
会员中心
创作中心

完善资料让更多小伙伴认识你,还能领取20积分哦,立即完善>

3天内不再提示

PWIL:不依赖对抗性的新型模拟学习

Tensorflowers 来源:TensorFlow 作者:TensorFlow 2020-10-13 10:01 次阅读
加入交流群
微信小助手二维码

扫码添加小助手

加入工程师交流群

强化学习 (Reinforcement Learning,RL) 是一种通过反复试验训练智能体 (Agent) 在复杂环境中有序决策的范式,在游戏、机器人操作和芯片设计等众多领域都取得了巨大成功。智能体的目标通常是最大化在环境中收集的总奖励 (Reward),这可以基于速度、好奇心、美学等各种参数。然而,由于 RL 奖励函数难以指定或过于稀疏,想要设计具体的 RL 奖励函数并非易事。

游戏
https://ai.googleblog.com/2019/06/introducing-google-research-football.html

这种情况下,模仿学习(Imitation Learning,IL) 方法便派上了用场,因为这种方法通过专家演示而不是精心设计的奖励函数来学习如何完成任务。然而,最前沿 (SOTA) 的 IL 方法均依赖于对抗训练,这种训练使用最小化/最大化优化过程,但在算法上不稳定并且难以部署。

在“原始 Wasserstein 模仿学习”(Primal Wasserstein Imitation Learning,PWIL) 中,我们基于 Wasserstein 距离(也称为推土机距离)的原始形式引入了一种新的 IL 方法,这种方法不依赖对抗训练。借助 MuJoCo 任务套件,我们通过有限数量的演示(甚至是单个示例)以及与环境的有限交互来模仿模拟专家,以此证明 PWIL 方法的有效性。

原始 Wasserstein 模仿学习
https://arxiv.org/pdf/2006.04678.pdf

MuJoCo 任务套件
https://gym.openai.com/envs/#mujoco

左图:使用任务的真实奖励(与速度有关)训练的算法类人机器人“专家”;右图:使用 PWIL 基于专家演示训练的智能体

对抗模仿学习

最前沿的对抗 IL 方法的运作方式与生成对抗网络 (GAN) 类似:训练生成器(策略)以最大化判别器(奖励)的混淆度,以便判别器本身被训练来区分智能体的状态-动作对和专家的状态-动作对。对抗 IL 方法可以归结为分布匹配问题,即最小化度量空间中概率分布之间距离的问题。不过,就像 GAN 一样,对抗 IL 方法也依赖于最小化/最大化优化问题,因此在训练稳定性方面面临诸多挑战。

训练稳定性方面面临诸多挑战
https://developers.google.com/machine-learning/gan/problems

模仿学习归结为分步匹配

PWIL 方法的原理是将 IL 表示为分布匹配问题(在本例中为 Wasserstein 距离)。第一步为从演示中推断出专家的状态-动作分布:即专家采取的动作与相应环境状态之间的关系的集合。接下来的目标是通过与环境的交互来最大程度地减少智能体的状态-动作分布与专家的状态-动作分布之间的距离。相比之下,PWIL 是一种非对抗方法,因此可绕过最小化/最大化优化问题,直接最小化智能体的状态-动作对分布与专家的状态-动作对分布之间的 Wasserstein 距离。

PWIL 方法

计算精确的 Wasserstein 距离会受到限制(智能体轨迹结束时才能计算出),这意味着只有在智能体与环境交互完成后才能计算奖励。为了规避这种限制,我们为距离设置了上限,可以据此定义使用 RL 优化的奖励。

结果表明,通过这种方式,我们确实可以还原专家的行为,并在 MuJoCo 模拟器的许多运动任务中最小化智能体与专家之间的 Wasserstein 距离。对抗 IL 方法使用来自神经网络的奖励函数,因此,当智能体与环境交互时,必须不断对函数进行优化和重新估计,而 PWIL 根据专家演示离线定义一个不变的奖励函数,并且它所需的超参数量远远低于基于对抗的 IL 方法。

PWIL 在类人机器人上的训练曲线:绿色表示与专家状态-动作分布的 Wasserstein 距离;蓝色表示智能体的回报(所收集奖励的总和)

类人机器人
https://gym.openai.com/envs/Humanoid-v2/

衡量真实模仿学习环境的相似度

与 ML 领域的众多挑战类似,许多 IL 方法都在合成任务上进行评估,其中通常有一种方法可以使用任务的底层奖励函数,并且可以根据性能(即预期的奖励总和)来衡量专家行为与智能体行为之间的相似度。

PWIL 过程中会创建一个指标,该指标可以针对任何 IL 方法。这种方法能将专家行为与智能体行为进行比较,而无需获得真正的任务奖励。从这个意义上讲,我们可以在真正的 IL 环境中使用 Wasserstein 距离,而不仅限于合成任务。

结论

在交互成本较高的环境(例如,真实的机器人或复杂的模拟器)中,PWIL 可以作为首选方案,不仅因为它可以还原专家的行为,还因为它所定义的奖励函数易于调整,且无需与环境交互即可定义。

这为未来的探索提供了许多机会,包括部署到实际系统、将 PWIL 扩展到只能使用演示状态(而不是状态和动作)的设置,以及最终将 PWIL 应用于基于视觉的观察。

责任编辑:lq

声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉
  • 模拟器
    +关注

    关注

    2

    文章

    992

    浏览量

    45381
  • 智能体
    +关注

    关注

    1

    文章

    387

    浏览量

    11520
  • 强化学习
    +关注

    关注

    4

    文章

    269

    浏览量

    11903

原文标题:PWIL:不依赖对抗性的新型模拟学习

文章出处:【微信号:tensorflowers,微信公众号:Tensorflowers】欢迎添加关注!文章转载请注明出处。

收藏 人收藏
加入交流群
微信小助手二维码

扫码添加小助手

加入工程师交流群

    评论

    相关推荐
    热点推荐

    储能类电池管理系统BMS HiL解决方案

    在北汇信息HiL测试环境中,可以在不依赖于真实电池组的情况下,为储能BMS提供所需的高压模拟信号、电芯电压与温度传感器信号、母线电流信号以及上层系统的通讯指令,实现储能BMS状态估算算法、充放电逻辑、热管理策略及故障诊断与保护机制的全面验证。
    的头像 发表于 11-10 14:18 1117次阅读
    储能类电池管理系统BMS HiL解决方案

    请问OTA是否一定依赖于ymodem协议?

    缺少什么步骤,通过对比发送的固件内容(日志打印)与“downloader”内容一致。 3,现在的需求是通过串口2,接收上位机发送过来的固件包更新。不依赖于ymodem等任何协议。不知这种想法是否成立。
    发表于 09-17 08:25

    太阳光模拟器 | 光辐射测量的基础知识

    光辐射测量覆盖电磁波谱全波段(紫外线UV、红外线IR、可见光),核心优势是不依赖人眼视觉,可精准量化全波段光能量,这一特性在太阳光模拟器领域尤为关键:模拟太阳辐射的准确性、光谱匹配度及辐照强度控制
    的头像 发表于 09-12 18:02 1154次阅读
    太阳光<b class='flag-5'>模拟</b>器 | 光辐射测量的基础知识

    NVMe IP高速传输却不依赖XDMA设计之九:队列管理模块(上)

    这是采用PCIe设计NVMe,并非调用XDMA方式,后者在PCIe4.0时不大方便,故团队直接采用PCIe设计,结合UVM验证加快设计速度。 队列管理模块采用队列的存储与控制分离的设计结构。
    的头像 发表于 08-04 09:53 595次阅读
    NVMe IP高速传输却<b class='flag-5'>不依赖</b>XDMA设计之九:队列管理模块(上)

    NVMe IP高速传输却不依赖XDMA设计之八:系统初始化

    采用XDMA是许多人常用xilinx库实现NVMe或其他传输的方法。但是,XDMA介绍较少,在高速存储设计时,尤其是PCIe4.0模式下,较难发挥其最优性能,因此,直接采用PCIe实现NVMe功能。
    的头像 发表于 07-26 15:14 640次阅读
    NVMe IP高速传输却<b class='flag-5'>不依赖</b>XDMA设计之八:系统初始化

    NVMe IP高速传输却不依赖XDMA设计之六:性能监测单元设计

    性能监测单元负责监测 NVMe over PCIe 逻辑加速引擎的运行状态和统计信息, 包括复位后 运行时间信息、 NVMe 指令数量统计信息、 数据操作数量统计信息、 IOPS 性能统计 信息、 指令延迟统计信息等。
    的头像 发表于 07-02 19:49 379次阅读
    NVMe IP高速传输却<b class='flag-5'>不依赖</b>XDMA设计之六:性能监测单元设计

    NVMe IP高速传输却不依赖XDMA设计之五:DMA 控制单元设计

    DMA 控制单元负责控制 DMA 传输事务, 该单元承担了 DMA 事务到 NVMe 事务的转换任务, 使用户对数据传输事务的控制更加简单快捷。 DMA 控制功能由 DMA寄存器组实现。
    的头像 发表于 07-02 19:47 1892次阅读
    NVMe IP高速传输却<b class='flag-5'>不依赖</b>XDMA设计之五:DMA 控制单元设计

    NVMe IP高速传输却不依赖XDMA设计之五:DMA 控制单元设计

    DMA 控制单元负责控制 DMA 传输事务, 该单元承担了 DMA 事务到 NVMe 事务的转换任务, 使用户对数据传输事务的控制更加简单快捷。 DMA 控制功能由 DMA寄存器组实现。DMA 寄存器组包含 DMA 操作寄存器、 DMA 长度寄存器、 DMA 源目的地址寄存器和 DMA 状态寄存器。 DMA 操作寄存器定义了 DMA 请求类型, 包括写和读操作; DMA 长度寄存器定义了 DMA 请求的数据传输长度, 该长度以 NVMe 设备逻辑块大小为单位; DMA 源地址和 DMA 目的地址寄存器定义了 DMA 请求的源数据存放的起始地址和数据传输的目的地址; DMA 状态寄存器定义了当前待运行的 DMA请求数量和 DMA 请求执行状态信息。 DMA 寄存器组定义如表 1 所示, 其中 DMA状态寄存器定义如表 2 所示。表 1 DMA 寄存器组定义 表 2 DMA状态寄存器定义想进一步了解相关视频,请搜索B站用户:专注与守望链接:https://space.bilibili.com/585132944/dynamic?spm_id_from=333.1365.list.card_title.click
    发表于 07-02 19:45

    NVMe IP高速传输却不依赖XDMA设计之四:系统控制模块

    系统控制模块负责实现 NVMe over PCI 逻辑加速引擎的控制功能, 其结构如图 1 所示。 用户通过系统控制模块实现对初始化功能、 队列管理功能、 DMA 功能等主要功能的控制, 同时逻辑加速引擎的工作状态也通过此模块反馈给用户。
    的头像 发表于 06-29 17:52 344次阅读
    NVMe IP高速传输却<b class='flag-5'>不依赖</b>XDMA设计之四:系统控制模块

    NVMe IP高速传输却不依赖XDMA设计之三:系统架构

    所设计的新系统架构中,Nvme over PCIe IP通过 PCIe 3.0x4 接口连接 NVMe固态硬盘, 并提供 AXI4-Lite 接口用于系统控制, 以及 AXI4 接口用于数据传输。 在该IP内部, 根据功能划分为系统控制模块、 初始化模块、 NVMe 控制模块、 PCIe 加速模块、 PCIE 集成块。
    的头像 发表于 06-29 17:46 887次阅读
    NVMe IP高速传输却<b class='flag-5'>不依赖</b>XDMA设计之三:系统架构

    NVMe IP高速传输却不依赖便利的XDMA设计之三:系统架构

    结合目前应用需求,以及前面基础分析,确定IP应具有如下特色: (1) 通用性 前端数据采集系统基于 FPGA 开发。 一方面, 设备类型多, 使用的 FPGA型号各不相同, 需要实现的设计能够在多种类型 FPGA 上的工作; 另一方面, 为了降部署低成本, 需要实现脱离 CPU 的存储控制。 综合考虑以上两方面因素,设计应采用纯逻辑电路的方式实现。 (2) 高性能 前端采集的数据存在连续数据、 零散数据等多种数据量形式。 面临大量零散数据存储请求时, 需要增加 NVMe I/O 队列的数量和深度来保证数据传输性能; 而面临大量连续数据存储请求时, 单队列足以发挥性能。 在这种情况下, 需要尽可能降低功耗,减少运行中的 I/O 队列数量。 因此, 需要实现动态的队列管理功能, 在满足高性能的同时适应不同的应用环境。 具体要求为使用 PCIe3.0 以上接口的高性能固态硬盘的顺序读写数据吞吐量不低于2GB/s, 随机写IOPS不低于500000, 随机写延迟不高于1ms。 (3) 易集成、 易操作 实现的 NVMe 主机控制逻辑和 NVMe 固态硬盘作为存储子系统, 应能够方便的集成到应用环境中, 并提供简易的操作方式实现数据的传输与存储。 因此, 设计需要采用标准化接口, 实现尽可能低的资源占用率, 并具备 DMA 数据传输功能。 基于以上需求, 本IP拟基于 FPGA 的 NVMe over PCIe(NoP) 逻辑进行设计,它具有以下特点: (1) 支持 NVMe 1.3d 协议、 支持 PCIe 3.0 协议。 (2) 基于 Xilinx PCIe Integration Block 硬核开发。 一方面, 该 PCIE 集成块具有多种版本, 并且适用平台多, 因此 NoP 逻辑加速引擎能够部署在支持 PCIE 集成块的FPGA 开发板上。 另一方面, 直接对接 PCIE 集成块的结构设计具有更高的数据传输性能。 (3) 纯逻辑电路开发。 设计基于纯逻辑电路, 不需要 CPU 的介入, 独立运行,可以节省 CPU 资源, 兼容 SoC 与纯逻辑环境。 (4) 使用 AXI 总线接口。 设计使用标准化的 AXI 总线接口提供系统控制和数据传输功能, 在保证了传输性能的同时, 更容易集成到应用环境中。 (5) 多队列并行管理与动态配置。 支持的最大 I/O 提交队列数量为 16, 支持的最大单 I/O 提交队列深度为 1024, 最大 I/O 提交队列总深度为 1024, 支持运行过程中动态的创建或删除队列。 (6) DMA 功能。 通过配置 DMA 寄存器直接请求数据传输, 数据传输通过 AXI4总线接口对接用户逻辑, 使用突发传输提高数据传输性能。 图1 Nvme逻 辑加速IP系统架构图 新系统中,Nvme逻辑加速IP通过 PCIe 3.0x4 接口连接 NVMe 固态硬盘, 并提供 AXI4-Lite 接口用于系统控制, 以及 AXI4 接口用于数据传输。 在该IP内部, 根据功能划分为系统控制模块、 初始化模块、 NVMe 控制模块、 PCIe 加速模块、 PCIE 集成块。 以下为各功能模块的定义: 系统控制模块是实现NVMe over PCIe关键组件。 NoP 逻辑加速引擎内部集成了各种功能, 包括初始化、 NVMe 队列管理以及 DMA 等多种功能, 统由系统控制模块进行管理。 为了有效管理这些功能, 系统控制模块设计了对应的功能控制单元, 并提供了 AXI4-Lite 从机接口, 使得 NoP 逻辑加速引擎能够轻松地与用户环境集成。 通过 AXI4-Lite 接口, 用户可以方便地访问各个功能控制单元, 实现对系统功能的控制。 这种设计使得用户能够直接与 NoP 逻辑加速引擎进行交互, 灵活地配置和管理系统的各项功能, 从而更好地满足特定的应用需求。 初始化模块负责控制系统的初始化流程, 其中包括 PCIe 初始化和 NVMe 初始化两个主要步骤。 在系统上电复位后, 首先由 PCIE 集成块执行物理层的链路训练和速度协商, 建立有效的 PCIe 通信链路。 随后, 由初始化模块进行 PCIe 设备的枚举与配置, 并执行 NVMe 的初始化流程。 初始化过程是确保系统能够在正确状态下运行的前提条件, 也为后续操作提供了必要的支持。 NVMe 控制模块是实现 NVMe 的命令提交和完成机制的核心模块。 首先, 该模块负责将来自系统控制模块的功能请求转换为 NVMe 命令请求, 并执行 NVMe 指令提交与完成机制。 其次, 该模块实现 NVMe 队列管理功能, 除了基本的队列存储、门铃控制、 请求仲裁、 条目解析等, 还包括了动态创建和删除队列功能。 最后, 该模块还负责实现 PRP 寻址机制, 根据指令管理和计算 PRP 偏移, 实现数据的寻址并降低 PRP 读取延迟。 PCIe 加速模块负责处理 PCIe TLP, 将 PCIe 事务与 NVMe 紧密结合。 一方面,该模块将来自初始化模块或 NVMe 控制模块的事务请求转换为 PCIe TLP 请求, 然后发送到 PCIE 集成块, 同时接收 PCIE 集成块的 TLP 响应包, 将其转换为内部事务响应发送到对应内部模块。 另一方面, 该模块负责处理来自 NVMe 存储设备的 TLP 请求, 根据请求内容将请求转发到 NVMe 控制模块或转换为 AXI4 总线事务, 同时将来自 NVMe 控制模块和 AXI4 总的响应组装为 CplD, 经由 PCIE 集成块发送给 NVMe存储设备。 PCIE 集成块实现 PCIe 的数据链路层和物理层。 PCIE 集成块是 Xilinx 提供的用于 PCIe 的高带宽、 可扩展和灵活的通用 I/O 核, 在 NoP 逻辑加速引擎中使用 PCIE集成块的 RC 模式实现 Root Complex 的数据链路层与物理层。 PCIE 集成块提供了四组 AXI stream 接口用于传递 PCIe TLP, 通过这些接口实现 TLP 与 PCIe 链路信号的相互转换, 此外还包含一组配置接口用于访问 PCIE 集成块的配置空间。 想进一步了解相关视频,请搜索B站用户:专注与守望 链接:https://space.bilibili.com/585132944/dynamic?spm_id_from=333.1365.list.card_title.click 更多博文见:https://blog.csdn.net/tiantianuser/article/details/148994728
    发表于 06-29 17:42

    NVMe IP高速传输却不依赖XDMA设计之二:PCIe读写逻辑

    应答模块的具体任务是接收来自PCIe链路上的设备的TLP请求,并响应请求。由于基于PCIe协议的NVMe数据传输只使用PCIe协议的存储器读请求TLP和存储器写请求TLP,应答模块分别针对两种TLP设置处理引擎来提高并行性和处理速度。
    的头像 发表于 06-09 17:25 608次阅读
    NVMe IP高速传输却<b class='flag-5'>不依赖</b>XDMA设计之二:PCIe读写逻辑

    GPS对时设备,不依赖互联网的&quot;独立时钟&quot;

    GPS对时设备的通用性使其适合应用于各种领域(IT、冶金、通信、电力、金融、广电、安防、交通、水利、国防、石化、、教育等)。山东唯尚电子有限公司生产的产品是标准19英寸机架式设备,高度为1U或2U。
    的头像 发表于 05-30 14:29 339次阅读
    GPS对时设备,<b class='flag-5'>不依赖</b>互联网的&quot;独立时钟&quot;

    NVMe IP高速传输却不依赖便利的XDMA设计之二

    NVMe IP放弃XDMA原因 选用XDMA做NVMe IP的关键传输模块,可以加速IP的设计,但是XDMA对于开发者来说,还是不方便,原因是它就象一个黑匣子,调试也非一番周折,尤其是后面PCIe4.0升级。因此决定直接采用PCIe设计,虽然要费一番周折,但是目前看,还是值得的,我们uvm验证也更清晰。 视频demo见B站:搜用户名: 专注与守望 或链接:https://space.bilibili.com/585132944/upload/video PCIe 写应答模块设计 应答模块的具体任务是接收来自PCIe链路上的设备的TLP请求,并响应请求。由于基于PCIe协议的NVMe数据传输只使用PCIe协议的存储器读请求TLP和存储器写请求TLP,应答模块分别针对两种TLP设置处理引擎来提高并行性和处理速度。 对于存储器写请求TLP,该类型的TLP使用Posted方式传输,即不需要返回完成报文,因此只需要接收并做处理,这一过程由写处理模块来执行,写处理模块的结构如图1所示。 图1 TLP写处理结构 当axis_cq 总线中出现数据流传输时,应答模块首先对传输的TLP报头的类型字段进行解析,如果为存储器写请求则由写处理模块进一步解析。写处理模块提取出TLP 报头的地址字段、长度字段等,然后将数据字段写入数据缓存中。提取出的地址字段用于进行地址映射,在NVMe协议中,设备端的请求写分为两种,分别是写完 成队列和写数据,因此地址映射的定向对应为队列管理模块的完成条目处理单元和数据传输AXI总线的写通道。完成条目的字段长度为128比特,因此无需进行数据缓存,跟随地址映射发送到队列管理模块。AXIMaster驱动负责将解析的字段与缓存的数据组成AXI写传输事务发送到AXI写通道,实现数据的写传输。 PCIe 读应答模块设计 对于存储器读请求TLP,使用Non-Posted方式传输,即在接收到读请求后,不仅要进行处理,还需要通过axis_cc总线返回CplD,这一过程由读处理模块执行,读处理模块的结构如图2所示。 图2 TLP读处理模块结构 当axis_cq 总线接收到存储器读请求时,数据流被转发到读处理模块。读请求TLP只包含128比特的请求报头,而axis总线位宽也是128比特,因此在短时间内可能接收到多个读请求,为了应对这种情况,读处理模块采用了带有outstanding能力和事务并行处理的结构设计,能够有效提高读请求事务处理效率和数据传输吞吐量。 首先当读请求数据流到达读处理模块时,经过解析和地址映射的两级流水后,放入响应处理单元outstanding 缓存中,响应处理单元从缓存中获取事务一一处理,将读取的数据打包成CplD,并将CplD放置到发送缓存中等待axis_cc总线的发送。根据地址的不同,读请求事务被分为三类,分别是读队列请求,读PRP请求和读数据请求,每种请求对应一个响应处理单元。 在实际应用环境中,由于队列、PRP、数据的存储往往在不同的位置,因此完成读取过程的延迟也不同,在本课题中,将队列管理与PRP都放置在了近PCIe端存储,因此读取队列与PRP的延迟远远小于读取数据的延迟。并且当大量不同的读请求交叉处理时,读处理模块的并行处理结构更能够充分利用PCIe的乱序传输能力来提高 吞吐量。为了清晰的说明读处理模块对吞吐量的提升,设置如图3所示的简单时序样例,样例中PCIeTLP的tag最大为3。 图3 TLP 读处理时序图 在对应图3中第1、2行时序的低性能处理模式下,同一时间只能处理一个读事务,并且不带有outstanding能力,此时从接收到读请求到成功响应所经历的延迟将会累积,造成axis_cq 请求总线的阻塞。在对应图中第3、4行时序的仅带有outstanding 能力的处理模式下,虽然可以连续接收多个读请求处理,但同一时间内只能处理一个事务,仍会由于较大的处理延迟导致axis总线存在较多的空闲周期,实际的数据传输效率并不高。在对应图中第5、6行时序的读处理模块处理模式下,利用多个响应处理单元的并行处理能力和发送缓存,先行处理完成的CplD可以优先发送,紧接着可以处理下一事务,使总线的传输效率和吞吐量明显提高。
    发表于 05-25 10:20

    NVMe IP高速传输却不依赖便利的XDMA设计之一

    NVMe IP放弃XDMA原因 选用XDMA做NVMe IP的关键传输模块,可以加速IP的设计,但是XDMA对于开发者来说,还是不方便,原因是它就象一个黑匣子,调试也非一番周折,尤其是后面PCIe4.0升级。因此决定直接采用PCIe设计,虽然要费一番周折,但是目前看,还是值得的,uvm验证也更清晰。 PCIe 加速模块设计 PCIe 加速模块负责处理PCIe事务层,并将其与NVMe功能和AXI接口直接绑定。如图1所示,PCIe加速模块按照请求发起方分为请求模块和应答模块。请求模块负责将内部请求事务转换为配置管理接口信号或axis请求方请求接口信号(axis_rq),以及解析 axis 请求方完成接口信号(axis_rc);应答模块负责接收axis完成方请求接口信号(axis_cq),将请求内容转换为AXI4接口信号或其它内部信号做进一步处理,同时将应答事务通过axis完成方完成接口axis_cc)发送给PCIE集成块.图1PCIe加速模块结构和连接关系图PCIe 加速模块不仅承担了TLP与其它接口信号的转换功能,也是降低传输延迟增加吞吐量的核心部件。接下来分别对请求模块和应答模块的结构设计进行具体分析。 PCIe 请求模块设计 请求模块的具体任务是将系统的请求转换成为axis接口形式的TLP或配置管理接口信号。这些请求主要包含初始化配置请求和门铃写请求。初始化配置请求由初始化模块发起,当配置请求的总线号为0时,请求通过Cfg_mgmt接口发送给PCIE集成块;当配置请求的总线号不为0时,请求以PCIe配置请求TLP的格式从axis_rq接口发送到PCIE集成块,然后由硬核驱动数据链路层和物理层通过PCIe接口发送给下游设备,下游设备的反馈通过axis_rc接口以Cpl或CplD的形式传回。门铃写请求由NVMe控制模块发起,请求以PCIe存储器写请求TLP的格式从axis_rq接口交由PCIE集成块发送。由于发起请求的模块存在多个,并且在时间顺序上初始化模块先占用请求,NVMe控制模块后占用请求,不会出现请求的竞争,因此设置一条内部请求总线用于发起请求和接收响应,该请求总线也作为请求模块的上游接口。请求模块的请求总线接口说明如表1所示。无论是配置请求还是门铃写请求,请求的数据长度都只有一个双字,因此设置读写数据位宽均为32比特。表1请求总线接口在接收到请求总线接口的请求事务后,当请求类型的值为0时,表示通过PCIE集成块的配置管理接口发送请求,由于请求接口的接口和时序与配置管理接口基本一致,因此此时直接将请求接口信号驱动到配置管理接口完成请求的发送,请求读数据和响应也通过选通器连接到配置管理接口。当请求类型值不为0时,则需要将请求转换为TLP以axis接口形式发送,这一过程通过请求状态机实现,请求状态机的状态转移图如图2所示。 图2PCIe请求状态转移图各状态说明如下:IDLE:空闲状态,复位后的初始状态。当请求写有效或请求读有效,且请求类型值不为0时,如果请求写有效跳转到WR_HEAD状态,如果请求读有效或读写同时有效跳转到RD_HEAD状态,否则保持IDLE状态。实际的上层设计中读写请求不会同时发生,这里的状态跳转条件增加了读优先设计,从而避免异常情况的出现。WR_HEAD:请求写TLP头发送状态。该状态下根据请求类型、请求地址组装写请求的TLP报文头部,并将报文头部通过axis_rq接口发送。当axis_rq接口握手时跳转到WR_DATA状态。WR_DATA:请求写TLP数据发送状态。该状态下将请求写的数据通过axis_rq接口发送,当axis_rq接口握手时跳转到DONE状态。RD_HEAD:请求读TLP头发送状态。该状态下组装读请求TLP报头通过axis_rq接口发送,当接口握手时跳转到RD_DATA状态。RD_DATA:请求读CplD接收状态。该状态下监测axis_rc接口信号,当出现数据传输有效时,启动握手并接受数据,然后跳转到DONE状态。DONE:请求完成状态。该状态下使能req_ack请求响应信号,如果是读请求同时将RD_DATA状态下接收的数据发送到req_rdata请求读数据接口。一个时钟周期后回到IDLE状态。
    发表于 05-24 17:09