关于在机器人领域深入应用FPGA技术的思考.docx

关于在机器人领域深入应用FPGA技术的思考.docx

《关于在机器人领域深入应用FPGA技术的思考.docx》由会员分享，可在线阅读，更多相关《关于在机器人领域深入应用FPGA技术的思考.docx（10页珍藏版）》请在冰豆网上搜索。

关于在机器人领域深入应用FPGA技术的思考

关于在机器人领域深入应用FPGA技术的思考

0引言

1机器人控制系统的理想化设计目

2基于ROS实现反馈控制环路的性能瓶颈、基于FPGA的解决方法

2.1建立作为分析对象的简化系统架构

2.2对信号采集阶段的分析

2.2.1基于ROS的架构中典型的信号采集过程

2.2.2基于ROS的架构中信号采集过程的性能瓶颈

2.2.3基于FPGA的架构针对信号采集过程的解决方法

2.3对数据处理阶段的分析

2.3.1基于ROS的架构中典型的数据处理过程

2.3.2基于ROS的架构中数据处理过程的性能瓶颈

2.3.3基于FPGA的架构针对数据处理过程的解决方

2.4对指令执行阶段的分析

2.4.1基于ROS的架构中典型的指令执行过程

2.4.2基于ROS的架构中指令执行过程的性能瓶颈

2.4.3基于FPGA的架构针对指令执行过程的解决方法

2.5关于RTOS+ROS2

2.6小结

3基本思路及实施方法

3.1在机器人领域深入应用FPGA技术的基本思路

3.2基本思路的实施方法

4系统优化科技树--基于FPGA实现EtherCAT主站控制器之后

5建议

0引言FPGA相比于CPU、DSP，具有高速、并行、运算及引脚资源极其丰富、定时精确、功能灵活、硬件直接实现算法、操作数存取机制简单高效、开发调试手段直探硬件底层的优点。

个人认为，在机器人领域深入应用FPGA技术具有非常广阔的前景，有望成为行业技术创新的下一个突破点。

在伺服驱动器中应用FPGA是业界的常规做法，在此基础上更进一步，已经有专业的机器人技术团队在深入应用FPGA的方向做出努力，我了解到的有武汉某初创公司的研发团队（以下简称为“武汉J团队”）以及某大型国企。

武汉J团队的最新方案“新一代片上驱控一体系统”以Zynq芯片作为硬件载体，用Zynq内置的一个ARM核跑Linux+ROS作为系统的基础，改写一部分ROS功能模块以提高其实时性，用Zynq内置的另一个ARM核无操作系统执行实时性要求比较高的软件算法（例如运动控制），用Zynq内置的FPGA资源实现硬件加速、信号处理、电机控制（包括电流环控制）、I/O扩展功能，在电机侧直接摒弃了EtherCAT。

武汉J团队的技术负责人曾经就他们的上述工作做过一次公开的介绍，其内容篇幅不长，并且整体来说偏重于从系统架构设计的角度进行阐述，可能不利于读者深入理解在架构中引入FPGA的重要意义；他关于ROS局限性的阐述，更多的是提供一些经验，没有进行原理方面的分析。

本文依据笔者对机器人系统、计算机体系结构、操作系统、ROS、FPGA技术的理解，定性分析以Linux+ROS为代表的软件系统实现实时多任务目标时存在的性能短板，提出关于在机器人领域深入应用FPGA技术的一些想法。

本文内容复制自笔者几年前写的一篇技术文档。

这篇文档当时曾在小范围内传播，现在以知乎文章的形式予以公布，以期为机器人领域底层技术的更新换代略尽绵薄之力。

笔者并非机器人专业科班出身，所述内容难免存在谬误之处，欢迎业内人士批评、指正。

所述内容若侵犯他人知识产权，请留言告知，笔者将道歉、删除相关内容。

1机器人控制系统的理想化设计目标为展开分析，首先明确在已完成反馈控制算法设计的情况下机器人控制系统的理想化设计目标：

在一定的成本约束下，在统一的时标下，在尽可能短的时间周期之内，以尽可能小的周期抖动幅度，完成对传感器信号集的采样、传输、数据处理、生成控制信号集，然后，以尽可能短的延迟，在各控制信号所需的尽可能精确的时刻，将控制信号集传输到各个执行器。

2基于ROS实现反馈控制环路的性能瓶颈、基于FPGA的解决方法2.1建立作为分析对象的简化系统架构图为方便分析问题，首先将基于ROS的机器人反馈控制系统抽象为一个简化的系统架构图（图A），然后逐一分析反馈控制环中的三个阶段：

信号采集、数据处理、指令执行，指出因为软件的执行必须在操作系统的调度下时分复用CPU而导致系统存在性能瓶颈，进而设计了加入FPGA之后系统的简单架构（图B），分析后者在解决这些瓶颈问题方面所能起到的作用。

图A中，在Linux内核调度下，多个ROS节点以时分复用CPU的模式运行，通过API与传感器/执行器的驱动程序通信，进而实现与传感器/执行器进行参数、指令、数据、状态的传输。

图B在图A的基础上增加了FPGA，FPGA一侧挂在CPU的外部总线上，另一侧连接各传感器/执行器，形成驱动程序与传感器/执行器之间的中间环节。

对图A、图B的几点说明：

（1）此处着重讨论软件运行机制对机器人性能的影响，所以并未按标准的机器人系统5级架构（主机、运动控制器、伺服驱动器、电机、机械结构）进行描述，而是将其抽象为“CPU+总线+内存+外设”的简化计算机系统。

（2）图A、B中将内存挂接在外部总线上属于抽象的示意。

实际的DDRX-SDRAM模组应该连接到位于CPU或北桥芯片中的内存控制器，若应用程序/外设需对内存进行读写，就要由CPU、各级Cache控制器、内存控制器协同执行一系列复杂的软硬件操作，这些操作仅仅在外部行为上可以抽象地表述为“某软/硬件读写了由某段地址标定的一块内存空间”。

（3）如某些技术资料中提到的，在产品化的机器人系统中，纯粹的ROS节点只能实现机器人所必须的大量功能中的一部分，很多功能需要由开发者自己编写的应用程序予以实现。

这些应用程序在形式上未必与ROS节点相同，但两者同属于应用软件，两者与操作系统、内存、传感器、执行器进行数据交互的基本过程也相差不多，所以在图中、在后续分析中未予单独表述。

（4）后续分析中,除了涉及EtherCAT的数据输入/输出操作之外，假设各应用程序、外设获取CPU使用权都采用中断模式。

轮询模式存在不同的问题，但不影响对软件系统性能瓶颈的分析，从略。

（5）为简化表述，图中忽略了驱动程序经GPIO之类的接口访问传感器/执行器的模式。

以下针对信号采集、数据处理、指令执行三个阶段分析简化机器人控制系统的反馈控制流程。

2.2对信号采集阶段的分析2.2.1基于ROS的架构中典型的信号采集过程考虑图A，对于带EtherCAT从站接口模块的传感器来说，运行于Linux内核之上的、作为ROS节点之一（或独立运行）的EtherCAT主站程序定时发送过程数据帧到以太网环路（图中未示出）上，传感器经EtherCAT从站接口模块接收过程数据帧、将上一个定时周期内采集到的状态数据装载进过程数据帧，然后将其转发到以太网环路上，携带状态数据的过程数据帧环回到运行EtherCAT主站程序的设备之后，其他ROS节点就能获得环路上的这些传感器在上个定时周期内采集到的状态数据。

对于不带EtherCAT从站接口模块的传感器来说，Linux内核需要响应各传感器的中断信号（图中未画出其线路），启动对应的传感器驱动程序，驱动程序按照总线仲裁时序访问CPU外部总线上与此传感器对应的地址区，读取传感器缓冲的待上传数据（或与传感器进行握手操作、直至读到其上传的数据），写入内存中为其分配的地址空间，通过各自的API告知对应的ROS节点：

有传感器数据需要读取。

2.2.2基于ROS的架构中信号采集过程的性能瓶颈采集带EtherCAT从站接口模块的传感器获得的数据时，作为ROS节点之一（或独立运行）的EtherCAT主站程序必须实时运行，任何比较大的帧发送延迟抖动都有可能导致信号采集不及时，进而影响反馈控制算法的执行。

例如，在CPU运算、控制负荷比较大（例如算法更复杂、轴数更多）的情况下，有可能因为数据处理不及时而迫使帧发送时刻延后。

采集不带EtherCAT从站接口模块的传感器获得的数据时，在传感器数量比较多、采样频率比较高的情况下，Linux内核频繁响应传感器的中断信号，把大量CPU工作时间耗费在频繁保存-恢复现场、执行传感器驱动程序上，影响承载核心业务的各ROS节点（包括EtherCAT主站程序）的执行。

当然，可以用DMA模式（或者为传感器单独设置CPU小系统，其实质就是DMA控制器）以防止主CPU被频繁的外部中断打扰，但是，大多数情况下不可能为每个传感器都配备一个DMA控制器，而且，一旦DMA控制器或CPU小系统的数量多了，它们就会替代传感器的位置，导致同样的问题。

事实上，ROS1不支持RTOS，非实时Linux执行（以及开始执行）EtherCAT主站程序、传感器驱动程序的时间（时刻）很难实现固定，导致ROS节点从EtherCAT主站程序、API处获知有传感器数据待读的时刻也很难实现固定。

ROS2+RTOS的问题后述。

2.2.3基于FPGA的架构针对信号采集过程的解决方法考虑图B，对于采集带EtherCAT从站接口模块的传感器获得的数据，由FPGA实现EtherCAT主站功能，以确保其发送、接收过程数据帧的实时性--事实上，我并不认为这样做是最合适的，我更倾向于武汉J团队的方案：

在实时反馈控制环路中摒弃EtherCAT，将所有传感器的对外接口都简单化，用本小节后述的方式完成信号采集。

在FPGA中，为每个传感器都提供一块独立的硬件电路作为它们的上位机，形成一个“DMA控制器集群”，其中的各成员并行运行；利用FPGA片内硬件资源设计控制电路，对集群中的各成员实现高效的协同管理。

FPGA中的各“DMA控制器”独立响应所负责传感器的中断请求，独立按照各传感器需要的个性化交互模式建立数据通道、读取其数据接口（或读取其数据缓冲区），把读出的上传数据缓存在片内RAM块中，按照系统分配下来的CPU外部总线连续地址段对缓存的数据统一编址，视系统需求提供数据更新标记、时间戳。

FPGA根据预设的规则对传感器上传的中断信号进行合并、统一向Linux内核发出中断信号，启动传感器驱动程序读取相应的地址空间；或者，由1个挂在CPU外部总线上的DMA控制器统一读取。

此时，软件系统中用于传感器驱动程序由于不再需要直接面对传感器硬件信号，因而可以被大幅度简化，并且不必为了与传感器建立数据通道而无谓等待，从而减少了执行驱动程序所占用的CPU工作时间、降低了这一段CPU工作时间长度的不确定程度，进而降低了ROS节点获得传感器数据的时刻的不确定程度。

2.3对数据处理阶段的分析2.3.1基于ROS的架构中典型的数据处理过程考虑图A，在Linux内核的调度下，ROS节点在属于自己的CPU工作时段读取与它所涉及传感器、关联ROS节点对应的内存空间，获取涉及自身状态、操作对象、协作对象、外部环境的数据，执行反馈控制算法，生成待执行的指令、节点间交互信息，写入内存中为其输出指令、输出信息分配的地址空间，通过API告知执行器驱动程序：

有指令、传输信息需要读取。

不具备ROS节点特征的应用程序，在上述机制涉及的层面上，其行为特征与ROS节点类似。

2.3.2基于ROS的架构中数据处理过程的性能瓶颈从宏观上看，机器人作为强实时反馈控制系统，应该采用RTOS，否则对软件编写的质量要求会很高。

但是，ROS1不支持RTOS，实时性不好。

在使用非实时操作系统的情况下，即使针对有实时性需求的功能自己开发了相应的程序模块，或者，对涉及的ROS节点程序进行了实时性优化，各ROS节点、应用程序的执行仍然必须时分复用CPU（非规整化的应用程序在多核CPU上的显式并行编程是非常非常复杂的）、彼此竞争，而操作系统内核运行过程的不可控性、各级软件执行时间的不确定性又将加剧数据处理周期的不确定性，最终导致生成下发指令、交互信息的时刻不确定，以及执行器的动作效果（尤其是协同动作效果）不确定。

从微观上看，不论是冯诺依曼体系结构还是哈佛体系结构，反馈控制算法的每一个运算步骤都要遵循指令/数据寻址、取指令/数据、执行指令、写执行结果的流程，其间还必须经过极其复杂的Cache更新决策、多级存储器映射、流水线调度等一系列底层软-硬件操作，由此导致大量时间被消耗在底层指令/数据的定位、存取、传输、更新的过程中；并且，其间产生的延迟，还必将因为各种不可预知的复杂情况（例如Cache是否命中，据说有的RTOS不惜为此关掉了Cache）及其叠加而变得难以预测。

2.3.3基于FPGA的架构针对数据处理过程的解决方法考虑图B，利用FPGA高速、并行、运算资源极其丰富、定时精确、功能灵活、硬件直接实现算法、操作数存取模式简单高效的特征，运用图B中FPGA内的硬件资源，并行执行一部分在图A中由CPU执行的、不很复杂的、运算量大的ROS节点算法（或一部分ROS节点算法中的某些步骤），利用片内硬件资源设计控制电路，对各算法模块的运行、彼此之间的数据交互进行高效的协同管理，形成一个协处理器。

例如，个人比较看好的是精密机械臂的灵敏控制算法，原因在于其对运算的实时性有较高的需求。

实际应用中对轨迹/位姿复杂性、反力多变性、运动敏捷性、动作平顺性的要求越高，设计时考虑的现场干扰因素越多，对控制算法的复杂度的需求就会越高，对核心芯片执行算法的实时性、并行性、协同性的需求就会越高。

如果能从其反馈控制算法中切分出较多适合FPGA执行的部分（主要标准是：

运算量大、并行性及协同性要求高，算法可以有一定的复杂度-- 由于多数早期的FPGA工程师是硬件出身，硬件思维比较多，以及，他们最初入手的可编程逻辑芯片是CPLD、简单FPGA，芯片对复杂算法的支持度很低，这些因素导致很多人误认为FPGA只适合执行非常简单的算法，这已经是非常过时的观念了），必将显著缩短整个系统的反馈控制时间、显著提高反馈控制时间的可预测性。

另外，FPGA在执行图像处理算法方面比CPU、DSP（作为基于Linux+ROS系统中的协处理器，下述的GPU同义）强得多，是最优方案；在执行人工智能算法（从硬件底层实现已经训练好的人工智能网络）时，FPGA是与GPU并列的主流方案，而且在功耗方面具备非常大的优势。

进而，FPGA在这两方面的性能，又会因为其具备实质上的SOC（SystemOnChip，非特指FPGA内置CPU核的“类ZYNQ”架构）属性，能够和其他算法功能模块、存储功能模块、I/O功能模块实现基于芯片内通信的高效协同（多通道、大数据量、低延迟量、低延迟抖动量），从而在系统整体性能上相比于以CPU+DSP/GPU为基础的Linux+ROS体系结构获得了更为显著的加成。

2.4对指令执行阶段的分析2.4.1基于ROS的架构中典型的指令执行过程考虑图A，对于驱动带EtherCAT从站接口模块的执行器来说，运行于Linux内核之上的、作为ROS节点之一（或独立运行）的EtherCAT主站程序定时发送携带着各执行器所需指令数据的过程数据帧到以太网环路（图中未示出）上，带EtherCAT从站接口模块的执行器接收过程数据帧、从中解析出属于自己的指令数据，然后将过程数据帧转发到以太网环路上，执行器执行收到的指令。

对于驱动不带EtherCAT从站接口模块的执行器来说，在Linux内核的调度下，执行器驱动程序获知下传指令的需求，在属于自己的CPU时段内，按照总线仲裁时序访问系统总线上与自己对应的地址区，读取属于自己的内存空间以获取待下传的指令、数据，将其写入执行器的指令缓冲区，或者，以DMA方式直接访问系统总线上属于自己的地址区段、直接对其进行读取操作。

2.4.2基于ROS的架构中指令执行过程的性能瓶颈对于驱动带EtherCAT从站接口模块的执行器来说，作为ROS节点之一（或独立运行）的EtherCAT主站程序必须实时运行，任何比较大的帧发送延迟抖动都有可能导致指令数据发送不及时，从而影响执行器的动作效果（尤其是协同动作效果）。

例如，在CPU运算、控制负荷比较大（例如算法更复杂、各协作运行的机械臂的总轴数更多）的情况下，有可能因为数据处理不及时而迫使帧发送时刻延后。

对于驱动不带EtherCAT从站接口模块的执行器来说，当执行器数量比较多、动作频率比较高的时候，Linux内核就必须把大量CPU工作时间耗费在执行传感器驱动程序上，影响承载核心业务的各ROS节点的执行。

同时，由于各执行器的驱动程序只能一个接一个地顺序执行（多核、多线程系统的任务并行程度本质上是比较低的），导致各驱动器的动作协同性是难以保证的。

事实上，ROS1不支持RTOS，非实时Linux执行（以及开始执行）EtherCAT主站程序、执行器驱动程序的时间（时刻）很难实现固定，导致执行器从EtherCAT主站程序、执行器驱动程序处获得指令数据的时刻很难实现固定，最终影响执行器的动作效果（尤其是协同动作效果）。

2.4.3基于FPGA的架构针对指令执行过程的解决方法考虑图B，对于驱动带EtherCAT从站接口模块的执行器来说，由FPGA实现EtherCAT主站功能，以确保其发送过程数据帧的实时性 --事实上，我并不认为这样做是最合适的，我更倾向于武汉J团队的方案：

在实时反馈控制环路中摒弃EtherCAT，将所有执行器的对外接口都简单化，用本小节后述的方式完成信号采集。

FPGA一侧挂在CPU的外部总线上，一侧连接各执行器、作为它们的上位机，形成一个“总驱动器”。

FPGA并行为各执行器提供其所需的信号波形、指令字段，利用分布式的、并行运行的片内硬件资源设计控制电路，对各执行器的动作时刻进行高效的协同管理，使其按照实际需要的量化时序关系进行动作，以确保各个执行器协同动作的效果。

同时，软件系统中用于执行器的驱动程序由于不再需要面对各种各样的执行器硬件信号，从而使执行器驱动程序可以尽可能简化，并且不必为了与执行器建立数据通道而无谓等待，从而减少了其占用的CPU工作时间，减少了这一段CPU工作时间长度的不确定程度，进而减少了执行器获得指令的时刻的不确定程度。

2.5关于RTOS+ROS2提高ROS节点、自研应用程序模块的运行实时性，最直接的方法是把非实时Linux换成RTOS。

事实上，据说ROS2已经在兼容RTOS方面做了很多工作。

但是，RTOS的本质仍然是软件操作系统，系统中的各内核子程序以及运行在系统上的中间件、应用程序、API、驱动程序，仍然要采用时分复用CPU的基本工作模式，其对CPU内核流水线调度、Cache更新决策、多级存储器映射、存储器一致性操作等复杂、耗时、延迟不确定的底层软硬件操作的依赖，也是不可能改变的。

也就是说，即使基于RTOS实现了机器人控制系统，其实时性指标也会比FPGA低很多。

而且，从笔者已经了解到的信息来看，目前ROS2对RTOS的支持仍然是不完善的。

2.6小结综上所述，在机器人反馈控制系统中加入FPGA，能够提高多路传感器采样的实时性、协同性，提高反馈控制算法的实时性、协同性，提高多路驱动器动作的实时性、协同性，进而提高反馈控制的速度（同等速度下提高对更复杂、协同性要求更高、基于更多路传感器/执行器的、效果更好的反馈控制算法的承载力），降低反馈控制过程耗时的不确定性，优化反馈控制的效果。

3基本思路及实施方法3.1在机器人领域深入应用FPGA技术的基本思路分析反馈控制流程中的所有算法、功能模块，只要适合在FPGA中予以实现，就移植到FPGA中，以使系统实时性最大化、承载更多高性能算法（此前因为运算量大、实时性差而被放弃了）；与此同时，中高端CPU（以及DSP）及其基于ROS的软件系统负责实现反馈控制算法流程中复杂程度太大以至于不适合用FPGA实现的算法模块，以及ROS节点等低实时性需求的复杂算法模块；低端CPU（或者空闲时段的中高端CPU）负责非实时的慢速任务，例如系统管理、人机界面、读写慢速外围设备（如FLASH）等等，并经外部接口完成与中高端CPU（以及DSP）、FPGA之间的慢速数据交互。

FPGA的一侧连接传感器、执行器，获取各监测点的实时状态信息、发出控制指令及参数；一侧连接中高端CPU（以及DSP）的高速外部总线，与之进行反馈控制算法数据的实时交互；另一侧连接低端CPU的外部接口，获取配置信息等慢速数据，提交系统管理、人机界面所需的状态信息。

武汉J团队基于Zynq的“新一代片上驱控一体系统”，也是可供选择的很好的方案。

但是，我认为，除了应考虑将更多算法移植进FPGA，他们的一些重要设计思想应该加以修改。

另外，如果仍然希望使用带有EtherCAT从站模块的传感器、执行器，则应将EtherCAT主站的实时部分的功能移植到FPGA中予以实现。

在这个技术方向，华中科技大学的宋宝教授带领的团队（并非前述的武汉J团队）已经获授了一项发明专利：

一种基于FPGA的EtherCAT主站装置（CN201510107162.X，在国家知识产权局网站能查到详情）。

3.2基本思路的实施方法在系统架构设计方面，需要首先如下个自然段所述大致确定算法移植的方案，然后由FPGA工程师与机器人系统架构设计师进行讨论，针对现有某产品控制系统的软硬件功能划分方案、软硬件底层通讯机制、软硬件上层数据交互机制、软硬件时序协同机制、软件系统的基本框架、FPGA系统的基本框架、硬件系统的基本框架、各种传感器/执行器的性能参数和接口特征、整机数据流设计、整机时序配合机制进行比较深入的讨论，最终共同商讨确定新版系统架构。

在算法移植方面，FPGA工程师很可能对于机器人专业涉及的位姿计算、动力学计算、运动规划、运动控制、伺服驱动等等算法了解不多，需要由相关的算法设计师对各种算法的原理、框架、基本的运算流程（常规内容即可，可以不针对相关单位实际采用的技术）进行梳理，然后由FPGA工程师研究判断其中哪一些可以移植进FPGA，进而初步确定算法移植方案。

事实上，根据笔者看过的一些技术资料，多轴机器人的运动规划、运动控制算法中虽然涉及大量复杂的公式变换，但绝大多数运算都能变换为由基础算子（算术运算、开方、三角函数等）构成的形式，都可以基于FPGA实现，实现之后必将大幅度提高运动规划、运运动控制算法执行的实时性。

在初步确定算法移植方案之后，由算法设计师将现有产品的待移植算法进行简化，然后借助数学变换将其转化为由基础算子构成的形式，由FPGA工程师或算法设计师用MATLAB验证其效果，由FPGA工程师依据各算法模块本身的实现过程、算法模块之间的协同情况、基础算子的参数特征和应用场景、资源调度需求的特征等等因素，规划待移植算法在FPGA中实现的体系架构、FPGA与外部软/硬件模块的接口形式及协同机制（为外部软/硬件模块的修改提供依据），然后写HDL代码予以实现。

之后，将FPGA工程生成的加载文件写入FPGA板的板载FLASH芯片，在新的软/硬件系统的合作下运行机器人系统，初步验证加入FPGA之后的运行效果。

进而，整理各种已研究过但尚未添加的各种优化算法，各种有思路但因为运算量大、CPU/DSP+软件的实时性不能满足系统要求而被放弃的各种优化算法，添加进FPGA设计、系统设计中，针对机器人的动力学实时运算、精细化实时运动控制、反力的精细化捷变响应等性能进行深度优化。

4系统优化科技树--基于FPGA实现EtherCAT主站控制器之后考虑到EtherCAT仍然是当前机器人系统架构中的主流总线，在此提供基于FPGA实现EtherCAT主站控制器之后的系统优化科技树，由业内人士进行参考。

5建议目前，在FPGA应用方面，业界正处在从局部性能优化（伺服驱动器）到系统架构优化（武汉J团队、某大型国企）转变的最初阶段，一旦完成比较成熟的应用案例，其性能优势必将非常显著，不能及时跟进的企业在产品性能落后、受到先行者建立的专利体系的制约的情况下，必将面临严峻的挑战。

所以，笔者在此向从事机器人整机研发、控制系统/部件研发的各单位提出建议：

认真考虑在产品中深入应用FPGA技术，建立系统架构、底层技术、产品性能的优势，以期在新一轮行业技术创新中抢得先机。

参考文献：

1《计算机体系结构：

量化研究方法》，作者：

JohnL.Hennessy，DavidA.Patterson。

2《计算机组成与设计：

硬件/软件接口》，作者：

DavidA.Patterson