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

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

Info

Publication number
CN115185718A
CN115185718A CN202211117078.2A CN202211117078A CN115185718A CN 115185718 A CN115185718 A CN 115185718A CN 202211117078 A CN202211117078 A CN 202211117078A CN 115185718 A CN115185718 A CN 115185718A
Authority
CN
China
Prior art keywords
thread
systemc
data
safety container
data volume
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202211117078.2A
Other languages
English (en)
Other versions
CN115185718B (zh
Inventor
郭晨光
罗文涛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Yunshu Innovation Software Technology Co ltd
Shanghai Hejian Industrial Software Group Co Ltd
Original Assignee
Beijing Yunshu Innovation Software Technology Co ltd
Shanghai Hejian Industrial Software Group Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Yunshu Innovation Software Technology Co ltd, Shanghai Hejian Industrial Software Group Co Ltd filed Critical Beijing Yunshu Innovation Software Technology Co ltd
Priority to CN202211117078.2A priority Critical patent/CN115185718B/zh
Publication of CN115185718A publication Critical patent/CN115185718A/zh
Application granted granted Critical
Publication of CN115185718B publication Critical patent/CN115185718B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/546Message passing systems or structures, e.g. queues
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45587Isolation or security of virtual machine instances

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明涉及一种基于SystemC和C++的多线程数据传输系统,包括一个SystemC线程、N个C++线程和M个线程安全容器,C++线程为生产线程,C++线程进入唤醒状态,用于生成数据,并存储至线程安全容器中,当线程安全容器的数据量符合预设数据量需求时,C++线程进入阻塞状态;SystemC线程为消费线程,周期性获取线程安全容器中的数据量,当符合预设数据量需求时,从线程安全容器中读取数据进行处理,当读取完毕时,SystemC线程向C++线程发送唤醒指令,C++线程继续生成数据并存储至线程安全容器中。本发明能够基于多个线程实现数据并发传输,提高了虚拟平台与硬件联合仿真的传输速率。

Description

基于SystemC和C++的多线程数据传输系统
技术领域
本发明涉及芯片技术领域,尤其涉及一种基于SystemC和C++的多线程数据传输系统。
背景技术
现有技术中,针对芯片电路系统的主流建模方法是基于SystemC标准进行模型开发的。但是,由于SystemC kernel(SystemC引擎)是单线程,因此,在基于虚拟平台和硬件加速器或FPGA的联合仿真中无法实现数据并发传输,从而极大地降低了数据传输速率。此外,由于SystemC kernel单线程无法实现数据并发传输,也会导致部分数据处理无法实现,例如,在虚拟平台和硬件加速器或FPGA的联合仿真中,为了提高仿真速度通常会将读写请求混合起来生成一个混合数据包,而单线程仿真无法实现读写混合数据包的操作,则可能造成仿真过程无法正常进行。
发明内容
本发明目的在于,提供一种基于SystemC和C++的多线程数据传输系统,能够基于多个线程实现数据并发传输,提高了虚拟平台与硬件(例如FPGA、emulator等)联合仿真的传输带宽,进而提高了虚拟平台与硬件联合仿真的数据传输速率。
本发明提供了一种基于SystemC和C++的多线程数据传输系统,包括:
一个SystemC线程、N个C++线程和M个线程安全容器,0<M≤N,所述SystemC线程与每一线程安全容器连接,每一线程安全容器与至少一个对应的C++线程连接。
所述C++线程为生产线程,在仿真阶段,所述C++线程进入唤醒状态,用于生成数据,并将生成的数据存储至对应的线程安全容器中,当所述线程安全容器的数据量符合SystemC线程对应的预设数据量需求时,对应的C++线程进入阻塞状态。
所述SystemC线程为消费线程,在仿真阶段,所述SystemC线程周期性获取对应的线程安全容器中的数据量,当对应的线程安全容器中的数据量符合SystemC线程对应的预设数据量需求时,所述SystemC线程从所述线程安全容器中读取数据进行处理,当读取完毕时,所述SystemC线程向对应的C++线程发送唤醒指令,对应的C++线程继续生成数据并存储至对应的线程安全容器中。
本发明与现有技术相比具有明显的优点和有益效果。借由上述技术方案,本发明提供的一种基于SystemC和C++的多线程数据传输系统可达到相当的技术进步性及实用性,并具有产业上的广泛利用价值,其至少具有下列优点:
本发明能够基于多个线程实现数据并发传输,提高了虚拟平台与硬件联合仿真的传输带宽,进而提高了虚拟平台与硬件联合仿真的数据传输速率。
上述说明仅是本发明技术方案的概述,为了能够更清楚了解本发明的技术手段,而可依照说明书的内容予以实施,并且为了让本发明的上述和其他目的、特征和优点能够更明显易懂,以下特举较佳实施例,并配合附图,详细说明如下。
附图说明
图1为本发明实施例一提供的基于SystemC和C++的多线程数据传输系统示意图;
图2为本发明实施例SystemC线程通知C++线程阶段信息的示意图;
图3为本发明实施例二提供的基于SystemC和C++的多线程数据传输系统示意图。
具体实施方式
为更进一步阐述本发明为达成预定发明目的所采取的技术手段及功效,以下结合附图及较佳实施例,对依据本发明提出的一种基于SystemC和C++的多线程数据传输系统的具体实施方式及其功效,详细说明如后。
实施例一、
实施例一提供了一种基于SystemC和C++的多线程数据传输系统,包括:
一个SystemC线程、N个C++线程和M个线程安全容器,0<M≤N,所述SystemC线程与每一线程安全容器连接,每一线程安全容器与至少一个对应的C++线程连接。本领域技术人员可以理解的是,本发明实施例所述的连接,并非一定是通过电缆之类的物理介质连接,也可以表示一种抽象的对应关系,也可以是两者之间通过无线通信等方式进行通信等等。
需要说明的是,每一C++线程对应一个C++线程函数,SystemC线程具体可以为sc_thread、sc_method、sc_cthread。SystemC线程和C++线程函数协调配合,虚拟平台通过C++线程函数调用硬件加速器或者FPGA(Field Programmable Gate Array,现场可编程逻辑门阵列)中的API(Application Programming Interface,应用程序编程接口)函数从而配合硬件实现真正的多通道通信。需要说明的是,在仿真过程中,所述SystemC线程始终处于唤醒状态,C++线程在仿真(simulation)阶段,根据具体需求处于阻塞状态或唤醒状态。
所述SystemC线程为生产线程,在仿真阶段,用于生成数据,并将生成的数据存储至对应的线程安全容器中,在所述SystemC线程向对应的线程安全容器中存储数据的过程中,对应的C++线程处于阻塞状态,当对应的线程安全容器的数据量符合对应的C++线程的预设数据量需求时,所述SystemC线程唤醒对应的C++线程。需要说明的是,仿真前准备阶段(elaboration)和仿真阶段是现有的SystemC kernel执行程序的两个必经的阶段,且先执行仿真前准备阶段,仿真前准备阶段执行结束后,执行仿真阶段,仿真阶段执行完毕后,结束程序执行,具体细节在此不再赘述,仿真前准备阶段指的是仿真阶段开始前的准备阶段,主要实现系统中仿真模型的构造和互连。
所述C++线程为消费线程,在仿真阶段,用于在对应的线程安全容器的数据量符合C++线程的预设数据量需求时,被SystemC线程唤醒,从所述对应的线程安全容器中读取数据进行处理。
当所有SystemC线程结束后SystemC仿真停止,通知所有C++线程结束进程。
图1示出了一个SystemC线程和一个C++线程实现实施例一的组成的系统结构,可以理解的是,根据C++线程、线程安全容器数量和连接关系的不同,可以基于图1做出适应性调整,不再一一列出。
需要说明的是,现有的SystemC kernel原来只有SystemC的单线程,只能模拟硬件的并发状态,而不能实现软件的并发,数据的产生在CPU上是有执行顺序的,软件上仍然是单线程。如果虚拟平台需要向硬件发送请求,为了提高数据传输速率,需要把多个request拼成一个数据包,多个request可能包括读请求,也包括写请求,全部发给FPGA,如果是SystemC单线程,需要采用SystemC单线程去调FPGA,此时必须把所有的包都处理完,一次回复回来。但是,由于数据包中既包括读请求又包括写请求,会造成SystemC单线程处于阻塞状态。本发明所述系统中除了SystemC线程,至少还包括一个C++线程,基于多个线程实现数据并发传输,提高了虚拟平台与硬件联合仿真的传输带宽,进而提高了传输速率。
作为一种实施例,所述SystemC线程和C++线程之间进行数据交互,实现资源共享与同步时,SystemC线程和C++线程之间的交互需要符合以下约束规则:所述SystemC线程中不能调用C++线程的wait函数,例如condition_variable.wait函数。所述C++线程不能调用SystemC sc_event的notify函数和SystemC的wait函数。如果不满足上述约束,则会出现线程死锁,仿真程序则无法正常进行。
需要说明的是,SystemC kernel需要将仿真的开始和结束通知C++线程,从而保证C++线程在仿真前准备阶段和仿真阶段合理访问SystemC的资源。当SystemC kernel结束仿真时,也要通知C++线程结束进程,从而结束程序的运行,作为一种实施例,如图2所示,当仿真前准备阶段开始时,所述SystemC线程向所述C++线程发送仿真前准备阶段开始指令,所述C++线程处于阻塞状态;当仿真阶段开始时,所述SystemC线程向所述C++线程发送仿真阶段开始指令,当所述C++线程收到所述SystemC线程的唤醒指令时,进入唤醒状态;当仿真停止时,所述SystemC线程向所述C++线程发送结束仿真指令,所述C++线程结束。需要说明的是,在仿真前准备阶段可以构建对应的C++线程,完成后,在进入仿真阶段之前,C++线程需要处于阻塞状态,也即这个过程中,C++线程不可以从对应的线程安全容器中读取数据,若此时C++线程在仿真前准备阶段从对应的线程安全容器中读取数据,则有可能会产生数据错误,因此,C++线程需要明确获知SystemC kernel对应的处理阶段。
作为一种实施例,所述线程安全容器包括线程锁,具体的,可以将一个预设的线程锁封装到容器中,得到线程安全容器。所述线程锁用于在所述SystemC线程向对应的线程安全容器中存储数据的过程中,控制对应的C++线程不能从所述线程安全容器中获取数据,在所述C++线程从对应的线程安全容器中获取数据的过程中,控制所述SystemC线程不能向对应的线程安全容器中存储数据。
作为一种实施例,所述C++线程用于向所述SystemC线程发送对应的C++线程的预设数据量需求信息,需要说明的是对应的C++线程的预设数据量需求信息指的是对应的C++线程每次需要从对应的线程安全容器中读取的数据量。所述SystemC线程用于在所述线程安全容器中存储的数据量达到对应的C++线程的预设数据量需求信息时,向对应的C++线程发送唤醒指令,所述SystemC线程暂停向对应的线程安全容器中存储数据,对应的C++线程从对应的线程安全容器中读取数据,当读取完毕时,所述SystemC线程继续向对应的线程安全容器中存储数据。
作为另一种实施例,所述SystemC线程在对应的线程安全容器中存储数据过程中,当对应的线程安全容器中的数据量发生变化时,则唤醒对应的C++线程,对应的C++线程判断对应的线程安全容器中当前数据量是否符合对应的C++线程的预设数据量需求,若符合,则从对应的线程安全容器中读取数据,所述SystemC线程暂停向所述对应的线程安全容器中存储数据,若不符合,则对应的C++线程重新进入阻塞状态。
作为一种实施例,所述线程安全容器以队列(queue)、向量(vector)、映射(key-value形式)或链表(list)等存储结构存储数据,具体结构基于所述系统的具体组成结构来确定。
实施方式一、
N=M,每一C++线程对应一个线程安全容器,所述SystemC线程定向向每一线程安全容器发送对应的数据,也即每一C++线程对应一个独立的线程安全容器,根据具体应用场景,配置所述SystemC线程定向向每一线程安全容器发送数据。例如,每一C++线程需要获取的数据均不相同,那么每一线程安全容器中存储的数据也均不相同。再如,在某些场景下,部分数据需要广播给多个C++线程,则此时可以向对应的多个C++线程所对应的多个线程安全容器发送广播数据。此种实施方式下,线程安全容器的存储结构存储数据可以为队列、向量、映射、链表等容器中的任意一种。
实施方式二、
M < N,所述线程安全容器对应一个或多个C++线程,当所述线程安全容器对应多个C++线程时,所述多个C++线程共享一个线程安全容器,需要说明的是,对于多个C++线程共享一个线程安全容器的情况,线程安全容器的存储结构存储数据能够区分数据来源于哪个C++线程,若M=1,则所有的C++线程共享一个线程安全容器。线程安全容器对应一个C++线程的情况下,线程安全容器的存储结构存储数据可以为队列、向量、映射、链表等容器中的任意一种。
实施例一适用于数据从SystemC线程流向C++线程,即数据流从虚拟平台流向硬件的场景,基于多个线程实现数据从SystemC线程流向C++线程的并发传输,提高了虚拟平台与硬件联合仿真的传输带宽,进而提高了传输速率。
实施例二、
实施例二提供了一种基于SystemC和C++的多线程数据传输系统,包括:
一个SystemC线程、N个C++线程和M个线程安全容器,0<M≤N,所述SystemC线程与每一线程安全容器连接,每一线程安全容器与至少一个对应的C++线程连接。
需要说明的是,每一C++线程对应一个C++线程函数,SystemC线程具体可以为sc_thread、sc_method、sc_cthread。SystemC线程和C++线程函数协调配合,虚拟平台通过C++线程函数调用硬件加速器或者FPGA中的API函数从而配合硬件实现真正的多通道通信。需要说明的是,在仿真过程中,所述SystemC线程始终处于唤醒状态,C++线程在仿真阶段,根据具体需求处于阻塞状态或唤醒状态。需要说明的是,仿真前准备和仿真阶段是现有的SystemC kernel执行程序的两个必经的阶段,且先执行仿真前准备阶段,仿真前准备阶段执行结束后,执行仿真阶段,仿真阶段执行完毕后,结束程序执行,具体细节在此不再赘述。
所述C++线程为生产线程,在仿真阶段,所述C++线程进入唤醒状态,用于生成数据,并将生成的数据存储至对应的线程安全容器中,当所述线程安全容器的数据量符合SystemC线程对应的预设数据量需求时,对应的C++线程进入阻塞状态。需要说明的是,仿真前准备和仿真阶段是现有的SystemC kernel执行程序的两个必经的阶段,且先执行仿真前准备阶段,仿真前准备阶段执行结束后,执行仿真阶段,仿真阶段执行完毕后,结束程序执行,具体细节在此不再赘述。
所述SystemC线程为消费线程,在仿真阶段,所述SystemC线程周期性获取对应的线程安全容器中的数据量,当对应的线程安全容器中的数据量符合SystemC线程对应的预设数据量需求时,所述SystemC线程从所述线程安全容器中读取数据进行处理,当读取完毕时,所述SystemC线程向对应的C++线程发送唤醒指令,对应的C++线程继续生成数据并存储至对应的线程安全容器中。
需要说明的是,所述SystemC线程基于预设硬件周期,周期性地获取对应的线程安全容器中的数据量。作为一种实施例,所述预设硬件周期为硬件时间周期或者基于SystemC线程内部机制触发预设的sc-event事件,实现所述预设硬件周期。作为一种实施例,所述C++线程中配置有对应的SystemC线程的预设数据量需求信息,
当所有C++线程结束仿真后,通知SystemC线程停止仿真,程序安全退出。
图3示出了一个SystemC线程和一个C++线程实现实施例二的组成的系统结构,可以理解的是,根据C++线程、线程安全容器数量和连接关系的不同,可以基于图3做出适应性调整,不再一一列出。
需要说明的是,现有的SystemC kernel原来只有SystemC的单线程,只能模拟硬件的并发状态,而不能实现软件的并发,数据的产生在CPU上是有执行顺序的,软件上仍然是单线程。本发明中除了SystemC线程,至少还包括一个C++线程,基于多个线程实现数据并发传输,提高了虚拟平台与硬件联合仿真的传输带宽,进而提高了传输速率。
作为一种实施例,所述SystemC线程和C++线程之间进行数据交互,实现资源共享与同步时,SystemC线程和C++线程之间的交互需要符合以下约束规则:所述SystemC线程中不能调用C++线程的wait函数,例如condition_variable.wait函数。所述C++线程不能调用SystemC sc_event的notify函数和SystemC的wait函数。如果不满足上述约束,则会出现线程死锁,仿真程序则无法正常进行。
需要说明的是,SystemC kernel需要将仿真的开始和结束通知C++线程,从而保证C++线程在仿真前准备阶段和仿真阶段合理访问SystemC的资源。作为一种实施例,当仿真前准备阶段开始时,所述SystemC线程向所述C++线程发送仿真前准备阶段开始指令,所述C++线程处于阻塞状态;当仿真阶段开始时,所述SystemC线程向所述C++线程发送仿真阶段开始指令,当所述C++线程收到所述SystemC线程的唤醒指令时,进入唤醒状态。需要说明的是,在仿真前准备阶段可以构建对应的C++线程,完成后,在进入仿真阶段之前,C++线程需要处于阻塞状态,也即这个过程中,C++线程不可以从对应的线程安全容器中读取数据,若此时C++线程在仿真前准备阶段从对应的线程安全容器中读取数据,则有可能会产生数据错误,因此,C++线程需要明确获知SystemC kernel对应的处理阶段。
作为一种实施例,所述线程安全容器包括线程锁,具体的,可以将线程安全容器封装在一个预设的线程锁中,得到线程安全容器。所述线程锁用于在对应的线程安全容器存储的数据量符合SystemC线程对应的预设数据量需求时,控制对应的C++线程不能向所述线程安全容器中存储数据;且在所述C++线程向对应的线程安全容器中存储数据的过程中,控制所述SystemC线程不能从对应的线程安全容器中读取数据。
作为一种实施例,所述SystemC线程用于向所述C++线程发送对应的预设数据量需求,当所述C++线程监测到对应的线程安全容器存储的数据量符合SystemC线程对应的预设数据量需求时,所述C++线程进入阻塞状态,不能向所述线程安全容器中存储数据。
作为一种实施例,所述线程安全容器以队列、向量、映射、链表等存储结构存储数据,具体结构基于所述系统的具体组成结构来确定。
实施方式一、
N=M,每一C++线程对应一个线程安全容器,所述SystemC线程定向向每一线程安全容器读取对应的数据,也即每一C++线程对应一个独立的线程安全容器,根据具体应用场景,配置所述SystemC线程定向向每一线程安全容器读取数据。例如,每一C++线程需要存储的数据均不相同,那么每一线程安全容器中存储的数据也均不相同。再如,在某些场景下,需要从多个C++线程中获取相同的数据,则此时可以向对应的多个C++线程所对应的多个线程安全容器存储相同的数据。此种实施方式下,线程安全容器的存储结构存储数据可以为队列、向量、映射或列表中的任意一种。
实施方式二、
M < N,所述线程安全容器对应一个或多个C++线程,当所述线程安全容器对应多个C++线程时,所述多个C++线程共享一个线程安全容器,需要说明的是,对于多个C++线程共享一个线程安全容器的情况,C++线程需要配置为映射形式的数据结构,若M=1,则所有的C++线程共享一个线程安全容器。线程安全容器对应一个C++线程的情况下,线程安全容器的存储结构存储数据可以为队列、向量、映射或链表中的任意一种。
实施例二适用于数据从C++线程流向SystemC线程,即数据流从硬件流向虚拟平台的场景,基于多个线程实现数据从C++线程流向SystemC线程的并发传输,提高了虚拟平台与硬件联合仿真的传输带宽,进而提高了传输速率。
需要说明的是,实施例一和实施例二可以组合使用,实施例一和实施例二中未提及的,在另一实施例中有详细描述的相同技术细节均可相互适用,不再重复赘述。
以上所述,仅是本发明的较佳实施例而已,并非对本发明作任何形式上的限制,虽然本发明已以较佳实施例揭露如上,然而并非用以限定本发明,任何熟悉本专业的技术人员,在不脱离本发明技术方案范围内,当可利用上述揭示的技术内容作出些许更动或修饰为等同变化的等效实施例,但凡是未脱离本发明技术方案的内容,依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化与修饰,均仍属于本发明技术方案的范围内。

Claims (8)

1.一种基于SystemC和C++的多线程数据传输系统,其特征在于,包括:
一个SystemC线程、N个C++线程和M个线程安全容器,0<M≤N,所述SystemC线程与每一线程安全容器连接,每一线程安全容器与至少一个对应的C++线程连接;
所述C++线程为生产线程,在仿真阶段,所述C++线程进入唤醒状态,用于生成数据,并将生成的数据存储至对应的线程安全容器中,当所述线程安全容器的数据量符合SystemC线程对应的预设数据量需求时,对应的C++线程进入阻塞状态;
所述SystemC线程为消费线程,在仿真阶段,所述SystemC线程周期性获取对应的线程安全容器中的数据量,当对应的线程安全容器中的数据量符合SystemC线程对应的预设数据量需求时,所述SystemC线程从所述线程安全容器中读取数据进行处理,当读取完毕时,所述SystemC线程向对应的C++线程发送唤醒指令,对应的C++线程继续生成数据并存储至对应的线程安全容器中。
2.根据权利要求1所述的系统,其特征在于,
所述SystemC线程基于预设硬件周期,周期性地获取对应的线程安全容器中的数据量。
3.根据权利要求2所述的系统,其特征在于,
所述预设硬件周期为硬件时间周期或者基于SystemC线程内部机制触发预设的sc-event事件,实现所述预设硬件周期。
4.根据权利要求1所述的系统,其特征在于,
所述C++线程中配置有对应的SystemC线程的预设数据量需求信息。
5.根据权利要求1所述的系统,其特征在于,
在仿真过程中,所述SystemC线程始终处于唤醒状态。
6.根据权利要求1所述的系统,其特征在于,
所述线程安全容器包括线程锁,所述线程锁用于在对应的线程安全容器存储的数据量符合SystemC线程对应的预设数据量需求时,控制对应的C++线程不能向所述线程安全容器中存储数据;且在所述C++线程向对应的线程安全容器中存储数据的过程中,控制所述SystemC线程不能从对应的线程安全容器中读取数据。
7.根据权利要求1所述的系统,其特征在于,
所述SystemC线程用于向所述C++线程发送对应的预设数据量需求,当所述C++线程监测到对应的线程安全容器存储的数据量符合SystemC线程对应的预设数据量需求时,所述C++线程进入阻塞状态,不能向所述线程安全容器中存储数据。
8.根据权利要求1所述的系统,其特征在于,
所述线程安全容器以队列、向量、映射、链表的存储结构存储数据。
CN202211117078.2A 2022-09-14 2022-09-14 基于SystemC和C++的多线程数据传输系统 Active CN115185718B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211117078.2A CN115185718B (zh) 2022-09-14 2022-09-14 基于SystemC和C++的多线程数据传输系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211117078.2A CN115185718B (zh) 2022-09-14 2022-09-14 基于SystemC和C++的多线程数据传输系统

Publications (2)

Publication Number Publication Date
CN115185718A true CN115185718A (zh) 2022-10-14
CN115185718B CN115185718B (zh) 2022-11-25

Family

ID=83524581

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211117078.2A Active CN115185718B (zh) 2022-09-14 2022-09-14 基于SystemC和C++的多线程数据传输系统

Country Status (1)

Country Link
CN (1) CN115185718B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117933155A (zh) * 2024-03-22 2024-04-26 摩尔线程智能科技(北京)有限责任公司 一种多进程联合仿真系统及方法、电子设备和存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180173825A1 (en) * 2015-06-25 2018-06-21 Commissariat A L'energie Atomique Et Aux Energies Alternatives Computer-implemented method of performing parallelized electronic-system level simulations
US20190057173A1 (en) * 2015-11-04 2019-02-21 Commissariat A L'energie Atomique Et Aux Energies Alternatives Electronic system level parallel simulation method with detection of conflicts of access to a shared memory
CN109783239A (zh) * 2019-01-25 2019-05-21 上海创景信息科技有限公司 SystemC仿真调度核的多线程优化方法、系统及介质
WO2021057643A1 (zh) * 2019-09-25 2021-04-01 华为技术有限公司 一种多线程同步方法及电子设备
US20220164507A1 (en) * 2020-11-25 2022-05-26 Commissariat A L'energie Atomique Et Aux Energies Alternatives Electronic system-level reproducible parallel simulation method implemented by way of a discrete event simulation multicore computing system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180173825A1 (en) * 2015-06-25 2018-06-21 Commissariat A L'energie Atomique Et Aux Energies Alternatives Computer-implemented method of performing parallelized electronic-system level simulations
US20190057173A1 (en) * 2015-11-04 2019-02-21 Commissariat A L'energie Atomique Et Aux Energies Alternatives Electronic system level parallel simulation method with detection of conflicts of access to a shared memory
CN109783239A (zh) * 2019-01-25 2019-05-21 上海创景信息科技有限公司 SystemC仿真调度核的多线程优化方法、系统及介质
WO2021057643A1 (zh) * 2019-09-25 2021-04-01 华为技术有限公司 一种多线程同步方法及电子设备
US20220164507A1 (en) * 2020-11-25 2022-05-26 Commissariat A L'energie Atomique Et Aux Energies Alternatives Electronic system-level reproducible parallel simulation method implemented by way of a discrete event simulation multicore computing system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
奚杰等: "利用SystemC实现多核系统的快速建模", 《微电子学与计算机》 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117933155A (zh) * 2024-03-22 2024-04-26 摩尔线程智能科技(北京)有限责任公司 一种多进程联合仿真系统及方法、电子设备和存储介质

Also Published As

Publication number Publication date
CN115185718B (zh) 2022-11-25

Similar Documents

Publication Publication Date Title
JP4489399B2 (ja) プロセッサでのデータ処理方法及びデータ処理システム
JP4334901B2 (ja) コンピュータ処理システム及びコンピュータで実行される処理方法
JP4597553B2 (ja) コンピュータ・プロセッサ及び処理装置
CN106164881B (zh) 异构计算系统中的工作窃取
JP5516398B2 (ja) マルチプロセッサシステム、マルチプロセッサシステムのos間デバイス共有方法
CN107077390B (zh) 一种任务处理方法以及网卡
CN111078436B (zh) 数据处理的方法、装置、设备及存储介质
Rossi et al. Preemption of the partial reconfiguration process to enable real-time computing with FPGAs
CN115185718B (zh) 基于SystemC和C++的多线程数据传输系统
Ahmadinia et al. Task scheduling for heterogeneous reconfigurable computers
Golchin et al. Boomerang: Real-time i/o meets legacy systems
Rehm et al. The road towards predictable automotive high-performance platforms
JP4183712B2 (ja) マルチプロセッサシステムにおいてプロセッサタスクを移動するデータ処理方法、システムおよび装置
Wang et al. CEFS: Compute-efficient flow scheduling for iterative synchronous applications
Bertogna et al. Static-priority scheduling and resource hold times
CN115357414B (zh) 基于SystemC和C++的多线程数据传输系统
CN115686758B (zh) 一种基于帧统计的VirtIO-GPU性能可控方法
Bouakaz et al. Design of safety-critical Java level 1 applications using affine abstract clocks
CN116302391A (zh) 一种多线程的任务处理方法及相关装置
CN114281529B (zh) 分布式虚拟化的客户操作系统调度优化方法、系统及终端
CN115269226A (zh) 一种基于原子消息与共享缓存的多线程多级并行通信方法
Ziccardi et al. Software-enforced interconnect arbitration for COTS multicores
Tabish Next-generation safety-critical systems using COTS based homogeneous multi-core processors and heterogeneous MPSoCS
CN114816678B (zh) 一种虚拟机调度的方法、系统、设备和存储介质
Harbour Real-time posix: an overview

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant