基于SystemC和C++的多线程数据传输系统

摘要

本发明涉及一种基于SystemC和C++的多线程数据传输系统，包括一个SystemC线程、N个C++线程和M个线程安全容器，SystemC线程与每一线程安全容器连接，每一线程安全容器与至少一个对应的C++线程连接，所述SystemC线程为生产线程，用于生成数据，并存储至线程安全容器中，在SystemC线程向线程安全容器中存储数据的过程中，C++线程处于阻塞状态，当线程安全容器的数据量符合C++线程的预设数据量需求符合预设数据量需求时，SystemC线程唤醒C++线程；C++线程为消费线程，用于在线程安全容器的数据量符合C++线程的预设数据量需求，被SystemC线程唤醒，从线程安全容器中读取数据进行处理。本发明能够基于多个线程实现数据并发传输，提高了虚拟平台与硬件联合仿真的传输速率。

权利要求

1.一种基于SystemC和C++的多线程数据传输系统，其特征在于，包括：一个SystemC线程、N个C++线程和M个线程安全容器，0

所述SystemC线程为生产线程，在simulation阶段，用于生成数据，并存储至对应的线程安全容器中，在所述SystemC线程向对应的线程安全容器中存储数据的过程中，对应的C++线程处于阻塞状态，当对应的线程安全容器的数据量符合C++线程的预设数据量需求符合对应的C++线程的预设数据量需求时，所述SystemC线程唤醒对应的C++线程；

所述C++线程为消费线程，在simulation阶段，用于在对应的线程安全容器的数据量符合C++线程的预设数据量需求，被SystemC线程唤醒，从所述线程安全容器中读取数据进行处理；

所述线程安全容器包括线程锁，将一个预设的线程锁封装到容器中，得到线程安全容器；所述线程锁用于在所述SystemC线程向对应的线程安全容器中存储数据的过程中，控制对应的C++线程不能从所述线程安全容器中获取数据，在所述C++线程从对应的线程安全容器中获取数据的过程中，控制所述SystemC线程不能向对应的线程安全容器中存储数据。

2.根据权利要求1所述的系统，其特征在于，

所述C++线程用于向所述SystemC线程发送对应的C++线程的预设数据量需求信息，所述SystemC线程用于在所述线程安全容器中存储的数据量达到对应的C++线程的预设数据量需求信息时，向对应的C++线程发送唤醒指令，所述SystemC线程暂停向对应的线程安全容器中存储数据，对应的C++线程从对应的线程安全容器中读取数据，当读取完毕时，所述SystemC线程继续向对应的线程安全容器中存储数据。

3.根据权利要求1所述的系统，其特征在于，

所述SystemC线程在对应的线程安全容器中存储数据过程中，当对应的线程安全容器中的数据量发生变化时，则唤醒对应的C++线程，对应的C++线程判断对应的线程安全容器中当前数据量是否符合对应的C++线程的预设数据量需求，若符合，则从对应的线程安全容器中读取数据，所述SystemC线程暂停向所述对应的线程安全容器中存储数据，若不符合，则对应的C++线程重新进入阻塞状态。

4.根据权利要求1所述的系统，其特征在于，

N＝M，每一C++线程对应一个线程安全容器，所述SystemC线程定向向每一线程安全容器发送对应的数据。

5.根据权利要求1所述的系统，其特征在于，

M

6.根据权利要求1所述的系统，其特征在于，

M＝1，所有的C++线程共享一个线程安全容器。

7.根据权利要求1所述的系统，其特征在于，

当elaboration阶段开始时，所述SystemC线程向所述C++线程发送elaboration阶段开始指令，所述C++线程处于阻塞状态；

当simulation阶段开始时，所述SystemC线程向所述C++线程发送simulation阶段开始指令，当所述C++线程收到所述SystemC线程的唤醒指令时，进入唤醒状态；

当仿真停止时，所述SystemC线程向所述C++线程发送结束仿真指令，所述C++线程结束。

8.根据权利要求1所述的系统，其特征在于，

所述SystemC线程和C++线程之间进行数据交互时，符合以下约束规则：所述SystemC线程中不能调用C++线程的wait函数；

所述C++线程不能调用SystemC sc_event的notify函数和SystemC的wait函数。

说明书

基于SystemC和C++的多线程数据传输系统

技术领域

[0001] 本发明涉及芯片技术领域，尤其涉及一种基于SystemC和C++的多线程数据传输系统。

背景技术

[0002] 现有技术中，针对芯片电路系统的主流建模方法是基于SystemC标准进行模型开发的。但是，由于SystemC kernel（SystemC引擎）是单线程，因此，在基于虚拟平台和硬件加速器或FPGA的联合仿真中无法实现数据并发传输，从而极大地降低了数据传输速率。此外，由于SystemC kernel单线程无法实现数据并发传输，也会导致部分数据处理无法实现，例如，在虚拟平台和硬件加速器或FPGA的联合仿真中，为了提高仿真速度通常会将读写请求混合起来生成一个混合数据包，而单线程仿真无法实现读写混合数据包的操作，则可能造成仿真过程无法正常进行。

发明内容

[0003] 本发明目的在于，提供一种基于SystemC和C++的多线程数据传输系统，能够基于多个线程实现数据并发传输，提高了虚拟平台与硬件（例如FPGA、emulator等）联合仿真的传输带宽，进而提高了虚拟平台与硬件联合仿真的数据传输速率。本发明提供了一种基于SystemC和C++的多线程数据传输系统，包括：

[0004] 一个SystemC线程、N个C++线程和M个线程安全容器，0

[0006] 所述C++线程为消费线程，在simulation阶段，用于在对应的线程安全容器的数据量符合C++线程的预设数据量需求，被SystemC线程唤醒，从所述线程安全容器中读取数据进行处理。

[0007] 本发明与现有技术相比具有明显的优点和有益效果。借由上述技术方案，本发明提供的一种基于SystemC和C++的多线程数据传输系统可达到相当的技术进步性及实用性，并具有产业上的广泛利用价值，其至少具有下列优点：

[0008] 本发明能够基于多个线程实现数据并发传输，提高了虚拟平台与硬件联合仿真的传输带宽，进而提高了虚拟平台与硬件联合仿真的数据传输速率。上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其他目的、特征和优点能够更明显易懂，以下特举较佳实施例，并配合附图,详细说明如下。

附图说明

[0009] 图1为本发明实施例一提供的基于SystemC和C++的多线程数据传输系统示意图；

[0010] 图2为本发明实施例SystemC线程通知C++线程阶段信息的示意图；

[0011] 图3为本发明实施例二提供的基于SystemC和C++的多线程数据传输系统示意图。

具体实施方式

[0012] 为更进一步阐述本发明为达成预定发明目的所采取的技术手段及功效,以下结合附图及较佳实施例，对依据本发明提出的一种基于SystemC和C++的多线程数据传输系统的具体实施方式及其功效，详细说明如后。

[0013] 实施例一、

[0014] 实施例一提供了一种基于SystemC和C++的多线程数据传输系统，包括：

[0015] 一个SystemC线程、N个C++线程和M个线程安全容器，0

[0016] 需要说明的是，每一C++线程对应一个C++线程函数，SystemC线程具体可以为sc_thread、sc_method、sc_cthread。SystemC线程和C++线程函数协调配合，虚拟平台通过C++线程函数调用硬件加速器或者FPGA（Field Programmable Gate Array，现场可编程逻辑门阵列）中的API（Application Programming Interface，应用程序编程接口）函数从而配合硬件实现真正的多通道通信。需要说明的是，在仿真过程中，所述SystemC线程始终处于唤醒状态，C++在simulation阶段，根据具体需求处于阻塞状态或唤醒状态。

[0017] 所述SystemC线程为生产线程，在simulation阶段，用于生成数据，并存储至对应的线程安全容器中，在所述SystemC线程向对应的线程安全容器中存储数据的过程中，对应的C++线程处于阻塞状态，当对应的线程安全容器的数据量符合C++线程的预设数据量需求符合对应的C++线程的预设数据量需求时，所述SystemC线程唤醒对应的C++线程。需要说明的是，elaboration（模拟）和simulation（仿真）是现有的SystemC kernel执行程序的两个必经的阶段，且先执行elaboration阶段，elaboration阶段执行结束后，执行simulation阶段，simulation阶段执行完毕后，结束程序执行，具体细节在此不再赘述。

[0018] 所述C++线程为消费线程，在simulation阶段，用于在对应的线程安全容器的数据量符合C++线程的预设数据量需求，被SystemC线程唤醒，从所述线程安全容器中读取数据进行处理。

[0019] 当所有systemc线程结束后systemc仿真停止，通知所有C++线程结束进程。

[0020] 图1示出了一个systemc线程和一个C++线程实现实施例一的组成的系统结构，可以理解的是，根据C++线程、线程安全容器数量和连接关系的不同，可以基于图1做出适应性调整，不再一一列出。

[0021] 需要说明的是，现有的SystemC kernel原来只有SystemC的单线程，只能模拟硬件的并发状态，而不能实现软件的并发，数据的产生在CPU上是有执行顺序的，软件上仍然是单线程。如果虚拟平台需要向硬件发送请求，为了提高数据传输速率，需要把多个request拼成一个数据包，多个request可能包括读请求，也包括写请求，全部发给FPGA，如果是SystemC单线程，需要采用SystemC单线程去调FPGA，此时必须把所有的包都处理完，一次回复回来。但是，由于数据包中既包括读请求又包括写请求，会造成SystemC单线程处于阻塞状态。本发明所述系统中除了SystemC线程，至少还包括一个C++线程，基于多个线程实现数据并发传输，提高了虚拟平台与硬件联合仿真的传输带宽，进而提高了传输速率。

[0022] 作为一种实施例，所述SystemC线程和C++线程之间进行数据交互，实现资源共享与同步时，SystemC线程和C++线程之间的交互需要符合以下约束规则：所述SystemC线程中不能调用C++线程的wait函数，例如condition_variable.wait函数。所述C++线程不能调用SystemC sc_event的notify函数和SystemC的wait函数。如果不满足上述约束，则会出现线程死锁，仿真程序则无法正常进行。

[0023] 需要说明的是，SystemC kernel需要将仿真的开始和结束通知C++线程，从而保证C++线程在elaboration阶段和simulation阶段合理访问SystemC的资源。当SystemC kernel结束仿真时，也要通知C++线程结束进程，从而结束程序的运行，作为一种实施例，如图2所示，当elaboration阶段开始时，所述SystemC线程向所述C++线程发送elaboration阶段开始指令，所述C++线程处于阻塞状态；当simulation阶段开始时，所述SystemC线程向所述C++线程发送simulation阶段开始指令，当所述C++线程收到所述SystemC线程的唤醒指令时，进入唤醒状态；当仿真停止时，所述SystemC线程向所述C++线程发送结束仿真指令，所述C++线程结束。需要说明的是，在elaboration阶段可以构建对应的C++线程，完成后，在进入simulation阶段之前，C++线程需要处于阻塞状态，也即这个过程中，C++线程不可以从对应的线程安全容器中读取数据，因为如果C++线程在elaboration阶段从对应的线程安全容器中读取数据，则有可能会产生数据错误，因此，C++线程需要明确获知SystemC kernel对应的处理阶段。

[0024] 作为一种实施例，所述线程安全容器包括线程锁，具体的，可以将一个预设的线程锁封装到容器中，得到线程安全容器。所述线程锁用于在所述SystemC线程向对应的线程安全容器中存储数据的过程中，控制对应的C++线程不能从所述线程安全容器中获取数据，在所述C++线程从对应的线程安全容器中获取数据的过程中，控制所述SystemC线程不能向对应的线程安全容器中存储数据。

[0025] 作为一种实施例，所述C++线程用于向所述SystemC线程发送对应的C++线程的预设数据量需求信息，需要说明的是对应的C++线程的预设数据量需求信息指的是对应的C++线程每次需要从对应的线程安全容器中读取的数据量。所述SystemC线程用于在所述线程安全容器中存储的数据量达到对应的C++线程的预设数据量需求信息时，向对应的C++线程发送唤醒指令，所述SystemC线程暂停向对应的线程安全容器中存储数据，对应的C++线程从对应的线程安全容器中读取数据，当读取完毕时，所述SystemC线程继续向对应的线程安全容器中存储数据。

[0026] 作为另一种实施例，所述SystemC线程在对应的线程安全容器中存储数据过程中，当对应的线程安全容器中的数据量发生变化时，则唤醒对应的C++线程，对应的C++线程判断对应的线程安全容器中当前数据量是否符合对应的C++线程的预设数据量需求，若符合，则从对应的线程安全容器中读取数据，所述SystemC线程暂停向所述对应的线程安全容器中存储数据，若不符合，则对应的C++线程重新进入阻塞状态。

[0027] 作为一种实施例，所述线程安全容器以queue（队列）、vector（数组）、map（key‑value形式）或list（链表）的存储结构存储数据，具体结构基于所述系统的具体组成结构来确定。

[0028] 实施方式一、

[0029] N=M，每一C++线程对应一个线程安全容器，所述SystemC线程定向向每一线程安全容器发送对应的数据，也即每一C++线程对应一个独立的线程安全容器，根据具体应用场景，配置所述SystemC线程定向向每一线程安全容器发送数据。例如，每一C++线程需要获取的数据均不相同，那么每一线程安全容器中存储的数据也均不相同。再如，在某些场景下，部分数据需要广播给多个C++线程，则此时可以向对应的多个C++线程所对应的多个线程安全容器发送广播数据。此种实施方式下，线程安全容器的存储结构存储数据可以为queue、vector、map、list等容器中的任意一种。

[0030] 实施方式二、

[0031] M < N，所述线程安全容器对应一个或多个C++线程，当所述线程安全容器对应多个C++线程时，所述多个C++线程共享一个线程安全容器，需要说明的是，对于多个C++线程共享一个线程安全容器的情况，线程安全容器的存储结构存储数据能够区分数据来源于哪个C++线程，若M=1，则所有的C++线程共享一个线程安全容器。线程安全容器对应一个C++线程的情况下，线程安全容器的存储结构存储数据可以为queue、vector、map、list等容器中的任意一种。

[0032] 实施例一适用于数据从systemc线程流向C++线程，即数据流从虚拟平台流向硬件的场景，基于多个线程实现数据从systemc线程流向C++线程的并发传输，提高了虚拟平台与硬件联合仿真的传输带宽，进而提高了传输速率。

[0033] 实施例二、

[0034] 实施例二提供了一种基于SystemC和C++的多线程数据传输系统，包括：

[0035] 一个SystemC线程、N个C++线程和M个线程安全容器，0

[0036] 需要说明的是，每一C++线程对应一个C++线程函数，SystemC线程具体可以为sc_thread、sc_method、sc_cthread。SystemC线程和C++线程函数协调配合，虚拟平台通过C++线程函数调用硬件加速器或者FPGA中的API函数从而配合硬件实现真正的多通道通信。需要说明的是，在仿真过程中，所述SystemC线程始终处于唤醒状态，C++在simulation阶段，根据具体需求处于阻塞状态或唤醒状态。需要说明的是，elaboration和simulation是现有的SystemC kernel执行程序的两个必经的阶段，且先执行elaboration阶段，elaboration阶段执行结束后，执行simulation阶段，simulation阶段执行完毕后，结束程序执行，具体细节在此不再赘述。

[0037] 所述C++线程为生产线程，在simulation阶段，所述C++线程进入唤醒状态，用于生成数据，并存储至对应的线程安全容器中，当所述线程安全容器的数据量符合SystemC线程对应的预设数据量需求时，对应的C++线程进入阻塞状态。需要说明的是，elaboration和simulation是现有的SystemC kernel执行程序的两个必经的阶段，且先执行elaboration阶段，elaboration阶段执行结束后，执行simulation阶段，simulation阶段执行完毕后，结束程序执行，具体细节在此不再赘述。

[0038] 所述SystemC线程为消费线程，在simulation阶段，所述SystemC线程周期性获取对应的线程安全容器中的数据量，当对应的线程安全容器中的数据量符合SystemC线程对应的预设数据量需求时，所述SystemC线程从所述线程安全容器中读取数据进行处理，当读取完毕时，所述SystemC线程向对应的C++线程发送唤醒指令，对应的C++线程继续生成数据并存储至对应的线程安全容器中。

[0039] 需要说明的是，所述SystemC线程基于预设的硬件周期，周期性地获取对应的线程安全容器中的数据量。作为一种实施例，所述硬件周期为硬件时间周期或者基于SystemC线程内部机制触发预设的sc‑event事件,实现所述预设的硬件周期。作为一种实施例，所述C++线程中配置有对应的C++线程的预设数据量需求信息，

[0040] 当所有C++线程结束仿真后，通知systemc线程停止仿真，程序安全退出。

[0041] 图3示出了一个systemc线程和一个C++线程实现实施例二的组成的系统结构，可以理解的是，根据C++线程、线程安全容器数量和连接关系的不同，可以基于图3做出适应性调整，不再一一列出。

[0042] 需要说明的是，现有的SystemC kernel原来只有SystemC的单线程，只能模拟硬件的并发状态，而不能实现软件的并发，数据的产生在CPU上是有执行顺序的，软件上仍然是单线程。本发明中除了SystemC线程，至少还包括一个C++线程，基于多个线程实现数据并发传输，提高了虚拟平台与硬件联合仿真的传输带宽，进而提高了传输速率。

[0043] 作为一种实施例，所述SystemC线程和C++线程之间进行数据交互，实现资源共享与同步时，SystemC线程和C++线程之间的交互需要符合以下约束规则：所述SystemC线程中不能调用C++线程的wait函数，例如condition_variable.wait函数。所述C++线程不能调用SystemC sc_event的notify函数和SystemC的wait函数。如果不满足上述约束，则会出现线程死锁，仿真程序则无法正常进行。

[0044] 需要说明的是，SystemC kernel需要将仿真的开始和结束通知C++线程，从而保证C++线程在elaboration阶段和simulation阶段合理访问SystemC的资源。作为一种实施例，当elaboration阶段开始时，所述SystemC线程向所述C++线程发送elaboration阶段开始指令，所述C++线程处于阻塞状态；当simulation阶段开始时，所述SystemC线程向所述C++线程发送simulation阶段开始指令，当所述C++线程收到所述SystemC线程的唤醒指令时，进入唤醒状态。需要说明的是，在elaboration阶段可以构建对应的C++线程，完成后，在进入simulation阶段之前，C++线程需要处于阻塞状态，也即这个过程中，C++线程不可以从对应的线程安全容器中读取数据，因为如果C++线程在elaboration阶段从对应的线程安全容器中读取数据，则有可能会产生数据错误，因此，C++线程需要明确获知SystemC kernel对应的处理阶段。

[0045] 作为一种实施例，所述线程安全容器包括线程锁，具体的，可以将线程安全容器封装在一个预设的线程锁中，得到线程安全容器。所述线程锁用于在对应的线程安全容器存储的数据符合SystemC线程对应的预设数据量需求时，控制对应的C++线程不能向所述线程安全容器中存储数据，在所述C++线程从对应的线程安全容器中存储数据的过程中，控制所述SystemC线程不能向对应的线程安全容器中读取数据。

[0046] 作为一种实施例，所述SystemC线程用于向所述C++线程发送对应的SystemC线程对应的预设数据量，当所述C++线程监测到对应的线程安全容器存储的数据符合SystemC线程对应的预设数据量需求时，所述C++线程进入阻塞状态，不能向所述线程安全容器中存储数据。

[0047] 作为一种实施例，所述线程安全容器以queue（队列）、vector（数组）、map（key‑value形式）、list（链表）等存储结构存储数据，具体结构基于所述系统的具体组成结构来确定。

[0048] 实施方式一、

[0049] N=M，每一C++线程对应一个线程安全容器，所述SystemC线程定向向每一线程安全容器读取对应的数据，也即每一C++线程对应一个独立的线程安全容器，根据具体应用场景，配置所述SystemC线程定向向每一线程安全容器读取数据。例如，每一C++线程需要存储的数据均不相同，那么每一线程安全容器中存储的数据也均不相同。再如，在某些场景下，需要从多个C++线程中获取相同的数据，则此时可以向对应的多个C++线程所对应的多个线程安全容器存储相同的数据。此种实施方式下，线程安全容器的存储结构存储数据可以为queue、vector、map或list中的任意一种。

[0050] 实施方式二、

[0051] M < N，所述线程安全容器对应一个或多个C++线程，当所述线程安全容器对应多个C++线程时，所述多个C++线程共享一个线程安全容器，需要说明的是，对于多个C++线程共享一个线程安全容器的情况，C++线程需要配置为map形式的数据结构，若M=1，则所有的C++线程共享一个线程安全容器。线程安全容器对应一个C++线程的情况下，线程安全容器的存储结构存储数据可以为queue、vector、map或list中的任意一种。

[0052] 实施例二适用于数据从C++线程流向systemc线程，即数据流从硬件流向虚拟平台的场景，基于多个线程实现数据从C++线程流向systemc线程的并发传输，提高了虚拟平台与硬件联合仿真的传输带宽，进而提高了传输速率。

[0053] 需要说明的是，实施例一和实施例二可以组合使用，实施例一和实施例二中未提及的，在另一实施例中有详细描述的相同技术细节均可相互适用，不再重复赘述。

[0054] 以上所述，仅是本发明的较佳实施例而已，并非对本发明作任何形式上的限制，虽然本发明已以较佳实施例揭露如上，然而并非用以限定本发明,任何熟悉本专业的技术人员，在不脱离本发明技术方案范围内,当可利用上述揭示的技术内容作出些许更动或修饰为等同变化的等效实施例,但凡是未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化与修饰，均仍属于本发明技术方案的范围内。