BLOG

Co-simulation

在联合仿真中，形成耦合问题的不同子系统以分布式方式建模和仿真。因此，建模是在子系统级别完成的，而无需考虑耦合问题。此外，耦合仿真是通过以黑盒方式运行子系统来进行的。在仿真过程中，子系统将交换数据。联合仿真可以认为是对已经成熟的工具和语义的联合仿真；当使用合适的求解器对它们进行模拟时。 [ 1 ]联合仿真通过提供灵活的解决方案，允许同时考虑具有不同时间步长的多个域，证明了其在验证多域和信息物理系统方面的优势。由于计算负载在模拟器之间共享，联合仿真还使得大规模系统评估成为可能。

Co-simulation 是指 硬件仿真与软件仿真 或者是 不同仿真域之间的联合仿真，通常包括以下两种场景：

1. 硬件与软件协同仿真：将硬件描述语言（HDL）模型和软件（如固件、驱动程序、操作系统等）代码一起仿真。这种仿真方法对于验证整个系统（包括硬件和软件交互）非常重要。
2. 多个仿真工具之间的协同仿真：将多个仿真工具结合起来，进行不同层次的设计验证，例如硬件仿真与软件仿真、系统级仿真与电路级仿真等。

Co-EMU

Co-EMU 是 Co-Simulation Emulator（协同仿真仿真器）的缩写，它是用于硬件和软件协同仿真（co-simulation）的一种仿真平台。具体来说，Co-EMU 是一种能够实现 硬件与软件联合仿真 的仿真工具，它使得设计人员能够在仿真过程中同时验证硬件和软件之间的交互行为。

• synopsys 的VDK支持与haps联合仿真
• mentor的veloce支持联合仿真
• candence 的helium 支持和Palladium \Protium 联合仿真

SystemC

SystemC缺点

sc model做不了性能仿真，或者说无法在rtl稳定之前做性能仿真。

架构探索，架构探索阶段简单点像是拼积木，找到相同资源下，承载能力最大的方案。做Ai的同学推荐python，或者xilinx的HLS tool。做通信的同学推荐matlb，拥有绝对强大的数学计算库。做cpu的用c/c++的居多。与国外资深同行交流过，目前没见过架构探索阶段使用SC的，一个是速度，一个是门槛。

systemc与rtl混合仿真并无论从构建case，比如pss的概念，还是替代UVM快速开发，或者说仿真速度提升等方面来讲，其实都没有很明显的优势，反而缺陷很多，sc是c++中的一个库，对硬件工程师来讲是一门特别不友好的语言，对软件工程师来讲，又要体验硬件开发中并行的概念，所以在过去20年芯片开发中，sc一直很难普及，sv对硬件工程师来很友好一骑绝尘，即使sv中也借鉴了TLM trans payload。

sc仿真速度，对软件开发来讲，实现同等功能的前提下，不如纯c/c++，对rtl来讲，实现同等仿真精度前提下，不如vcs等大型商业仿真软件，wave trace更是难用，波形无压缩，小规模开发验证无压力，但是中等以上规模项目很耽误进度。以前在花花内部评估过，面对商业区软件，毫无胜算。

SystemC优势

再说说实际点的优势，systemc把c++很顺畅的引入到uvm，A家自有的一套uvm验证平台，融合了uvmc sc c++，性能提升三倍，当然不是什么通用方法学，人家自己开发的独有的一套验证平台，既然c++ 都引入了，自然也将cpython也就直接带入，这可以打打大大提高生产力。

复用，做芯片，总得做一套gold model，借鉴pss的理念，复用为上，那首推sc，从算法模型，验证模型，软件开发平台，coemu验证平台，silicon debug，sc做的model基本都能都用得上。

牛逼架构师加持下的性能仿真，前提是牛逼架构师能制定好kpi，好用的工具还需要大牛才能发挥出真正的威力，sc给不管与硬件有关密切，他还是一套软件工具，所以不要总盯着带宽，延时这两个必须的指标，多利用软件的灵活度关注模块内部逻辑。

联合仿真框架的抽象层

建立协同仿真框架可能是一项具有挑战性和复杂的任务，因为它需要参与元素之间强大的互操作性，特别是在多重形式主义协同仿真的情况下。需要对各个模型中实际采用的标准和协议进行协调、适应和最终更改，以便能够集成到整体框架中。协同仿真框架的通用分层结构[ 3 ]突出了协同仿真框架设计过程中领域的交叉点和需要解决的问题。一般来说，联合仿真框架由五个抽象层组成：

从概念结构出发，定义了联合仿真框架开发的架构和形式语义关系/句法表述。详细的技术实现和同步技术涵盖在动态层和技术层中。

问题划分——联合仿真的架构

划分过程识别耦合问题在空间上分离成多个划分子系统的过程。信息通过临时接口或通过由主算法控制的中间缓冲区进行交换。主算法（如果存在）负责实例化模拟器并编排信息交换（模拟器-模拟器或模拟器-编排器）。

连接方式

协同仿真耦合方法根据抽象层的不同可分为操作集成和形式集成。一般来说，操作集成用于特定问题的联合仿真，旨在实现动态层和技术层（即信号交换）的互操作性。另一方面，形式集成允许通过模型耦合或模拟器耦合在语义和句法级别上进行互操作。正式的集成通常需要一个主联盟来协调模拟器之间交互的语义和句法。

从动态和技术的角度来看，在实现过程中需要考虑同步技术和通信模式。

通信模式

主算法存在三种主要的通信模式。 Gauss-Seidel、雅可比变体和传输线建模、TLM。前两种方法的名称源自与同名数值方法的结构相似性。

原因是雅可比方法很容易转化为等效并行算法，而高斯-赛德尔方法则很难转化为等效并行算法。

Gauss-Seidel (serial)

两个子系统的高斯-赛德尔序列

Jacobi (parallel)

两个子系统的雅可比序列

Transmission line modelling, TLM

在传输线建模（也称为双向延迟线建模）中，电容（或电感）被具有波传播的传输线元件替代。时间延迟设置为一个时间步长。通过这种方式，引入了物理驱动的时间延迟，这意味着可以在该位置对系统进行分区。由于不存在数值误差，因此保证了数值稳定性，而是引入了建模误差，这是更良性的。这通常是最容易实现的，因为它会产生显式方案。

VCS-MX

VCS-MX 是 Synopsys VCS（Verilog Compiler Simulator）的一个增强版本，通常用于高性能的仿真和验证。在半导体设计和验证领域，VCS 是 Synopsys 公司开发的一个非常流行的硬件仿真工具，广泛用于数字集成电路的功能验证。

VCS-MX 的特点

VCS-MX 是 VCS 的一种 高级版本，它在基础的 VCS 仿真引擎之上进行了性能和功能的增强，专门用于处理更大规模的设计，或者是针对特定的验证需求做了优化。它能够支持更大范围的设计和更复杂的验证任务，特别是对现代 SoC（System on Chip）和复杂的数字设计进行验证时非常有用。

VCS-MX 在 VCS 基础上增加了一些关键的特性，具体包括：

1. 高效的仿真性能：VCS-MX 提供更高效的仿真速度，尤其是对大规模设计的支持。通过优化仿真引擎，能够加快仿真过程，适用于复杂和大型设计。
2. 多核和分布式仿真：VCS-MX 支持多核处理器和分布式仿真，能够充分利用硬件资源，分配仿真任务到多个计算节点，从而提高仿真效率和速度。
3. 高级调试功能：与 VCS 相比，VCS-MX 提供了更多的高级调试功能，比如更多的仿真日志、断点控制、波形查看和分析等，这对于调试复杂的设计和验证过程非常重要。
4. 大规模并行仿真：支持多线程和并行仿真，这使得 VCS-MX 在处理复杂的验证任务时能够更高效，特别适用于大规模的 SoC 设计验证。
5. 支持高级验证语言：VCS-MX 支持一些高级验证语言和技术，比如 UVM (Universal Verification Methodology)，这使得它在进行系统级验证时具有更高的灵活性和可扩展性。
6. 集成环境支持：VCS-MX 通常与其他 Synopsys 工具链（如 Design Compiler、PrimeTime 等）紧密集成，提供一个端到端的验证和设计流程。

VCS 和 VCS-MX 的区别

1. 性能提升：VCS-MX 在性能上对比 VCS 提供了显著提升，尤其是在大规模设计和仿真时，能够更快地执行仿真任务。
2. 并行仿真支持：VCS-MX 强调并行仿真和分布式仿真功能，允许在多个处理器和计算节点上运行仿真，从而大幅度提高仿真速度。
3. 额外的验证功能：VCS-MX 在验证支持上提供了额外的增强功能，如更好的波形查看、更复杂的调试工具、以及对高级验证技术（如 UVM）的优化支持。
4. 资源利用效率：VCS-MX 通过对硬件资源的高效利用，使得它能够处理更复杂的设计，特别是当设计的规模超过了传统 VCS 的能力时。

VCS-MX 是 Synopsys 提供的高性能仿真工具，其本身是一个硬件仿真引擎，广泛用于验证数字电路设计，特别是 Verilog 和 SystemVerilog 语言的设计。然而，对于现代复杂系统的验证，仅仅仿真硬件是不够的，往往需要 与软件 进行 协同仿真，以验证硬件和软件的交互行为。因此，VCS-MX 提供了强大的 Co-simulation 支持，使得硬件和软件的联合仿真变得更加高效和便捷。

具体来说，VCS-MX 支持以下几种常见的协同仿真方式：

1.硬件-软件协同仿真（Hardware-Software Co-Simulation）

VCS-MX 可以与 软件仿真环境（如 GDB、Xilinx SDK、QEMU 等）联合工作，进行硬件和软件的协同仿真。通常在这种仿真中，硬件模型（如 CPU、外设、总线等）使用 VCS-MX 仿真，而软件代码（如固件、操作系统、驱动程序等）则在软件仿真环境中运行。

典型流程：

• 在硬件仿真中，VCS-MX 执行硬件设计的仿真，模拟硬件的行为（如数据路径、控制单元等）。
• 同时，软件（例如嵌入式程序、操作系统或驱动程序）在一个独立的软件仿真环境中运行，仿真软件与硬件通过接口进行交互。
• VCS-MX 与软件仿真环境通过仿真接口（如 Verilog-RTL 与 C/C++ 仿真接口）进行协同工作。数据可以通过仿真接口在硬件和软件之间传递，确保仿真过程中两者的正确交互。

这种协同仿真非常适合验证 SoC 设计，因为现代的 SoC 包括了复杂的硬件组件（CPU、GPU、外设等）和运行在上面的软件（操作系统、固件等），需要确保硬件与软件的互操作性和正确性。

2. 基于模型的协同仿真（Model-Based Co-Simulation）

除了硬件和软件的协同仿真外，VCS-MX 还可以与其他验证工具进行模型级的协同仿真。例如，VCS-MX 可以与 系统级建模工具（如 MATLAB/Simulink）进行协同仿真，这对于验证嵌入式系统中硬件和控制软件的交互至关重要。

在这种类型的协同仿真中，系统的高层模型（如 MATLAB/Simulink 中的控制算法或系统模型）与硬件 RTL 模型（由 VCS-MX 进行仿真）结合，能够更好地验证系统级行为。例如，在汽车、航空航天和其他嵌入式系统中，硬件与算法的交互必须一起验证，以确保系统的功能。

3. 支持的 Co-simulation 接口

VCS-MX 提供了多种接口，帮助实现硬件和软件或其他仿真工具的协同仿真：

• C/C++ 接口：VCS-MX 允许通过 C/C++ 接口与外部软件仿真工具进行交互。这样可以将硬件仿真和软件仿真部分连接起来，保证两者可以共同工作。
• Verilog 与 C/C++ 混合仿真：通过将 Verilog 模块与 C/C++ 代码进行结合，VCS-MX 支持硬件与软件的混合仿真。C/C++ 代码可以模拟嵌入式软件、固件或驱动程序，同时与硬件进行交互。
• HDL-to-Software 连接：VCS-MX 还支持通过 Transaction-Level Modeling (TLM) 或其他协议与高层软件模型进行交互。这样可以将硬件和软件模型结合在一起，进行系统级的验证。

4. 分布式协同仿真

VCS-MX 支持 分布式仿真，即将仿真任务分配到多个计算节点上运行，以提高仿真效率。分布式协同仿真可以将硬件仿真和软件仿真任务分配到不同的计算机或集群上，同时仿真并通过网络进行通信和同步。这对于非常复杂或规模庞大的系统非常有用，可以显著提高仿真速度。

ModelSim

ModelSim是西门子[ 1 ] （之前由Mentor Graphics开发， [ 2 ] ）开发的多语言环境，用于仿真VHDL 、 Verilog和SystemC等硬件描述语言，并包含一个内置的 C 调试器。 [ 3 ] [ 2 ] ModelSim 可以独立使用，也可以与Intel Quartus Prime 、 PSIM 、 [ 4 ] Xilinx ISE或Xilinx Vivado结合使用。 [ 5 ]使用图形用户界面(GUI) 或使用脚本自动执行模拟。

Mentor HDL 仿真产品提供多个版本，例如 ModelSim PE 和 Questa Sim。

Questa Sim 提供高性能和先进的调试功能，而 ModelSim PE 是面向爱好者和学生的入门级模拟器。 [ 2 ] Questa Sim 用于大型数百万门设计，并支持Microsoft Windows和 Linux、32 位和 64 位架构。 [ 2 ]

ModelSim 还可以与MATLAB / Simulink一起使用，使用ModelSim 的 Link 。 [ 7 ] [ 8 ] Link for ModelSim是 Simulink 和 ModelSim 之间的快速双向协同仿真接口。 [ 8 ] [ 7 ]对于此类设计，MATLAB 提供了数值仿真工具集，而 ModelSim 提供了用于验证设计的硬件实现和时序特性的工具。

支持语言

ModelSim使用统一的内核对所有支持的语言进行仿真，调试嵌入式C代码的方法与VHDL或Verilog相同。 [ 2 ]

ModelSim 和 Questa Sim 产品支持以下语言的仿真、验证和调试：

• VHDL
• Verilog
• Verilog 2001
• SystemVerilog
• PSL
• SystemC

建模

TLM

事务级建模 (TLM) 是一种使用电子设计自动化软件对复杂数字系统进行建模的方法。它通常使用 C++ 语言和 SystemC 库作为事务级建模语言 (TLML)，通过函数调用来定义一系列事务和通道，从而描述系统的行为。
TLM 的主要优点

• 抽象性高：TLM 忽略了底层实现细节，例如时钟信号和管脚连接，只关注数据通信和功能行为。这使得模型更加简洁易懂，也大大提高了仿真速度。
• 可扩展性好：TLM 模型可以方便地进行扩展和修改，以适应更复杂的设计需求。
• 可重用性强：TLM 模型可以重复用于不同的设计项目，降低开发成本。

TLM 的常见应用场景：

• 系统架构探索：评估不同架构方案的可行性和性能。
• 性能分析：分析系统瓶颈并优化性能。
• 构建虚拟平台：为软件开发提供运行环境。
• 功能验证：验证系统功能的正确性。

ESL建模

电子数字硬件设计已从门级低级抽象发展到寄存器传输级 (RTL)，RTL 之上的抽象级别通常称为高级。高级验证 (HLV) 或电子系统级 (ESL) 验证，是在高抽象级别验证 ESL 设计的任务，即验证表示高于寄存器传输级 (RTL) 抽象级别的硬件的模型的任务，专注于更高抽象级别的关注点。

电子系统级 (ESL) 设计包括硬件/软件交互和更高层次的抽象来解决系统级任务。

ESL 方法已从用于架构探索和“概念验证”的算法建模发展为一套完整的互补技术，涵盖嵌入式系统设计、系统级功能测试平台开发和验证、硬件/软件协同验证以及 ASIC 和 FPGA 设计的高级综合。

为了跟踪设计规模和复杂性，设计人员现在正在寻找设计生产力、实施和验证方面的下一个突破。他们希望在 ESL 工具中找到答案。为了使 ESL 工具成功渗透到行业，供应商需要探索正确的方法和与当前设计流程共存的方法。有效的 ESL 设计既需要功能验证，也需要能够快速将设计功能从概念转移到最佳实施。

另一个挑战是让供应商就基本定义达成一致。目前，有三种 ESL 方法需要关注：算法、处理器/内存和控制逻辑。这些方法进一步细分为基于平台和架构的设计类。

此外，ESL 工具肯定会包含一些内容。首先，至少会涉及一些硬件和软件方面的参考。ESL 还涉及围绕设计中更高层次的抽象的讨论，而不仅仅是更高层次的抽象语言语法。其次，需要解决系统级任务。

HW/SW 空间

ESL 的演变影响硬件和软件空间（下图 1）。在硬件空间中，我们看到逐渐向更高的设计抽象级别迈进。

设计捕获曾经使用多边形，但在电子硬件设计的早期阶段，它转向使用原理图。随后，设计师接触到了集成的原理图捕获和仿真工具。大多数设计都使用 HDL。有趣的是，许多设计师也在使用图形工具进行调试和分析。

设计可视化仍然是设计过程的关键部分，特别是在描述功能时。因此，人们在一定程度上依赖图形来理解更高的复杂性。这实际上提高了设计抽象的价值。

在软件流程中，我们见证了从位和字节级机器代码和汇编语言到编译语言的转变。最新的趋势是面向对象语言，它已广泛应用于软件实现。面向对象编程 (OOP) 技术相对于过程编程技术的主要优势之一是，它使程序员能够创建在添加新类型对象时不需要更改的模块。程序员可以简单地创建一个从现有对象继承其许多功能的新对象。

这种 OOP 方法还用于 SystemVerilog 语言，用于构建用于验证系统级设计的复杂测试台。因此，通过支持断言、功能覆盖和改进的约束随机测试生成，具有显著的验证优势。设计范式的这些变化导致了 HW/SW 开发领域的质量更高、重用性更强。

ESL 设计流程

ESL 最适合设计实施和功能验证。引入了称为事务级建模 (TLM) 的概念。TLM 通常支持更高抽象级别的设计，因此需要更少的实施细节，并实现更快的系统组装、更改和验证。

这些事务级模型可以来自 IP 提供商，或者用户可以自己为特定于设计的功能创建它们。能够以快速抽象的方式描述 SoC 是提供功能验证虚拟原型的关键。

在常见的 HW/SW 系统验证中，可以为硬件生成来自软件的真实刺激。使用这种方法进行更彻底的功能测试有助于减少在流程后期（通常是关键后期）发现的错误。拥有系统的工作模型为软件开发与硬件实现并行进行提供了基础。

另一种模型来源（使用 C 或 C++ 开发特定处理算法）是使用算法综合来生成用于系统级组装和分析的 TLM 和用于实现的 RTL 模型。由于开发的系统可以在相同的硬件和软件环境中可视化，因此 ESL 可以在硬件和软件之间实现重要的架构设计约束交换。

对于每个抽象级别，一些语言已经成为首选语言，它们最有效地满足需求，帮助构建整个系统流程（下图 2）。虽然这些首选语言可能不是满足需求的唯一方法，但它们往往具有更好的能力来辅助流程。

C/C++ 及其变体（如 SystemC）为系统级和 TLM 设计提供了最佳功能，但也可以与其他语言一起用于流程中。

将设计中的活动和流量视为事务的概念已经使用了很多年。然而，这一概念最近才被接受用于定义 SoC 设计中的接口和标准。

定义的事务枚举每个数据操作的开始、持续时间、结束和内容，而不是试图解释一堆混乱的事件和边缘。

最近的开放系统 C 计划 (OSCI) TLM 标准为构建强大的系统块模型奠定了基础，这些模型可以轻松互连、执行和分析，而无需不必要地限制行为或实现选择。

为了更全面地了解系统设计，可以使用统一建模语言 (UML) 来建模最高级别的行为。这些模型可以执行和改进，以帮助推动其余的流程。UML 越来越受欢迎，因为它可以支持创新的 ESL 方法，将架构、设计和验证领域绑定在一个统一的视角中。

ESL 类别具体包括基于平台的设计、事务级建模、基于 C 的仿真、硬件/软件协同验证、性能优化和基于 C 的综合。

有了多种解决方案可供选择，设计人员可以根据自己的需求构建 ESL 环境。Mentor Graphics 提供 ESL 解决方案，包括用于设计、建模、性能分析和验证的 Perspecta。

通过 ESL 实现新的系统级设计方法的目标是在设计流程中实现直接效益。尽早验证系统功能行为有助于减少迭代 — 在此级别上进行更快的仿真使人们有机会探索设计架构中的替代方案，找到更好的选择并锻炼更多的设计。所取得的成果将有助于将生产率提高 10-100 倍，并支持未来 10-15 年的设计，从而弥合硬件和软件开发之间的鸿沟。

主要应用领域：

• 性能/架构模型(CA/AT)：架构探索，评估与优化，架构设计阶段
• 功能模型(TL)：软件提前开发，软硬件并行开发，缩短研发周期
• 功耗模型：功耗评估
• 系统设计(System Level Design)：软硬件协同设计、验证与划分
• Co-simulation(Model+RTL)混合仿真：包括功能和性能仿真
• 高阶综合(HLS)：使用工具将C++/SystemC+TLM2.0模型直接综合成RTL代码

example：

开源

• SystemC+TLM2.0
• QEMU
• GEM5

商用

• FastModel, arm
• VDK, Synopsys
• Simics, Wind River/Intel

SystemC

SystemC解决了对跨越硬件和软件的系统设计和验证语言的需求。它是一种内置于标准C++中的语言，通过使用类库扩展语言。该语言特别适合于模型系统的分区，评估和验证块的分配到硬件或软件实现，并架构和测量功能块之间的交互。知识产权（IP）、电子设计自动化（EDA）、半导体、电子系统和嵌入式软件行业的领先公司目前使用SystemC进行架构探索，以提供各种抽象级别的高性能硬件模块，并开发用于硬件/软件协同设计的虚拟平台。SystemC已被开放式SystemC计划（OSCI）和Accellera系统计划标准化，并被批准为IEEE Std 1666™-2023。

https://systemc.org/resources/standards/

设计工具必须在架构和实现（RT和物理）级别上提供数量级的生产力改进。此外，工具必须支持一种方法，使嵌入式应用程序和系统软件的早期开发，早在RTL设计或硅原型的可用性。如果不能实现设计生产力的必要提高，将导致错过市场窗口，并导致设计成本激增。

SystemC是一种单一的、统一的设计和验证语言，以开源C++类的形式表达架构和其他系统级属性。它支持系统级的设计和验证，独立于任何详细的硬件和软件实现，并支持与RTL设计的协同验证。与更详细的RT级别相比，这种更高级别的抽象支持更快、更高效的架构权衡分析、设计和重新设计。此外，系统架构和其他系统级属性的验证比引脚精确、时序精确的RT级快几个数量级。

SystemC事务级建模（TLM）

事务级建模标准定义了SystemC的接口，为公司内部和整个IP供应链的模型交换提供了一个基本框架，用于架构分析、软件开发和性能分析以及硬件验证。它明确地解决了虚拟原型，其中SystemC模型可以在系统中轻松交换和排列，从而实现模型的最佳重用和跨不同用例的建模工作。

SystemC模拟/混合信号（AMS）

IEEE Std 1666.1-2016中定义的SystemC AMS标准介绍了嵌入式模拟/混合信号（AMS）系统的系统级设计和建模。SystemC AMS提供了独特的功能，用于在更高的设计抽象级别上设计和建模嵌入式模拟/混合信号应用。SystemC AMS扩展定义了一种统一和标准化的建模方法，可与面向数字的ESL设计方法结合使用，支持嵌入式模拟/混合信号系统的功能建模、架构探索和虚拟原型设计的优化方法。

SystemC配置、控制和检查（CCI）

配置、控制和检测（CCI）的目标是提高模型创建者和工具提供商的效率和投资回报率。CCI标准将允许供应商对模型进行仪表化，从而实现丰富的用户体验，并且它们将允许行业工具利用这种仪表化来提供强大的调试和分析功能。CCI工作组发布了CCI 1.0参考实现，以支持SystemC模型和工具之间的模型配置。

SystemC综合子集标准

SystemC合成子集标准定义了C++和SystemC中的语法元素，这些语法元素适用于SystemC模型，这些模型旨在作为高级合成（HLS）工具的输入。可综合子集的当前版本基于ISO/IEC 14882：2003和IEEE Std 1666-2011，SystemC综合工作组现在正在考虑合并由于向C++17和IEEE Std 1666-2023演进而产生的更改和增强。

SystemC验证（UVM-SystemC，SCV）

UVM-SystemC库提供了SystemC中通用验证方法（UVM）的实现。UVM-SystemC类库支持为系统级验证和测试开发可扩展和可重用的验证辅助材料。

SystemC Verification（SCV）库提供了一组通用的API，用作SystemC验证活动的基础（在约束条件下生成值，事务记录等）。这些API在市场上所有主要的SystemC模拟器中实现。

RTL

在数字电路设计中，寄存器传输级 (RTL) 是一种设计抽象，它根据硬件寄存器之间的数字信号（数据）流和对这些信号执行的逻辑运算来对同步数字电路进行建模。寄存器传输级抽象用于硬件描述语言 (HDL)，如 Verilog 和 VHDL，以创建电路的高级表示，可以从中派生出较低级别的表示，最终可以派生出实际的布线。在现代数字设计中，RTL 级设计是典型做法。

与软件编译器设计不同，其中寄存器传输级是中间表示，并且在最低级别，RTL 级是电路设计人员操作的常用输入。事实上，在电路综合中，有时会使用输入寄存器传输级表示和目标网络表之间的中间语言。与网络表不同，可以使用诸如单元、函数和多位寄存器之类的构造。示例包括 FIRRTL 和 RTLIL。

RTL模型是功能模型，不包含有关如何在硅中实现该功能的详细信息。由于这种抽象，复杂的数字功能可以比在详细的门级更快速、更简洁地建模。RTL模型的仿真速度也大大快于门级和开关级模型，这使得验证更大、更复杂的设计成为可能。

其他建模方法

1. 行为级建模 (Behavioral Modeling)

行为级建模关注系统的功能行为，通常使用 C/C++ 或 SystemC 等语言来描述系统的算法和控制流程。行为级模型可以快速实现并用于早期验证，但其精度和仿真速度相对较低。

2. 结构级建模 (Structural Modeling)

结构级建模关注系统的结构和组成，通常使用 Verilog 或 VHDL 等硬件描述语言 (HDL) 来描述系统的各个模块及其连接关系。结构级模型可以提供更高的精度，但其开发和维护成本较高。

3. 门级建模 (Gate-Level Modeling)

门级建模关注系统的电路实现细节，通常使用 HDL 来描述系统的各个门电路及其连接关系。门级模型可以提供最高的精度，但其开发和维护成本也非常高。

4. 寄存器传输级建模 (Register Transfer Level, RTL)

RTL 建模介于结构级建模和门级建模之间，它使用 HDL 来描述系统的寄存器、数据通路和控制逻辑。RTL 模型在精度、开发成本和仿真速度之间取得了较好的平衡，因此是目前最常用的建模方法之一。

资料

刚接触芯片仿真，建模的朋友，可以参考以下资料，建议以编号为1，2，3为主，其它为辅，熟悉之后，还可以接触一下开源仿真框架，比如gem5,qemu等，还有商业仿真框架ESL, VDK, Simics等，这些框架底层都是以C++/SystemC为基础，万变不离其宗，但是像VDK，Simics两款商业仿真框架，在systemc的基础上，某些仿真做了增加，比如多核并行仿真(将功能不相关的模型push到多个物理核上)以提升性能，如果不是这样谁又会买他们的license呢？当然还可以看一些学术论文，比如建模方法学，并行建模等。对于学习过程需要使用的demo，建议以官方安装目录下的example为主。

由于收藏的朋友比较多，同时发现很多资源有遗漏，今天再次更新，供大家参考之用。

SystemC 是一种用于建模和仿真的硬件描述语言 (HDL)。它是一种基于 C++ 的语言，旨在提高系统级设计的效率。SystemC 可用于对各种系统进行建模，包括处理器、存储器、外围设备和通信网络。

以下是一些依赖 systemC 的库：

• SystemVerilog：SystemVerilog 是一种用于验证和调试电子设计的硬件描述语言 (HDL)。它是一种基于 Verilog 的语言，旨在提高验证效率。SystemVerilog 可用于对各种设计进行验证，包括处理器、存储器、外围设备和通信网络。

  

• Verilog：Verilog 是一种用于建模和仿真的硬件描述语言 (HDL)。它是一种基于 C 的语言，旨在提高数字系统设计的效率。Verilog 可用于对各种系统进行建模，包括处理器、存储器、外围设备和通信网络。

  

• VHDL：VHDL 是一种用于建模和仿真的硬件描述语言 (HDL)。它是一种基于 IEEE 标准的语言，旨在提高数字系统设计的效率。VHDL 可用于对各种系统进行建模，包括处理器、存储器、外围设备和通信网络。

  

• C++：C++ 是一种通用的、编译的、面向对象的编程语言。它旨在提高效率和灵活性。C++ 可用于开发各种应用程序，包括系统软件、应用程序软件和游戏。

  

• Python：Python 是一种通用的、高级的、解释性的编程语言。它旨在提高可读性和生产力。Python 可用于开发各种应用程序，包括 Web 开发、数据科学和机器学习。

  

• SystemC AMS：SystemC AMS 是一种用于建模和仿真的模拟/混合信号硬件描述语言 (HDL)。它是一种基于 SystemC 的语言，旨在提高模拟/混合信号系统设计的效率。SystemC AMS 可用于对各种系统进行建模，包括处理器、存储器、外围设备和通信网络。

  

• SystemC TLM：SystemC TLM 是一种用于建模和仿真交易级建模 (TLM) 的硬件描述语言 (HDL)。它是一种基于 SystemC 的语言，旨在提高系统级设计的效率。SystemC TLM 可用于对各种系统进行建模，包括处理器、存储器、外围设备和通信网络。

  

• SystemC QEMU：SystemC QEMU 是一种用于在 QEMU 模拟器上运行 SystemC 模型的工具。它允许在不使用硬件的情况下测试和调试 SystemC 模型。

  

方法学的对比

各种软件工程方法的适用范围不尽相同，目前使用得最广泛的软件工程方法是传统方法学和面向对象方法学。

（1）传统方法学

软件工程传统方法学也称为结构化方法，采用结构化技术，包括结构化分析，结构化设计和结构化程序设计，来完成软件开发任务。

软件工程传统方法学通常会使用的工具有：E-R图（实体-联系图Entity Relationship Diagram），数据流图（Data Flow Diagram,DFD）,状态转换图，IPO图，数据字典（Data Dictonary ,DD），结构化语言，判定表，判定树等。

软件工程传统方法学把软件开发分成偌干个阶段，顺序完成各阶段的任务，每个阶段的开始和结束都有严格的标准；每个阶段结束时要进行严格的技术审查和管理

结构化的核心思想是‘自顶向下，逐步分解’，特别适合数据处理领域的问题（例如会计行业）。但由于使用了整体静态的分析方法，并不能很好的应对变化，不适合解决大规模的，特别复杂的项目。

核心建模方法：数据流图，自顶向下的建模方法，在软件工程传统方法学中此建模方法既是需求分析技术，也是完成需求规格化的技术手段。

（2）面向对象方法学

面向对象方法学的重要流派有Grady Booch的Booch方法，James Rumbaugh的OMT（Object Modeling Technique）和Ivar Jacobson的OOSE（Object-oriented software engineering）等。现代的面向对象方法学通常采用业务建模，用例技术，OOA(面向对象分析),OOD（面向对象设计）,OOP（面向对象程序设计）来完成软件开发任务。

面向对象方法学通常使用的工具有：uml（序列图，类图，对象图，用例图，状态图，活动图，组件图等），面向对象开发语言等。

面向对象的核心思想是一切皆对象。用对象描述整个世界，对象的结构（属性+方法），对象之间的关系（继承，关联，组合，聚合，依赖）和对象状态的封装（使用对象的方法改变对象的属性）构成了整个模型。面向对象模型的建立所需要的知识与我们平常的对真实世界的认知很接近，这使得我们建立模型的成本大大降低。由于创建软件模型的知识和人对现实世界的认知高度吻合，使得软件模型能跟随现实世界的变化而变化，从而使软件有较好的稳定性和应对变化的能力。这也是隐隐暗示着我们：软件的精髓在于描述，而不是创造。

核心建模方法：

业务建模（组织建模）：分析与愿景（Vision）相关的业务流程，寻找可用软件改善之处，常用工具 ：序列图，活动图,类图（领域模型）。

需求建模：汇聚需改善的要求形成待开发系统的需求，也就是系统的外在表现。常用工具：用例图，用例规约。

分析建模：为支撑系统的外在表现，用对象的方式描述系统内部结构和运行机理。常用工具：类图（分析模型），序列图，状态图。

设计建模：将分析建模得到模型映射到某具体的技术平台上。此阶段产生的模型按层次和抽象程度可分为：架构模型（系统结构），详细设计模型（用设计模式改善过的类图，某类数据库的表结构），程序设计模型（代码）。

面向对象方法学适应多种开发模型（软件生命周期，软件过程模型），由于UML创始人(Grady Booch、James Rumbaugh和Ivar Jacobson)的原因RUP（Rational Unified Process，统一软件开发过程）成了面向对象方法学目前最常用的开发模型。

（3）传统方法学与面向对象方法学的联系与比较

传统方法学与面向对象方法学的联系：

面向对象方法学脱胎于传统方法学，虽然目前面向对象方法学已经成为了主流，传统方法学开始势微。但面向对象方法学是在汲取了传统方法学的精髓发展而来的，俩者实际上有着很多相同，相通之处。

a。为了描述领域概念，面向对象方法学用的是类图，软件工程传统方法学有E-R图，如果是面向对象用的是贫血模型（entity（实体类）没有业务逻辑方法），那就几乎和E-R图一模一样了。

b。在面向对象方法中为了详细的描述少数的核心类的状态变化和封装的业务逻辑，我们通常会为这些核心类建立状态机图。状态机图就是软件工程传统方法学的状态转换图发展而来的.传统方法学的状态转换图是针对的整个系统的状态图，它是表明了系统的外在表现，这就跟需求规格说明书差不多的用途了。只不过如果系统稍微复杂一些，状态转换图就很难被建立起来。所以在实际开发中很少能看到状态转换图的，却能看到为描述少数的核心类的状态变化的状态机图。

c。用例技术是面向对象方法学的需求获取和描述的利器。但在James Rumbaugh的OMT方法中的描述需求时用的是功能模型，还在用传统方法学的数据流图。直到Ivar Jacobson的OOSE方法中在OMT的基础上，发明了用例，创建了需求模型（注重系统对外提供的价值），取代了使用数据流图进行需求分析和建立功能模型。就算现在的用例规约（用例的文本形式），也保留功能的一些特点，例如：依然有输入输出的选项，依然有主路径（成功路径，主要流程），异常路径（支线流程）等。

传统方法学与面向对象方法学的比较：

这两种方法学都可以创建出优秀的软件，但众多影响软件开发的因素中，经济因素往往占主导地位，也可以说软件开发是经济学。而软件开发的成本通常成为首先要考虑的问题。

a.软件工程传统方法学是面向过程的，面向过程用的是尼古拉斯·沃斯 提出那个著名的等式：程序 = 算法 +数据结构。但是数据结构是计算机存储、组织数据的方式，也就是说软件工程传统方法学用的是面向计算机的思想。而软件要处理的问题大都不计算机领域的问题，其他领域的问题要转换到计算机领域来解决，在这两者之间往往存在着巨大差距，这就导致了软件工程传统方法学制作软件成本高昂。而面向对象的思想与我们的日常认知很接近，可以复用我们平常的知识，这会让我们制作软件会容易得多，大大降低了成本。

b。面向对象的基本构成是对象，对象的构成是 属性+影响属性的方法，从某种角度也可以看成是对象是算法 +数据结构的结合体，这个粒度要比面向过程的单个过程和分散的数据要大，同样功能需求的软件用面向对象技术分析要比面向过程技术分析要更容易。因为分解的粒度大就会导致要分析的东西会变少。人在同一时间只能同时关注7+2个事物，需要关注的事物少会有助于大脑对事件的把握，降低了脑负荷，这也相当于降低了开发成本。

Simualtor

概述

在计算中，仿真器是使一个计算机系统（称为主机）能够像另一个计算机系统（称为来宾）一样运行的硬件或软件。仿真器通常使主机系统能够运行软件或使用为客户系统设计的外围设备。仿真是指电子设备中的计算机程序模拟（或模仿）另一个程序或设备 的能力。

https://en.wikipedia.org/wiki/List_of_emulators Emulator software

https://en.wikipedia.org/wiki/Category:Simulation_software Simulation software

• ARM Fastsim 指令集模拟器和 ARM IP 系统模型集。
• Gem5 一个开源的全系统和 ISA 模拟器和框架。
• OVPsim 一个全系统仿真框架，可免费用于非商业用途，并附带 100 多个运行 Linux、Android 和许多其他操作系统的开源模型和平台。
• Qemu 开源程序，可以像 Simics 一样进行全系统模拟，包括使用硬件虚拟化来加速 X86 或 X86 的执行。
• SPIM MIPS 处理器模拟器，设计用于运行 R2000、R3000 等。
• Instruction set simulator

模拟和仿真(Simulation and emulation)-哪个术语是正确的？

这个模型可以在一定的精度和细节程度上模拟设备。然而，我们通常只讨论模拟外部系统的行为，这是程序代码可用的。代码并不关心任何特定的CPU指令在内部是如何实现的；主要的是它能工作。这种模拟的版本很常见，开发起来很容易，而且相当快；即使是普通的PC用户站也具有足够的计算能力进行无故障的实施。

然而，如果我们需要知道一个程序在真实硬件上运行多久，这种模拟就不够了。这样的任务不仅需要建模外部行为，还需要复制内部结构和业务逻辑。这也可以做到各种程度的细节和精度。更正确的是称这样的模型为emulator，因为它们真的是在模拟设备，而不仅仅是模拟设备操作的结果。

创建一个emulator由于模型应该实现的功能更多，所以更复杂。模拟器在模拟外部行为方面比模拟器慢得多；使用模拟器启动Windows将需要几年的时间。因此，没有人从事创建整个平台的软件模拟器；这将非常昂贵和耗时。相反，只有系统或平台的特定组成部分，如CPU被模拟，只有一部分的模拟过程在其上启动。当模拟器的一部分是高级模型，一部分是低级模型，一部分在可编程门阵列（FPGA）中，一部分通常是真实设备时，可能的混合方案各不相同。

四个模拟层次

Application Binary Interface (ABI) 应用程序二进制接口

具体的应用程序二进制接口（ABI）实现可能是最高的抽象级别。本质上，ABI为两个程序（通常是用户程序和库或操作系统）的交互指定了一个二进制接口。ABI涵盖了调用约定（如何传递参数和返回值）、数据类型大小和系统调用。它是如何工作的？例如，在基于Linux的程序中创建附加应用程序线程时，将调用pthread_create（）函数。但是，如果我们在Windows中创建一个具有这样一个函数的库，并实现必要的机制来动态链接应用程序和库（动态链接），会怎么样呢？这将允许用户在Windows中运行Linux应用程序，这意味着Windows将“模拟”Linux。这正是Windows 10中用于Linux的Windows子系统所做的，这允许用户在Windows上运行未经修改的二进制Linux应用程序。很酷吧？

Instruction Set Architecture (ISA) 指令集体系结构

最常见的选择是在CPU指令级进行模拟，即所谓的指令集架构（ISA）。换句话说，我们讨论的是模拟执行指令的结果，而不模拟在真实的处理器中如何发生的所有内部逻辑，也不跟踪各种指令的执行时间。这类模拟器也被称为功能模拟器--著名的VirtualBox、Vmware Workstation、Wind River Simics、KVM和QEMU平台。这些都允许开发人员运行为模拟设备设计的应用程序，而不需要重新编译或对正在运行的程序进行任何其他操作。换句话说，可以运行未经修改的二进制代码。

Microarchitecture 微架构

较低级别和更详细的仿真级别包括CPU微体系结构级别，其中模拟真实的内部算法和处理器块，例如指令解码器、队列、分支预测器、高速缓存、缓存器和计算设备本身。这样的建模允许对真实的程序执行时间和性能进行剖析，以及针对所需架构对其进行优化。此外，在模拟未来微处理器原型的情况下，可以预测和评估这些设备的性能。

trace-driven simulation

追踪驱动模拟从文件中读取固定序列的追踪记录作为输入。这些追踪记录通常代表内存引用、分支结果、或特定机器指令等。虽然追踪驱动模拟被认为相对较快，其结果高度可复制，但它也需要非常大的存储空间。另一方面，执行驱动模拟读取程序，并模拟机器指令的即时执行。程序文件通常比追踪文件小几个数量级。然而，执行驱动模拟比追踪驱动模拟慢得多，因为它必须逐条处理每个指令，并更新所有涉及的微架构组件的状态。因此，模拟的输入类型选择是空间和时间之间的权衡。特别是，需要非常大的存储空间来进行高精度模拟的详细追踪，而非常精确的执行驱动模拟需要很长时间来执行程序中的所有指令。

除了输入类型，细节级别也可以用来分类模拟。特别是，模拟微处理器在循环-by-循环基础上执行程序的软件被称为周期精确模拟器，而指令集模拟器只通过指令调度器的视角模拟微处理器上程序的执行，同时粗略地计算指令执行的时间。大多数提供实践经验的计算机架构计算机科学课程采用指令集模拟器作为教学工具，而周期精确模拟器主要用于研究项目，因为它们既复杂又消耗资源。
例子：

• Shade (trace-driven, instruction set simulator)

  Shade  （跟踪驱动，指令集模拟器）

• SimpleScalar (execution-driven, cycle-accurate simulator)

  SimpleScalar   （执行驱动、周期精确模拟器）

• SPIM (execution-driven, instruction set simulator)

  SPIM  （执行驱动，指令集模拟器）

• SMTSIM (execution-driven, cycle-accurate simulator)

  SMTSIM  （执行驱动、周期精确模拟器）

Full-system Simulation 全系统仿真

任何设备（例如网卡）都可以建模为独立设备，以研究其工作流程并开发固件或驱动程序。但是，将此设备与平台基础设施的其余部分分开使用没有多大意义，因为需要额外的工作来准备输入数据和转换输出。您不能简单地运行相应的设备驱动程序，因为它需要CPU，内存，总线和硬件方面的许多其他设备以及软件方面的操作系统，网络堆栈和应用程序。可能还需要单独的数据包生成器和服务器来接收回复。

全系统模拟器提供了一个运行完整的未经修改的软件堆栈的环境，包括从BIOS和引导程序到OS及其子系统（例如，网络堆栈，驱动程序，用户级应用程序）的所有内容。全系统模拟器包括CPU、存储器、磁盘驱动器、输入输出设备、显示器和网络设备等计算机设备。

作为示例，下面显示了Intel x58芯片组的框图。要开发此芯片组的全平台计算机模拟器，应实现列出的大多数设备，包括IOH（输入/输出集线器）和ICH（输入/输出控制器集线器）内部的设备，这些设备未在框图中详细显示。

全系统模拟器通常是在CPU指令级别（ISA - 指令集架构，参见我之前的文章）实现的。这使得用户可以相对快速且经济地创建一个模拟器，而不是在创建过于详细的所有设备模型上浪费时间，如果在微结构或逻辑门级别实现的话。

ISA级别也很好，因为它相对保持不变，不像例如API / ABI级别，它更经常变化。此外，指令级别的实现允许运行未修改的二进制软件。换句话说，你可以直接从硬盘上进行转储，将其指定为全系统模拟器中模型的图像，然后瞧——操作系统和其他程序在模拟器中启动并运行，无需任何额外的努力。

Simulators’ Performance 模拟器性能

正如我前面提到的，使用所有设备对整个系统进行仿真是一个相当耗时的过程。因此，在细节一级的执行将非常缓慢。相反，指令级允许操作系统和程序以足够舒适和流畅的用户体验的速度运行。

模拟器的性能以IPS（每秒指令数）来衡量，更准确地说是MIPS（百万IPS），即模拟器每秒执行的处理器指令数。同时，仿真速度还取决于仿真运行所在主机的性能。因此，“减速”一词通常用来指与真实的主机性能相比的模拟器速度。

目前市场上的全系统模拟器速度非常快，以至于用户可能甚至没有注意到他们正在模拟器中工作。现代CPU中提供的虚拟化支持以及所谓的二进制翻译算法大大提高了仿真性能。因此，模拟只比真实的系统慢5-10倍，而且它经常以相同的速度工作。然而，许多因素影响模拟速度。例如，如果我们想模拟一个有几十个CPU的系统，那么整体速度将立即下降几十倍。类似的情况在Simics中得到了解决，Simics的最新版本支持多处理器主机硬件，并有效地将模拟的内核并行化到真实的处理器的内核。

微体系结构仿真通常比真实的系统慢大约1000-10000倍。逻辑元素级别的实现甚至更慢。这就是为什么FPGA经常在这个级别上用作仿真器，这可以显着提高性能。

Cycle-accurate Simulation循环精确模拟

尽管执行速度很低，微架构模拟器还是很常见的。事实上，为了准确地模拟每条指令的执行时间，有必要对CPU内部块进行建模。

您可能想知道为什么不能简单地将每条指令的执行时间直接放入模型程序代码（或程序员所说的“硬核”）中。原因是这样的模拟器将不能准确地工作，因为同一指令的执行时间可能从一个执行到另一个不同。

最简单的例子是内存读取指令。如果所请求的存储单元（其值）在该高速缓存中可用，则执行时间将是最小的。如果该高速缓存没有它（所谓的高速缓存未命中事件），则指令的执行时间会急剧增加。因此，需要一个高速缓存模型进行精确的模拟。然而，缓存模型并不是影响速度的唯一因素。如果数据不在该高速缓存中，则处理器不会停止，并且它继续执行以下指令，选择不依赖于从存储器的该阅读的结果的指令。这就是所谓的乱序执行（OOO），并且有必要最小化处理器空闲时间。正确计算指令执行时间需要考虑所有这些因素，并对所有这些CPU块进行详细建模。

在相关的说明中，在所描述的OOO执行期间，可能发生条件跳转。如果条件的结果目前未知，CPU不会停止执行，而是做出“假设”，并继续预防性地执行从跳转点开始的指令，就好像跳转已经发生一样。这样的块称为分支预测器，也必须在微体系结构模拟器中实现。

下图显示了主要的CPU模块，并演示了微架构实现的复杂性。

在真实的CPU中，所有这些块都与特殊的时钟信号同步。模型中使用了相同的方法。这就是为什么这样的微架构模拟器被称为周期精确的。它们的主要目的是准确预测当前正在设计和建造的未来CPU的性能，并正确测量在此CPU上运行的程序的执行时间，例如，一些CPU基准测试。如果对于新CPU，基准值低于必要值，则需要重新设计CPU算法和块。

周期精确仿真非常慢，并且它仅用于调查程序执行的特定部分，其中有必要测量真实的执行速度并评估正在为其建模的原型的设备的未来性能。函数模拟器用于模拟程序执行的其余部分。这种联合功能和周期精确模拟是如何工作的？

首先，在功能模拟器上引导操作系统和运行目标程序的所有先决条件。无论是操作系统本身，还是运行程序的初始阶段及其配置，对于评估性能都没有多大意义。然而，从技术上讲，我们不能跳过这些步骤，直接跳到有趣的地方，所以初步的步骤必须在功能模拟器上运行。在那之后，有两个选择。第一个选项是用周期精确的模型替换模型并继续执行。使用可执行代码（即未修改的编译二进制程序文件）时的仿真模型称为执行驱动仿真。这是最常见的模拟，用于功能和周期精确模拟器。第二种是跟踪驱动的模拟。

Trace-driven Simulation 跟踪驱动仿真

这种类型的模拟包括两个步骤。使用功能模拟器或真实的系统（其他方法也是可能的：例如，使用编译器），程序动作日志被收集并写入文件。此日志称为跟踪。根据所调查的内容，跟踪可能包括可执行指令、内存地址、端口号或中断信息。

下一步是所谓的跟踪回放，当周期精确模拟器读取跟踪并从那里一个接一个地执行所有操作和指令时。因此，可以计算执行时间并获得其他有趣的信息，例如缓存命中百分比。

值得一提的是，跟踪执行是确定性的，即相同的动作序列可以根据需要重复多次。通过更改模型的参数（该高速缓存、缓冲区和队列的大小）并使用各种内部算法或对其进行微调，可以研究特定参数如何影响整体系统性能，以及哪个参数集可提供最佳结果。所有这些都可以在创建硬件原型之前使用设备的虚拟模型原型来完成。

这种方法相当困难，因为它需要预先运行应用程序来收集跟踪，而且跟踪文件非常大。然而，它仍然非常常见，特别是因为它只模拟设备或平台的一部分就足够了，而执行驱动的模拟通常需要完整的模型。

Emulation of logic components 逻辑元件仿真

最低级别的仿真是模拟现代芯片所用的逻辑组件的级别。这种仿真器是软件或硬件（基于FPGA）。FPGA逻辑使用Verilog、VHDL等中的寄存器传输级（RTL）来描述。编译产生图像（比特流），然后将其闪存到FPGA器件中。这不需要烙铁或电气工程硕士学位。FPGA板通过USB或JTAG接口连接到PC，FPGA板制造商的特殊软件执行记录。这种电路板的成本从最简单的10美元到主要芯片制造公司使用的机柜大小的大型FPGA的数百万美元。在这些公司，FPGA仿真是将RTL投入生产之前的最后一步。

如果我们谈论的是简单的设备，那么手头上有FPGA图像意味着您可以联系专业公司，然后他们将根据FPGA比特流制作具有编程逻辑的真实的（非FPGA）设备。