基于消息的FPGA硬件/软件协同设计集成器件的研究：Thomas Baumela 在格勒诺布尔阿尔卑斯大学的博士论文

使用端到端硬件/软件协同设计的基于消息的方法在FPGA中集成器件Thomas Baumela引用此版本：托马斯·包梅拉。使用端到端的硬件/软件协同设计的基于消息的方法在FPGA中集成器件。嵌入式系统格勒诺布尔阿尔卑斯大学[2020-..]，2021.英语NNT：2021GRALM 004。电话：03259401HAL Id：tel-03259401https://theses.hal.science/tel-032594012021年6月14日提交HAL是一个多学科的开放获取档案馆，用于存放和传播科学研究文件，无论它们是否已这些文件可能来自法国或国外的教学和研究机构，或来自公共或私人研究中心。L’archive ouverte pluridisciplinaireTHAPOSE为了获得等级格勒诺布尔大学博士阿尔卑斯专业：信息Arrêté ministériel：25 mai 2016Présentée par托马斯·包梅拉这是弗雷德里克·佩特罗特说的奥利维耶·格鲁伯的著作准备在TIMA（UMR 5159）和LIG（UMR 5217）实验室以及信息、信息科学和技术博士学校开设课程基于消息的端到端软硬件协同设计FPGA器件Thèse soutenue publiquement le 24 février 2021，陪审团组成后：M. 坦吉·里塞CITI，INSA-Lyon，特别报告员M. 盖尔·托马斯巴黎南部电信公司首席报告员，特别报告员M. 诺埃尔·德帕尔马Grenoble Alpes大学校长M. 凯文马丁Maquitre de confécement，Institutoire Lab-STICC，Université deBretagne Sud，ExaminateurM.弗雷德里克·佩特罗TIMA，Grenoble INP，Directeur de thèse内容1介绍12背景和问题概述92.1问题说明. . . . . . . . . . . . . . . . . . . . . . . . . . . .92.2硬件/软件集成的SoC方法。. . . . . . . . . . . . . . . .112.3简化设备驱动程序开发的操作系统方法。. . . . . . . . .122.4总结. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163基于消息的嵌入式系统集成173.1当前的一体化挑战。. . . . . . . . . . . . . . . . . . . .183.2背景。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .213.3基于消息的集成解决方案。. . . . . . . . . . . . . . . . . . .233.3.1软件视角. . . . . . . . . . . . . . . . . . . . .233.3.2硬件方面。. . . . . . . . . . . . . . . . . . . .273.3.3全面的. . . . . . . . . . . . . . . . . . . . . . .293.4消息和类泛型。. . . . . . . . . . . . . . . . . . . . . .303.4.1使用消息。. . . . . . . . . . . . . . . . . . . . . . . . . .313.4.2类-通用协议。. . . . . . . . . . . . . . . . . . . . .343.4.3异质结。. . . . . . . . . . . . . . . . . . . . . . . . . . .353.5评价。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .393.5.1间接费用评估。. . . . . . . . . . . . . . . . . . . . . . .405.2小型嵌入式系统. . . . . . . . . . . . . . . . . . . .453.6总结. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .494Linux集成514.1背景。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .524.1.1Linux内核模块. . . . . . . . . . . . . . . . . . . . . .524.1.2用户空间接口。. . . . . . . . . . . . . . . . . . . . . . .544.1.3Linux设备驱动模型。. . . . . . . . . . . . . . . . . . .564.1.3.1设备、驱动程序、总线。. . . . . . . . . . . . . . . .574.1.4Linux下的软硬件通信。 . . . . . . . . .614.1.5 Linux中的一些总线实现示例。. . . . . . . . .624.1.5.1 PCI驱动程序。. . . . . . . . . . . . . . . . . . . . . . .624.1.5.2 USB驱动程序。. . . . . . . . . . . . . . . . . . . . . .644.2扩展建议. . . . . . . . . . . . . . . . . . . . . . . . . .67III四.目录4.2.1一个新的Linux消息总线。. . . . . . . . . . . . . . . . . .684.2.2驱动程序API。. . . . . . . . . . . . . . . . . . . . . . . . . . . . .694.2.3低级驱动程序API。. . . . . . . . . . . . . . . . . . . . . .714.3实验。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .755Xen集成795.1云计算中的FPGA采用。. . . . . . . . . . . . . . . . . . . . .795.1.1云的架构。. . . . . . . . . . . . . . . . . .795.1.2 FPGA在云中的采用状况。. . . . . . . . . . . .835.2我们对云的建议的影响。. . . . . . . . . . . . . . . .845.2.1基于消息的通信。. . . . . . . . . . . . . . . . .855.2.2类的泛型。. . . . . . . . . . . . . . . . . . . . . . . . . .865.3可行性。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .875.3.1hypervisor提供的概念。. . . . . . . . . . . . . . . .875.3.2描述我们的解决方案。. . . . . . . . . . . . . . . . . . .885.4深入分析。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .975.4.1在Xen中的集成. . . . . . . . . . . . . . . . . . . . . . . .975.4.2我们的云系统解决方案的后果。. . . . . . . . 1026结论1056.1总结. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1056.2观点。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108参考书目111第1章绪论硬件开发的步伐趋于不断加快。例如，多处理器片上系统（MPSoC）就是这种情况，它嵌入了许多特定的知识产权（IP）。这些系统的发展非常迅速，以适应特定的消费市场。例如，Snapdragon平台的几个版本可以在一年内发布1。因此，集成硬件，使其功能可用于高级软件应用程序，是一个非常重要的问题。实际上，随着硬件不断发展，具有新的和不断变化的能力，并且由于更有效的工具和更高的开发人员专业知识，系统变得越来越复杂，集成硬件的成本不断增加。如果这对于MPSoC来说是真的，那么对于现场可编程门阵列（FPGA）来说就更糟了，因为FPGA的高可编程性使得硬件开发更快，因此硬件集成成为一个更关键的问题。因此，本文的工作旨在提高FPGA的硬件集成度从小型嵌入式系统到云计算，FPGA技术在各个领域的应用越来越广泛它们通常用于将可编程硬件逻辑与处理系统相关联。在这样的系统中，可以通过对预先存在的芯片进行编程来设计和集成硬件组件，而不必改变实际硬件。 这打开了伟大的职位，关于可编程性，电源效率和性能。不过，这也带来了一些缺点：不仅FPGA编程可能很复杂，而且将新创建的硬件与软件集成也是一项繁重的任务。1https://en.wikipedia.org/wiki/List_of_Qualcomm_Snapdragon_processors12第1章绪论将FPGA用于具有细粒度并行性的任务的优势增加了它们在许多领域的采用。特别是，它们的可重新编程性提供了很大的进化可能性。它使系统更新更容易，只需重新编程FPGA，而无需更改实际硬件。甚至可以远程重新编程FPGA，使此类系统的维护更容易。它们的功率效率，即使仍然低于纯粹的专用集成电路（ASIC），也远远优于在CPU上运行软件它们还允许更快的原型设计，因为它们能够设计和实现硬件，而无需构建实际的FPGA上的实现是在晶体管级进行的，从而为需要它的应用程序提供更好的并行化与软件实现相比，这提供了整体出色的性能，使FPGA成为嵌入式系统，中型系统和云计算系统的理想解决方案。在嵌入式系统中，可编程逻辑用于将硬件逻辑部署为设备。这些设备可以是外部设备的控制器，例如人机接口设备（控制器和显示器）、存储和网络设备或传感器和致动器。它们也可以是加密、视频和音频处理以及现在的人工神经网络推理的加速器。与在CPU上运行的软件实现相比，这降低了功耗，同时提供了更好的性能。图1.1描述了FPGA如何集成到嵌入式系统中的整体视图这允许FPGA访问I/O接口，从而允许其访问外部外围设备和总线，如USB、以太网或I2C。 它还将FPGA与系统总线连接，使其上运行的软件能够访问FPGA上的设备。通过在处理系统上运行的软件驱动器来集成部署在这样的FPGA中的设备 每个设备都有一个可用的驱动程序，该驱动程序将其提供的功能集成到上层软件中。FPGA也以这种方式用于更大的系统，运行完整的操作系统。 在这些系统中，FPGA要么位于与处理系统相同的SoC或板上，要么位于通常通过PCI链路连接的单独板上。 尽管这些系统比嵌入式系统更大，但FPGA以类似的方式集成。硬件组件部署在FPGA中，并被视为软件中的设备。这些设备必须与操作系统中的驱动程序集成这是一项非常具有挑战性的任务，因为驱动程序更新必须遵循每个操作系统更新计划的规则。3第1章绪论faceFPGA装置2装置1设备0FPGA接口FPGA集成总线R总线处理系统InteI/O驱动器1驱动程序0处理系统图Re 1.1：嵌入式系统FPGA也越来越多地用于云计算。这些系统本质上是为多个客户端共享硬件资源而设计的这意味着无论客户端处于哪个级别（虚拟机、操作系统或应用程序级别），FPGA资源都必须在多个客户端之间共享我们决定只关注在FPGA上实现的共享设备事实上，共享FPGA本身，这意味着允许多个客户端重新编程部分或全部FPGA是一个不同的主题，目前有几项工作正在解决在我们的案例中，设备部署在FPGA中，并与客户端共享，客户端可以随时进出。 由于这些器件位于FPGA上，因此它们可能会被更新、删除或随时出现新器件。 这意味着集成这些设备需要在所有层中具有更大的动态性。图1.2显示了FPGA如何集成到云系统中的整体情况。硬件方面，架构是一样的设备部署在FPGA上，与处理系统总线集成，让软件访问这些设备。软件方面的情况是不同的，因为多个操作系统共享相同的硬件资源.第一层软件称为hypervisor，负责共享硬件，从而共享FPGA上的设备共享设备有多种方式，但总体思路是每个操作系统都有自己的驱动程序集，用于它想要处理的设备驱动程序与管理程序通信以处理设备。然后，管理程序负责共享来自所有操作系统的驱动程序的设备操作此外，一些设备也可能完全分配给一个特定的访客，使情况与以前的系统完全相同。4第1章绪论rfaceFPGAice 1装置2Dev设备0FPGA接口FPGA集成总线总线处理系统我是I/O管理程序驱动器1驱动程序0驱动程序0OS 1OS 0处理系统图Re 1.2：嵌入式系统由于FPGA在许多不同的应用领域具有许多功率和性能优势，人们可能会问，为什么这样一项伟大的技术的采用如此缓慢，尽管它正在向前发展答案的很大一部分是FPGA有一个主要的缺点：在实际的软件密集型系统中集成部署在FPGA中的设备是一个真正的挑战。这一挑战影响了硬件和软件方面，使其成为一个协同设计问题。设备制造商必须使其设备接口适应每个系统的中断控制器、硬件接口很难标准化。尽管作出了一些努力，但没有出现真正的标准该行业的两个主要行为者认识到这一挑战，并开始解决这一问题，尽管只是部分解决。多年来，他们已经大大改进了他们的工具，为使用硬件描述语言（HDL）和高级综合（HLS）开发硬件提供了很大的支持他们还增加了硬件组件库，使其更容易重用硬件商品，如缓冲器，总线控制器或DMA引擎。他们还努力推动AXI标准，提供了很好的工具和组件，可以更轻松地与标准接口 但这些工具和资源主要集中在改进可编程逻辑上硬件的设计、集成和部署上。尽管这是帮助将器件集成到FPGA中的重要而必要的一步，但这只是我们所面临挑战的一半5第1章绪论我们面临的集成挑战是跨软件和硬件的。当然，硬件特征必须被设计和部署在可编程逻辑上，但是软件必须被编写和安装在处理系统上以能够利用这些硬件特征。这意味着编写软件驱动程序来驱动硬件设备。编写驱动程序需要硬件和软件技能，而不是每个人都具备这些技能，这使得它们的开发既耗时又昂贵。开发人员必须处理基于寄存器和中断的当前硬件-软件边界，暴露了许多硬件实现细节。他们必须处理不断增长的文档，通常长达数百页，描述每个硬件寄存器的每一点，因为他们必须深入研究细节，以便驱动程序开发人员了解如何驱动设备。这些文档总是随着设备每隔几个月进行一次修订而不断发展，并且通常不明确。此外，新设备不断出现，使编写驱动程序成为一场永无止境的斗争。 这导致驱动程序很难保持安全，因为它们必须经常更新，因此是一个重要的潜在bug来源。 考虑到需要驱动程序的软件栈的多样性，从裸金属到各种流行版本的Linux内核，如果不解决问题，情况可能会变得非常严重。在这篇论文中，我们提出了一个新的简单而有效的方法来解决这个问题。我们的方法不需要昂贵的或新的技术。它可以逐步采用，而不必抛弃现有的每一个解决方案。它与现有的FPGA和处理系统技术兼容，无需更改现有工具。我们的解决方案需要遵循端到端的设计，同时考虑到软件和硬件集成过程的全面视图这种设计可以使用现有的工具和技术进行，这意味着许多现有的改进可以集成到我们的设计中。我们的方法受到通用串行总线（USB）背后原理的启发，并适用于部署在FPGA上的设备我们从USB中保留的两个核心原则是：1）在设备和驱动程序之间提供消息管道，完全隐藏由中断和寄存器组成的旧边界，2）定义设备类，允许一个驱动程序能够驱动同一类的多个设备。 使用消息管道将驱动程序从其设备中分离出来，从而实现了非常需要的关注点分离。 不再需要几百页长的笨拙文档，不再需要几十个内存映射硬件寄存器和中断。唯一的要求是高级消息协议。这将使驱动程序更小，更容易编写，操作更安全此外，它还提供了标准化消息的可能性6第1章绪论协议，而不是针对每个特定设备具有一个特定协议使用类通用协议，只需一个驱动程序即可驱动整个类的设备。这两个原则，一个消息管道和类通用协议，是任何USB密钥可以插入几乎任何主机并开箱即用的两个关键原因 它的工作原理首先是因为物理密钥本身可以插入，这需要标准插头和电缆。 然后它工作，因为USB密钥被视为一个大容量存储设备，一类设备，支持标准的大容量存储协议。最后，它之所以能工作，是因为处理系统为特定类别的设备运行通用驱动程序，并将其与软件堆栈的其余部分集成在基于消息的总体方法提供了硬件设计和软件编码之间的正确分离。 双方都只将对方视为信息的发送者和接收者，以确保顺利和具有成本效益的整合。不幸的是，USB规范不能用于此。 USB不开放，不自由，不够抽象。 它的规格是一个封闭的世界，锁定采用者和某些电缆和插头的力量，使其难以定制某些需求。我们的建议是定义一个开放的和抽象的管道发送和接收消息之间的边界的可编程逻辑和处理系统。幸运的是，我们不需要建立新的电缆和插头。FPGA已经有了与处理系统集成的解决方案，这些解决方案可以在同一个SoC、板上或通过现有的总线（如PCI）运行良好在FPGA本身上，业界的努力，特别是与AXI标准相关的努力，在我们的解决方案中完全可重复使用特别是，我们使用AXI和AXI流标准构建了我们的解决方案，使用FPGA供应商的现有工具，而无需更改它们或完全重新发明轮子。因此，挑战不在于此，我们需要的所有构建块都存在，并且将被重用。挑战在于根据两个接口设计1. 所有驱动程序将用于发送和接收消息的软件接口2. 所有设备用来接收和发送消息的硬件接口。本论文的第一个目标是定义一个完全抽象的接口，是简单和安全的使用。 拥有一个抽象的接口是关键，因为我们要针对的所有系统都是非常异构的。因此，我们不能强加一个特定的现有标准7第1章绪论因为一些用户可能需要低功率低性能接口，而另一些用户可能需要高性能。有了抽象接口，电路板供应商将有实现的自由，以适应我们的建议，他们的板的具体情况，从小型嵌入式系统到大型的。事实上，我们的建议可以适应处理系统，可编程逻辑和它们之间的互连总线方面的非常不同的技术添加一个抽象层意味着我们必须注意重要的需求。使用消息不能在延迟或吞吐量方面引入任何不适当的开销 我们还必须保持可编程逻辑端的占用空间和功耗。我们首先为小型嵌入式系统设计解决方案此设计通过定义新消息管道的软件和硬件接口来解决我们所描述的集成挑战软件方面，我们设计了一个异步接口的灵感来自Linux驱动程序模型，这是熟悉的驱动程序开发人员。硬件方面，我们设计了一个基于流接口的抽象接口，用来与软件进行消息的发送和接收这些流接口的实现不是由我们的解决方案强加的，只有在其中传输的消息协议是。这意味着人们可以使用与我们不同的实现来构建我们的解决方案，并且仍然可以从其优势中受益我们构建的原型表明，我们的解决方案适合具有低延迟和低吞吐量设备的小型系统，而不会增加实现的规模。我们还将我们的解决方案集成到Linux内核中，展示了它在更大系统中的可行性我们证明了我们的解决方案可以适用于高性能设备，性能开销可以忽略不计 我们证明了我们的设计可以很好地集成到Linux内核中，而不会干扰现有的解决方案。它表明，我们的解决方案是灵活的，可以通过在我们的设计中集成一些设备和在现有的解决方案中集成一些其他设备在云计算的背景下，我们分析了我们的解决方案可以提供很大的好处，以提高FPGA集成，但也硬件支持。事实上，消息是在多个客人之间共享设备的良好解决方案它们也很适合著名的hypervisors，特别是Xen，它具有我们的解决方案所需的所有功能，而不需要修改它。此外，云计算还受益于我们基于消息的解决方案所支持的类它允许客户操作系统需要更少的驱动程序来支持硬件。我们的解决方案还允许将基于消息的驱动程序从非监督操作系统重用到监督操作系统。8第1章绪论手稿的组织如下。第2章概述了我们开展工作的背景，并讨论了我们认为与我们的建议相关的相关工作。第3章介绍了我们的第一个贡献，一个基于消息的方法，针对嵌入式系统的上下文的设计和实现。第4章介绍了我们的第二个贡献，详细介绍了我们的解决方案如何集成到更大的系统中，特别是那些运行Linux内核的系统，并介绍了如何在Linux中实现第5章是一个不太成熟的贡献，更具体地说，实现还有待演示，它展示了我们的解决方案如何对云有用，以及如何通过Xenhypervisor集成到云系统。最 后，第6章总结了我们所解决的问题和我们提出的解决方案，并提出了一些观点。第2背景和问题概述章节内容2.1问题说明92.2硬件/软件集成的SoC方法112.3简化设备驱动程序开发122.4摘要.16我们在这篇论文中所解决的工作是在几个倡议的十字路口，一些来自片上系统的研究，其他人从操作系统的研究。SOC和OS研究有着非常不同的目标，而在一天结束时，两者的整合是建立一个有用的硅基系统的必要条件。本章一开始，我们就举例说明了硬件发展的快速步伐和它所引起的软件困难然后，我们分析它，首先集中在目标的方法，从自下而上的角度集成到片上系统的IP然后，我们采取相反的立场，其中操作系统是工作的核心，硬件是必要的邪恶。最后，我们得出了一些结论，一些缺失的部分，将简化集成的ad-hoc硬件在遗留操作系统软件。2.1问题说明今天的多处理器片上系统就是昨天的专用集成电路：针对一个应用或一类应用进行优化的硅片尽管它们往往是可重用的，并且能够有效地处理越来越910第2章背景和问题概述根据目标用途和市场嵌入特定的硬件知识产权（IP）基于平台的设计[1]一直是推动行业发展的关键词，因为它最大限度地提高了硬件重用，从而缩短了开发时间。看看移动平台是相当有启发性的：高通公司在2007年至2020年期间向其客户发布了150多个不同的Snapdragon平台实例，德州仪器在离开这个市场之前宣传了25个，市场上的其他参与者也随着时间的推移，这些平台变得如此复杂，以至于业界甚至没有尝试给出SoC包含的内容的粗略图表，如图2.1所示。（a）OMAP 3430框图（b）Snapdragon 865框图图2.1：SoC在（a）2010年、（b）2020年的典型市场表现尽管SoC的快速和节能硬件设计仍然是一个真正的挑战，但平台版本的巨大数量只会加剧本已困难的硬件/软件集成问题事实上，每个平台都包含不同数量的IP，在大多数情况下，即使是提供相同功能的IP也略有不同。因此，硬件/软件集成过程必须处理10到100个IP，每个IP本身具有数十到数百个寄存器。此外，每个寄存器都可能有一 个 位 字 段 ， 具 有 多 达 许 多 功 能 。 即 使 对 于 Raspberry Pi 4 （ BroadcomBCM2711 ） 中的适度SoC，我们也已经计算了超过2500个寄存器。Texas-Instrument的工程师报告说，现代SoC中时钟和电源模式的唯一启动涉及读取和写入1000多个不同的寄存器[2]。 在这种情况下，使用（和重用）IP是一个双重问题。首先，使用加载和存储在正确的时间以正确的顺序在正确的地址/偏移处访问寄存器/位字段，这可以被视为其次，在这些资源中设置正确的值，以便设备做它应该做的事情，这更像是一个总的来说，拥有一个工作的硬件/软件系统是一个巨大的工作量和调试。它11第2章背景和问题概述因此毫不奇怪，操作系统中的绝大多数bug来自设备驱动程序（大约70%的bug，其中驱动程序占Linux内核源代码的70%），其中三分之一是由于操作系统和设备之间的接口[3]。在运行时检测这些错误的一部分是非常昂贵的，并导致100%的开销[4]。在FPGA的背景下，这个问题甚至更糟它们的高可编程性使得IP版本的数量增长得更快。事实上，使用硬件描述语言（如verilog或VHDL）或高级综合（这使得IP开发更加容易）来实现IP非常容易例如，仅在Xilinx IP公共目录中，就可以找到最新版本的800多个IP与ASIC或片上系统相比，更新基于FPGA的平台也非常快 在几个小时（有时几分钟）内，可以更新IP，运行几个测试，实现嵌入新版本的平台，并最终使用更新的平台对FPGA进行编程。在此之后，通常需要进行软件更新，并且可能需要大量的工作来更新和调试驱动程序，即使是微小的更新。2.2用于硬件/软件集成在SoC领域，简单和早期的硬件/软件集成一直受到关注。这是由于这样的事实，即由于高成本的限制，需要硬件/软件设计空间的容易探索，以优化用于给定应用或一类应用的目标系统以处理数据流的SoC为例，这对于消费者应用程序来说是典型的，在某些时候，应用程序最终被指定为一组互连的任务。然后，第一步是决定哪些任务将在硬件中实现，哪些将在软件中实现 如何完成此划分取决于许多因素，其中最少的因素是是否存在适合任务的HW IP。一旦完成此选择，任务，独立于其硬件或软件性质，必须进行通信，同时考虑延迟和带宽约束。因此，通信合成的目的是自动生成通信所需的硬件和软件[5]。以流应用程序为例，[6]提出了一种分层方法，其中应用程序级，系统级，操作系统级和物理级接口使用模板预定义。合成通信归结为实例化12第2章背景和问题概述正确的硬件和软件元素，并设置适当的参数。基于这些原则的方法非常适合于ad-hoc使用，适用于可以使用静态任务图和数据流（如通信）指定的应用程序[7，8]。如[9]中所述，已经提出了更通用的方法，其也针对共享内存通信他们实际上是从高层次的规范中为硬件和软件部分构建有限状态机在[ 10 ]中提出了一种基于远程过程调用概念的正交策略。这里的原则是通过作者称之为“共享对象”的东西来描述应用程序中的通信，这些对象能够序列化请求并执行操作，如果它们是硬件IP，则在内部执行操作，否则将其转发给软件任务。 虽然有趣的是作为一个不同的抽象，共享对象的管理是有点不寻常的，并描述与此语义繁琐的应用程序，这使得该建议难以推广。总体而言，以SoC为中心的方法不关心驱动程序本身的概念，并且不处理内核接口、设备共享、进程隔离等。 它们专注于通信抽象，这很好，但在针对实际的以处理器为中心的产品时，不能忽视操作系统的遗留问题。2.3简化设备驱动程序开发的操作系统方法就操作系统而言，这个问题是已知的，也是公认的，并且已经尝试了不同的解决方案，但是都是在硬件/软件边界保持不变的假设下。 硬件被看作是一组（可能是巨大的）寄存器，必须按照一个寄存器中表示的约束进行读写。第一个相关工作是自动生成驱动程序大多数方法都是从定义一种域特定语言（DSL）开始的，在这种语言中，设备的特定性（描述为硬件资源和行为的混合）被捕获。然后，一个工具，特定于一个操作系统（或者甚至是它的一个版本是完全准确的，例如Linux pre 2.6有一个大的内核锁，现在每个设备都有自己的一组锁），用于生成实际的驱动程序[11，12]。驱动程序生成工具本身可以通过操作系统接口的形式化描述进行参数化[4，13]。图2.2总结了这个想法。13第2章背景和问题概述.c器械规范设备类规范设备驱动程序OS规范图2.2：从DSL生成驱动程序的原理（摘自[4]）另一种方法是推动使用高级编程语言编写设备驱动程序或同步等软件挑战。这项工作[14]建议用Java编写驱动程序，在内核中运行Java虚拟机这项工作[15]甚至主张完全用高级语言重写内核，在这种情况下是Go语言。使用DSL是一个方向，但不是唯一的方向。 工具和DSL被期望帮助解决语法问题，而不是真正的语义问题。因此，它们对于使用特定设备的复杂性的鲁棒性没有多大帮助然而，它们通过抽象其API来帮助驱动程序与操作系统的集成。它们简化了操作系统定义的编程规则，特别是关于动态驱动程序加载和卸载的复杂规则。软件社区的其他努力一直在推动工具而不是框架。像Coccinelle [16]或Coverity [17]这样的工具是为了帮助编写更安全的内核代码和更好地支持代码演进。这些工具有助于编写内核代码的常见软件挑战，例如内存管理或同步，但实际驱动硬件设备的挑战没有得到解决。 该工作[18]讨论了基于IP-XACT的集成流程，这是一种描述硬件组件以促进其集成的XML格式。我们看到这些方法可能存在局限性事实上，在定义高级语言时必须考虑所有情况，这并不容易。 因此，要么语言非常抽象且易于使用，但范围可能有限，要么语言允许描述许多细节，在这种情况下，很难以通用的方式使用，并且需要大量的工作来准确地建模行为。因此，给定操作系统的每一次演变都需要新的发展，新操作系统的引入也是如此。白蚁14第2章背景和问题概述第二项工作是隐藏软件看到的硬件接口。RIFFA [19]受微软研究院SIRC [ 20 ]的启发RIFFA结合了软件和硬件部分。RIFFA在处理系统上运行，提供了一个C库和一个Linux设备驱动程序。RIFFA部署在可编程逻辑上，提供了一套硬件组件。 双方已被设计为PCIe总线和DMA引擎用于通过处理-ING系统和编程逻辑上的加速器之间的数据。RIFFA设计仅集中在具有DMA和PCIe特定设计的加速器上，但该方法肯定可以扩展到其他总线技术和其他硬件设备。值得注意的是，早期RiFFA-1 [19]的DMA传输后来被RIFFA-2 [21]中的通信信道更好地抽象化，这是非常有趣的事情，朝着抽象管道的想法发展 但是RIFFA库是用于在用户模式下运行的应用程序的。虽然这种将可编程逻辑上的加速器专用于单个应用程序的方法解决了有问题的问题，但它们没有在操作系统级别集成设备。 在内核级别集成它意味着将支持设备生命周期，因为驱动程序可能会被加载和卸载，设备可能会失败。RIFFA不包括任何生命周期管理，这在集成设备时是非常关键的实际上，设备有时不仅仅是在加电时启动并始终无故障运行的硬件 它们可能会遇到问题，某些功能在一段时间内不可用，或者只是在重置之前失败。尽管RIFFA在当时有很大的帮助，但它不再被维护了。它已经遭受了很多Linux内核更新，使大量的工作，以保持最新的人仍然在该项目。这表明，即使对于像RIFFA这样成功的项目，保持软件/硬件接口与他们必须遵循的所有硬件和软件更新一样，也是一项非常艰巨的任务它再次揭示了这个接口的复杂性是很多困难的根源，使我们相信降低其复杂性可以帮助减少驱动程序维护和调试所需的工作。MPRACE [22]的工作遵循与RIFFA类似的理念，非常专注于帮助开发需要非常高带宽的PCIe设备工作的重点是帮助能够使PCIe链路饱和，即能够使用PCIe总线可能提供的所有吞吐量。C库旨在隐藏15第2章背景和问题概述设备虚拟机客户OS物 理 设备驱动器块后端驱动程序器件沟道块前端驱动程序DMA引擎的详细信息。 DMA引擎隐藏在FIFO接口后面，供硬件设计人员使用。这些选择符合FPGA供应商推动DMA引擎前置AXI流的要求。这是一个很好的灵感，可以进一步推动这个想法成为一个完整的基于消息的解决方案。最后，第三个完全不同的操作系统研究领域是虚拟化，我们相信这对我们自己的目标是有启发的 从管理程序或微内核的角度来看，得出了相同的结论[23]：客户操作系统对设备的访问是通过进程间通信（IPC）机制执行的。然而，这些方法的意图不是改变硬件-软件边界，而是将中断包装为消息，使驱动程序仍然在硬件寄存器中加载和存储值。图2.3说明了Xen hypervisor所提倡的分割驱动程序方法，它通过主机操作系统（最常见的是Linux）提供对设备的访问。如[24]中所解释的，原则是为客户操作系统提供“简单、狭窄和理想化的硬件视图”，必须对其进行修改，客户操作系统有一个后端，它接收前端的请求，并调用本机驱动程序来实际访问设备。这种策略简单而干净：提供给前端的硬件抽象允许通过后端访问主机上未修改的遗留驱动程序毛皮-Xen中的拆分设备驱动程序物理驱动程序在隔离的VM中运行，通过共享内存设备通道连接到访问该设备的来宾VM。Xen图Re 2.3：Xen但是，对于给定的驱动程序类，需要单个（前端，后端）对，这最小化了要在客户操作系统上完成的修改[25]的工作使用这个概念来虚拟化SoC上的设备，并提供对它们的访问作为OS服务。 这种方法是有意义的，但是在内存占用和计算能力方面非常昂贵，因为它需要在拆分驱动程序的后端使用原始的Linux设备驱动程序。