已剪辑自: 链接
编者按
硬件定义软件？还是软件定义硬件？这是个宏大的命题。本文篇幅有限，也自认能力有限，很难完整而准确的把握。只为抛砖引玉，期望能有更多的朋友一起探讨。（期待未来能优化更新本篇文章。）
从软件到硬件，从硬件到软件；硬件定义并驱动软件，软件定义并驱动硬件；软硬件系统的发展，是个螺旋上升，不断深化的过程。
未来，随着设计规模逐步扩大，各种处理引擎及其生态持续丰富，软件和硬件，更像是相互博弈相互协同的共生系统，这应该算是“软硬件融合”吧！
指令是软件和硬件的媒介，指令的复杂度决定了系统的软硬件解耦程度。
按照单位计算(指令)的复杂度，处理器平台大致分为CPU、协处理器、GPU、FPGA和ASIC。从左往右，单位计算越来越复杂，灵活性越来越低。
任务在CPU运行，则定义为软件运行；任务在协处理器、GPU、FPGA或ASIC运行，则定义为硬件加速运行。
软件定义是当前非常热门的话题，比如软件定义网络、软件定义数据中心、软件定义汽车等等。软件定义的范畴非常大，不仅仅涉及到底层的软硬件技术，也涉及到系统的运行管理、监控、更新等，甚至还涉及到商业上的一些考量。
系统是由软件和硬件组成。当我们说软件定义XX的时候，其实说的是软件定义XX系统。本文篇幅有限，从最底层的软件和硬件相关的技术以及两者之间的相互关系和影响来阐述系统中软件定义和硬件定义。
“硬件定义软件”定义为：
对应的，“软件定义硬件”定义为：
CPU是最灵活的，原因在于运行于CPU指令都是最基本粒度的加减乘除外加一些访存及控制类指令，就像积木块一样，我们可以随意组合出我们想要的各种形态的功能。
很多人会认为，CPU可以自动的执行非常复杂的计算机程序，这是CPU最大的价值所在。其实不然，CPU最大的价值在于提供并规范了标准化的指令集，使得软件和硬件从此解耦：
在桌面和服务器领域，X86是最流行的处理器架构。而在手机等移动端，ARM则占据绝对的统治地位。开源RISC-v符合未来技术和商业发展的趋势，其在MCU领域已经占据重要地位，并且在向桌面和服务器领域发起冲锋。
软件的庞大生态，是构建在特定的CPU架构之上的。但是，我们一般来说，CPU作为指令足够细粒度，计算足够通用的计算平台，其是软件和硬件解耦的：
从长期发展的角度，RISC-v应该会是未来更好的选择：
CPU和软件程序的交互接口是指令集，是最细粒度的加减乘除等指令，像积木块一样，随意组合出任意想要的各种程序。
CPU到底是软件定义还是硬件定义，从不同的角度有不同的看法：
一个系统，必然经过前期快速迭代，后期逐渐稳定的过程。因此，系统运行的处理器平台选择也必然有如下的一些规律：
当需要面向一个新领域开发的时候，要快速实现，或者应用的场景不够确定，需要硬件平台有足够多的适应性，这些情况使用CPU比较合适。当需要极致的效率，并且成本敏感、功耗敏感，而且规模足够庞大，那么选择定制开发ASIC会更合适一些。如果折中的，需要有一定的灵活性，又要保证一定的性能加速，并且应用有足够的并行度，这个时候GPU则更合适一些。
从软件到硬件的一个经典的例子就是比特币，其激烈而快速的完成了从CPU到ASIC的过渡。比特币使用的技术区块链核心算法是SHA-256，它在各个平台上的性能对比如下：
上述CPU、GPU、FPGA性能数据来自于《区块链：技术驱动金融》，数据为2013年前后的性能数据。
SOC是CPU、GPU、各种加速处理引擎（ASIC）以及接口模块（ASIC）的集成。
智能手机使用电池供电，同时又要提供足够强大的性能。如此苛刻的应用条件，使得智能手机处理器通常都选用集成度非常高的SOC。上图是高通手机SOC处理器骁龙810芯片，可以看到此芯片主要包括：
于是，手机系统就形成了如下表格的分层：
| 应用层 | 应用程序 |
|---|---|
| 系统层 | 操作系统Android/iOS等 |
| 驱动层 | Driver和HAL |
| 硬件层 | 通用CPU；GPU、DSP、ISP等处理引擎；4G、GPS等子系统；WiFi、USB、蓝牙等连接模块；安全模块；其他。 |
GPU由数以千计的CUDA核组成，要想对数以千计的CPU内核进行编程，把这么多核的计算性能发挥出来，是非常大的挑战。
GPU编程有一个最重要的约束是在同一个并行线程组里运行的是相同的程序，也称之为“齐头并进”。即使如此，GPU的编程难度依然相当的大。
于是，为了提升GPU编程易用性和快捷性的CUDA编程框架应运而生了。
2006年NVIDIA推出了CUDA，这是一个通用的并行计算平台和编程模型，利用NVIDIA GPU中的并行计算引擎，以一种比CPU更高效的方式解决许多复杂的计算问题。CUDA提供了开发者使用C++作为高级编程语言的软件环境。也支持其他语言、应用程序编程接口或基于指令的方法，如FORTRAN、DirectCompute、OpenACC。
CUDA是NVIDIA成功的关键，它极大的降低了用户基于GPU并行编程的门槛，在此基础上，还针对不同场景构建了功能强大的开发库和中间件，逐步建立了GPU+CUDA的强大生态。
三类典型的平台：
根据系统业务逻辑的具体实现：
ASIC实现的是整个SOC大系统中的一个子系统，整个子系统的业务逻辑基本上是在ASIC模块硬件中完成（有时候需要控制面软件来控制ASIC模块的运行），因此，其性能相对CPU和GPU较高。
当我们设计一个ASIC硬件模块或加速器的时候，需要提供相应的驱动，如果是要接入OS等标准接口，还需要有一层HAL层负责把不同接口映射到OS的标准接口。应用程序根据ASIC硬件提供的功能接口使用硬件。
GPU平台，硬件的GPGPU提供接口给CUDA，CUDA再提供接口给应用。每一代具体的GPU，给上层提供的是不同的访问接口， CUDA框架有特定的驱动和HAL屏蔽不同GPU的实现细节；并且CUDA为了向前兼容和维护生态，最终映射到标准的库。这些标准的库，提供了标准的接口给上层的CUDA应用程序。
即使CUDA映射成标准的库API接口，CUDA程序依然是要依赖于CUDA提供的接口来设计应用软件。
总结一下，软件依赖于硬件平台存在，体现在两个方面：
上一节我们讲到，系统从起始发展，到逐步稳定，系统的运行平台逐步从CPU演进到ASIC。那么，ASIC是不是所有系统最终的运行平台？
答案是否定的。原因主要如下：
这样，在许多场景，我们根据实际的场景需求，除ASIC，也开始选择DSA、FPGA、GPU甚至CPU等处理引擎。
最典型的一个案例就是SDN（Software Defined Network）的发展。经过几十年的发展，网络芯片已经演进到了完全ASIC的实现，这意味着基于ASIC芯片的网络设备其功能是确定的，用户只能根据厂家实现的确定功能来使用网络设备。
然而，随着云计算、4G/5G移动通信等的发展，新的网络协议和网络功能层出不穷，纯ASIC实现的网络系统遇到了挑战。
如上图所示，IETF（Internet Engineering Task Force，互联网工程任务组）的RFC（Request for Comments，请求意见稿，即网络协议）数量一直在爆炸式的增长，应用于各种新型网络场景的新协议层出不穷。但是，传统的网络处理芯片都是封闭的、特定的设计，用于特定协议处理。想要增加新的协议非常困难，并且对新协议的支持受到不同供应商的约束。定制的网络处理芯片，对新协议的支持不足以及缺乏有效的灵活性，这使得要想在网络系统增加新的功能非常困难，限制了客户的网络创新能力。
客户希望能够快速便捷的对网络进行配置和管理；客户希望能够快速的进行网络协议创新。这样，ASIC的功能固定越来越成为网络创新的约束。于是，SDN开始了两个方面的创新：
OVS（Open Virtual Switch）是Apache 2许可下的开源的软件交换机。OVS的目标是实现一个生产环境的交换机平台，支持标准管理界面，并为程序扩展和控制开放转发功能。OVS非常适合在VM环境中用作虚拟交换机，除了向虚拟网络层公开标准控制和可见性接口之外，它还旨在支持跨多个物理服务器的分发。OVS支持多种基于Linux的虚拟化平台，包括Xen、KVM等。
最新的OVS版本支持以下功能：
如图，OVS答题可以分为三层：
上图为PISA（Protocol Independent Switch Architecture，协议无关的交换架构）架构交换机的流水线，PISA是一种支持P4数据面可编程包处理的流水线引擎架构，通过可编程的解析器、多阶段的可编程的匹配动作以及可编程的逆解析器组成的流水线，来实现数据面的编程。这样可以通过编写P4程序，下载到处理器流水线，可以非常方便的支持新协议的处理。
当实现了完全可编程的流水线之后，在P4工具链的支持下，就可以通过P4编程的方式来实现自定义的流水线，来达到对自定义协议的支持。
如图所示，P4定义的Parser程序会被映射到可编程的解析器，数据、包头定义、表以及控制流会被映射到多个匹配动作阶段。图 6.25中把L2处理、IPv4处理、IPv6处理以及访问控制处理分别映射到不同的匹配动作处理单元进行串行或并行的处理，来实现完整的支持各种协议的网络包处理。
Virtio旨在提供一套高效的、良好维护的通用的Linux驱动，实现虚拟机应用和不同Hypervisor实现的模拟设备之间标准化的接口。Virtio作为类虚拟化的I/O设备接口，广泛应用于云计算虚拟化场景，某种程度上，Virtio已经成为事实上的I/O设备的接口标准。
因为软件定义了标准化的Virtio接口，因此，如上图所示，在SmartNIC和DPU中，offload虚拟化和Workload的最关键部分就是要把Virtio硬件化。
如上图所示，站在虚拟化角度，把Virtio卸载，可以看做是从软件到硬件。但是，如果从硬件接口的角度，从一个完全硬件定义的接口（例如NV自定义的SR-IOV接口）过渡到软件定义的接口（Virtio接口），则可以算是从硬件到软件。
英特尔oneAPI是一个开放、可访问且基于标准的编程系统，支持开发人员跨多种硬件架构参与和创新，包括 CPU、GPU、FPGA、AI 加速器等。这些处理引擎具有非常不同的属性，因此用于各种不同的处理——oneAPI试图通过将它们统一在同一个模型下来简化这些操作。
即使在今天，开发人员面临的一个持续问题是我们日益数字化的世界提供的编程环境的数量。不同的编程环境使代码重用等节省时间的策略失效，并成为软件开发人员的真正障碍。作为其软件优先战略的一部分，英特尔在 2019 年的超级计算活动中推出了oneAPI。该模型标志着英特尔的雄心是拥有统一的编程框架作为限制专有编程平台的解决方案。oneAPI 使开发人员能够在不厌倦使用不同语言、工具、库和不同硬件的情况下工作。
Intel oneAPI可以实现：设计一套应用，根据需要，非常方便的把程序映射到CPU、GPU、FPGA或者AI-DSA/其他DSA等不同的处理器平台。
软件定义是一个非常宏大并且非常热点的话题，除了软件定义网络之外，还有很多软件定义的热点领域：
软件定义存储和软件定义无线电还主要是技术的范畴，而软件定义数据中心和软件定义汽车，则是把软件定义的思路和理念更加深化和拓展，应用于更广阔的领域。
软件定义XX，最本质的做法还是把整个系统重新从硬件实现变成偏软件的实现。随着这势必对CPU的性能提出了更高的要求。
然而，如上图所示，随着CPU的性能提升逐渐停滞，已经无法满足数字经济时代对算力持续提升的要求。
因此，还是要再轮回，“硬件”加速。
支持P4的网络数据面可编程引擎，属于DSA的范畴，专门用于网络包处理的加速，性能跟ASIC相当，但其具有非常好的软件可编程能力。
标准的P4程序，有P4前端编译器把P4程序编译成一个中间态的程序（类似Java编译器）。然后特定硬件实现的后端编译器负责把中间态的程序映射到具体的硬件实现（有点像Java虚拟机，但P4是静态）。
P4 DSA引擎预先配置好P4程序之后，P4-DSA就成了执行特定协议处理的网络包处理引擎。然后需要和已有的网络程序进行适配，实现网络任务的数据面offload。
P4的整个系统栈跟之前CPU、GPU、ASIC最大的不同在于先定义了标准的P4，然后各厂家根据标准的P4去实现各自不同的P4处理引擎。
CPU虽然现在有三大架构（x86、ARM和RISC-v），但就具体的架构而言，其定义的ISA是非常明确的。特别是在RISC-v生态下，大家遵循一致的ISA，已有的程序可以非常方便的在不同Vendor的RISC-v CPU上运行。
但是在DSA领域，目前还看不到这一点。
可以说，当前所有的DSA，包括P4 DSA，都还没有实现接口的软件定义，接口依然是硬件定义的，可以说是不完全的软件定义XX。
我们把oneAPI模型框架再增强一下，如上图所示。这样，跨平台，不仅仅是在CPU、GPU、FPGA和DSA的跨平台，更在于是不同Vendor的不同处理器的跨平台。
不管是软件定义硬件还是硬件定义软件，接口（这里接口是泛指，ISA是接口，IO设备的数据访问接口也是接口，GPU等加速器呈现的访问接口也是接口）都是非常关键的角色，因为是通过接口给对方呈现自己的功能和如何访问。
我们来总结一下软硬件之间的接口类型：
“硬件定义软件”是传统的思路。新的技术发展很快，已有的技术仍在快速迭代；而硬件系统越来越复杂，更新迭代也越来越慢。系统如果是硬件为主，软件依赖于硬件。则势必限制技术的快速发展。
“软件定义硬件”代表了一种趋势：要从系统层次，主动的来定义个体的硬件。但“软件定义硬件”的描述更多的强调系统，容易忽略个体的特点。站在系统层面，可以“站得高，看得远”，代表了宏观的、整体的思考，能够更好的资源统筹，更好的定义系统功能。而站在个体的层面，个体是本源，代表了事物本质的特征。事物受客观规律的约束，具有特定的发展规律。并且，个体具有差异化，如何更好的体现这些差异化优势，是系统持续不断创新的本源驱动。
“软件和硬件相互定义”，可以更好的协同系统和个体的关系，既能够实现软件定义的宏观统筹，又能够兼顾硬件个体的特点和优势，把两者有机的结合起来，实现软硬件更加协同的更优的系统。
