带有 RISC 主机和可配置微处理器的 SoC 的软硬件分区方法

文摘 2024-11-04 07:00 北京

摘要：

本文介绍了一种新的 SoC 硬件/软件分区方法。目标架构由 RISC 主机和一个或多个可配置微处理器组成。首先，对系统进行全局分区，然后才对其进行本地分区。在本地分区中，使用共同综合技术。我们已将该方法应用于 MPEG-2 解码器，并获得了良好的结果，例如通过共同综合实现了 36% 的性能提升。

1. 简介

半导体技术的最新进展促进了数百万个门在单个芯片上的集成，并导致了片上系统 (SoC) 的集成。SoC 应用的典型示例可以在多媒体领域和智能交通系统中找到。在这些应用中，通常必须并行处理大量数据。但是，除了少数特殊情况外，仅通过高性能处理器上运行的软件或硬件执行此类处理效率不高。最理想的是硬件和软件的最佳组合以及将系统划分为硬件和软件的最佳组合。

软硬件协同设计的研究已经进行了很长时间。第一种方法是知识产权 (IP) 重用方法。作为其相关技术，已经对基于 IP 构建系统所需的接口综合进行了研究 [1][2]。但是，在这种方法中，存在一个限制，即现有 IP 未涵盖的数据处理只能由软件完成。作为另一种协同设计方法，已经研究了一种直接从系统规范描述中将系统划分为硬件和软件的方法，即所谓的协同综合 [3][4][5]。在传统的协同综合中，由于目标架构由通用处理器和总线组成（有关详细信息，请参阅第 2 节），因此观察到性能下降。为了克服这些问题，人们也在研究可配置处理器 [6][7][8]、处理器生成和可重定向编译器 ([9][10][11])。这些研究的问题是如何在硬件/软件划分时避免只进行局部优化，从而实现全局优化。

本文介绍了一种新的硬件/软件划分方法，该方法使用 RISC 主机处理器和一个或多个可配置嵌入式微处理器来执行时间关键型任务。该方法旨在通过专用硬件加速器将主机上运行的软件从计算密集型任务中卸载。应用程序的主要部分在主机处理器上运行，而时间关键型数据处理部分则在基于可配置架构的一个或多个深度嵌入式异构处理器上执行。由于 SoC 通常对成本高度敏感，因此优化硅面积与设计效率具有同等重要性，可以加速 SoC 开发过程。传统的软硬件划分方法主要侧重于 EDA 方面，例如算法和设计流程改进，但这些方法不足以开发具有成本效益的 SoC。因此，我们开发了一个灵活的硬件平台，该平台基于可配置处理器架构，具有各种硬件扩展和分层总线结构[12][13][14]。已经开发了一种基于 EDA 的划分方法来支持该平台。

我们的方法由两个阶段组成，我们称之为“全局划分”和“局部划分”。虽然在局部划分阶段使用了协同综合方法，但通过使目标硬件架构可配置并改进编译器的调度，可以解决前面提到的问题。

在第 2 节中，我们更详细地解释了相关的传统研究，尤其是协同综合的研究。第 3 节讨论了所提出的划分方法及其目标架构。第 4 节描述了该方法的应用结果，第 5 节是本文的总结。

2. 协同综合相关工作

SoC 开发中，软硬件协同设计的必要性早已被指出[15]，许多项目也开发了协同设计工具。

协同设计大致可分为两种方法，面向软件的划分[4][16]和面向硬件的划分[3][5]。两者的区别在于功能规范模型是作为软件模型还是硬件模型编写的。

大多数方法都侧重于硬件/软件划分技术，以将功能规范转换为最佳系统架构。应用专有算法或方法进行最佳硬件/软件划分的研究正在进行中。旨在通过应用硬件/软件划分算法自动生成可交叉编译的软件模型和可在高级综合的硬件模型的方法称为协同综合[3][4][5]。协同综合的优点之一是几乎不需要用户干预就可以划分硬件模型和软件模型。但是，这一特性降低了设计人员的可见性，从而降低了可控性。一些协同综合方法采用分阶段方法，即在过程中定义某些阶段，以根据功能规范创建最佳系统架构，设计人员可以在其中细化功能规范 [17][18]。这种方法的优点是可以在中间阶段揭示架构限制，从而尽早识别出规范问题，否则这些问题只会在后期阶段浮出水面。

如上所述，文献中描述了许多系统开发方法。但由于固有的局限性，将这些方法应用于实际 SoC 设计仍然很困难。

一个限制是，设计过程基于具有通用处理器和总线的目标架构，该总线上分配有 ROM、RAM、硬件加速器、协处理器等。很难估计硬件单元的执行周期，因为总线由各种数据传输共享。

最好使用可在目标架构上执行的模型作为规范，因为现有规范模型的可重用性得到了提高。此外，规范模型最好是可以交叉编译的软件模型。原因是软件模型的细化将直接影响最终系统的性能。在传统的协同设计方法中，规范模型无法交叉编译，因为使用了诸如扩展 C 语言或专有语言之类的语言，因此规范模型既可以用软件模型描述，也可以用硬件模型描述。在关键条件下，对规范模型进行硬件/软件分区的评估结果与仅使用执行模型的评估结果之间的差异很大，并且很可能需要耗费时间重复分区过程。

最后，尽管 EDA 工具最近取得了显着发展，但硬件设计仍然是一项耗时的任务。这就是为什么系统模拟快速准确很重要的原因。为此，不仅必须在 RTL（协同验证）级别进行验证，而且还必须在更高级别的模型（例如基于 C 的模型）上进行验证（协同仿真）。然而，在联合仿真方法中，使用传统联合设计项目的基本模块[19][20]，所能达到的精度并不令人满意。

3. RISC Plus 可配置处理器平台方法

3.1. 自上而下的 SoC 设计方法

首先，让我们解释一下作为整个方法基础的自上而下的 SoC 设计方法。在这种自上而下的方法中，系统的硬件/软件分区分两个阶段进行：（1）全局和（2）本地。然后将分区的系统映射并实现在硬件平台上，这将在下一节中解释以获得所需的 SoC。图 1 说明了这种自上而下的设计方法的概念。以下是全局和本地分区的详细说明。

图 1. SoC 自上而下的设计流程

（1）全局分区

全局分区是根据下面描述的启发式方法手动完成的。

数字消费应用的 SoC 通常由两部分组成：（a）数据处理部分，以及（b）控制数据处理并与外部通信的应用程序部分。因此，首先将 SoC 的整个功能划分为数据处理和应用部分。

在应用部分，与外部的通信通常基于明确定义的标准进行，因此可以通过符合给定标准的优化 IP 块来实现。另一方面，应用程序本身通常是面向软件的，可以通过在处理器上运行的软件来实现。通常，数据处理部分由多个任务组成。通过将具有公共 I/O 数据的任务组合在一起，将任务划分为几个组，其中每个任务组在一个处理器上实现。此外，通常存在需要高吞吐量的任务，因此显然适合硬件加速。在识别出此类硬件任务后，可以将它们从软件模型中删除并作为硬件实现。如果做得好，该硬件可以以时间复用的方式在不同任务之间共享。

根据上述启发式方法对系统进行划分后，通过执行系统模拟来验证系统操作。对于高速模拟，最好基于高度抽象的 API 创建硬件模型。

(2) 局部划分

在全局划分之后，我们根据如下所示的贪婪启发法对每个任务进行局部划分。划分过程如图 2 所示。

首先，我们将任务描述为 C 程序（步骤 1）。然后，我们执行该程序以评估它是否达到所需的性能（步骤 2）。如果没有，我们将获取配置文件信息（步骤 3）。然后，我们更改配置文件信息指示的部分的实现，使其处理对硬件来说最重（步骤 4）。这种改变的方式将在第 3.3 节中描述。之后，我们再次执行该程序并检查它是否满足所需的性能（步骤 5）。通过重复步骤 3 到 5，直到达到所需的性能，划分就完成了。

通常，只有基于贪婪启发法的划分才有可能最终达到远离全局最优的局部最优。在我们选择的分区方法中，通过首先以全局方式对系统进行分区，可以避免此问题。

图 2. 本地分区流程

3.2 基于 RISC 主机和可配置微处理器的 SoC 平台

在本节中，我们将基于第 3.1 节中介绍的自上而下的设计方法解释 SoC 设计平台。图 3 显示了架构框图，该框图表示用于处理数字音频和视频的 SoC 的通用平台。该架构由两个主要块组成，分别对应于上一节中介绍的应用程序部分和数据处理部分，以及这两个块共享的内存。

应用程序部分由将充当主机的 RISC 处理器和外设 IP 组成。RISC 处理器所需的性能因目标 SoC 而异，因此需要根据具体情况选择合适的 RISC 处理器。例如，低端 SoC 选择了 32 位 RISC 处理器用于 DVD 播放，而 HDTV 和 PVR（个人视频录像机）SoC 选择了 64 位 RISC 处理器。同样，根据目标 SoC 的要求，从 USB1.1/2.0、IEEE1394 等中选择 I/O IP。

¡¡由于数据处理部分需要针对每个任务的高性能，因此它具有由定制处理器组成的异构架构，这些定制处理器是基于可配置处理器和硬件模块设计的。作为可配置处理器，使用 MeP（媒体嵌入式处理器）[12]。

图 4 显示了说明 MeP SoC 基本架构的框图。在该处理器中，MeP SoC 中的每个 MeP 模块都是针对特定任务定制的。MeP 模块由 MeP 核心（即处理器核心）和扩展单元组成，它允许可选指令（例如快速乘加指令）以及修改指令缓存/RAM 和数据缓存/RAM 的大小或配置。它还允许用户自己的指令或硬件引擎作为扩展单元附加到 MeP 核心。本地分区（将在 3.3 中解释）适用于 MeP 模块的定制。MeP 模块的特点是它包含一个 DMA 控制器，这使得 MeP 模块可以作为包括数据传输在内的独立功能块运行。数据处理部分的配置可以逐个模块地更改。例如，在 DVD 的 SoC 中，数据处理部分由音频解码和视频解码的 MeP 模块组成，而在 PVR 的 SoC 中，数据处理部分由音频 CODEC、视频 CODEC 和运动预测的 MeP 模块组成。

图 3 数字多媒体平台

图 4 MeP 架构

3.3. 局部分区 - 协同合成方法

现在，让我们进一步解释 3.1 中概述的局部分区。局部分区的方法有两个方面：利用用户自己的指令的添加，以及利用硬件引擎。由于前者已经在 [14] 中进行了解释，因此我们在此重点介绍后者。协同合成技术应用于后一种方法。

传统的协同合成具有第 2 节中提到的局限性。因此，我们开发了一种新的协同合成系统，其中目标架构本身得到了优化。我们为处理器的硬件扩展准备了专用总线。在联合仿真阶段，很容易估计连接到专用总线的硬件扩展的执行周期，并且我们系统的估计结果具有良好的准确性。

我们采用了面向软件的方法，并决定用 C 语言描述规范模型，因为规范模型可以按原样用作 C 程序。此外，C 编译器经过修改，使用硬件单元的延迟进行代码调度。在执行硬件单元的处理时，处理器会执行与这些处理无关的指令。

最后，我们决定从 C 程序生成基于 C 的硬件模型进行验证，以使用指令集模拟 (ISS) 在 C 级进行验证。这个基于 C 的硬件模型成为硬件架构规范，并通过我们的高级综合工具将其转换为 RTL。如果需要，这个高级综合工具还能够自动生成目标架构总线的接口和处理器模块中本地内存的直接访问接口。

通过直接访问接口和编译器的代码调度能力的结合，我们的协同设计系统可以将硬件模型和软件模型之间通信产生的开销降至最低。

从这里开始，我们来介绍我们的协同综合系统 Hegen。Hegen 是一种工具，它需要用 C 语言编写的软件模型作为输入，并根据设计人员的简单指令从软件模型的一部分（具体来说，是函数）自动生成基于 C 的硬件模型。除此之外，Hegen 还会修改软件模型并结合设备驱动程序来自动控制基于 C 的硬件模型，从而使系统设计不受人为错误的影响，并且更加高效。

如图 5 所示，Hegen 可以定位为自上而下进行系统设计的支持工具。此外，由于现有系统的规范模型可以原封不动地用作输入，因此它能够进行重新设计，将软件模型的一部分转换为硬件模型，以追求进一步提高性能。

图 5 系统结构。

我们的协同设计系统的设计流程如图 6 所示

1. 准备要应用于 MeP 的 C 程序文件

5. 通过执行 Hegen 生成 MPI（MeP 集成器）的设置文件

在此阶段，将自动生成硬件引擎模型、用于控制的设备驱动程序、用于生成编译器的设置文件以及用于生成模拟器的设置文件等。请注意，它们都不必手动编写。

Hegen 将检查为硬件模型指定的函数的参数、返回值、正在使用的全局变量及其 I/O 属性，然后将它们分配给 MeP 上的每个端口（为 I/O 映射的寄存器和内存）。将对要在 C 程序环境中使用的设备驱动程序进行编程，以便可以从分配的端口写入和读取值。此外，还将对硬件模型进行编程，以便可以通过模拟器的 API 执行其值的读写。

图 6 使用 Hegen 的设计流程

这里，我们通过一个简单的例子来解释如何使用 Hegen 修改 C 程序。准备一个名为 muladd 的函数作为示例，该函数执行乘积求和。

int muladd(int a,int b,int c){return a*b+c;}

当指定 muladd 作为转换为硬件模型的目标时，Hegen 将分析 muladd 接受 a、b 和 c 的输入并接受它们的返回值的输出。此外，如果 MeP 的控制总线地址空间在 0x2000 及之后是空闲的，则将分配地址 0x2000 来启动硬件引擎，并在 0x2001 之后分配 a、b、c 和返回值。

然后，muladd 的内容将被重写，以使用两个函数形成设备驱动程序，如下所示，其中一个是 stcb(data,address)，用于将数据写入指定地址，另一个是 ldcb(*data,address)，用于从指定地址读取数据。

首先将要用作输入的参数 (a,b,c) 加载到地址空间。

然后，启动硬件引擎。

最后，将从地址空间读取形成输出值的数据。__order 是一个宏，用于将硬件引擎的延迟传输到编译器。在本例中，硬件引擎的延迟为 14。

int muladd(int a,int b,int c){int ret;        stcb(a,0x2001); // Set the value        stcb(b,0x2002); // to the hardware engine.        stcb(c,0x2003); //
        __order (          stcb(1,0x2000), // Initiate the hardware engine.          ldcb(&ret,0x2000), // Read the results.          14); // Latency of the hardware engine
        return ret;}

在 C 程序中，可以使用名为 muladd 的函数来使用硬件引擎，该函数已被重写为设备驱动程序。由于此操作是自动执行的，因此根本不需要手动重写 C 程序。

另一方面，与此设备驱动程序相对应的硬件引擎模型是作为模拟器中定义的类的派生类生成的。当模拟器定制时，此模型会自动链接到模拟器。

4. 应用结果

在本节中，我们解释了基于第 3 节中解释的 SoC 自上而下设计方法设计的单芯片 DVD 播放器 SoC。

4.1. 单芯片 DVD SoC，“TC90600FG”

(1) DVD 播放器系统概述

TC90600FG 是一个单芯片 SoC，其上装载了 DVD 播放器系统的读取通道处理电路、数字伺服电路、控制微控制器和 MPEG2 音频/视频解码器。

图 7 是采用 TC90600FG 的 DVD 播放器系统的框图。DVD 播放器系统由头部放大器、电机驱动器、64Mbit SDRAM、8Mbit Flash ROM 和用于红外遥控接口/前面板显示的子微机组成。

(2) TC90600FG 的硬件概述

由于 TC90600FG 是作为 DVD 播放器的关键组件开发的，因此它配备了 DVD 播放器系统所需的所有功能。此外，为了满足日益增长的降低系统成本的需求，其电路规模、芯片尺寸和功耗被最小化。为了创建具有少量组件的 DVD 播放器系统，将模拟前端处理电路、用于控制的 RISC 和由可配置媒体处理器 MeP 实现的后端处理电路集成到一个芯片中。

作为控制用的 RISC 处理器，我们采用了 TX19，这是一个 32 位 RISC 处理器核心，基于符合 MIPS 标准的 RISC 微处理器 R3000A 开发，并增加了高代码效率扩展指令集 MIPS16 ASE（特定于应用程序的扩展）。

为了以最低的成本创建 DVD 播放器系统，我们采用了需要单个外部 64Mbit SDRAM 的 UMA（统一内存架构）。在外部 DRAM 中，分配了用于 MPEG2 视频解码处理的帧内存和用户区域。

TC900600FG SoC 上使用两个 MeP 模块。一个专用于音频解码处理，另一个执行除此以外的处理，例如轨道缓冲区控制、版权保护处理、子图解码处理、MPEG2 视频解码处理、OSD（屏幕显示）处理和视频缩放处理。

表1为TC90600FG的规格，表2为图像/图片处理MeP模块和音频处理MeP模块的MeP核心配置。

（3）TC90600FG软件概要

在TC90600FG中，DVD播放器SoC系统的软件采用分层结构，按降序排列以下三层。

（a）导航引擎层

（b）演示引擎层

（c）任务引擎层

软件结构与各层之间的关系如图8所示。

导航引擎层控制GUI（图形用户界面）、红外遥控接口、前面板显示、磁盘托盘和再现条件设置。该层在TX19上运行，并通过调用API（应用程序编程接口）定义的函数连接到演示引擎层。

演示引擎层控制每个任务引擎，以便根据导航引擎层的API指令执行DVD再现。该层由运行在TX19上的呈现引擎部分和运行在MeP上的另一个呈现引擎部分组成。TX19上的呈现引擎部分具有通过API处理上层向MeP上的呈现引擎部分发出的命令以及将所需的任务状态返回给上层的功能。另一方面，MeP上的呈现引擎部分具有控制向每个任务发出命令及其时间以及控制任务的功能。

任务引擎层大致可分为两个引擎：读取通道处理/伺服控制引擎和音频/视频处理引擎。读取通道处理/伺服控制引擎由专用硬件和从TX19控制该专用硬件的固件组成。音频/视频处理引擎由在（2）中解释的两个MeP上运行的固件和连接到这些MeP的专用硬件组成。音频/视频处理引擎也由多个任务引擎组成。具体来说，它们是轨道缓冲区、程序流解码器、MPEG2视频解码器、子图解码器、音频解码器等。演示引擎层和每个任务引擎之间的接口是通过内存中的通信区域执行的，该通信区域存储对每个任务的命令和每个任务的状态。

图7 DVD播放器系统框图

4.2 TC90600FG的分区结果

现在，我们展示TC90600FG的硬件/软件分区结果。

DVD播放器的功能中，光盘驱动器控制、数据处理部分控制和用户界面控制等应用部分由运行在TX19 32位RISC处理器上的软件实现。

同时，DVD播放器功能的数据处理部分，即读取通道处理、数字伺服、轨道缓冲区控制、版权保护处理、子画面解码处理、MPEG2视频解码处理、OSD（屏幕显示）处理、视频缩放处理和音频解码处理由专用硬件和两个具有不同配置的MeP模块实现。

我们将在下一节详细解释TC90600FG MeP模块的硬件/软件本地分区方法的部分应用结果。

表1. TC90600FG的规格

表2. TC90600FG中MeP模块的配置

4.3.局部分区结果

我们将这里介绍的两阶段分区方法应用于 TC90600FG 中使用的视频解码任务（以下称为 VDec）。如上一节所述，在 TC90600FG 的情况下，首先在全局分区阶段对 IDCT/IQ 等硬件进行分区。但是，全局分区后的 VDec C 程序的性能低于所需性能 10% 以上。因此，将局部分区方法应用于此程序。

VDec 模拟执行的配置文件结果表明，运动矢量和预测运动矢量（以下称为 PMV）的解码消耗了大量处理时间。因此，我们将 PMV 的实现从软件转移到专用硬件引擎。首先，我们创建了 PMV 的 C 仿真模型并确认了其操作。然后，我们使用高级综合将 C 仿真模型转换为 RTL。通过这种转换，VDec 的速度提高了 19%，并达到了所需的性能。

到目前为止，我们已经解释了在实际 SoC 设计过程中所做的工作。我们尝试通过应用协同综合技术进一步加速此 VDec。

图 8. TC90600FG 的软件架构

在此 PMV 硬件引擎和解码运动矢量的过程之间，执行了多次数据交换。这意味着可以将一些解码运动矢量的过程添加到 PMV 硬件引擎中。

图 9 C 程序的函数层次结构

因此，我们重新设计了规范模型，其中 PMV 硬件引擎的硬件模型作为软件模型的一部分被纳入其中，充分利用了基于 C 的硬件模型的特点。结果如表 3 所示。

表 3 仿真结果

如表 3 所示，在所有情况下，性能都优于仅使用软件模型的“默认”情况。此外，与仅具有 PMVEngine 作为硬件模型的传统 PMV 硬件引擎相比，性能最高提高了 36%。

5. 结论

本文介绍了基于两阶段分区的自上而下设计方法和通过协同合成进行分区的方法。我们已成功将我们的方法应用于 MPEG-2 解码器任务的开发。在局部分区方面，我们将协同合成方法应用于视频解码任务的运动补偿，并且可以观察到该任务的性能提高了 36%。

基于我们的分区方法和 C 语言的协同合成方法，可以在开发的早期阶段进行准确的性能评估，从而实现具有竞争力和有效的 SoC 设计。

关键词列表：

硬件/软件划分、可配置处理器、RISC、高级语言协同合成、SoC、多媒体、MPEG2

REFERENCES

[1]P. Chou, et al., Interface Co-Synthesis Techniques for Embededded Systems, in Proc. of ICCAD, 1995, PP.280-287
[2]K. V. Rompaey, et al., CoWare ¨C A design environment for heterogeneous hardware/software systems, in Proc. of European Design Automation Conference, 1996, PP. 252-257
[3]Rajesh K. Gupta, Co-Synthesis of Hardware and Software for Digital Embedded Systems, Kluwer Academic publishers, 1995
[4]R. Ernst, J. Henkel, T. Benner, Hardware-Software Co-Synthesis for Microcontrollers, IEEE Design & Test of Computers, Vol.10, No.4, Dec. 1993, pp.64-75.
[5]Hardware-Software Co-Design of Embedded Systems, The POLIS approach, Kluwer Academic Publishers, 1997.
[6]ARC Inc. http://www.arccores.com/
[7]R. Gonzalez, Xtensa: A Configurable and Extensible Processor, IEEE Micro, March/April 2000, pp.60-70.
[8]Y. Kondo, et al., A 4GOPS 3Way-VLIW Image Recognition Processor Based on a Configurable Media-processor, Proc. of ISSCC 2001, Feb. 2001, PP.148-149.
[9]J. Sato, M. Imai, et al, PEAS-I: A Hardware/Software Codesign System for ASIP Development, IEICE Trans. Fundamentals, E77-A(3), Mar. 1994, pp. 483-491
[10]H. Tomiyama, et al., Compiler Generator for Software Codesign, Proc. of 2nd Asia Pacific Conference on Hardware Description Languages (APCHDL'94), Oct. 1994, pp.267-270.
[11]ACE, The Cosy compiler development system : http://www.ace.nl/products/cosytech.htm
[12]T. Miyamori, A Configurable and Extensible Media Processor, Embedded Processor Forum, 2002.
[13]S. Ishiwata, et al., A Single-Chip MPEG-2 Codec Based on Customizable Media Microprocessor, Proc. CICC 2002, May 2002, pp.163-166.
[14] Mizuno et. al. "Design Methodology and System for a Configurabel Media Embedded Processor Extensible to VLIW Architecture"; ICCD Conference, 2002
[15]W. H. Wolf, Hardware-Software Co-Design of Embedded Systems, Proc. of the IEEE, Vol. 82, No.7, July 1994, pp.967-989.
[16]B. Dave, G. Lakshminarayana, and N. K. Jha, COSYN:Hardware-software cosynthesis of embedded systems, In Proc. 34th DAC, June 1997, pp. 703-708.
[17]G. F. Marchioro, J. M. Daveau, A. A. Jerraya, Transformational Partitioning for Co-Design of Multiprocessor Systems, In Proc 17th ICCAD'97, pp.508-515, 1997.
[18]L. Cai, D. D. Gajski, M. Olivarez, P. Kritziger, C/C++ Based System Design Flow Using SpecC, VCC and SystemC, CECS, UC Irvine, Technical Report CECS-TR-02-30, June 2002.
[19]R. Ernst, W. Ye, Embedded program timing analysis based on path clustering and architecture classification, In Proc. 17th ICCAD'97, pp. 598-604.
[20]S.Malik, W.Wolf, Y.S.Li, T.Yen, Performance Analysis of Embedded Systems, NATOASI, Workshop on Hardware-Software Co-Design, Tremezzo, Italy, 1995.

http://mp.weixin.qq.com/s?__biz=MzIxODAzMDA0Mg==&mid=2650946060&idx=2&sn=61a412ed0c98da224a16843c0e951b3c

软硬件协同设计 HW-SW Co-Design

欢迎后台留言，AI 客服全天在线。脱离物理硬件，开发测试和调试软件。基于虚拟原型的软硬件协同设计，提前一年实现产品上市创收，降低一半开发时间。