WO2024108496A1 - 一种芯片验证系统、方法、装置、设备及存储介质 - Google Patents

一种芯片验证系统、方法、装置、设备及存储介质 Download PDF

Info

Publication number
WO2024108496A1
WO2024108496A1 PCT/CN2022/134106 CN2022134106W WO2024108496A1 WO 2024108496 A1 WO2024108496 A1 WO 2024108496A1 CN 2022134106 W CN2022134106 W CN 2022134106W WO 2024108496 A1 WO2024108496 A1 WO 2024108496A1
Authority
WO
WIPO (PCT)
Prior art keywords
sub
simulation
management
file
dut
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.)
Ceased
Application number
PCT/CN2022/134106
Other languages
English (en)
French (fr)
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.)
New H3c Semiconductor Technologies Co Ltd
New H3C Semiconductor Technology Co Ltd
Original Assignee
New H3c Semiconductor Technologies Co Ltd
New H3C Semiconductor Technology 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 New H3c Semiconductor Technologies Co Ltd, New H3C Semiconductor Technology Co Ltd filed Critical New H3c Semiconductor Technologies Co Ltd
Priority to EP22966012.1A priority Critical patent/EP4425337A4/en
Priority to PCT/CN2022/134106 priority patent/WO2024108496A1/zh
Priority to CN202280004684.5A priority patent/CN118401925A/zh
Priority to US18/714,972 priority patent/US20250278543A1/en
Publication of WO2024108496A1 publication Critical patent/WO2024108496A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/33—Design verification, e.g. functional simulation or model checking
    • G06F30/3308—Design verification, e.g. functional simulation or model checking using simulation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2111/00—Details relating to CAD techniques
    • G06F2111/02—CAD in a network environment, e.g. collaborative CAD or distributed simulation

Definitions

  • the present application relates to the field of chip testing technology, and in particular to a chip verification system, method, device, equipment and storage medium.
  • the conventional idea is to use a single TB (TestBench, verification platform) to verify the chip based on the chip's DUT (Design Under Test, design to be verified) file in a simulation manner.
  • DUT Design Under Test, design to be verified
  • the purpose of the embodiments of the present application is to provide a chip verification system, method, device and storage medium to improve the chip verification efficiency.
  • the specific technical solution is as follows:
  • an embodiment of the present application provides a chip verification system, the system comprising: a management TB and a simulation TB, the simulation TB comprising a plurality of sub-TBs, each sub-TB being deployed with a different sub-DUT file of a chip's DUT file, wherein:
  • the management TB is used to control the head TB to start verification through the control channel, and the head TB is: a sub-TB in which the first sub-DUT file of the business simulation task is deployed;
  • the header TB is used to generate a simulated input signal and send the simulated input signal to the management TB through a service channel;
  • Each sub-TB is used to run the locally deployed sub-DUT file to obtain intermediate results, and send the intermediate results to other sub-TBs through the data channel;
  • the tail TB is used to obtain the simulation result for the business simulation task and send the simulation result to the management TB through the business channel.
  • the tail TB is: the sub-TB where the last sub-DUT file of the business simulation task is deployed;
  • the management TB is also used to obtain the benchmark result of the business simulation task based on the simulation input signal, and verify the chip according to the benchmark result and the simulation result.
  • an embodiment of the present application provides a chip verification method, which is applied to a management TB in a chip verification system, wherein the chip verification system further includes a simulation TB, wherein the simulation TB includes multiple sub-TBs, each of which is deployed with a different sub-DUT file of a DUT file of a chip;
  • the method comprises:
  • tail TB is a sub-TB in which the last sub-DUT file of the business simulation task is deployed;
  • a benchmark result of the business simulation task is obtained based on the simulation input signal, and the chip is verified according to the benchmark result and the simulation result.
  • an embodiment of the present application provides a chip verification method, which is applied to a sub-TB included in a simulation TB in a chip verification system, wherein the chip verification system further includes a management TB, and each sub-TB is deployed with different sub-DUT files of a DUT file of a chip;
  • the method comprises:
  • the sub-TB is a head TB
  • a simulation input signal is generated, and based on the simulation input signal, a local sub-DUT file deployed locally is run to obtain an intermediate result;
  • the simulation input signal is sent to the management TB through a service channel, and the intermediate result is sent to a downstream TB through a data channel,
  • the sub-DUT file deployed by the downstream TB is a downstream sub-DUT file of the local sub-DUT file
  • the head TB is: a sub-TB in which the first sub-DUT file of a service simulation task is deployed;
  • the sub-TB receives the intermediate result sent by the upstream TB, uses the received intermediate result as input to run the locally deployed local sub-DUT file to obtain the intermediate result, and sends the obtained intermediate result to the downstream TB through the data channel between itself and the downstream TB, wherein the sub-DUT file deployed by the upstream TB is the upstream sub-DUT file of the local sub-DUT file, and the intermediate TB is: the sub-TB other than the head TB and the tail TB;
  • the sub-TB receives the intermediate results sent by the upstream TB, runs the locally deployed local sub-DUT file with the received intermediate results as input to obtain simulation results, and sends the simulation results to the management TB through the business channel, so that the management TB verifies the chip based on the simulation input signal and the simulation results, wherein the tail TB is: the sub-TB with the last sub-DUT file of the business simulation task deployed.
  • an embodiment of the present application provides a chip verification device, which is applied to a management TB in a chip verification system, wherein the chip verification system further includes a simulation TB, wherein the simulation TB includes a plurality of sub-TBs, each of which is deployed with a different sub-DUT file of a DUT file of a chip;
  • the device comprises:
  • a control module used for controlling a head TB to start verification through a control channel, so that the head TB generates a simulation input signal, the head TB being: a sub-TB in which the first sub-DUT file of a business simulation task is deployed;
  • a business information receiving module used to receive the simulation input signal sent by the head TB through the business channel; receive the simulation result for the business simulation task fed back by the tail TB through the business channel, wherein the tail TB is: a sub-TB in which the last sub-DUT file of the business simulation task is deployed;
  • the chip verification module is used to obtain a benchmark result of the business simulation task based on the simulation input signal, and verify the chip according to the benchmark result and the simulation result.
  • an embodiment of the present application provides a chip verification device, which is applied to a sub-TB included in a simulation TB in a chip verification system, wherein the chip verification system further includes a management TB, and each sub-TB is deployed with different sub-DUT files of a DUT file of a chip;
  • the device comprises:
  • a control response module for generating a simulation input signal in response to the start verification control of the management TB if the simulation TB is a head TB, and running the locally deployed local sub-DUT file based on the simulation input signal to obtain an intermediate result, wherein the head TB is: a sub-TB in which the first sub-DUT file of the business simulation task is deployed;
  • a data transceiver module is used to send the intermediate result obtained to the downstream TB through the data channel if the simulation TB is a head TB; if the sub-TB is an intermediate TB, receive the intermediate result sent by the upstream TB, use the received intermediate result as input to run the locally deployed local sub-DUT file to obtain the intermediate result, and send the intermediate result obtained to the downstream TB through the data channel between itself and the downstream TB; if the sub-TB is a tail TB, receive the intermediate result sent by the upstream TB, use the received intermediate result as input to run the locally deployed local sub-DUT file to obtain the simulation result, wherein the tail TB is: the sub-TB with the last sub-DUT file of the business simulation task deployed, the intermediate TB is the sub-TB other than the head TB and the tail TB, the sub-DUT file deployed by the downstream TB is the downstream sub-DUT file of the local sub-DUT file, and the sub-DUT file deployed by the upstream TB is the upstream sub-
  • a service information sending module is used to send the simulation input signal to the management TB through a service channel if the simulation TB is a head TB; if the sub-TB is a tail TB, send the simulation result to the management TB through a service channel, so that the management TB verifies the chip based on the simulation input signal and the simulation result.
  • an embodiment of the present application provides a verification platform, including: a processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions that can be executed by the processor, and the processor is prompted by the machine-executable instructions to: implement the chip verification method described in the second aspect or the third aspect above.
  • an embodiment of the present application provides a computer-readable storage medium storing machine-executable instructions.
  • the machine-executable instructions When called and executed by a processor, the machine-executable instructions prompt the processor to implement the chip verification method described in the second aspect or the third aspect above.
  • an embodiment of the present application further provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to implement the chip verification method described in the second aspect or the third aspect above.
  • the head TB can generate a simulation input signal in response to the control of the management TB, and send the simulation input signal to the above-mentioned management TB through the business channel; the tail TB can obtain the simulation result for the business simulation task, and feed back the obtained simulation result to the management TB through the business channel, so that the management TB can receive the above-mentioned simulation input signal and simulation result, and then can successfully verify the chip based on the above-mentioned simulation input signal and simulation result.
  • each sub-TB is used to run the locally deployed sub-DUT file to obtain the intermediate results, and send the obtained intermediate results to other sub-TBs through the data channel. It can be seen that, on the one hand, each sub-TB can send the obtained intermediate results to other sub-TBs so that other sub-TBs can obtain new intermediate results based on the received intermediate results. On the other hand, each sub-TB can continue to run the locally deployed sub-DUT file to obtain the intermediate results. That is, in the above process, each sub-TB is executed in parallel.
  • each sub-TB can be executed in parallel and use its own computing resources to run the locally deployed sub-DUT file to work together to obtain the simulation results. This reduces the time consumption when obtaining the simulation results, improves the efficiency of obtaining the simulation results, and thus improves the efficiency of verifying the chip based on the simulation results.
  • the management TB controls the head TB to start verification through the control channel
  • the head TB and the tail TB respectively feed back the simulation input signal and the simulation result to the management TB through the service channel
  • each sub-TB sends the intermediate result to other sub-TBs through the data channel.
  • FIG1 is a schematic diagram of the structure of a first chip verification system provided in an embodiment of the present application.
  • FIG2 is a signaling interaction diagram of a first chip verification method provided in an embodiment of the present application.
  • FIG3 is a signaling interaction diagram of a second chip verification method provided in an embodiment of the present application.
  • FIG4 is a signaling interaction diagram of a third chip verification method provided in an embodiment of the present application.
  • FIG5 is a schematic diagram of the contents of a topology file provided in an embodiment of the present application.
  • FIG6 is a schematic diagram of a topology file generation interface provided in an embodiment of the present application.
  • FIG7 is a schematic diagram of the structure of a second chip verification system provided in an embodiment of the present application.
  • 8a and 8b are signaling interaction diagrams of a fourth chip verification method provided in an embodiment of the present application.
  • FIG9 is a schematic diagram of a fifth chip verification method according to an embodiment of the present application.
  • FIG10 is a schematic diagram of a sixth chip verification method according to an embodiment of the present application.
  • FIG11 is a schematic diagram of a flow chart of a seventh chip verification method provided in an embodiment of the present application.
  • FIG12 is a schematic flow chart of an eighth chip verification method provided in an embodiment of the present application.
  • FIG13 is a schematic diagram of a flow chart of a ninth chip verification method provided in an embodiment of the present application.
  • FIG14 is a schematic diagram of the structure of a first chip verification device provided in an embodiment of the present application.
  • FIG15 is a schematic diagram of the structure of a second chip verification device provided in an embodiment of the present application.
  • FIG16 is a schematic diagram of the structure of a verification platform provided in an embodiment of the present application.
  • the design file to be verified may be written in HDL (Hardware Description Language).
  • a part of the DUT file obtained by splitting the DUT file obtained by splitting the DUT file.
  • the embodiments of the present application do not limit the specific method for segmenting the DUT file to obtain the sub-DUT files.
  • the staff can segment the DUT file according to the actual situation and the sub-functions of the chip to be verified.
  • each sub-DUT file obtained by segmentation corresponds to each sub-function of the chip to be verified.
  • the task of verifying the function of the chip by TB simulation can also be called a verification case, corresponding to a verification process.
  • the business simulation task can record the information of each sub-DUT file that needs to be executed in the verification process.
  • business simulation task T1 is for the verification of sub-function 1 of the chip, then T1 records the information of sub-DUT files 1-3 related to sub-function 1;
  • business simulation task T2 is for the verification of sub-functions 2 and 3 of the chip, then T2 records the information of sub-DUT files 5-9 related to sub-functions 2 and 3, and so on.
  • the business simulation task will involve multiple sub-DUT files that need to be executed in the verification process. These sub-DUT files have a certain execution order during the verification process.
  • a sub-DUT file that is executed after a sub-DUT file in the verification process can be called a downstream sub-DUT file of the sub-DUT file.
  • a sub-DUT file that is executed before a sub-DUT file in the verification process can be called an upstream sub-DUT file of the sub-DUT file.
  • the sub-DUT file deployed by its downstream TB is the downstream sub-DUT file of the local sub-DUT file deployed by the sub-TB; similarly, the sub-DUT file deployed by its upstream TB is the upstream sub-DUT file of the local sub-DUT file deployed by the sub-TB.
  • Head TB Head TB
  • tail TB middle TB.
  • the head TB is the sub-TB where the first sub-DUT file of the business simulation task is deployed, and similarly, the tail TB is the sub-TB where the last sub-DUT file of the business simulation task is deployed.
  • the middle TB is the sub-TB other than the head TB and the tail TB.
  • the embodiments of the present application provide a chip verification system, method, apparatus, device and storage medium, which are described in detail below.
  • an embodiment of the present application provides a chip verification system, the system comprising: a management TB and a simulation TB, the simulation TB comprising a plurality of sub-TBs, each sub-TB being deployed with a different sub-DUT file of a chip's DUT file, wherein:
  • the management TB is used to control the head TB to start verification through the control channel.
  • the head TB is: a sub-TB in which the first sub-DUT file of the business simulation task is deployed;
  • the header TB is used to generate a simulated input signal and send the simulated input signal to the management TB through a service channel;
  • Each sub-TB is used to run the locally deployed sub-DUT file to obtain intermediate results, and send the intermediate results to other sub-TBs through the data channel;
  • the tail TB is used to obtain the simulation result for the business simulation task and to feed back the simulation result to the management TB through the business channel.
  • the tail TB is: the sub-TB where the last sub-DUT file of the business simulation task is deployed;
  • the management TB is also used to obtain a benchmark result of the business simulation task based on the simulation input signal, and verify the chip according to the benchmark result and the simulation result.
  • the head TB can generate a simulation input signal in response to the control of the management TB, and send the simulation input signal to the above-mentioned management TB through the business channel; the tail TB can obtain the simulation result for the business simulation task, and feed back the obtained simulation result to the management TB through the business channel, so that the management TB can receive the above-mentioned simulation input signal and simulation result, and then can successfully verify the chip based on the above-mentioned simulation input signal and simulation result.
  • each sub-TB is used to run the locally deployed sub-DUT file to obtain the intermediate results, and send the obtained intermediate results to other sub-TBs through the data channel. It can be seen that, on the one hand, each sub-TB can send the obtained intermediate results to other sub-TBs so that other sub-TBs can obtain new intermediate results based on the received intermediate results. On the other hand, each sub-TB can continue to run the locally deployed sub-DUT file to obtain the intermediate results. That is, in the above process, each sub-TB is executed in parallel.
  • each sub-TB can be executed in parallel and use its own computing resources to run the locally deployed sub-DUT file to work together to obtain the simulation results. This reduces the time consumption when obtaining the simulation results, improves the efficiency of obtaining the simulation results, and thus improves the efficiency of verifying the chip based on the simulation results.
  • the management TB controls the head TB to start verification through the control channel
  • the head TB and the tail TB respectively feed back the simulation input signal and the simulation result to the management TB through the service channel
  • each sub-TB sends the intermediate result to other sub-TBs through the data channel.
  • FIG. 1 is a structural diagram of the first chip verification system provided in an embodiment of the present application.
  • the above-mentioned chip verification system includes: management TB101 and simulation TB102, wherein the simulation TB102 includes multiple sub-TBs, and each sub-TB is deployed with different sub-DUT files of the chip's DUT file.
  • the simulation TB102 in FIG. 1 includes sub-TBs including a head TB and a tail TB, and the connection between the management TB101 and the simulation TB102 represents the communication connection established between the management TB101 and the above sub-TBs.
  • the following first describes a scenario in which chip verification is performed using the chip verification system provided by an embodiment of the present application.
  • the chip verification system includes a management TB and a simulation TB.
  • the simulation TB includes multiple sub-TBs, and each sub-TB is deployed with different sub-DUT files of the DUT file of the chip.
  • each sub-TB Before performing chip verification, the management TB and the above-mentioned sub-TBs can start working, and then each sub-TB can run its locally deployed sub-DUT file in parallel. At this time, since no simulation input signal is generated, each sub-TB will not generate an operation result for the simulation input signal until the management TB controls the head TB to start verification. After the head TB receives the control message for starting verification sent by the management TB, it starts verification and generates a simulation input signal.
  • the chip verification solution provided in the embodiment of the present application begins to execute.
  • chip verification solution provided in the embodiment of the present application is described in detail in the form of a signaling diagram below.
  • FIG. 2 which is a signaling interaction diagram of the first chip verification method provided in an embodiment of the present application, the method includes the following steps S201-S206.
  • Step S201 The management TB controls the head TB to start verification through the control channel.
  • the above-mentioned header TB is: a sub-TB in which the first sub-DUT file of the business simulation task is deployed.
  • the first sub-DUT file of the above business simulation task is: the first sub-DUT file executed during the execution of the business simulation task.
  • control channel and the service channel and data channel mentioned later are all transmission channels used to transmit data or messages.
  • the management TB controls the header TB to start verification, which can be understood as the management TB controls the header TB to generate a simulation input signal, thereby starting verification for the business simulation task, that is, starting verification of part or all functions of the chip targeted by the business simulation task.
  • the management TB may send a control message to the head TB through a control channel, thereby controlling the head TB to start verification.
  • Step S202 The header TB generates a simulated input signal.
  • the head TB can generate a simulated input signal according to the following two situations.
  • the header TB pre-stores information for generating a simulated input signal, so that after receiving a control message sent by the management TB, the header TB can generate a simulated input signal according to the above information.
  • the management TB when the management TB controls the head TB to generate a simulated input signal, it can send a message for generating the simulated input signal to the head TB, so that the head TB can generate the simulated input signal according to the received message.
  • each sub-TB is used to run the locally deployed sub-DUT file to obtain an intermediate result, and sends the obtained intermediate result to other sub-TBs through the data channel.
  • Step S203 the head TB sends a simulated input signal to the management TB through the service channel.
  • Step S204 the tail TB obtains the simulation result for the business simulation task.
  • the tail TB is a sub-TB in which the last sub-DUT file of the business simulation task is deployed.
  • the last sub-DUT file of the above business simulation task can be understood as: the last sub-DUT file executed during the execution of the business simulation task.
  • the sub-DUT file locally deployed by the tail TB does not have a downstream sub-DUT file, indicating that the sub-DUT file it deploys is the last sub-DUT file that needs to be executed in this business simulation task. Therefore, the result obtained by the tail TB running the locally deployed sub-DUT file is the simulation result for this business simulation task.
  • Step S205 the tail TB feeds back the simulation result to the management TB through the service channel.
  • Step S206 the management TB obtains a benchmark result of the business simulation task based on the simulation input signal, and verifies the chip according to the benchmark result and the simulation result.
  • the management TB can input the simulation input signal into the locally deployed reference model (Reference Model) to obtain the benchmark result of the model output.
  • the reference model is written in a high-level language and describes the functional logic of the chip.
  • the management TB can compare the simulation results with the benchmark results to see if they are consistent. If they are consistent, it is determined that the chip has passed the verification for the business simulation task; if they are inconsistent, it is determined that the chip has failed the verification for the business simulation task.
  • the head TB can generate a simulation input signal in response to the control of the management TB, and send the simulation input signal to the above-mentioned management TB through the business channel; the tail TB can obtain the simulation result for the business simulation task, and feed back the obtained simulation result to the management TB through the business channel, so that the management TB can receive the above-mentioned simulation input signal and simulation result, and then can successfully verify the chip based on the above-mentioned simulation input signal and simulation result.
  • each sub-TB is used to run the locally deployed sub-DUT file to obtain the intermediate results, and send the obtained intermediate results to other sub-TBs through the data channel. It can be seen that, on the one hand, each sub-TB can send the obtained intermediate results to other sub-TBs so that other sub-TBs can obtain new intermediate results based on the received intermediate results. On the other hand, each sub-TB can continue to run the locally deployed sub-DUT file to obtain the intermediate results. That is, in the above process, each sub-TB is executed in parallel.
  • each sub-TB can be executed in parallel and use its own computing resources to run the locally deployed sub-DUT file to work together to obtain the simulation results. This reduces the time consumption when obtaining the simulation results, improves the efficiency of obtaining the simulation results, and thus improves the efficiency of verifying the chip based on the simulation results.
  • the management TB controls the head TB to start verification through the control channel
  • the head TB and the tail TB respectively feed back the simulation input signal and the simulation result to the management TB through the service channel
  • each sub-TB sends the intermediate result to other sub-TBs through the data channel.
  • the above solution is also applicable to verification scenarios with large DUT logic scale of various chips to be verified, such as networking verification of multiple chip sets, chiplet system verification of multi-die (Die-to-Die) interconnected, and distributed joint simulation of EMU (Emulator) and EDA (electronic design assistance).
  • the management TB can also send a verification completion message to each sub-TB through the control channel between the management TB and each sub-TB; each sub-TB can respond to the verification completion message by closing the service channel between the management TB, the data channel between the adjacent sub-TBs, and the control channel between the management TB.
  • the end condition of the chip verification may be that each business simulation task has traversed all sub-DUT files and the verification of each business simulation task has passed.
  • control channels, business channels and data channels established between various types of TBs can be closed in time, so that the memory occupied by the above transmission channels can be released in time.
  • each sub-TB can send its intermediate results to other sub-TBs through a data channel according to the upstream and downstream relationships between itself and other sub-TBs.
  • the present disclosure provides a second chip verification method.
  • FIG. 3 which is a signaling interaction diagram of a second chip verification method provided in an embodiment of the present application, the method includes the following steps S301 - S308 .
  • Step S301 Management TB control head simulation TB start verification.
  • the management TB can control the head simulation TB to start verification in the following way.
  • step S201 it may be the same as the aforementioned step S201, and will not be described in detail here.
  • the management TB may store the access address of the head TB, so that the management TB may control the head TB to generate an excitation signal based on the access address.
  • the access address may be an IP address, MAC address or other address of the head TB; the method of controlling the head TB to generate an excitation signal based on the access address may be to send an instruction message to start verification to the head TB.
  • Step S302 The header TB generates a simulation input signal, and runs the locally deployed local sub-DUT file based on the simulation input signal to obtain an intermediate result.
  • the above-mentioned simulation input signal is the input signal of the head TB running the local sub-DUT file.
  • the head TB runs the local sub-DUT file
  • the local sub-DUT file is input with the above-mentioned simulation input signal, and the output result can be obtained.
  • the above-mentioned output result can be called the intermediate result for the simulation input signal.
  • the head TB runs the local sub-DUT file
  • the functional module corresponding to the local sub-DUT file in the chip is simulated.
  • the above intermediate results can be understood as the interface timing of the above functional module output for the above simulation input signal.
  • Step S303 The head TB sends a simulated input signal to the management TB.
  • the head TB may send the simulation input signal to the management TB in the following manner.
  • the head TB may send a simulated input signal to the management TB through a service channel.
  • the head TB may pre-store the access address of the management TB, so that after the simulation input signal is generated, the head TB may send the generated simulation input signal to the management TB based on the access address.
  • Step S304 The head TB sends the obtained intermediate result to the downstream TB.
  • the sub-DUT file deployed by the downstream TB is a downstream sub-DUT file of the local sub-DUT file.
  • the head TB may send the intermediate result to its own downstream TB.
  • the downstream TB of the head TB may be one or more.
  • the head TB may send the intermediate result to the downstream TB in the following manner.
  • the head TB may pre-store the access address of the downstream TB, so that after the head TB obtains the intermediate result, it may send the intermediate result to the downstream TB based on the access address.
  • the head TB may send the obtained intermediate result to the downstream simulation TB via a data channel between the head TB and the downstream simulation TB.
  • Step S305 the intermediate TB receives the intermediate result sent by the upstream TB, uses the received intermediate result as an input signal to run the locally deployed local sub-DUT file to obtain the intermediate result, and sends the obtained intermediate result to the downstream TB.
  • the above-mentioned intermediate TB is: a sub-TB except the head TB and the tail TB, and the sub-DUT file deployed by the upstream TB is an upstream sub-DUT file of the local sub-DUT file.
  • the middle TB is a sub-TB other than the head TB and the tail TB
  • the local sub-DUT file deployed locally in the middle TB has downstream sub-DUT files, indicating that there are subsequent sub-DUT files that need to be executed in this business simulation task, and this business simulation task has not yet ended, that is, the intermediate result obtained by the middle TB is not the final simulation result of this business simulation task.
  • the intermediate TB can send the intermediate results obtained by itself to the downstream TB, so that the downstream TB receives the intermediate results and inputs the received intermediate results as input signals into the local sub-DUT file it runs.
  • the intermediate TB runs the local sub-DUT file
  • the functional module corresponding to the local sub-DUT file in the chip is simulated.
  • the above intermediate results can be understood as the interface timing of the above functional module output for the above simulation input signal.
  • the intermediate TB may send the obtained intermediate result to the downstream TB in the following manner.
  • the intermediate TB may pre-store the access address of its downstream simulation TB, so that after the intermediate TB obtains the intermediate result, it may send the intermediate result to its downstream simulation TB based on the access address.
  • the intermediate TB may send the obtained intermediate result to the downstream TB via a data channel between the intermediate TB and the downstream TB.
  • Step S306 the tail TB receives the intermediate result sent by the upstream TB, and uses the received intermediate result as an input signal to run the locally deployed local sub-DUT file to obtain the simulation result.
  • the tail TB is the sub-TB where the last sub-DUT file of the business simulation task is deployed.
  • the local sub-DUT file deployed locally does not have a downstream sub-DUT file, indicating that the sub-DUT file deployed is the last sub-DUT file that needs to be executed in this business simulation task. Therefore, the result obtained by running the local sub-DUT file with the intermediate result sent by the upstream TB as the input signal is the simulation result for the business simulation task.
  • Step S307 the tail TB feeds back the simulation result to the management TB.
  • the tail TB may feed back the simulation result to the management TB in the following manner.
  • the tail TB may pre-store the access address of the management TB, so that the tail TB may feed back the obtained intermediate result as the simulation result to the management TB based on the access address.
  • the tail TB may send the simulation result to the management TB through the service channel between the tail TB and the management TB.
  • Step S308 the management TB obtains a benchmark result of the business simulation task based on the simulation input signal, and verifies the chip according to the benchmark result and the simulation result.
  • This step is the same as step S206 in the embodiment shown in FIG. 2 , and will not be described in detail here.
  • the head TB can run the locally deployed local sub-DUT file based on the simulation input signal generated by itself to obtain an intermediate result, and then send the obtained intermediate result to the downstream TB through the data channel between itself and the downstream TB.
  • the middle TB can receive the intermediate result sent by the upstream TB, and run the locally deployed local sub-DUT file with the received intermediate result as the input signal to obtain the intermediate result, and send the obtained intermediate result to the downstream TB through the data channel between itself and the downstream TB.
  • the tail TB can receive the intermediate result sent by the upstream TB, and run the locally deployed local sub-DUT file with the received intermediate result as the input signal to obtain the simulation result.
  • each sub-TB can exchange data in an orderly manner according to the upstream and downstream relationships, and finally the tail TB can obtain the simulation results accurately.
  • FIG. 4 is a signaling interaction diagram of a third chip verification method provided in an embodiment of the present application, the method includes the following steps S401 - S411 .
  • Step S401 Each sub-TB establishes a control channel with the management TB.
  • the embodiment of the present application does not limit the process of establishing a control channel between each sub-TB and the management TB.
  • the sub-TB may actively establish a control channel with the management TB, or the management TB may control the sub-TB to establish a control channel with itself.
  • the management TB can establish a control server, and each sub-TB establishes a control client. After successfully establishing the control client, a control communication connection is established with the control server, and a local control thread is started based on the control communication connection. The management TB also starts a local control thread based on the control communication connection.
  • the management TB and each sub-TB can receive or send control messages based on the local control thread, that is, the control channel between each sub-TB and the management TB is established.
  • the control message can be a verification start indication message, TB information, etc.
  • the management TB and each sub-TB have established control threads locally based on the control communication connection, so that the above-mentioned control threads can be dedicated to receiving and sending control messages between the management TB and each sub-TB. In this way, the interaction of control messages will not cause interaction confusion with other types of information, which is conducive to improving the efficiency of control message interaction between the management TB and each sub-TB.
  • the data transmitted by the control channel is in TLV (Type-Length-Value) format.
  • the Type part can use 8 bits to represent the command type identifier; the Value part represents the Payload, that is, the actual data content; the Length part can use 8 bits to represent the actual byte length of the Value part, supporting a maximum Value byte length of 256 bytes.
  • the data format transmitted by the data control channel adopts the TLV format, which can support the transmission of variable-length control messages and is conducive to enriching the message types that the data control channel can transmit.
  • Step S402 The head TB and the tail TB establish a service channel with the management TB.
  • the tail TB is: the simulation TB in which the last sub-DUT file of the business simulation task is deployed.
  • the embodiment of the present application does not limit the process of establishing a service channel between the head TB, the tail TB and the management TB.
  • the head TB and the tail TB may actively establish a service channel with the management TB, or the management TB may control the head TB and the tail TB to establish a service channel with itself.
  • the management TB can establish a business server, the head TB and the tail TB can establish a business communication connection with the business server, and start a local business thread based on the business communication connection, and the management TB also starts a local business thread based on the business communication connection.
  • the management TB and the head TB and tail TB can all receive or send service information based on the local service thread, that is, the service channel between the head TB, tail TB and the management TB is established.
  • the above service information can be a simulation input signal, a simulation result, and the like.
  • the head TB, tail TB and management TB have all established business threads locally based on the business communication connection, so that the above business threads can be dedicated to receiving and sending business information between the management TB and the head TB and tail TB.
  • the interaction of business information will not cause interaction confusion with other types of information, which is conducive to improving the efficiency of business information interaction between the management TB and the head TB and tail TB.
  • the data transmitted by the above-mentioned service channel is: a variable-length message in a dynamic array format.
  • the elements in the above dynamic array can be 8 bits in size.
  • the data sender can apply for the size of the dynamic array according to the actual length of the data to be transmitted.
  • the data receiver can obtain each variable-length message through the de-sticking packet technology at the bottom layer of the Socket.
  • variable-length message supports the transmission of variable-length data. Therefore, the data format transmitted by the service channel adopts the variable-length message format, which can support the transmission of variable-length information and is conducive to enriching the information types that can be transmitted by the service channel.
  • Step S403 establishing a data channel between adjacent sub-TBs.
  • the sub-DUT files deployed by adjacent sub-TBs have an upstream and downstream relationship.
  • the embodiment of the present application does not limit the method of establishing a data channel between adjacent sub-TBs.
  • the following introduces a method of establishing a data channel between adjacent sub-TBs by taking steps A to C as an example.
  • Step A Each sub-TB sends TB information to the management TB through the control channel between itself and the management TB.
  • the above-mentioned TB information may include information such as the TB identification and access address of the sub-TB.
  • Step B The management TB obtains the topology file, updates the topology file according to the received TB information, determines the adjacent sub-TBs based on the updated topology file, sends a control message to the adjacent sub-TB through the control channel between itself and the determined adjacent sub-TB, and synchronizes the updated topology file to each sub-TB.
  • the topology file is used to record the topological relationship between the management TB and each sub-TB, the TB information of the management TB, and the TB information of each sub-TB.
  • the topology file please refer to the embodiments shown in the subsequent Figures 5 and 6, which will not be described in detail here.
  • the management TB may update the topology file according to the received TB information by updating the TB information in the topology file to the received TB information, deleting the topological relationship of the sub-TBs for which the TB information has not been received and recorded in the topology file.
  • the management TB can determine the TB for establishing the data channel recorded in the topology file as the adjacent sub-TB, and then send a control message to the adjacent sub-TB through the control channel between itself and the determined adjacent sub-TB, and synchronize the updated topology file to each sub-TB.
  • the management TB can send a control message to one of the adjacent sub-TBs, so that the sub-TB that receives the control message can actively initiate a data channel establishment request for another sub-TB.
  • the management TB can also send a control message to both sub-TBs in the adjacent sub-TBs.
  • Step C The adjacent sub-TB responds to the control message, establishes a data communication connection with the adjacent sub-TB based on the received topology file, and starts a local data thread according to the data communication connection.
  • the adjacent sub-TB may read the sub-TBs adjacent to itself recorded in the topology file, and then establish a data communication connection with the sub-TBs, and start a local data thread according to the data communication connection.
  • the adjacent sub-TBs can receive or send data through the above data communication connection based on the local data thread, that is, the data channel between the adjacent sub-TBs is established.
  • the above data can be an intermediate result, etc.
  • the management TB can determine the adjacent sub-TBs according to the updated topology file, and then synchronize the updated topology file to each sub-TB, and instruct the adjacent sub-TBs to establish a data channel, so that the sub-TB can accurately determine the sub-TBs adjacent to itself based on the updated topology file, and establish a data channel with the sub-TB.
  • the data thread can be dedicated to receiving and sending data between adjacent sub-TBs, so that the interaction of the data does not cause interaction confusion with other types of information, which is conducive to improving the efficiency of data interaction between adjacent sub-TBs.
  • the data transmitted by the above-mentioned data channel is: data based on a signal-based SB (Signal Based) mode or a TB (Transaction Based) mode.
  • the data transmitted by the above-mentioned data channel is: the port signal value generated by running the sub-DUT file and transmitted at the clock cycle granularity.
  • This mode requires cycle-level data flow synchronization;
  • the data transmitted by the data sender is the interface data in the data format of the business channel.
  • the data receiver can parse the above-mentioned data to generate an interface timing signal. This mode requires the data receiver to parse the received data, but does not require cycle-level data flow synchronization.
  • the data in SB mode or TB mode can be selected for transmission in the data channel according to the actual situation, so that the selected transmitted data meets the characteristics of the data required to be transmitted by the data channel, thereby facilitating the improvement of the data transmission efficiency of the data channel.
  • step S402 can be executed before or after step S403, and the above two steps can also be executed in parallel.
  • Step S404 The management TB controls the head TB to start verification through the control channel.
  • Step S405 The header TB generates a simulation input signal, and runs the locally deployed local sub-DUT file based on the simulation input signal to obtain an intermediate result.
  • Step S406 the head TB sends a simulated input signal to the management TB through the service channel.
  • Step S407 the head TB sends the intermediate result to the downstream TB via the data channel between itself and the downstream TB.
  • Step S408 the intermediate TB receives the intermediate result sent by the upstream TB, runs the second sub-DUT file with the received intermediate result as the input signal to obtain the intermediate result, and sends the obtained intermediate result to the downstream TB through the data channel between itself and the downstream TB.
  • Step S409 the tail TB receives the intermediate result sent by the upstream TB, and uses the received intermediate result as an input signal to run the locally deployed local sub-DUT file to obtain the simulation result.
  • Step S410 the tail TB feeds back the simulation result to the management TB through the service channel.
  • Step S411 the management TB obtains a benchmark result of the business simulation task based on a simulation input signal, and verifies the chip according to the benchmark result and the simulation result.
  • FIG5 is a schematic diagram of the contents of a topology file provided in an embodiment of the present application.
  • the number of managed TBs is 1 and the TB ID of the managed TB is 100.
  • TB with TB marked as a is referred to as TBa hereinafter.
  • ETH_TB_LEFT 200, ETH_TB_RIGHT: 300.
  • COM_TB_DES 200_300_DRV,1,200,300,10900.
  • “1” means that the channel type is a data channel
  • "200, 300” means that TB200 is connected to TB300.
  • TB200 can create a client based on the Socket method to connect to the server created by TB300
  • "10900” means the Socket port number used when establishing the above connection.
  • the topology description statement shown in Figure 5 indicates that two data channels (channel type is 1) are established from TB200 to TB300 and from TB300 to TB200, two business channels (channel types are 2 and 3) are established from TB200 to TB100, and two business channels (channel types are 2 and 3) are established from TB00 to TB100.
  • a control channel is established between the management TB and each sub-TB. Therefore, during the execution of this solution, the management TB can establish a control channel with each sub-TB by default. That is, the management TB does not need to parse the topology file when establishing the control channel. Therefore, the above-mentioned topology file does not need to record the information used to characterize the control channel establishment relationship between the management TB and the sub-TB.
  • FIG. 6 is a schematic diagram of a topology file generation interface provided in an embodiment of the present application.
  • the staff can use the topology file generation interface shown in FIG6 to generate a topology file.
  • topology file generation interface shown in FIG6 provides the staff with two functional windows: TB definition and TB connection relationship definition. The above two functions are described below respectively.
  • the staff Used to determine the information of each sub-TB.
  • the staff can use the above function to enter the TB number (TB quantity), Simulation TB name (sub-TB name) and Simulation TB ID (sub-TB identification) of the sub-TB for which the transmission channel is to be established, and click the Add button to confirm the input.
  • the staff Used to determine the connection relationship between various types of TBs.
  • the staff can use the above function to input Connection Description, Client TB ID, Server TB ID, Socket Port, select Connection Type, and click the Add button to confirm the input.
  • the staff uses the above function to determine the TB information and the connection relationship between each type of TB, they can click the Gen (generation) button to obtain a topology file that records the TB information and the connection relationship between each type of TB.
  • Gen generation
  • the above interface will pop up a window to remind the staff that the generation is successful, as shown in Figure 6.
  • the content of the pop-up window can be "generate topo file successfully!.
  • each type of TB contains different components or modules, and these components together implement the chip verification scheme provided in the embodiment of the present application, which is explained below in conjunction with Figure 7.
  • FIG. 7 is a schematic diagram of the structure of a second chip verification system provided in an embodiment of the application.
  • the management TB mainly includes two modules: the management data socket comparison agent (master_data_socket_checker_agent) module and the socket control process (socket_control_process) module, which are introduced below.
  • EVT_SYNC component CFG_SYNC component
  • Data Pkt Rec Thread component Verification (Checker) component
  • Data Pkt Socket component Data Pkt Socket component
  • the Data Pkt Socket component is used to establish a business channel with the sub-TB using the Socket method
  • the EVT_SYNC component is used to synchronize events
  • the CFG_SYNC component is used to synchronize configuration information
  • the Data Pkt Rec Thread component is used to create and maintain threads that receive business information based on business channels, for example, receiving simulation results or simulation input signals sent by sub-TBs;
  • the Checker component is used to compare the received simulation input signal with the simulation result to determine whether the chip has passed the verification.
  • EDT_Process It includes event process (EVT_Process) component, message process (Msg Process) component, topology process (Topo Process) component and Control Socket component.
  • the Control Socket component is used to establish a control channel with the sub-TB using the Socket method
  • the EVT_Process component and the Msg Process component are used to send events and messages to the sub-TB based on the control channel, including message processing and distribution, event processing and distribution, etc.;
  • the Topo Process component is used to parse locally stored topology files.
  • the sub-TB is introduced by taking the sub-TB on the left below as an example.
  • the sub-TB includes a virtual data transfer agent (virtual_data_transfer_agent) module and various components, which are introduced below.
  • virtual_data_transfer_agent virtual data transfer agent
  • the interface timing received through the service channel is sent to ETH_DUT as the excitation signal of the DVA TX direction.
  • the DVA TX direction is a predefined direction, which means the direction from left to right in the figure.
  • the DVA RX direction is a pre-defined direction, which means the direction from right to left in the figure.
  • It includes Data Stream Drv&Rec Thread components, EVT_SYNC components, CFG_SYNC components, Data Stream SOCKET (DATA_SREAM SOCKET) components, etc.
  • the DATA_SREAM SOCKET component is used to establish a data channel with the adjacent sub-TB using the socket method
  • the EVT_SYNC component is used to synchronize events
  • the CFG_SYNC component is used to synchronize configuration information
  • the Data Stream Drv&Rec Thread component is used to create and maintain threads that receive or send data based on data channels.
  • Socket control process (socket_control_process) component.
  • It is used to realize communication between the control channel and the management TB. On the one hand, it receives the control message sent by the management TB, and on the other hand, it sends the information and events of the current sub-TB to the management TB for processing.
  • the above-mentioned information and events of the current sub-TB can be TB information, information for synchronization, etc.
  • Socket data process (socket_data_process) component.
  • It is used to send the DVA TX direction excitation signal generated by the TXIF_DRV_AGT component and the interface timing information generated in the DVA RX direction collected by the RXIF_MON_AGT component to the management TB.
  • the components represented by the rectangular boxes except the dotted rectangular box in Figure 7 can all be called DVA (Distributed Verification Acceleration) components.
  • the chip verification solution provided in the embodiment of the present application can be implemented based on the above-mentioned DVA component, which is specifically explained below by taking examples.
  • the existing technology integrates the above components into the TB used in each BT-level verification process, and can directly perform IT (Integration Testbench, subsystem verification platform) level or ST (SoC Testbench, system verification platform) level verification without rebuilding a dedicated environment for IT-level or ST-level verification. This can start IT and ST-level chip verification more quickly, improving the chip verification efficiency.
  • IT Integration Testbench, subsystem verification platform
  • ST SoC Testbench, system verification platform
  • Figures 8a and 8b are signaling interaction diagrams of the fourth chip verification method provided in an embodiment of the present application, wherein the first simulation TB and the second simulation TB are both sub-TBs, the first simulation TB corresponds to the aforementioned head TB, and the second simulation TB is a sub-TB other than the head TB, which can be the aforementioned middle TB or the aforementioned tail TB.
  • the chip verification method shown in FIG. 8 a and FIG. 8 b is described below from the perspective of the execution timing of each type of TB. Tn and Tn+1 mentioned below only represent the order of execution of the steps.
  • T1 Management TB initiates the verification process.
  • the management TB starts the verification process, which can be understood as the management TB prepares to establish various transmission channels to prepare for the execution of the business simulation task.
  • T2 The management TB parses the topology file, and the first simulation TB and the second simulation TB start the verification process.
  • the first simulation TB and the second simulation TB start the verification process, which can be understood as the first simulation TB and the second simulation TB start to run their respective locally deployed sub-DUT files in parallel, but the simulation input signal has not been generated at this time, so each sub-TB will not produce an operating result for the simulation input signal.
  • T3 Manage TB to establish a control server.
  • T4 The first simulation TB and the second simulation TB establish a control client.
  • the management TB starts the verification process before the first simulation TB and the second simulation TB, so that the management TB can establish a control server in advance, so that the first simulation TB and the second simulation TB can directly connect to the above server after establishing the control client.
  • T5 The first simulation TB and the second simulation TB send a control communication connection establishment request to the management TB.
  • T6 The management TB establishes a control communication connection, and starts a local control thread based on the control communication connection.
  • the first simulation TB and the second simulation TB start local control threads based on the control communication connection.
  • control channels between the management TB and the first simulation TB and the second simulation TB are established.
  • T7 The first simulation TB and the second simulation TB send TB information through the control channel between themselves and the management TB.
  • T8 Management TB updates the topology file based on TB information.
  • T9 The management TB synchronizes the updated topology file to the first simulation TB through the control channel between itself and the first simulation TB, and synchronizes the updated topology file to the second simulation TB through the control channel between itself and the second simulation TB.
  • T10 The first simulation TB and the second simulation TB receive the updated topology file.
  • the management TB sends a service channel establishment message through the control channel between itself and the first simulation TB, and sends a service channel establishment message through the control channel between itself and the second simulation TB.
  • the management TB can determine the second simulation TB to which the service channel is to be established based on the parsing result of the topology file in the aforementioned step T2, and then send a service channel establishment message to the second simulation TB through the control channel between the management TB and the second simulation TB.
  • the second simulated TB of the service channel to be established is the tail TB.
  • T12 Manage TB to establish business server.
  • T13 The first simulation TB and the second simulation TB send a service channel establishment request to the management TB.
  • T14 Manage TB to establish business channels.
  • the method of managing TB to establish a service channel in the above steps T11-T14 can be obtained on the basis of the control channel establishment method described in the above steps T3-T6, and will not be repeated here.
  • T15 The management TB sends a data channel establishment message through the control channel between itself and the adjacent simulation TB.
  • the management TB may determine the adjacent simulation TBs according to the parsing result of the topology file in the aforementioned step T2.
  • the adjacent simulation TBs mentioned above correspond to the adjacent sub-TBs mentioned above.
  • T16 Establish a data channel between adjacent simulation TBs.
  • T17 The management TB, the first simulation TB, and the second simulation TB synchronize information to internal components.
  • the information synchronized between the above-mentioned various TBs may be any information required in the verification process.
  • T18 The first simulation TB and the second simulation TB send a DUT initialization configuration completion message through the control channel between themselves and the management TB.
  • T19 The management TB controls the first simulation TB to start verification through the control channel between itself and the first simulation TB.
  • the management TB After the management TB receives the message that the DUT initialization configuration is completed, it can start to control the first simulation TB to start verification. At this time, the first simulation TB starts to generate simulation input signals and the business simulation task starts to execute.
  • the first simulation TB generates a simulation input signal, and runs the locally deployed first sub-DUT file based on the simulation input signal to obtain an intermediate result.
  • T21 The first simulation TB sends a simulation input signal to the management TB through the service channel between itself and the management TB.
  • the first simulation TB sends the obtained intermediate result to the simulation TB of the downstream sub-DUT file where the first sub-DUT file is deployed through the data channel between itself and the adjacent simulation TB.
  • the second simulation TB receives the intermediate result sent by the simulation TB of the upstream sub-DUT file where the second sub-DUT file is deployed, and runs the second sub-DUT file with the received intermediate result as an input signal to obtain the intermediate result.
  • T24 If the second sub-DUT file has a downstream sub-DUT file, the second simulation TB sends the obtained intermediate result to the simulation TB where the downstream sub-DUT file of the second sub-DUT file is deployed through the data channel between itself and the adjacent simulation TB.
  • the simulation TB in which the downstream sub-DUT file of the second sub-DUT file is deployed is also the downstream TB of the second simulation TB.
  • the second simulation TB is an intermediate TB, which can send the obtained intermediate results to the downstream TB through the data channel between itself and the downstream TB.
  • T25 If the second sub-DUT file does not have a downstream sub-DUT file, the second simulation TB feeds back the obtained intermediate result as a simulation result to the management TB through the service channel between itself and the management TB.
  • the second sub-DUT file does not have a downstream sub-DUT file, it means that the second simulation TB is the tail TB, then the intermediate result it obtains is the simulation result, and it can feed back the intermediate result as the simulation result to the management TB through the business channel between itself and the management TB.
  • T26 Management TB obtains the benchmark results of the business simulation task based on the simulation input signal, and verifies the chip according to the benchmark results and simulation results.
  • step S206 in the embodiment shown in FIG. 2 , and will not be described in detail here.
  • T27 The management TB detects that the verification is completed and destroys the business thread.
  • the management TB controls the first simulation TB to close the data channel and the service channel through the control channel between itself and the first simulation TB, and controls the second simulation TB to close the data channel and the service channel through the control channel between itself and the second simulation TB.
  • T29 The first simulation TB and the second simulation TB close the data channel and the service channel.
  • T30 The management TB controls the first simulation TB to close the control channel through the control channel between itself and the first simulation TB, and controls the second simulation TB to close the control channel through the control channel between itself and the second simulation TB.
  • T31 The first simulation TB and the second simulation TB close the control channel.
  • T32 The management TB, the first simulation TB and the second simulation TB end the verification process.
  • the embodiments of the present application further provide chip verification methods respectively applied to the management TB and the sub-TBs included in the simulation TB in the chip verification system, which are respectively introduced below.
  • FIG. 9 is a flowchart of a fifth chip verification method provided in an embodiment of the present application, and is applied to a management TB in a chip verification system, the method includes the following steps S901 to S904 .
  • Step S901 Start verification by controlling the header TB through the control channel.
  • Step S902 Receive the simulated input signal sent by the header TB through the service channel.
  • Step S903 receiving the simulation result for the business simulation task fed back by the tail TB through the business channel.
  • the simulation input signal can be input into the local DUT file running locally to obtain an intermediate result, and the intermediate result can be sent to the downstream TB through the data channel.
  • the intermediate TB can obtain the intermediate result based on the intermediate result sent by the upstream TB, and send the intermediate result to the downstream TB through the data channel between itself and the downstream TB.
  • the tail TB can receive the intermediate result sent by the upstream TB, and use the received intermediate result as the input signal to run the locally deployed local sub-DUT file to obtain the simulation result.
  • Step S904 Obtain a benchmark result of the business simulation task based on the simulation input signal, and verify the chip according to the benchmark result and the simulation result.
  • the management TB controls the head TB to start verification, it can receive the simulation input signal sent by the head TB through the business channel and the simulation result fed back by the tail simulation TB through the business channel, so that the benchmark result of the business simulation task can be obtained based on the simulation input signal, and the chip can be verified based on the benchmark result and the simulation result.
  • the simulation result of the chip is obtained by multiple sub-TBs including the head TB and the tail TB, and when obtaining the simulation result, each sub-TB is executed in parallel.
  • each sub-TB can be executed in parallel and use their own computing resources to work together to obtain the simulation result, which reduces the time consumed in obtaining the simulation result and improves the efficiency of obtaining the simulation result, thereby improving the efficiency of verifying the chip based on the simulation result.
  • FIG. 10 is a flow chart of a sixth chip verification method provided in an embodiment of the present application, which is applied to managing TB, the method includes the following steps S1001 to S1005 .
  • Step S1001 establish a control channel with each sub-TB, establish a service channel with the head TB and the tail TB, and control adjacent sub-TBs to establish a data channel.
  • the management TB After receiving the connection request sent by the control client established by the sub-TB, the management TB establishes a control communication connection with the control client, and starts a local control thread based on the control communication connection.
  • the management TB and each sub-TB have established control threads locally based on the control communication connection, so that the above-mentioned control threads can be dedicated to receiving and sending control messages between the management TB and each sub-TB, so that the interaction of control messages and other information will not be confused, which is conducive to improving the efficiency of control message interaction between the management TB and each sub-TB.
  • the management TB establishes a business service end, and after receiving the connection request sent by the head TB and the tail TB, establishes a business communication connection with the head TB and the tail TB, and starts a local business thread based on the business communication connection.
  • the management TB has established a business thread locally based on the business communication connection, so that the above business thread can be dedicated to receiving and sending business information between the management TB and the head TB and the tail TB, so that the interaction of business information does not cause interaction confusion with other types of information, which is conducive to improving the efficiency of business information interaction between the management TB and the head TB and the tail TB.
  • the management TB can obtain the topology file, receive the TB information sent by each sub-TB through the control channel between itself and the management TB, update the topology file according to the received TB information, determine the adjacent sub-TBs based on the updated topology file, and then send a control message to the adjacent sub-TB through the control channel between itself and the determined adjacent sub-TB, and synchronize the updated topology file to each sub-TB, so that the adjacent sub-TB that receives the control message establishes a data channel with the adjacent sub-TB based on the received topology file.
  • the management TB can determine the adjacent sub-TBs according to the updated topology file, and then synchronize the updated topology file to each sub-TB, and instruct the adjacent sub-TBs to establish a data channel, so that the sub-TB can accurately determine the sub-TBs adjacent to itself based on the updated topology file, and establish a data channel with the sub-TB.
  • the data thread can be dedicated to receiving and sending data between adjacent sub-TBs, so that the interaction of the data does not cause interaction confusion with other types of information, which is conducive to improving the efficiency of data interaction between adjacent sub-TBs.
  • Step S1002 Start verification by controlling the header TB through the control channel.
  • Step S1003 Receive the simulated input signal sent by the header TB through the service channel.
  • Step S1004 receiving the simulation result for the business simulation task fed back by the tail TB through the business channel.
  • Step S1005 Obtain a benchmark result of the business simulation task based on the simulation input signal, and verify the chip according to the benchmark result and the simulation result.
  • a control channel is established between the management TB and each sub-TB, a service channel is established with the head TB and the tail TB, and adjacent sub-TBs are controlled to establish a data channel.
  • the above-mentioned different types of transmission channels can be used to perform different types of information or data transmission services. This can separate transmission services of different dimensions from each other, which is conducive to avoiding confusion between different transmission services and improving the transmission efficiency of information and data.
  • the above steps also include: after the management TB determines that the chip verification is completed, it sends a verification completion message to each sub-TB through the control channel between itself and each sub-TB, so that each sub-TB closes the business channel, control channel and data channel between adjacent sub-TBs.
  • the management TB can promptly control the sub-TB to disconnect the control channel and business channel with itself, and control the adjacent sub-TB to disconnect the data channel, so as to release the memory occupied by the above transmission channels in time.
  • the following introduces a chip verification method for a sub-TB included in a simulation TB in a chip verification system.
  • the sub-TB can be a head TB, a middle TB, or a tail TB, which will be introduced below with reference to FIGS. 11 to 13 , respectively.
  • FIG. 11 is a flow chart of a seventh chip verification method provided in an embodiment of the present application, which is applied to a head TB, the method includes the following steps S1101 to S1103 .
  • Step S1101 In response to the startup verification control of the management TB, a simulation input signal is generated.
  • Step S1102 Run the locally deployed local sub-DUT file based on the simulation input signal to obtain an intermediate result.
  • Step S1103 Send the simulation input signal to the management TB through the service channel, and send the obtained intermediate result to the downstream TB through the data channel.
  • FIG. 12 is a flow chart of an eighth chip verification method provided in an embodiment of the present application, which is applied to an intermediate TB, the method includes the following steps S1201 to S1203 .
  • Step S1201 Receive the intermediate result sent by the upstream TB.
  • Step S1202 Using the received intermediate result as an input signal, the locally deployed local sub-DUT file is run to obtain the intermediate result.
  • Step S1203 Send the intermediate result to the downstream TB through the data channel between itself and the downstream TB.
  • FIG. 13 which is a flow chart of a ninth chip verification method provided in an embodiment of the present application, and applied to the tail TB, the method includes the following steps S1301 to S1303 .
  • Step S1301 Receive the intermediate result sent by the upstream TB.
  • Step S1302 Run the locally deployed local sub-DUT file with the received intermediate result as input to obtain the simulation result.
  • Step S1303 Send the simulation result to the management TB through the service channel, so that the management TB verifies the chip based on the simulation input signal and the simulation result.
  • each sub-TB obtains the intermediate result
  • each sub-TB sends the obtained intermediate result to its downstream simulation TB, so that its downstream TB obtains a new intermediate result based on the received intermediate result.
  • each sub-TB can continue to run the locally deployed sub-DUT file to obtain the intermediate result. That is, when obtaining the simulation result, each sub-TB is executed in parallel.
  • each sub-TB can be executed in parallel and use their own computing resources to work together to obtain the simulation result. This reduces the time consumed in obtaining the simulation result and improves the efficiency of obtaining the simulation result, thereby improving the efficiency of verifying the chip based on the simulation result.
  • the head TB and the tail TB respectively feed back the simulation input signal and the simulation result to the management TB through the service channel, and each sub-TB sends the intermediate result to other sub-TBs through the data channel.
  • the following steps are also included:
  • Each sub-TB establishes a control channel with the management TB. If the sub-TB is a head TB or a tail TB, it establishes a service channel with the management TB. Each sub-TB establishes a data channel with an adjacent sub-TB.
  • each sub-TB establishes a control client, and after successfully establishing the control client, establishes a control communication connection with the control server established by the management TB, and starts a local control thread based on the control communication connection.
  • each sub-TB has established a control thread locally based on the control communication connection, so that the above-mentioned control thread can be dedicated to receiving and sending control messages between the management TB and each sub-TB, so that the interaction of control messages and other types of information will not be confused, which is conducive to improving the efficiency of control message interaction between the management TB and each sub-TB.
  • the head simulation TB and the tail TB can establish a business communication connection with the management TB, and start a local business thread based on the business communication connection.
  • the head TB and the tail TB have established business threads locally based on the business communication connection, so that the above-mentioned business threads can be dedicated to receiving and sending business information between the management TB and the head TB and the tail TB, so that the interaction of business information and other types of information will not be confused, which is conducive to improving the efficiency of business information interaction between the management TB and the head TB and the tail TB.
  • each sub-TB sends TB information to the management TB through the control channel between itself and the management TB, receives the topology file sent by the management TB that is updated based on the TB information, determines the adjacent sub-TBs based on the topology file, and then establishes a data communication connection with the determined adjacent sub-TBs, and starts the local data thread according to the data communication connection.
  • each sub-TB can accurately determine the sub-TBs adjacent to itself based on the updated topology file sent by the management TB, and establish a data channel with the above sub-TBs.
  • the above data thread can be dedicated to receiving and sending data between each sub-TB and the adjacent sub-TB, so that the interaction of data and other types of information will not be confused, which is conducive to improving the efficiency of data interaction between adjacent sub-TBs.
  • each sub-TB after the management TB verifies the chip based on the simulation input signal and the simulation result, it also includes: each sub-TB responds to the verification end message sent by the management TB through the control channel between itself and each sub-TB, and closes the business channel between the management TB, the data channel between the adjacent sub-TBs, and the control channel between the management TB.
  • each sub-TB can promptly disconnect the control channel and business channel between the management TB, and disconnect the data channel between the adjacent sub-TB, so as to promptly release the memory occupied by the above transmission channels.
  • the embodiment of the present application also provides a chip verification device respectively used for managing TB and simulating TB, which are introduced below respectively.
  • FIG. 14 it is a schematic diagram of the structure of a first chip verification device provided in an embodiment of the present application.
  • the device includes the following modules:
  • the control module 1401 is used to control the head TB to start verification through the control channel so that the head TB generates a simulation input signal, and the head TB is: a sub-TB in which the first sub-DUT file of the business simulation task is deployed;
  • the business information receiving module 1402 is used to receive the simulation input signal sent by the head TB through the business channel; receive the simulation result for the business simulation task fed back by the tail TB through the business channel, wherein the tail TB is: the sub-TB in which the last sub-DUT file of the business simulation task is deployed;
  • the chip verification module 1403 is used to obtain a benchmark result of the business simulation task based on the simulation input signal, and verify the chip according to the benchmark result and the simulation result.
  • the management TB controls the head TB to start verification, it can receive the simulation input signal sent by the head TB through the business channel and the simulation result fed back by the tail simulation TB through the business channel, so that the benchmark result of the business simulation task can be obtained based on the simulation input signal, and the chip can be verified based on the benchmark result and the simulation result.
  • the simulation result of the chip is obtained by a plurality of sub-TBs including the head TB and the tail TB, and when obtaining the simulation result, each sub-TB is executed in parallel.
  • each sub-TB can be executed in parallel and use their own computing resources to work together to obtain the simulation result, which reduces the time consumption when obtaining the simulation result and improves the efficiency of obtaining the simulation result, thereby improving the efficiency of verifying the chip based on the simulation result.
  • the channel establishment module is specifically used to establish a control server; after receiving a connection request sent by a control client established by the sub-TB, establish a control communication connection with the control client; and start a local control thread based on the control communication connection.
  • the management TB and each sub-TB have established control threads locally based on the control communication connection, so that the above-mentioned control threads can be dedicated to receiving and sending control messages between the management TB and each sub-TB, so that the interaction of control messages and other information will not be confused, which is conducive to improving the efficiency of control message interaction between the management TB and each sub-TB.
  • the channel establishment module is specifically used to obtain a topology file; receive TB information sent by each sub-TB through the control channel between itself and the management TB; update the topology file according to the received TB information; determine the adjacent sub-TBs with upstream and downstream relationships of the deployed sub-DUT files based on the updated topology file; send control messages to the adjacent sub-TBs through the control channel between itself and the determined adjacent sub-TBs, and synchronize the updated topology file to each sub-TB, so that the adjacent sub-TB that receives the control message establishes a data channel with the adjacent sub-TB based on the received topology file.
  • the channel establishment module is specifically used to establish a business service end; after receiving the connection request sent by the head TB and the tail TB, establish a business communication connection with the head TB and the tail TB; and start a local business thread based on the business communication connection.
  • the management TB has established a business thread locally based on the business communication connection, so that the above business thread can be dedicated to receiving and sending business information between the management TB and the head TB and the tail TB, so that the interaction of business information does not cause interaction confusion with other information, which is conducive to improving the efficiency of business information interaction between the management TB and the head TB and the tail TB.
  • the end message sending module is used to send a verification end message to each sub-TB through the control channel between itself and each sub-TB after determining that the chip verification is completed, so that each sub-TB closes the business channel, control channel between itself and the data channel between adjacent sub-TBs.
  • the management TB can promptly control the sub-TB to disconnect the control channel and business channel with itself, and control the adjacent sub-TB to disconnect the data channel, so as to release the memory occupied by the above transmission channels in time.
  • FIG. 15 it is a schematic diagram of the structure of a second chip verification device provided in an embodiment of the present application, which is applied to a sub-TB included in a simulation TB in a chip verification system.
  • the device includes:
  • the control response module 1501 is used for generating a simulation input signal in response to the start verification control of the management TB if the simulation TB is a head TB, and running the locally deployed local sub-DUT file based on the simulation input signal to obtain an intermediate result, wherein the head TB is: a sub-TB in which the first sub-DUT file of the business simulation task is deployed;
  • the data transceiver module 1502 is used to send the intermediate result obtained to the downstream TB through the data channel if the simulation TB is a head TB; if the sub-TB is an intermediate TB, receive the intermediate result sent by the upstream TB, use the received intermediate result as input to run the locally deployed local sub-DUT file to obtain the intermediate result, and send the intermediate result obtained to the downstream TB through the data channel between itself and the downstream TB; if the sub-TB is a tail TB, receive the intermediate result sent by the upstream TB, use the received intermediate result as input to run the locally deployed local sub-DUT file to obtain the simulation result, wherein the tail TB is: the sub-TB with the last sub-DUT file of the business simulation task deployed, the intermediate TB is the sub-TB other than the head TB and the tail TB, the sub-DUT file deployed by the downstream TB is the downstream sub-DUT file of the local sub-DUT file, and the sub-DUT file deployed by the upstream TB is the upstream
  • the business information sending module 1503 is used to send the simulation input signal to the management TB through the business channel if the simulation TB is a head TB; if the sub-TB is a tail TB, send the simulation result to the management TB through the business channel, so that the management TB verifies the chip based on the simulation input signal and the simulation result.
  • each sub-TB obtains the intermediate result
  • each sub-TB sends the intermediate result to its downstream simulation TB, so that its downstream TB obtains a new intermediate result based on the received intermediate result.
  • each sub-TB can continue to run the locally deployed sub-DUT file to obtain the intermediate result. In other words, when obtaining the simulation result, each sub-TB is executed in parallel.
  • each sub-TB can be executed in parallel and use their own computing resources to work together to obtain the simulation result. This reduces the time consumed in obtaining the simulation result and improves the efficiency of obtaining the simulation result, thereby improving the efficiency of verifying the chip based on the simulation result.
  • the head TB and the tail TB respectively feed back the simulation input signal and the simulation result to the management TB through the service channel, and each sub-TB sends the intermediate result to other sub-TBs through the data channel.
  • control response module 1501 before the control response module 1501, it also includes:
  • a control channel establishing module used to establish a control channel with the management TB
  • a service channel establishing module configured to establish a service channel with the management TB if the sub-TB is a head TB or a tail TB;
  • the data channel establishment module is used to establish a data channel with adjacent sub-TBs, wherein the sub-DUT files deployed in the adjacent sub-TBs have an upstream and downstream relationship.
  • each sub-TB can promptly disconnect the control channel and business channel between the management TB, and disconnect the data channel between the adjacent sub-TB, so as to promptly release the memory occupied by the above transmission channels.
  • control channel establishment module is specifically used to establish a control client; after successfully establishing the control client, establish a control communication connection with the control server established by the management TB; and start a local control thread based on the control communication connection.
  • each sub-TB has established a control thread locally based on the control communication connection, so that the above control thread can be dedicated to receiving and sending control messages between the management TB and each sub-TB, so that the interaction of control messages and other information will not be confused, which is conducive to improving the efficiency of control message interaction between the management TB and each sub-TB.
  • the data channel establishment module is specifically used to send TB information to the management TB through the control channel between itself and the management TB; receive a topology file sent by the management TB that is updated based on the TB information; determine adjacent sub-TBs based on the topology file; establish a data communication connection with the determined adjacent sub-TBs; and start a local data thread based on the data communication connection.
  • the business channel establishment module is specifically used to establish a business communication connection with the business service end established by the management TB if the simulation TB is a head TB or a tail TB; and start a local business thread based on the business communication connection.
  • An embodiment of the present application also provides a verification platform, as shown in Figure 16, a processor 1601 and a machine-readable storage medium 1602, wherein the machine-readable storage medium 1602 stores machine-executable instructions that can be executed by the processor, and the processor 1601 is prompted by the machine-executable instructions to implement the aforementioned chip verification method applied to managing TB or the chip verification method applied to simulating TB.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • Quality & Reliability (AREA)
  • Design And Manufacture Of Integrated Circuits (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

本申请实施例提供了一种芯片验证系统、方法、装置、设备及存储介质，涉及芯片测试技术领域，上述系统包括：管理TB和仿真TB；管理TB用于通过控制通道控制头部TB启动验证；头部TB用于生成仿真输入信号，通过业务通道向所述管理TB发送仿真输入信号；各子TB用于运行本地部署的子DUT文件得到中间结果，通过数据通道向其他子TB发送所得中间结果；尾部TB用于得到针对业务仿真任务的仿真结果，通过业务通道向管理TB发送所述仿真结果；管理TB还用于基于所述仿真输入信号获得所述业务仿真任务的基准结果，并根据所述基准结果和所述仿真结果，对所述芯片进行验证。应用本申请实施例提供的方案能够提高芯片的验证效率。

Description

一种芯片验证系统、方法、装置、设备及存储介质 技术领域
本申请涉及芯片测试技术领域，特别是涉及一种芯片验证系统、方法、装置、设备及存储介质。
背景技术
对芯片进行流片生产之前，需要先对芯片进行验证，确保芯片的功能符合设计需求。
在芯片的仿真验证阶段，常规思路是使用单一TB(TestBench，验证平台)以仿真的方式基于芯片的DUT(Design Under Test，待验证设计)文件对芯片进行验证。当DUT逻辑规模较大时，单一TB的仿真效率较低，进而导致芯片的验证效率较低。
发明内容
本申请实施例的目的在于提供一种芯片验证系统、方法、装置设备及存储介质，以提高芯片的验证效率。具体技术方案如下：
第一方面，本申请实施例提供了一种芯片验证系统，所述系统包括：管理TB和仿真TB，仿真TB包括多个子TB，各子TB部署有芯片的DUT文件的不同子DUT文件，其中，
所述管理TB，用于通过控制通道控制头部TB启动验证，所述头部TB为：部署有业务仿真任务的首个子DUT文件的子TB；
所述头部TB，用于生成仿真输入信号，通过业务通道向所述管理TB发送所述仿真输入信号；
各子TB，用于运行本地部署的子DUT文件得到中间结果，通过数据通道向其他子TB发送所得中间结果；
尾部TB，用于得到针对所述业务仿真任务的仿真结果，通过业务通道向所述管理TB发送所述仿真结果，所述尾部TB为：部署有业务仿真任务的最后一个子DUT文件的子TB；
所述管理TB，还用于基于所述仿真输入信号获得所述业务仿真任务的基准结果，并根据所述基准结果和所述仿真结果，对所述芯片进行验证
第二方面，本申请实施例提供了一种芯片验证方法，应用于芯片验证系统中的管理TB，所述芯片验证系统还包括仿真TB，所述仿真TB包括多个子TB，各子TB部署有芯片的DUT文件的不同子DUT文件；
所述方法包括：
通过控制通道控制头部TB启动验证，以使得所述头部TB生成仿真输入信号，所述头部TB为：部署有业务仿真任务的首个子DUT文件的子TB；
接收所述头部TB通过业务通道发送的所述仿真输入信号；
接收尾部TB通过业务通道反馈的针对所述业务仿真任务的仿真结果，所述尾部TB为：部署有业务仿真任务的最后一个子DUT文件的子TB；
基于所述仿真输入信号获得所述业务仿真任务的基准结果，并根据所述基准结果和所述仿真结果，对所述芯片进行验证。
第三方面，本申请实施例提供了一种芯片验证方法，应用于芯片验证系统中仿真TB包括的子TB，所述芯片验证系统还包括管理TB，各子TB部署有芯片的DUT文件的不同子DUT文件；
所述方法包括：
若所述子TB为头部TB，响应于所述管理TB的启动验证控制，生成仿真输入信号，基于所述仿真输入信号运行本地部署的本地子DUT文件得到中间结果；通过业务通道向所述管理TB发送所述仿真输入信号，并通过数据通道向下游TB发送所得中间结果，所述下游TB部署的子DUT文件为本地子DUT文件的下游子DUT文件，所述头部TB为：部署有业务仿真任务的首一个子DUT文件的子TB；
若所述子TB为中间TB，接收上游TB发送的中间结果，以所接收中间结果为输入运行本地部署的本地子DUT文件得到中间结果，通过自身与下游TB之间的数据通道向下游TB发送所得中间结果，其中，所述上游TB部署的子DUT文件为本地子DUT文件的上游子DUT文件，所述中间TB为：除所述头部TB和尾部TB之外的子TB；
若所述子TB为尾部TB，接收上游TB发送的中间结果，以所接收中间结果为输入运行本地部署的本地子DUT文件得到仿真结果，通过业务通道向所述管理TB发送所述仿真结果，以使得所述管理TB基于所述仿真输入信号和所述仿真结果对所述芯片进行验证，其中，所述尾部TB为：部署有业务仿真任务的最后一个子DUT文件的子TB。
第四方面，本申请实施例提供了一种芯片验证装置，应用于芯片验证系统中的管理TB，所述芯片验证系统还包括仿真TB，所述仿真TB包括多个子TB，各子TB部署有芯片的DUT文件的不同子DUT文件；
所述装置包括：
控制模块，用于通过控制通道控制头部TB启动验证，以使得所述头部TB生成仿真输入信号，所述头部TB为：部署有业务仿真任务的首个子DUT文件的子TB；
业务信息接收模块，用于接收所述头部TB通过业务通道发送的所述仿真输入信号；接收尾部TB通过业务通道反馈的针对所述业务仿真任务的仿真结果，所述尾部TB为：部署有业务仿真任务的最后一个子DUT文件的子TB；
芯片验证模块，用于基于所述仿真输入信号获得所述业务仿真任务的基准结果，并根据所述基准结果和所述仿真结果，对所述芯片进行验证。
第五方面，本申请实施例提供了一种芯片验证装置，应用于芯片验证系统中仿真TB包括的子TB，所述芯片验证系统还包括管理TB，各子TB部署有芯片的DUT文件的不同子DUT文件；
所述装置包括：
控制响应模块，用于若所述仿真TB为头部TB，响应于所述管理TB的启动验证控制，生成仿真输入信号，基于所述仿真输入信号运行本地部署的本地子DUT文件得到中间结果，所述头部TB为：部署有业务仿真任务的首一个子DUT文件的子TB；
数据收发模块，用于若所述仿真TB为头部TB，通过数据通道向下游TB发送所得中间结果；若所述子TB为中间TB，接收上游TB发送的中间结果，以所接收中间结果为输入运行本地部署的本地子DUT文件得到中间结果，通过自身与下游TB之间的数据通道向下游TB发送所得中间结果；若所述子TB为尾部TB，接收上游TB发送的中间结果，以所接收中间结果为输入运行本地部署的本地子DUT文件得到仿真结果,其中，所述尾部TB为：部署有业务仿真任务的最后一个子DUT文件的子TB，所述中间TB为除头部TB和尾部TB之外的子TB，下游TB部署的子DUT文件为本地子DUT文件的下游子DUT文件，上游TB部署的子DUT文件为本地子DUT文件的上游子DUT文件；
业务信息发送模块，用于若所述仿真TB为头部TB，通过业务通道向所述管理TB发送所述仿真输入信号；若所述子TB为尾部TB，通过业务通道向所述管理TB发送所述仿真结果，以使得所述管理TB基于所述仿真输入信号和所述仿真结果对所述芯片进行验证。
第六方面，本申请实施例提供了一种验证平台，包括：处理器和机器可读存储介质，所述机器可读存储介质存储有能够被所述处理器执行的机器可执行指令，所述处理器被所述机器可执行指令促使：实现上述第二方面或第三方面所述的芯片验证方法。
第七方面，本申请实施例提供了一种计算机可读存储介质，存储有机器可执行指令，在被处理器调用和执行时，所述机器可执行指令促使所述处理器：实现上述第二方面或第三方面所述的芯片验证方法。
第八方面，本申请实施例还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行时实现上述第二方面或第三方面所述的芯片验证方法。
由以上可见，应用本申请实施例提供的方案进行芯片验证时，头部TB可以响应于管理TB的控制生成仿真输入信号，并通过业务通道向上述管理TB发送仿真输入信号；尾部TB可以得到针对业务仿真任务的仿真结果，通过业务通道向管理TB反馈得到的仿真结果，从而管理TB可以接收上述仿真输入信号和仿真结果，进而可以基于上述仿真输入信号和仿真结果成功对芯片进行验证。
另外，在得到上述仿真结果时，各子TB用于运行本地部署的子DUT文件得到中间结果，通过数据通道向其他子TB发送所得中间结果，可以看出，一方面，各子TB可以向其他子TB发送所得到的中间结果，以使得其他子TB基于接收到的中间结果得到新的中间结果，另一方面，各子TB自身同时可以继续运行本地部署的子DUT文件得到中间结果。也就是，在在上述过程中，各个子TB是并行执行的。由于运行DUT文件得到仿真结果这一过程往往需要耗费较多计算资源、耗时较长，而上述方案中各子TB可以并行执行、使用各自的计算资源运行本地部署的子DUT文件从而协力得到仿真结果，这样减少了获得仿真结果时的耗时，提高了仿真结果的获得效率，从而提高了基于仿真结果验证芯片的效率。
并且，管理TB通过控制通道控制头部TB启动验证、头部TB和尾部TB分别通过业务通道向管理TB反馈仿真输入信号和仿真结果、且各子TB通过数据通道向其他子TB发送所得中间结果，由以上可见，不同类型的信息或数据通过上述不同类型的传输通道传输，这样可以将不同维度的传输业务相互分离，有利于避免不同的传输业务之间相互混淆，有利于提高信息和数据的传输效率。
当然，实施本申请的任一产品或方法并不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本申请实施例和现有技术的技术方案，下面对实施例和现有技术中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的第一种芯片验证系统的结构示意图；
图2为本申请实施例提供的第一种芯片验证方法的信令交互图；
图3为本申请实施例提供的第二种芯片验证方法的信令交互图；
图4为本申请实施例提供的第三种芯片验证方法的信令交互图；
图5为本申请实施例提供的一种拓扑文件内容示意图；
图6为本申请实施例提供的一种拓扑文件生成界面的示意图；
图7为本申请实施例提供的第二种芯片验证系统的结构示意图；
图8a和图8b为本申请实施例提供的第四种芯片验证方法的信令交互图；
图9为本申请实施例提供的第五种芯片验证方法的流程示意图；
图10为本申请实施例提供的第六种芯片验证方法的流程示意图；
图11为本申请实施例提供的第七种芯片验证方法的流程示意图；
图12为本申请实施例提供的第八种芯片验证方法的流程示意图；
图13为本申请实施例提供的第九种芯片验证方法的流程示意图；
图14为本申请实施例提供的第一种芯片验证装置的结构示意图；
图15为本申请实施例提供的第二种芯片验证装置的结构示意图；
图16为本申请实施例提供的一种验证平台的结构示意图。
具体实施方式
为使本申请的目的、技术方案、及优点更加清楚明白，以下参照附图并举实施例，对本申请进一步详细说明。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
首先对本申请所提供的方案中涉及的相关概念进行说明。
1、DUT文件。
待验证设计文件，即待验证的芯片设计文件，上述设计文件可以由HDL(Hardware Description Language，硬件描述语言)编写。
2、子DUT文件。
对DUT文件进行分割得到的一部分DUT文件。
本申请实施例不限定针对DUT文件分割得到子DUT文件的具体方式。例如，工作人员可以根据实际情况，依据芯片待验证的子功能对DUT文件进行分割，这种情况下，分割得到的各子DUT文件对应于芯片的各个待验证的子功能。
3、业务仿真任务。
采用TB仿真的方式对芯片的功能进行验证的任务，也可以称为一个验证用例，对应于一次验证流程。业务仿真任务中可以记录有该次验证流程中需要被执行的各子DUT文件的信息。
例如，业务仿真任务T1为针对芯片的子功能1的验证，则T1中记录有与子功能1相关的子DUT文件1-3的信息；业务仿真任务T2为针对芯片的子功能2和子功能3的验证，则T2中记录有与子功能2和子功能3相关的子DUT文件5-9的信息等。
4、子DUT文件的下游子DUT文件和上游子DUT文件。
由前述针对业务仿真任务的说明可知，业务仿真任务会涉及到多个在该次验证流程中需要被执行的子DUT文件，这些子DUT文件在验证过程中有一定的执行顺序。
基于上述理解，可以将验证流程中执行顺序在一个子DUT文件之后的子DUT文件称为该子DUT文件的下游子DUT文件。
同理，可以将验证流程中执行顺序在一个子DUT文件之前的子DUT文件称为该子DUT文件的上游子DUT文件。
5、子TB的下游TB、上游TB。
针对一个子TB，其下游TB部署的子DUT文件为该子TB部署的本地子DUT文件的下游子DUT 文件；同理，其上游TB部署的子DUT文件为该子TB部署的本地子DUT文件的上游子DUT文件。
6、头部TB、尾部TB、中间TB。
头部TB为部署有业务仿真任务的首个子DUT文件的子TB，类似的，尾部TB为部署有业务仿真任务的最后一个子DUT文件的子TB。中间TB为除上述头部TB和尾部TB之外的子TB。
下面对本申请实施例提供的芯片验证方案进行说明。
为提高芯片的验证效率，本申请实施例提供了一种芯片验证系统、方法、装置、设备及存储介质，下面分别进行详细描述。
首先，本申请实施例提供了一种芯片验证系统，上述系统包括：管理TB和仿真TB，仿真TB包括多个子TB，各子TB部署有芯片的DUT文件的不同子DUT文件，其中，
上述管理TB，用于通过控制通道控制头部TB启动验证，上述头部TB为：部署有业务仿真任务的首个子DUT文件的子TB；
上述头部TB，用于生成仿真输入信号，通过业务通道向上述管理TB发送上述仿真输入信号；
各子TB，用于运行本地部署的子DUT文件得到中间结果，通过数据通道向其他子TB发送所得中间结果；
尾部TB，用于得到针对所述业务仿真任务的仿真结果，通过业务通道向上述管理TB反馈所述仿真结果，上述尾部TB为：部署有业务仿真任务的最后一个子DUT文件的子TB；
上述管理TB，还用于基于上述仿真输入信号获得上述业务仿真任务的基准结果，并根据上述基准结果和上述仿真结果，对上述芯片进行验证。
由以上可见，应用本申请实施例提供的方案进行芯片验证时，头部TB可以响应于管理TB的控制生成仿真输入信号，并通过业务通道向上述管理TB发送仿真输入信号；尾部TB可以得到针对业务仿真任务的仿真结果，通过业务通道向管理TB反馈得到的仿真结果，从而管理TB可以接收上述仿真输入信号和仿真结果，进而可以基于上述仿真输入信号和仿真结果成功对芯片进行验证。
另外，在得到上述仿真结果时，各子TB用于运行本地部署的子DUT文件得到中间结果，通过数据通道向其他子TB发送所得中间结果，可以看出，一方面，各子TB可以向其他子TB发送所得到的中间结果，以使得其他子TB基于接收到的中间结果得到新的中间结果，另一方面，各子TB自身同时可以继续运行本地部署的子DUT文件得到中间结果。也就是，在在上述过程中，各个子TB是并行执行的。由于运行DUT文件得到仿真结果这一过程往往需要耗费较多计算资源、耗时较长，而上述方案中各子TB可以并行执行、使用各自的计算资源运行本地部署的子DUT文件从而协力得到仿真结果，这样减少了获得仿真结果时的耗时，提高了仿真结果的获得效率，从而提高了基于仿真结果验证芯片的效率。
并且，管理TB通过控制通道控制头部TB启动验证、头部TB和尾部TB分别通过业务通道向管理TB反馈仿真输入信号和仿真结果、且各子TB通过数据通道向其他子TB发送所得中间结果，由以上可见，不同类型的信息或数据通过上述不同类型的传输通道传输，这样可以将不同维度的传输业务相互分离，有利于避免不同的传输业务之间相互混淆，有利于提高信息和数据的传输效率。
参见图1，为本申请实施例提供的第一种芯片验证系统的结构示意图，上述芯片验证系统包括：管理TB101和仿真TB102，其中，仿真TB102包括多个子TB，各子TB部署有芯片的DUT文件的不同子DUT文件。
需要说明的是，图1中仿真TB102包括头部TB和尾部TB在内的各子TB，管理TB101和仿真TB102之间的连线表示的是管理TB101与上述各子TB之间建立的通信连接。
下面先对采用本申请实施例提供的芯片验证系统进行芯片验证时的场景进行说明。
由图1可知，本申请实施例提供的芯片验证系统中包含管理TB和仿真TB，仿真TB包括多个子TB，各子TB部署有芯片的DUT文件的不同子DUT文件。
在进行芯片验证之前，管理TB和上述各子TB可以启动工作，进而各子TB可以并行的运行各自本地部署的子DUT文件，这时，由于没有生成仿真输入信号，所以各子TB不会产生针对仿真输入信号的运行结果，直到管理TB控制头部TB启动验证，头部TB接收到管理TB发送的启动验证的控制消息后启动验证，生成仿真输入信号，本申请实施例提供的芯片验证方案才开始执行。
为了更加直观的说明上述芯片验证系统进行芯片验证的方式，下面采用信令图的形式对本申请实施例提供的芯片验证方案进行详细说明。
参见图2，为本申请实施例提供的第一种芯片验证方法的信令交互图，上述方法包括以下步骤 S201-S206。
步骤S201：管理TB通过控制通道控制头部TB启动验证。
其中，上述头部TB为：部署有业务仿真任务的首个子DUT文件的子TB。
上述业务仿真任务的首个子DUT文件为：业务仿真任务在执行过程中首个被执行的子DUT文件。
上述控制通道以及后续提及的业务通道、数据通道均为传输通道，用于传输数据或消息。
本步骤中，管理TB控制头部TB启动验证，可以理解为，管理TB控制头部TB生成仿真输入信号，从而开始针对业务仿真任务启动验证，也就是，启动业务仿真任务所针对的芯片的部分或者全部功能的验证。
具体的，管理TB可以通过控制通道向头部TB发送控制消息，从而控制头部TB启动验证。
步骤S202：头部TB生成仿真输入信号。
具体的，头部TB可以按照以下两种情况生成仿真输入信号。
一种情况下，头部TB预先存储有用于生成仿真输入信号的信息，这样头部TB在接收到管理TB发送的控制消息后，可以根据上述信息生成仿真输入信号。
另一种情况下，管理TB控制头部TB生成仿真输入信号时，可以向头部TB发送用于生成仿真输入信号的消息，从而头部TB可以根据接收到的上述消息生成仿真输入信号。
需要说明的是，在本步骤头部TB生成仿真输入信号后，各子TB用于运行本地部署的子DUT文件得到中间结果，通过数据通道向其他子TB发送所得中间结果。
上述中间结果的概念详见图3所示实施例，这里暂不详述。
步骤S203：头部TB通过业务通道向管理TB发送仿真输入信号。
步骤S204：尾部TB得到针对业务仿真任务的仿真结果。
其中，上述尾部TB为：部署有业务仿真任务的最后一个子DUT文件的子TB。
其中，上述业务仿真任务的最后一个子DUT文件可以理解为：业务仿真任务在执行过程中最后一个被执行的子DUT文件。
可见，尾部TB本地部署的子DUT文件不存在下游子DUT文件，表明其部署的子DUT文件为本次业务仿真任务中需要被执行的最后一个子DUT文件，因此，尾部TB运行本地部署的子DUT文件得到结果即为针对本次业务仿真任务的仿真结果。
步骤S205：尾部TB通过业务通道向管理TB反馈仿真结果。
步骤S206：管理TB基于仿真输入信号获得业务仿真任务的基准结果，并根据基准结果和仿真结果，对芯片进行验证。
具体的，管理TB接收到仿真输入信号之后，可以将上述仿真输入信号输入本地部署的参考模型(Reference Model)，得到模型输出的基准结果。上述参考模型使用高级语言编写，描述了芯片的功能逻辑。
得到基准结果之后，管理TB可以比对仿真结果与基准结果是否一致，若一致，则确定芯片针对业务仿真任务的验证通过；若不一致，则确定芯片针对业务仿真任务的验证未通过。
由以上可见，应用本申请实施例提供的方案进行芯片验证时，头部TB可以响应于管理TB的控制生成仿真输入信号，并通过业务通道向上述管理TB发送仿真输入信号；尾部TB可以得到针对业务仿真任务的仿真结果，通过业务通道向管理TB反馈得到的仿真结果，从而管理TB可以接收上述仿真输入信号和仿真结果，进而可以基于上述仿真输入信号和仿真结果成功对芯片进行验证。
另外，在得到上述仿真结果时，各子TB用于运行本地部署的子DUT文件得到中间结果，通过数据通道向其他子TB发送所得中间结果，可以看出，一方面，各子TB可以向其他子TB发送所得到的中间结果，以使得其他子TB基于接收到的中间结果得到新的中间结果，另一方面，各子TB自身同时可以继续运行本地部署的子DUT文件得到中间结果。也就是，在在上述过程中，各个子TB是并行执行的。由于运行DUT文件得到仿真结果这一过程往往需要耗费较多计算资源、耗时较长，而上述方案中各子TB可以并行执行、使用各自的计算资源运行本地部署的子DUT文件从而协力得到仿真结果，这样减少了获得仿真结果时的耗时，提高了仿真结果的获得效率，从而提高了基于仿真结果验证芯片的效率。
并且，管理TB通过控制通道控制头部TB启动验证、头部TB和尾部TB分别通过业务通道向管理TB反馈仿真输入信号和仿真结果、且各子TB通过数据通道向其他子TB发送所得中间结果，由以上可见，不同类型的信息或数据通过上述不同类型的传输通道传输，这样可以将不同维度的传输业务相互分离，有利于避免不同的传输业务之间相互混淆，有利于提高信息和数据的传输效率。
另外，上述方案还适用于多个芯片套片的组网验证、多die(Die-to-Die，裸片到裸片)互联的Chiplet 系统验证、EMU(Emulator，仿真器)和EDA(electronic design assistance，电子设计辅助)分布式联合仿真等多种待验证芯片的DUT逻辑规模较大的验证场景。
本申请的一个实施例中，管理TB还可以在确定芯片验证结束后，通过管理TB与各子TB之间的控制通道，向各子TB发送验证结束消息；各子TB可以响应于验证结束消息，关闭与管理TB之间的业务通道、与相邻子TB之间的数据通道以及与管理TB之间的控制通道。
其中，上述芯片验证的结束条件可以是各业务仿真任务遍历了所有的子DUT文件、且针对各业务仿真任务的验证均通过。
这样在芯片验证结束后，可以及时的关闭各类型TB之间建立的控制通道、业务通道及数据通道，从而可以及时释放上述传输通道占用的内存。
本公开的一个实施例中，各子TB可以根据自身与其他子TB之间的上下游关系，通过数据通道向其他子TB发送自身得到的中间结果。鉴于上述情况，本公开实施例提供了第二种芯片验证方法。
参见图3，为本申请实施例提供的第二种芯片验证方法的信令交互图，上述方法包括以下步骤S301-S308。
步骤S301：管理TB控制头部仿真TB启动验证。
具体的，管理TB可以通过以下方式控制头部仿真TB启动验证。
一种实施方式中，可以与前述步骤S201相同，这里不再赘述。
另一种实施方式中，管理TB中可以存储有上述头部TB的访问地址，这样管理TB可以基于上述访问地址控制头部TB生成激励信号。
其中，上述访问地址可以是头部TB的IP地址、MAC地址等地址；基于上述访问地址控制头部TB生成激励信号的方式可以是向头部TB发送启动验证的指示消息等。
步骤S302：头部TB生成仿真输入信号，基于仿真输入信号运行本地部署的本地子DUT文件得到中间结果。
上述仿真输入信号为头部TB运行本地子DUT文件的输入信号，这样头部TB运行本地子DUT文件过程中，本地子DUT文件被输入上述仿真输入信号后，能够得到输出结果，将上述输出结果可以称为针对仿真输入信号的中间结果。
一种情况下，头部TB运行本地子DUT文件时，可以认为是对本地子DUT文件在芯片中对应的功能模块进行了仿真，基于此，上述中间结果可以理解为上述功能模块针对上述仿真输入信号输出的接口时序。
步骤S303：头部TB向管理TB发送仿真输入信号。
具体的，头部TB可以通过以下方式向管理TB发送仿真输入信号。
一种实施方式中，头部TB可以通过业务通道向管理TB发送仿真输入信号。
另一种实施方式中，头部TB中可以预先存储管理TB的访问地址，从而头部TB可以在仿真输入信号生成之后，基于上述访问地址向管理TB发送所生成的仿真输入信号。
步骤S304：头部TB向下游TB发送所得中间结果。
其中，上述下游TB部署的子DUT文件为本地子DUT文件的下游子DUT文件。
本步骤中，头部TB在得到中间结果之后，可以向自身的下游TB发送所得到的中间结果。其中，头部TB的下游TB可以为一个，也可以为多个。
具体的，头部TB可以采用以下方式向下游TB发送所得中间结果。
一种实施方式中，头部TB中可以预先存储下游TB的访问地址，从而头部TB得到中间结果之后，可以基于上述访问地址向下游TB发送上述中间结果。
另一种实施方式中，头部TB可以通过自身与下游仿真TB之间的数据通道向下游仿真TB发送所得中间结果。
步骤S305：中间TB接收上游TB发送的中间结果，以所接收中间结果为输入信号运行本地部署的本地子DUT文件得到中间结果，并向下游TB发送所得中间结果。
其中，上述中间TB为：除头部TB和尾部TB之外的子TB，上游TB部署的子DUT文件为本地子DUT文件的上游子DUT文件。
由于中间TB为除头部TB和尾部TB之外的子TB，因此，中间TB本地部署的本地子DUT文件存在下游子DUT文件，表明后续还存在本次业务仿真任务中需要被执行的子DUT文件，本次业务仿真任务还未结束，也即中间TB得到的中间结果不是本次业务仿真任务的最终仿真结果。
因此，中间TB可以向下游TB发送自身得到的中间结果，以使得下游TB接收中间结果、将所接 收中间结果作为输入信号输入其运行的本地子DUT文件。
同样的，中间TB运行本地子DUT文件时，可以认为是对本地子DUT文件在芯片中对应的功能模块进行了仿真，基于此，上述中间结果可以理解为上述功能模块针对上述仿真输入信号输出的接口时序。
具体的，中间TB可以采用以下方式向下游TB发送所得中间结果。
一种实施方式中，中间TB中可以预先存储其下游仿真TB的访问地址，从而中间TB得到中间结果之后，可以基于上述访问地址向其下游仿真TB发送上述中间结果。
另一种实施方式中，中间TB可以通过自身与下游TB之间的数据通道向下游TB发送所得中间结果。
步骤S306：尾部TB接收上游TB发送的中间结果，以所接收中间结果为输入信号运行本地部署的本地子DUT文件得到仿真结果。
本步骤中，尾部TB为部署有业务仿真任务的最后一个子DUT文件的子TB，其本地部署的本地子DUT文件不存在下游子DUT文件，表明其部署的子DUT文件为本次业务仿真任务中需要被执行的最后一个子DUT文件，因此，尾部TB以上游TB发送的中间结果为输入信号运行本地子DUT文件得到的结果即为针对业务仿真任务的仿真结果。
步骤S307：尾部TB向管理TB反馈仿真结果。
具体的，尾部TB可以采用以下方式向管理TB反馈向仿真结果。
一种实施方式中，尾部TB中可以预先存储管理TB的访问地址，从而尾部TB可以基于上述访问地址将所得中间结果作为仿真结果向管理TB反馈。
另一种实施方式中，尾部TB可以通过自身与管理TB之间的业务通道向管理TB发送仿真结果。
步骤S308：管理TB基于仿真输入信号获得业务仿真任务的基准结果，并根据基准结果和仿真结果，对芯片进行验证。
本步骤与前述图2所示实施例中步骤S206相同，这里不再赘述。
由以上可见，应用本申请实施例提供的方案进行芯片验证时，头部TB可以基于自身生成的仿真输入信号运行本地部署的本地子DUT文件得到中间结果，然后通过自身与下游TB之间的数据通道向下游TB发送所得中间结果，这样中间TB可以接收上游TB发送的中间结果，以所接收中间结果为输入信号运行本地部署的本地子DUT文件得到中间结果，通过自身与下游TB之间的数据通道向下游TB发送所得中间结果，进而尾部TB可以接收上游TB发送的中间结果，以所接收的中间结果为输入信号运行本地部署的本地子DUT文件得到仿真结果。
这样各子TB可以按照上下游关系有条不紊的进行数据交互，最终使得尾部TB能够准确的得到仿真结果。
在图2和图3所示实施例的基础上可知，子TB之间进行数据交互之前需要先建立数据通道，子TB与管理TB之间进行信息交互之前需要先建立控制通道和业务通道。鉴于上述情况，本申请实施例提供了第三种芯片验证方法。
参见图4，为本申请实施例提供的第三种芯片验证方法的信令交互图，上述方法包括以下步骤S401-S411。
步骤S401：各子TB与管理TB建立控制通道。
本申请实施例不限定各子TB与管理TB建立控制通道的流程，可以是子TB主动与管理TB建立控制通道，也可以是管理TB控制子TB与自身建立控制通道。
一种实施方式中，管理TB可以建立控制服务端，各子TB建立控制客户端，在成功建立控制客户端后与控制服务端建立控制通信连接，基于控制通信连接启动本地的控制线程，管理TB也基于控制通信连接启动本地的控制线程。
这样管理TB和各子TB均可以基于本地的控制线程接收或发送控制消息，也即各子TB与管理TB之间的控制通道建立完毕。例如，上述控制消息可以是验证开始指示消息、TB信息等。
可见，管理TB和各子TB均在本地基于控制通信连接建立了控制线程，使得上述控制线程可以专用于进行管理TB和各子TB之间控制消息的接收与发送，这样控制消息的交互与其他类型的信息不产生交互混淆，有利于提高管理TB和各子TB之间的控制消息交互效率。
本申请的一个实施例中，上述控制通道传输的数据为：TLV(Type-Length-Value，标签-长度-值)格式的数据。
具体的，Type部分可以采用8bit表示命令类型标识；Value部分表示Payload，即实际的数据内容；Length部分可以采用8bit表示Value部分的实际字节长度，支持最大256字节的Value字节长度。
由于TLV格式较为简单，且支持传输变长数据，因此数据控制通道所传输的数据格式采用TLV格式，可以使得其支持传输变长的控制消息，有利于丰富数据控制通道所能够传输的消息类型。
步骤S402：头部TB和尾部TB与管理TB建立业务通道。
其中，尾部TB为：部署有业务仿真任务的最后一个子DUT文件的仿真TB。
本申请实施例不限定头部TB、尾部TB与管理TB建立业务通道的流程，可以是头部TB、尾部TB主动与管理TB建立业务通道，也可以是管理TB控制头部TB、尾部TB与自身建立业务通道。
一种实施方式中，管理TB可以建立业务服务端，头部TB、尾部TB可以与业务服务端建立业务通信连接，并基于业务通信连接启动本地的业务线程，管理TB也基于业务通信连接启动本地的业务线程。
这样管理TB和头部TB、尾部TB均可以基于本地的业务线程接收或发送业务信息，也即头部TB、尾部TB与管理TB之间的业务通道建立完毕。例如，上述业务信息可以是仿真输入信号、仿真结果等。
可见，头部TB、尾部TB与管理TB均在本地基于业务通信连接建立了业务线程，使得上述业务线程可以专用于进行管理TB和头部TB、尾部TB之间业务信息的接收与发送，这样业务信息的交互与其他类型的信息不产生交互混淆，有利于提高管理TB和头部TB、尾部TB之间的业务信息交互效率。
本申请的一个实施例中，上述业务通道传输的数据为：动态数组格式的变长报文。
具体的，上述动态数组的内的元素可以是8bit大小，数据发送方在发送数据时可以根据实际所需传输的数据长度申请动态数组的大小，数据接收方在在Socket(套接字)底层可以通过去粘包技术获取各个变长报文。
可见上述变长报文支持传输变长数据，因此业务通道所传输的数据格式采用变长报文格式，可以使得其支持传输变长的信息，有利于丰富业务通道所能够传输的信息类型。
步骤S403：相邻子TB之间建立数据通道。
其中，相邻子TB所部署的子DUT文件具有上下游关系。
本申请实施例不限定相邻子TB之间建立数据通道的方式，以下通过步骤A-步骤C所述的举例介绍相邻子TB之间建立数据通道的一种方式。
步骤A：各子TB通过自身与管理TB之间的控制通道向管理TB发送TB信息。
上述TB信息可以包括子TB的TB标识、访问地址等信息。
步骤B：管理TB获得拓扑文件，根据所接收的TB信息更新拓扑文件，基于更新后的拓扑文件确定相邻子TB，通过自身与确定出的相邻子TB之间的控制通道向相邻子TB发送控制消息，并向各子TB同步更新后的拓扑文件。
其中，拓扑文件用于记录管理TB和各子TB之间的拓扑关系、管理TB的TB信息以及各子TB的TB信息。对于拓扑文件的详细说明详见后续图5以及图6所示实施例，这里暂不详述。
具体的，管理TB根据所接收的TB信息更新拓扑文件的方式可以是：将拓扑文件中的TB信息更新为接收到的TB信息、删除拓扑文件中记录的未接收到TB信息的子TB的拓扑关系等。
得到更新后的拓扑文件后，管理TB可以将拓扑文件中记录的建立数据通道的TB确定为相邻子TB，然后通过自身与确定出的相邻子TB之间的控制通道向相邻子TB发送控制消息，并向各子TB同步更新后的拓扑文件。其中，管理TB可以向相邻子TB中的一个子TB发送控制消息，这样接收到控制消息的子TB可以主动发起针对另一子TB的数据通道建立请求，当然，管理TB也可以向相邻子TB中的两个子TB均发送控制消息。
步骤C：相邻子TB响应于控制消息，基于接收到的拓扑文件与相邻子TB建立数据通信连接，根据数据通信连接启动本地的数据线程。
相邻子TB接收到控制消息之后，可以读取拓扑文件中记录的与自身相邻的子TB，然后与上述子TB建立数据通信连接，根据数据通信连接启动本地的数据线程。
这样相邻子TB可以基于本地的数据线程通过上述数据通信连接接收或发送数据，也即相邻子TB之间的数据通道建立完毕。例如，上述数据可以是中间结果等。
可见，管理TB可以根据更新后的拓扑文件确定出相邻子TB，然后将更新后拓扑文件同步至各子TB，并指示相邻子TB之间建立数据通道，从而子TB可以基于上述更新后的拓扑文件准确的确定出与自身相邻的子TB，并与上述子TB建立数据通道。另外，上述数据线程可以专用于进行相邻子TB之间的数据接收与发送，使得上述数据的交互与其他类型的信息不产生交互混淆，有利于提高相邻子TB之间的数据交互效率。
本申请的一个实施例中，上述数据通道传输的数据为：基于信号的SB(Signal Based)模式或TB(Transaction Based)模式的数据。
其中，当采用SB模式时，上述数据通道所传输的数据为：以时钟周期粒度传输的、运行子DUT 文件产生的端口信号值，该模式需要做好Cycle(周期)级的数据流同步；当采用TB模式时，数据发送方所传输的数据为业务通道的数据格式的接口数据，数据接收方可以解析上述数据生成接口时序信号，该模式需要数据接收方解析接收到的数据，但是不需要做Cycle级的数据流同步。
这样可以根据实际情况选择在数据通道传输SB模式的数据或TB模式的数据，使得选择传输的数据符合数据通道所需传输的数据的特点，从而有利于提高数据通道的数据传输效率。
需要说明的是，本申请实施例不限定上述步骤S402与步骤S403之间的执行顺序，上述步骤S402可以在步骤S403之前或之后执行，上述两步骤也可以并行执行。
步骤S404：管理TB通过控制通道控制头部TB启动验证。
步骤S405：头部TB生成仿真输入信号，基于仿真输入信号运行本地部署的本地子DUT文件得到中间结果。
步骤S406：头部TB通过业务通道向管理TB发送仿真输入信号。
步骤S407：头部TB通过自身与下游TB之间的数据通道向下游TB发送所得中间结果。
步骤S408：中间TB接收上游TB发送的中间结果，以所接收中间结果为输入信号运行第二子DUT文件得到中间结果，通过自身与下游TB之间的数据通道向下游TB发送所得中间结果。
步骤S409：尾部TB接收上游TB发送的中间结果，以所接收中间结果为输入信号运行本地部署的本地子DUT文件得到仿真结果。
步骤S410：尾部TB通过业务通道向管理TB反馈仿真结果。
步骤S411：管理TB基于仿真输入信号获得业务仿真任务的基准结果，并根据基准结果和仿真结果，对芯片进行验证。
上述步骤S404-步骤S411的具体实施方式已在前述图3所示实施例中步骤S301-S308中说明，这里不再赘述。
下面结合图5，对前述提及的拓扑文件进行详细说明。
参见图5，为本申请实施例提供的一种拓扑文件内容示意图。
可以看出，图5所示的内容为拓扑文件中记录的拓扑描述语句，以下对图中部分拓扑描述语句进行介绍：
1、SLV_TB_NUM＝2。
表示仿真TB中包括的子TB的个数为2。
2、TB_NAME_ID_MAP＝MASTER_TB:100。
表示管理TB的个数为1，管理TB的TB标识为100。
为便于表述，以下将TB标识为a的TB简称为TBa。
3、ETH_TB_LEFT:200、ETH_TB_RIGHT:300。
表示子TB的个数为2，分别为TB200和TB300。
4、COM_TB_DES＝200_300_DRV,1,200,300,10900。
表示建立的1个传输通道。
其中，“1”表示通道类型为数据通道，“200，300”表示TB200连接到TB300，例如，TB200可以基于Socket方式创建客户端连接到TB300创建的服务端，“10900”表示建立上述连接时采用的Socket端口号。
在上述4的举例基础上类推，可知图5所示的拓扑描述语句表示分别建立TB200到TB300以及TB300到TB200这2个数据通道(通道类型为1)，建立TB200到TB100的两个业务通道(通道类型为2和3)，且建立TB00到TB100的两个业务通道(通道类型为2和3)。
需要说明的是，由前述实施例可知，管理TB与各子TB之间均建立控制通道，因此管理TB在本方案的执行过程中可以默认与各子TB之间均建立控制通道，也即管理TB在建立控制通道时无需解析拓扑文件，所以，上述拓扑文件中无需记载用于表征管理TB与子TB之间的控制通道建立关系的信息。
下面再对上述拓扑文件的生成方式进行介绍。
参见图6，为本申请实施例提供的一种拓扑文件生成界面的示意图。
工作人员可以使用图6所示的拓扑文件生成界面生成拓扑文件。
可以看出，图6所示的拓扑文件生成界面向工作人员提供了TB定义以及TB连接关系定义两种功能窗口，下面对上述两种功能分别进行描述。
1、TB定义功能。
用于确定各子TB的信息。工作人员可以使用上述功能输入待建立传输通道的子TB的TB number (TB数量)、Simulation TB name(子TB名称)以及Simulation TB ID(子TB标识)，点击Add(添加)按钮确认输入。
2、TB连接关系定义功能。
用于确定各类型TB之间的连接关系。工作人员可以使用上述功能输入Connection Description(连接描述信息)、Client TB ID(作为客户端的TB标识)、Server TB ID(作为服务端的TB标识)、Socket Port(Socket端口号)，并选择Connection Type(连接方式)，点击Add按钮确认输入。
工作人员使用上述功能确定TB信息以及各类型TB之间的连接关系之后，可以点击Gen(generation，生成)按钮，从而可以得到记录有TB信息以及各类型TB之间的连接关系的拓扑文件，拓扑文件成功生成之后，上述界面会弹窗提醒工作人员生成成功，如图6中所示，弹窗的内容可以是“generate topo file successfully(成功生成拓扑文件)！”。
在本申请实施例提供的芯片验证方案中，从软件层面来说，各类型TB中包含不同的组件或模块，这些组件共同实现了本申请实施例提供的芯片验证方案，下面结合图7进行说明。
参见图7，为申请实施例提供的第二种芯片验证系统的结构示意图。
首先对图7所示的管理TB进行介绍。
可以看出，管理TB中主要包含管理数据socket对比代理(master_data_socket_checker_agent)模块以及socket控制进程(socket_control_process)模块两个模块，下面分别进行介绍。
1、master_data_socket_checker_agent模块。
包含EVT_SYNC组件、CFG_SYNC组件、Data Pkt Rec Thread组件、验证(Checker)组件以及Data Pkt Socket组件等组件。其中，
Data Pkt Socket组件用于采用Socket方式与子TB建立业务通道；
EVT_SYNC组件用于对事件进行同步；
CFG_SYNC组件用于对配置信息进行同步；
Data Pkt Rec Thread组件用于创建和维护基于业务通道接收业务信息的线程，例如，接收子TB发送的仿真结果或仿真输入信号；
Checker组件用于根据接收到的仿真输入信号和仿真结果进行对比，确定芯片是否通过验证。
2、socket_control_process模块。
包含事件进程(EVT_Process)组件、消息进程(Msg Process)组件、拓扑进程(Topo Process)组件以及Control Socket组件等组件。其中，
Control Socket组件用于采用Socket方式与子TB建立控制通道；
EVT_Process组件和Msg Process组件用于基于控制通道向子TB发送事件和消息，包括消息处理和分发，事件处理和分发等；
Topo Process组件用于解析本地存储的拓扑文件。
再以下方左侧的子TB为例对子TB进行介绍。
可以看出，子TB中包含虚拟数据传输代理(virtual_data_transfer_agent)模块以及各组件，下面分别进行介绍。
1、ETH_DUT。
表示子TB本地部署的本地子DUT文件。
2、TXIF_DRV_AGT组件。
将通过业务通道接收到的接口时序发给ETH_DUT作为DVA TX方向的激励信号。其中，DVA TX方向为预先定义的方向，表示图中由左至右的方向。
3、RXIF_MON_AGT组件
采集ETH_DUT在DVA RX方向上产生的接口时序，并将其转换为业务通道的信息。其中，DVA RX方向为预先定义的方向，表示图中由右至左的方向。
4、virtual_data_transfer_agent模块。
包括数据流驱动和接收线程(Data Stream Drv&Rec Thread)组件、EVT_SYNC组件、CFG_SYNC组件、数据流SOCKET(DATA_SREAM SOCKET)组件等组件。其中，
DATA_SREAM SOCKET组件用于采用Socket方式与相邻子TB建立数据通道；
EVT_SYNC组件用于对事件进行同步；
CFG_SYNC组件用于对配置信息进行同步；
Data Stream Drv&Rec Thread组件用于创建和维护基于数据通道接收或发送数据的线程。
5、socket控制进程(socket_control_process)组件。
用于实现基于控制通道与管理TB之间的通信，一方面，接收管理TB发送的控制消息，另一方面，将当前子TB的信息和事件发送给管理TB进行处理。上述当前子TB的信息和事件可以是TB信息、用于同步的信息等。
6、socket数据进程(socket_data_process)组件。
用于实现向管理TB发送TXIF_DRV_AGT组件产生的DVA TX方向的激励信号以及RXIF_MON_AGT组件采集的DVA RX方向上产生的接口时序信息。
其中，图7中除虚线矩形框之外的矩形框表示的组件均可以称为DVA(Distributed Verification Acceleration，分布式验证加速)组件。
可以看出，通过在管理TB以及子TB中集成上述DVA组件，就可以基于上述DVA组件实现本申请实施例提供的芯片验证方案，下面通过举例进行具体说明。
例如，现有技术在对芯片的BT(Block Testbench，模块级验证平台)级验证结束之后，将上述组件集成至各BT级验证流程中使用的TB，就可以直接进行IT(Integration Testbench，子系统验证平台)级或ST(SoC Testbench，系统验证平台)级的验证，而无需重新搭建进行IT级或ST级验证的专用环境，这样可以更加快速的启动IT和ST级的芯片验证，提高了芯片的验证效率。
下面再结合图8a以及图8b所示的具体举例对本申请实施例提供的芯片验证流程进行说明。
参见图8a以及图8b，为本申请实施例提供的第四种芯片验证方法的信令交互图，其中，第一仿真TB和第二仿真TB均为子TB，第一仿真TB对应前述头部TB，第二仿真TB为除头部TB之外的子TB，可以是前述中间TB，也可以是前述尾部TB。
以下从各类型TB执行时序的角度，对图8a以及图8b所示的芯片验证方法进行说明，下面提及的Tn、Tn+1仅表示步骤执行的先后关系。
T1：管理TB启动验证流程。
本步骤中，管理TB启动验证流程，可以理解为，管理TB准备建立各种传输通道，为业务仿真任务的执行做准备。
T2：管理TB解析拓扑文件，第一仿真TB和第二仿真TB启动验证流程。
本步骤中，第一仿真TB和第二仿真TB启动验证流程，可以理解为，第一仿真TB和第二仿真TB开始并行的运行各自本地部署的子DUT文件，但此时还没有生成仿真输入信号，所以各子TB不会产生针对仿真输入信号的运行结果。
T3：管理TB建立控制server。
T4：第一仿真TB和第二仿真TB建立控制client。
由T1-T2可知管理TB在第一仿真TB和第二仿真TB之前启动验证流程，这样管理TB可以提前建立控制server，使得第一仿真TB和第二仿真TB建立控制client之后可以直接连接到上述server。
T5：第一仿真TB和第二仿真TB向管理TB发送控制通信连接建立请求。
T6：管理TB建立控制通信连接，基于控制通信连接启动本地的控制线程，第一仿真TB和第二仿真TB基于控制通信连接启动本地的控制线程。
也就是管理TB与第一仿真TB和第二仿真TB之间的控制通道建立完毕。
T7：第一仿真TB和第二仿真TB通过自身与管理TB之间的控制通道发送TB信息。
T8：管理TB基于TB信息更新拓扑文件。
T9：管理TB通过自身与第一仿真TB之间的控制通道将更新后的拓扑文件同步到第一仿真TB，并通过自身与第二仿真TB之间的控制通道将更新后的拓扑文件同步到第二仿真TB。
T10：第一仿真TB和第二仿真TB接收更新后的拓扑文件。
T11：管理TB通过自身与第一仿真TB之间的控制通道发送业务通道建立消息，并通过自身与第二仿真TB之间的控制通道发送业务通道建立消息。
本步骤中，管理TB可以根据前述步骤T2中对拓扑文件的解析结果，确定待建立业务通道的第二仿真TB，然后通过与上述第二仿真TB之间的控制通道向上述第二仿真TB发送业务通道建立消息。
由前述实施例可知，上述待建立业务通道的第二仿真TB即为尾部TB。
T12：管理TB建立业务server。
T13：第一仿真TB和第二仿真TB向管理TB发送业务通道建立请求。
T14：管理TB建立业务通道。
上述步骤T11-T14中管理TB建立业务通道的方式可以在前述T3-T6中描述的控制通道建立方式的 基础上得到，这里不再赘述。
T15：管理TB通过自身与相邻的仿真TB之间的控制通道发送数据通道建立消息。
本步骤中，管理TB可以根据前述步骤T2中对拓扑文件的解析结果，确定相邻的仿真TB。
上述相邻的仿真TB对应前述相邻子TB。
T16：相邻的仿真TB之间建立数据通道。
上述步骤T15-T16中相邻的仿真TB之间建立数据通道的具体方式可以在前述T3-T6中描述的控制通道建立方式的基础上得到，这里不再赘述。
T17：管理TB、第一仿真TB以及第二仿真TB同步信息到内部组件。
上述各类TB之间同步的信息可以是验证流程中所需用到的任意信息。
T18：第一仿真TB和第二仿真TB通过自身与管理TB之间的控制通道发送DUT初始化配置完毕消息。
T19：管理TB通过自身与第一仿真TB之间的控制通道控制第一仿真TB启动验证。
管理TB接收到DUT初始化配置完毕消息之后，可以开始控制第一仿真TB启动验证，此时第一仿真TB开始生成仿真输入信号，业务仿真任务开始执行。
T20：第一仿真TB生成仿真输入信号，基于仿真输入信号运行本地部署的第一子DUT文件得到中间结果。
T21：第一仿真TB通过自身与管理TB之间的业务通道向管理TB发送仿真输入信号。
T22：第一仿真TB通过自身与相邻仿真TB之间的数据通道向部署有第一子DUT文件的下游子DUT文件的仿真TB发送所得中间结果。
T23：第二仿真TB接收部署有第二子DUT文件的上游子DUT文件的仿真TB发送的中间结果，以所接收中间结果为输入信号运行第二子DUT文件得到中间结果。
T24：若第二子DUT文件存在下游子DUT文件，第二仿真TB通过自身与相邻仿真TB之间的数据通道向部署有第二子DUT文件的下游子DUT文件的仿真TB发送所得中间结果。
上述部署有第二子DUT文件的下游子DUT文件的仿真TB也即第二仿真TB的下游TB。
本步骤中，若第二子DUT文件存在下游子DUT文件，表示第二仿真TB为中间TB，其可以通过自身与下游TB之间的数据通道向下游TB发送所得中间结果。
T25：若第二子DUT文件不存在下游子DUT文件，第二仿真TB通过自身与管理TB之间的业务通道将所得中间结果作为仿真结果向管理TB反馈。
本步骤中，若第二子DUT文件不存在下游子DUT文件，表示第二仿真TB为尾部TB，那么其得到的中间结果即为仿真结果，其可以通过自身与管理TB之间的业务通道将所得中间结果作为仿真结果向管理TB反馈。
T26：管理TB基于仿真输入信号获得业务仿真任务的基准结果，并根据基准结果和仿真结果，对芯片进行验证。
上述T26的实施方式与前述图2所示实施例中步骤S206相同，这里不再赘述。
T27：管理TB检测到验证结束，销毁业务线程。
T28：管理TB通过自身与第一仿真TB之间的控制通道控制第一仿真TB关闭数据通道和业务通道，并通过自身与第二仿真TB之间的控制通道控制第二仿真TB关闭数据通道和业务通道。
T29：第一仿真TB和第二仿真TB关闭数据通道和业务通道。
T30：管理TB通过自身与第一仿真TB之间的控制通道控制第一仿真TB关闭控制通道，并通过自身与第二仿真TB之间的控制通道控制第二仿真TB关闭控制通道。
T31：第一仿真TB和第二仿真TB关闭控制通道。
T32：管理TB、第一仿真TB以及第二仿真TB结束验证流程。
与上述芯片验证系统相对应的，本申请实施例还提供了分别应用于芯片验证系统中管理TB以及仿真TB包括的子TB的芯片验证方法，下面分别进行介绍。
首先对应用于芯片验证系统中管理TB的芯片验证方法进行介绍。
参见图9，为本申请实施例提供的第五种芯片验证方法的流程示意图，应用于芯片验证系统中的管理TB，上述方法包括以下步骤S901-步骤S904。
步骤S901：通过控制通道控制头部TB启动验证。
以使得头部TB生成仿真输入信号。
步骤S902：接收头部TB通过业务通道发送的仿真输入信号。
步骤S903：接收尾部TB通过业务通道反馈的针对业务仿真任务的仿真结果。
由前述系统实施例可知，头部TB生成仿真输入信号之后，可以将仿真输入信号输入本地运行的本地DUT文件得到中间结果，并通过数据通道向下游TB发送所得中间结果，然后中间TB可以基于上游TB发送的中间结果得到中间结果，通过自身与下游TB之间的数据通道向下游TB发送所得中间结果，进而尾部TB可以接收上游TB发送的中间结果，以所接收中间结果为输入信号运行本地部署的本地子DUT文件得到仿真结果
步骤S904：基于仿真输入信号获得业务仿真任务的基准结果，并根据基准结果和仿真结果，对芯片进行验证。
上述步骤S901-步骤904的实施方式可以在前述图2-图4所示实施例的基础上得到，区别仅为突出了管理TB的执行内容，这里不再赘述。
由以上可见，应用本申请实施例提供的方案进行芯片验证时，管理TB控制头部TB启动验证之后，可以接收头部TB通过业务通道发送的仿真输入信号以及尾部仿真TB通过业务通道反馈的仿真结果，从而可以基于仿真输入信号获得业务仿真任务的基准结果，并根据基准结果和仿真结果，对芯片进行验证。其中，在芯片验证的过程中，芯片的仿真结果是由包括头部TB和尾部TB在内的多个子TB共同得到的，在获得仿真结果时，各个子TB是并行执行的。由于运行DUT文件得到仿真结果这一过程往往需要耗费较多计算资源、耗时较长，而上述方案中各子TB可以并行执行、使用各自的计算资源协力得到仿真结果，这样减少了获得仿真结果时的耗时，提高了仿真结果的获得效率，从而提高了基于仿真结果验证芯片时的效率。
在图9所示实施例的基础上可知，管理TB与子TB之间进行信息交互之前需要先建立控制通道和业务通道，子TB与子TB之间进行数据交互之前需要先建立数据通道。鉴于上述情况，本申请实施例提供了第六种芯片验证方法。
参见图10，为本申请实施例提供的第六种芯片验证方法的流程示意图，应用于管理TB，上述方法包括以下步骤S1001-步骤S1005。
步骤S1001：与各子TB建立控制通道、与头部TB和尾部TB建立业务通道，并控制相邻子TB建立数据通道。
上述传输通道建立的具体方式已在前述图4所示实施例中说明，区别仅为本步骤突出了管理TB的执行内容，下面进行简要描述。
首先对管理TB与各子TB建立控制通道的方式进行说明。
具体的，管理TB接收到子TB所建立的控制客户端发送的连接请求后，与控制客户端建立控制通信连接，基于控制通信连接启动本地的控制线程。
可见，管理TB和各子TB均在本地基于控制通信连接建立了控制线程，使得上述控制线程可以专用于进行管理TB和各子TB之间控制消息的接收与发送，使得控制消息的交互与其他信息不产生交互混淆，有利于提高管理TB和各子TB之间的控制消息交互效率。
再对管理TB与头部TB、尾部TB建立业务通道的方式进行说明。
具体的，管理TB建立业务服务端，接收到头部TB和尾部TB发送的连接请求后，与头部TB、尾部建立业务通信连接，并基于业务通信连接启动本地的业务线程。
可见，管理TB在本地基于业务通信连接建立了业务线程，使得上述业务线程可以专用于进行管理TB和头部TB、尾部TB之间业务信息的接收与发送，使得业务信息的交互与其他类型的信息不产生交互混淆，有利于提高管理TB与头部TB、尾部TB之间的业务信息交互效率。
最后对管理TB控制相邻子TB建立数据通道的方式进行说明。
具体的，管理TB可以获得拓扑文件，接收各子TB通过自身与管理TB之间的控制通道发送的TB信息，根据接收到的TB信息更新拓扑文件，基于更新后的拓扑文件确定相邻子TB，然后通过自身与确定出的相邻子TB之间的控制通道向相邻子TB发送控制消息，并向各子TB同步更新后的拓扑文件，以使得接收到控制消息的相邻子TB基于接收到的拓扑文件与相邻子TB建立数据通道。
可见，管理TB可以根据更新后的拓扑文件确定出相邻子TB，然后将更新后拓扑文件同步至各子TB，并指示相邻子TB之间建立数据通道，从而子TB可以基于上述更新后的拓扑文件准确的确定出与自身相邻的子TB，并与上述子TB建立数据通道。另外，上述数据线程可以专用于进行相邻子TB之间的数据接收与发送，使得上述数据的交互与其他类型的信息不产生交互混淆，有利于提高相邻子TB之间的数据交互效率。
步骤S1002：通过控制通道控制头部TB启动验证。
步骤S1003：接收头部TB通过业务通道发送的仿真输入信号。
步骤S1004：接收尾部TB通过业务通道反馈的针对业务仿真任务的仿真结果。
步骤S1005：基于仿真输入信号获得业务仿真任务的基准结果，并根据基准结果和仿真结果，对芯片进行验证。
上述步骤S1002-步骤S1005的实施方式可以在前述图2-图4所示实施例的基础上得到，区别仅为突出了管理TB的执行内容，这里不再赘述。
由以上可见，管理TB与各子TB之间建立控制通道、与头部TB和尾部TB建立业务通道，并控制相邻子TB建立数据通道，上述不同类型的传输通道可以用于进行不同类型的信息或数据的传输业务，这样可以将不同维度的传输业务相互分离，有利于避免不同的传输业务之间相互混淆，有利于提高信息和数据的传输效率。
本申请的一个实施例中，上述步骤还包括：管理TB确定芯片验证结束后，通过自身与各子TB之间的控制通道向各子TB发送验证结束消息，以使得各子TB关闭与自身之间的业务通道、控制通道以及相邻子TB之间的数据通道。
这样在芯片验证结束后，管理TB可以及时的控制子TB断开与自身的控制通道、业务通道，并控制相邻子TB断开数据通道，从而可以及时释放上述传输通道占用的内存。
下面对应用于芯片验证系统中仿真TB包括的子TB的芯片验证方法进行介绍。
其中，由前述实施例可知，子TB可以为头部TB，可以为中间TB，也可以为尾部TB，下面分别通过图11-图13进行介绍。
参见图11，为本申请实施例提供的第七种芯片验证方法的流程示意图，应用于头部TB，上述方法包括以下步骤S1101-步骤S1103。
步骤S1101：响应于管理TB的启动验证控制，生成仿真输入信号。
步骤S1102：基于仿真输入信号运行本地部署的本地子DUT文件得到中间结果。
步骤S1103：通过业务通道向管理TB发送仿真输入信号，并通过数据通道向下游TB发送所得中间结果。
上述步骤S1101-步骤S1103的实施方式可以在前述图2-图4所示实施例的基础上得到，区别仅为突出了头部TB的执行内容，这里不再赘述。
参见图12，为本申请实施例提供的第八种芯片验证方法的流程示意图，应用于中间TB，上述方法包括以下步骤S1201-步骤S1203。
步骤S1201：接收上游TB发送的中间结果。
步骤S1202：以所接收中间结果为输入信号运行本地部署的本地子DUT文件得到中间结果。
步骤S1203：通过自身与下游TB之间的数据通道向下游TB发送所得中间结果。
上述步骤S1201-步骤S1203的实施方式可以在前述图2-图4所示实施例的基础上得到，区别仅为突出了中间TB的执行内容，这里不再赘述。
参见图13，为本申请实施例提供的第九种芯片验证方法的流程示意图，应用于尾部TB，上述方法包括以下步骤S1301-步骤S1303。
步骤S1301：接收上游TB发送的中间结果。
步骤S1302：以所接收中间结果为输入运行本地部署的本地子DUT文件得到仿真结果。
步骤S1303：通过业务通道向管理TB发送仿真结果，以使得管理TB基于仿真输入信号和仿真结果对所述芯片进行验证。
上述步骤S1301-步骤S1303的实施方式可以在前述图2-图4所示实施例的基础上得到，区别仅为突出了尾部TB的执行内容，这里不再赘述。
结合上述图11-图13所示实施例可知，在芯片验证过程中，芯片的仿真结果是由头部TB、中间TB和尾部TB共同得到的，各子TB得到中间结果后，一方面，各子TB向其下游的仿真TB发送所得到的中间结果，以使得其下游TB基于接收到的中间结果得到新的中间结果，另一方面，各子TB自身同时可以继续运行本地部署的子DUT文件得到中间结果。也就是，在获得仿真结果时，各子TB是并行执行的。由于运行DUT文件得到仿真结果这一过程往往需要耗费较多计算资源、耗时较长，而上述方案中各子TB可以并行执行、使用各自的计算资源协力得到仿真结果，这样减少了获得仿真结果时的耗时，提高了仿真结果的获得效率，从而提高了基于仿真结果验证芯片时的效率
并且，头部TB和尾部TB分别通过业务通道向管理TB反馈仿真输入信号和仿真结果，各子TB 通过数据通道向其他子TB发送所得中间结果，由以上可见，不同类型的信息或数据通过上述不同类型的传输通道传输，这样可以将不同维度的传输业务相互分离，有利于避免不同的传输业务之间相互混淆，有利于提高信息和数据的传输效率。
本公开的一个实施例中，头部TB生成仿真输入信号之前，还包括以下步骤：
各子TB与管理TB建立控制通道，若子TB为头部TB或尾部TB，与所述管理TB建立业务通道，各子TB与相邻子TB建立数据通道。
这样可以使得不同类型的信息或数据通过上述不同类型的传输通道传输，这样可以将不同维度的传输业务相互分离，有利于避免不同的传输业务之间相互混淆，有利于提高信息和数据的传输效率。
下面对上述各类型的传输通道的建立方式进行说明。
上述传输通道建立的具体方式已在前述图4所示实施例中说明，下面进行简要描述。
首先对各子TB与管理TB建立控制通道的方式进行说明。
具体的，各子TB建立控制客户端，在成功建立控制客户端后，与管理TB建立的控制服务端建立控制通信连接，基于控制通信连接启动本地的控制线程。
可见，各子TB在本地基于控制通信连接建立了控制线程，使得上述控制线程可以专用于进行管理TB和各子TB之间控制消息的接收与发送，使得控制消息的交互与其他类型信息不产生交互混淆，有利于提高管理TB和各子TB之间的控制消息交互效率。
再对头部TB、尾部TB与管理TB建立业务通道的方式进行说明。
具体的，头部仿真TB和尾部TB可以与管理TB建立业务通信连接，基于业务通信连接启动本地的业务线程。
可见，头部TB、尾部TB在本地基于业务通信连接建立了业务线程，使得上述业务线程可以专用于进行管理TB和头部TB、尾部TB之间业务信息的接收与发送，使得业务信息的交互与其他类型信息的不产生交互混淆，有利于提高管理TB和头部TB、尾部TB之间的业务信息交互效率。
最后对相邻子TB建立数据通道的方式进行说明。
具体的，各子TB通过自身与管理TB之间的控制通道向管理TB发送TB信息，接收管理TB发送的基于TB信息更新后的拓扑文件，基于拓扑文件确定相邻子TB，然后与确定出的相邻子TB建立数据通信连接，并根据数据通信连接启动本地的数据线程。
可见，各子TB可以基于管理TB发送的更新后的拓扑文件准确的确定出与自身相邻的子TB，并与上述子TB建立数据通道。另外，上述数据线程可以专用于进行各子TB与相邻子TB之间的数据接收与发送，使得数据的交互与其他类型信息不产生交互混淆，有利于提高相邻子TB之间的数据交互效率。
本申请的一个实施例中，管理TB基于仿真输入信号和仿真结果对芯片进行验证之后，还包括：各子TB响应于管理TB通过自身与各子TB之间的控制通道发送的验证结束消息，关闭与管理TB之间的业务通道、与相邻子TB之间的数据通道以及与管理TB之间的控制通道。
这样在芯片验证结束后，各子TB可以及时断开与管理TB之间的控制通道、业务通道，并断开与相邻子TB之间的数据通道，从而可以及时释放上述传输通道占用的内存。
与上述芯片验证系统相对应的，本申请实施例还提供了分别应用于管理TB以及仿真TB的芯片验证装置，下面分别进行介绍。
参见图14，为本申请实施例提供的第一种芯片验证装置的结构示意图，上述装置包括以下模块：
控制模块1401，用于通过控制通道控制头部TB启动验证，以使得所述头部TB生成仿真输入信号，所述头部TB为：部署有业务仿真任务的首个子DUT文件的子TB；
业务信息接收模块1402，用于接收头部TB通过业务通道发送的所述仿真输入信号；接收尾部TB通过业务通道反馈的针对所述业务仿真任务的仿真结果，所述尾部TB为：部署有业务仿真任务的最后一个子DUT文件的子TB；
芯片验证模块1403，用于基于所述仿真输入信号获得所述业务仿真任务的基准结果，并根据所述基准结果和所述仿真结果，对所述芯片进行验证。
由以上可见，应用本申请实施例提供的方案进行芯片验证时，管理TB控制头部TB启动验证之后，可以接收头部TB通过业务通道发送的仿真输入信号以及尾部仿真TB通过业务通道反馈的仿真结果，从而可以基于仿真输入信号获得业务仿真任务的基准结果，并根据基准结果和仿真结果，对芯片进行验证。其中，在芯片验证的过程中，芯片的仿真结果是由包括头部TB和尾部TB在内的多个子TB共同得到的，在获得仿真结果时，各个子TB是并行执行的。由于运行DUT文件得到仿真结果这一过程往往需要耗费较多计算资源、耗时较长，而上述方案中各子TB可以并行执行、使用各自的计算资源协力 得到仿真结果，这样减少了获得仿真结果时的耗时，提高了仿真结果的获得效率，从而提高了基于仿真结果验证芯片时的效率。
本申请的一个实施例中，所述装置还包括：
通道建立模块，具体用于与各子TB建立控制通道、与所述头部TB和尾部TB建立业务通道、并控制相邻子TB建立数据通道，其中，相邻子TB所部署的子DUT文件具有上下游关系。
由以上可见，管理TB与各子TB之间建立控制通道、与头部TB和尾部TB建立业务通道，并控制相邻子TB建立数据通道，上述不同类型的传输通道可以用于进行不同类型的信息或数据的传输业务，这样可以将不同维度的传输业务相互分离，有利于避免不同的传输业务之间相互混淆，有利于提高信息和数据的传输效率。
本申请的一个实施例中，所述通道建立模块，具体用于建立控制服务端；接收到子TB所建立的控制客户端发送的连接请求后，与所述控制客户端建立控制通信连接；基于所述控制通信连接启动本地的控制线程。
可见，管理TB和各子TB均在本地基于控制通信连接建立了控制线程，使得上述控制线程可以专用于进行管理TB和各子TB之间控制消息的接收与发送，使得控制消息的交互与其他信息不产生交互混淆，有利于提高管理TB和各子TB之间的控制消息交互效率。
本申请的一个实施例中，所述通道建立模块，具体用于获得拓扑文件；接收各子TB通过自身与所述管理TB之间的控制通道发送的TB信息；根据接收到TB信息更新所述拓扑文件；基于更新后的拓扑文件确定所部署子DUT文件具有上下游关系的相邻子TB；通过自身与确定出的相邻子TB之间的控制通道向相邻子TB发送控制消息，并向各子TB同步更新后的拓扑文件，以使得接收到所述控制消息的相邻子TB基于接收到的拓扑文件与相邻子TB建立数据通道。
可见，管理TB可以根据更新后的拓扑文件确定出相邻子TB，然后将更新后拓扑文件同步至各子TB，并指示相邻子TB之间建立数据通道，从而子TB可以基于上述更新后的拓扑文件准确的确定出与自身相邻的子TB，并与上述子TB建立数据通道。另外，上述数据线程可以专用于进行相邻子TB之间的数据接收与发送，使得数据的交互与其他信息不产生交互混淆，有利于提高相邻子TB之间的数据交互效率。
本申请的一个实施例中，所述通道建立模块，具体用于建立业务服务端；接收到所述头部TB和尾部TB发送的连接请求后，与所述头部TB和尾部TB建立业务通信连接；基于所述业务通信连接启动本地的业务线程。
可见，管理TB在本地基于业务通信连接建立了业务线程，使得上述业务线程可以专用于进行管理TB和头部TB、尾部TB之间业务信息的接收与发送，使得业务信息的交互与其他信息不产生交互混淆，有利于提高管理TB和头部TB、尾部TB之间的业务信息交互效率。
本申请的一个实施例中，所述装置还包括：
结束消息发送模块，用于确定芯片验证结束后，通过自身与各子TB之间的控制通道向各子TB发送验证结束消息，以使得各子TB关闭与自身之间的业务通道、控制通道以及相邻子TB之间的数据通道。
这样在芯片验证结束后，管理TB可以及时的控制子TB断开与自身的控制通道、业务通道，并控制相邻子TB断开数据通道，从而可以及时释放上述传输通道占用的内存。
参见图15，为本申请实施例提供的第二种芯片验证装置的结构示意图，应用于芯片验证系统中仿真TB包括的子TB，上述装置包括：
控制响应模块1501，用于若所述仿真TB为头部TB，响应于所述管理TB的启动验证控制，生成仿真输入信号，基于所述仿真输入信号运行本地部署的本地子DUT文件得到中间结果，所述头部TB为：部署有业务仿真任务的首一个子DUT文件的子TB；
数据收发模块1502，用于若所述仿真TB为头部TB，通过数据通道向下游TB发送所得中间结果；若所述子TB为中间TB，接收上游TB发送的中间结果，以所接收中间结果为输入运行本地部署的本地子DUT文件得到中间结果，通过自身与下游TB之间的数据通道向下游TB发送所得中间结果；若所述子TB为尾部TB，接收上游TB发送的中间结果，以所接收中间结果为输入运行本地部署的本地子DUT文件得到仿真结果,其中，所述尾部TB为：部署有业务仿真任务的最后一个子DUT文件的子TB，所述中间TB为除头部TB和尾部TB之外的子TB，下游TB部署的子DUT文件为本地子DUT文件的下游子DUT文件，上游TB部署的子DUT文件为本地子DUT文件的上游子DUT文件；
业务信息发送模块1503，用于若所述仿真TB为头部TB，通过业务通道向所述管理TB发送所述 仿真输入信号；若所述子TB为尾部TB，通过业务通道向所述管理TB发送所述仿真结果，以使得所述管理TB基于所述仿真输入信号和所述仿真结果对所述芯片进行验证。
结合以上可知，在芯片验证过程中，芯片的仿真结果是由头部TB、中间TB和尾部TB共同得到的，各子TB得到中间结果后，一方面，各子TB向其下游的仿真TB发送所得到的中间结果，以使得其下游TB基于接收到的中间结果得到新的中间结果，另一方面，各子TB自身同时可以继续运行本地部署的子DUT文件得到中间结果。也就是，在获得仿真结果时，各子TB是并行执行的。由于运行DUT文件得到仿真结果这一过程往往需要耗费较多计算资源、耗时较长，而上述方案中各子TB可以并行执行、使用各自的计算资源协力得到仿真结果，这样减少了获得仿真结果时的耗时，提高了仿真结果的获得效率，从而提高了基于仿真结果验证芯片时的效率
并且，头部TB和尾部TB分别通过业务通道向管理TB反馈仿真输入信号和仿真结果，各子TB通过数据通道向其他子TB发送所得中间结果，由以上可见，不同类型的信息或数据通过上述不同类型的传输通道传输，这样可以将不同维度的传输业务相互分离，有利于避免不同的传输业务之间相互混淆，有利于提高信息和数据的传输效率。
本申请的一个实施例中，在所述控制响应模块1501之前，还包括：
控制通道建立模块，用于与所述管理TB建立控制通道；
业务通道建立模块，用于若所述子TB为头部TB或尾部TB，与所述管理TB建立业务通道；
数据通道建立模块，用于与相邻子TB建立数据通道，其中，相邻子TB所部署的子DUT文件具有上下游关系。
这样在芯片验证结束后，各子TB可以及时断开与管理TB之间的控制通道、业务通道，并断开与相邻子TB之间的数据通道，从而可以及时释放上述传输通道占用的内存。
本申请的一个实施例中，所述控制通道建立模块，具体用于建立控制客户端；在成功建立控制客户端后，与所述管理TB建立的控制服务端建立控制通信连接；基于所述控制通信连接启动本地的控制线程。
可见，各子TB在本地基于控制通信连接建立了控制线程，使得上述控制线程可以专用于进行管理TB和各子TB之间控制消息的接收与发送，使得控制消息的交互与其他信息不产生交互混淆，有利于提高管理TB和各子TB之间的控制消息交互效率。
本申请的一个实施例中，所述数据通道建立模块，具体用于通过自身与所述管理TB之间的控制通道向所述管理TB发送TB信息；接收所述管理TB发送的基于TB信息更新后的拓扑文件；基于所述拓扑文件确定相邻子TB；与确定出的相邻子TB建立数据通信连接；根据所述数据通信连接启动本地的数据线程。
可见，各子TB可以基于管理TB发送的更新后的拓扑文件准确的确定出与自身相邻的子TB，并与上述子TB建立数据通道。另外，上述数据线程可以专用于进行各子TB与相邻子TB之间的数据接收与发送，使得数据的交互与其他信息不产生交互混淆，有利于提高相邻子TB之间的数据交互效率。
本申请的一个实施例中，所述业务通道建立模块，具体用于若所述仿真TB为头部TB或尾部TB，与所述管理TB建立的业务服务端建立业务通信连接；基于所述业务通信连接启动本地的业务线程。
可见，头部TB和尾部TB在本地基于业务通信连接建立了业务线程，使得上述业务线程可以专用于进行管理TB与头部TB和尾部TB之间业务信息的接收与发送，使得业务信息的交互与其他信息不产生交互混淆，有利于提高管理TB和头部TB、尾部TB之间的业务信息交互效率。
本申请的一个实施例中，所述装置还包括：
通道关闭模块，用于响应于所述管理TB通过自身与各子TB之间的控制通道发送的验证结束消息，关闭与所述管理TB之间的业务通道、与相邻子TB之间的数据通道以及与所述管理TB之间的控制通道。
这样在芯片验证结束后，各子TB可以及时断开与管理TB之间的控制通道、业务通道，并断开与相邻子TB之间的数据通道，从而可以及时释放上述传输通道占用的内存。
本申请实施例还提供了一种验证平台，如图16所示，处理器1601和机器可读存储介质1602，所述机器可读存储介质1602存储有能够被所述处理器执行的机器可执行指令，所述处理器1601被所述机器可执行指令促使：实现前述应用于管理TB的芯片验证方法或应用于仿真TB的芯片验证方法。
上述机器可读存储介质可以包括随机存取存储器(Random Access Memory，RAM)，也可以包括非易失性存储器(Non-Volatile Memory，NVM)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。
上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
本申请实施例还提供了一种计算机可读存储介质，存储有机器可执行指令，在被处理器调用和执行时，所述机器可执行指令促使所述处理器：实现前述应用于管理TB的芯片验证方法或应用于仿真TB的芯片验证方法。
本申请实施例还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行前述应用于管理TB的芯片验证方法或应用于仿真TB的芯片验证方法。
以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (17)

  1. 一种芯片验证系统，其特征在于，包括：管理TB和仿真TB，所述仿真TB包括多个子TB，各子TB部署有芯片的DUT文件的不同子DUT文件，其中，
    所述管理TB，用于通过控制通道控制头部TB启动验证，所述头部TB为：部署有业务仿真任务的首个子DUT文件的子TB；
    所述头部TB，用于生成仿真输入信号，通过业务通道向所述管理TB发送所述仿真输入信号；
    各子TB，用于运行本地部署的子DUT文件得到中间结果，通过数据通道向其他子TB发送所得中间结果；
    尾部TB，用于得到针对所述业务仿真任务的仿真结果，通过业务通道向所述管理TB发送所述仿真结果，所述尾部TB为：部署有业务仿真任务的最后一个子DUT文件的子TB；
    所述管理TB，还用于基于所述仿真输入信号获得所述业务仿真任务的基准结果，并根据所述基准结果和所述仿真结果，对所述芯片进行验证。
  2. 根据权利要求1所述的系统，其特征在于，
    所述头部TB，具体用于基于所述仿真输入信号运行本地部署的本地子DUT文件得到中间结果；通过自身与下游TB之间的数据通道向下游TB发送所得中间结果，所述下游TB部署的子DUT文件为本地子DUT文件的下游子DUT文件；
    中间TB，用于接收上游TB发送的中间结果，以所接收中间结果为输入信号运行本地部署的本地子DUT文件得到中间结果，通过自身与下游TB之间的数据通道向下游TB发送所得中间结果，所述上游TB部署的子DUT文件为本地子DUT文件的上游子DUT文件，所述中间TB为：除所述头部TB和尾部TB之外的子TB；
    所述尾部TB，具体用于接收上游TB发送的中间结果，以所接收中间结果为输入信号运行本地部署的本地子DUT文件得到仿真结果。
  3. 根据权利要求1所述的系统，其特征在于，
    所述管理TB，具体用于建立控制服务端；
    各子TB，具体用于建立控制客户端，在成功建立控制客户端后，与所述控制服务端建立控制通信连接，基于所述控制通信连接启动本地的控制线程；
    所述管理TB，具体用于基于所述控制通信连接启动本地的控制线程。
  4. 根据权利要求1所述的系统，其特征在于，
    各子TB，具体用于通过自身与所述管理TB之间的控制通道向所述管理TB发送TB信息；
    所述管理TB，具体用于获得拓扑文件，根据所接收的TB信息更新所述拓扑文件，基于更新后的拓扑文件确定相邻子TB，通过自身与确定出的相邻子TB之间的控制通道向相邻子TB发送控制消息，并向各子TB同步更新后的拓扑文件，其中，所述拓扑文件用于记录所述管理TB和各子TB之间的拓扑关系、所述管理TB的TB信息以及各子TB的TB信息，相邻子TB所部署的子DUT文件具有上下游关系；
    相邻子TB，具体用于响应于所述控制消息，基于接收到的拓扑文件与相邻子TB建立数据通信连接，根据所述数据通信连接启动本地的数据线程。
  5. 根据权利要求2所述的系统，其特征在于，
    所述管理TB，具体用于建立业务服务端；
    所述头部TB和尾部TB，具体用于与所述业务服务端建立业务通信连接，基于所述业务通信连接启动本地的业务线程；
    所述管理TB，具体用于基于所述业务通信连接启动本地的业务线程。
  6. 根据权利要求2-5中任一项所述的系统，其特征在于，
    所述管理TB，还用于确定芯片验证结束后，通过所述管理TB与各子TB之间的控制通道，向各子TB发送验证结束消息；
    各子TB，还用于响应于所述验证结束消息，关闭与所述管理TB之间的业务通道、与相邻子TB之间的数据通道以及与所述管理TB之间的控制通道。
  7. 根据权利要求2-5中任一项所述的系统，其特征在于，
    所述控制通道传输的数据为：标签-长度-值TLV格式的数据；和/或
    所述业务通道传输的数据为：动态数组格式的变长报文；和/或
    所述数据通道传输的数据为：基于信号的SB模式或TB模式的数据。
  8. 一种芯片验证方法，其特征在于，应用于芯片验证系统中的管理TB，所述芯片验证系统还包括 仿真TB，所述仿真TB包括多个子TB，各子TB部署有芯片的DUT文件的不同子DUT文件；
    所述方法包括：
    通过控制通道控制头部TB启动验证，以使得所述头部TB生成仿真输入信号，所述头部TB为：部署有业务仿真任务的首个子DUT文件的子TB；
    接收所述头部TB通过业务通道发送的所述仿真输入信号；
    接收尾部TB通过业务通道反馈的针对所述业务仿真任务的仿真结果，所述尾部TB为：部署有业务仿真任务的最后一个子DUT文件的子TB；
    基于所述仿真输入信号获得所述业务仿真任务的基准结果，并根据所述基准结果和所述仿真结果，对所述芯片进行验证。
  9. 根据权利要求8所述的方法，其特征在于，在所述通过控制通道控制头部TB启动验证之前，还包括：
    与各子TB建立控制通道、与所述头部TB和尾部TB建立业务通道、并控制相邻子TB建立数据通道，其中，相邻子TB所部署的子DUT文件具有上下游关系。
  10. 根据权利要求9所述的方法，其特征在于，
    所述与各子TB建立控制通道，包括：建立控制服务端；接收到子TB所建立的控制客户端发送的连接请求后，与所述控制客户端建立控制通信连接；基于所述控制通信连接启动本地的控制线程；
    或
    所述控制相邻子TB建立数据通道，包括：获得拓扑文件；接收各子TB通过自身与所述管理TB之间的控制通道发送的TB信息；根据接收到的TB信息更新所述拓扑文件；基于更新后的拓扑文件确定相邻子TB；通过自身与确定出的相邻子TB之间的控制通道向相邻子TB发送控制消息，并向各子TB同步更新后的拓扑文件，以使得接收到所述控制消息的相邻子TB基于接收到的拓扑文件与相邻子TB建立数据通道；
    或
    所述与所述头部TB和尾部TB建立业务通道，包括：建立业务服务端；接收到所述头部TB和尾部TB发送的连接请求后，与所述头部TB和尾部TB建立业务通信连接；基于所述业务通信连接启动本地的业务线程；
    或
    所述方法还包括：确定芯片验证结束后，通过自身与各子TB之间的控制通道向各子TB发送验证结束消息，以使得各子TB关闭与自身之间的业务通道、控制通道以及相邻子TB之间的数据通道。
  11. 一种芯片验证方法，其特征在于，应用于芯片验证系统中仿真TB包括的子TB，所述芯片验证系统还包括管理TB，各子TB部署有芯片的DUT文件的不同子DUT文件；
    所述方法包括：
    若所述子TB为头部TB，响应于所述管理TB的启动验证控制，生成仿真输入信号，基于所述仿真输入信号运行本地部署的本地子DUT文件得到中间结果；通过业务通道向所述管理TB发送所述仿真输入信号，并通过数据通道向下游TB发送所得中间结果，所述下游TB部署的子DUT文件为本地子DUT文件的下游子DUT文件，所述头部TB为：部署有业务仿真任务的首一个子DUT文件的子TB；
    若所述子TB为中间TB，接收上游TB发送的中间结果，以所接收中间结果为输入运行本地部署的本地子DUT文件得到中间结果，通过自身与下游TB之间的数据通道向下游TB发送所得中间结果，其中，所述上游TB部署的子DUT文件为本地子DUT文件的上游子DUT文件，所述中间TB为：除所述头部TB和尾部TB之外的子TB；
    若所述子TB为尾部TB，接收上游TB发送的中间结果，以所接收中间结果为输入运行本地部署的本地子DUT文件得到仿真结果，通过业务通道向所述管理TB发送所述仿真结果，以使得所述管理TB基于所述仿真输入信号和所述仿真结果对所述芯片进行验证，其中，所述尾部TB为：部署有业务仿真任务的最后一个子DUT文件的子TB。
  12. 根据权利要求11所述的方法，其特征在于，所述生成仿真输入信号之前，还包括：
    与所述管理TB建立控制通道；
    若所述子TB为头部TB或尾部TB，与所述管理TB建立业务通道；
    与相邻子TB建立数据通道，其中，相邻子TB所部署的子DUT文件具有上下游关系。
  13. 根据权利要求12所述的方法，其特征在于，
    所述与所述管理TB建立控制通道，包括：建立控制客户端；在成功建立控制客户端后，与所述管理TB建立的控制服务端建立控制通信连接；基于所述控制通信连接启动本地的控制线程；
    或
    所述与相邻子TB建立数据通道，包括：通过自身与所述管理TB之间的控制通道向所述管理TB发送TB信息；接收所述管理TB发送的基于TB信息更新后的拓扑文件；基于所述拓扑文件确定相邻子TB；与确定出的相邻子TB建立数据通信连接；根据所述数据通信连接启动本地的数据线程；
    或
    所述与所述管理TB建立业务通道，包括：与所述管理TB建立的业务服务端建立业务通信连接；基于所述业务通信连接启动本地的业务线程；
    或
    所述方法还包括：响应于所述管理TB通过自身与各子TB之间的控制通道发送的验证结束消息，关闭与所述管理TB之间的业务通道、与相邻子TB之间的数据通道以及与所述管理TB之间的控制通道。
  14. 一种芯片验证装置，其特征在于，应用于芯片验证系统中的管理TB，所述芯片验证系统还包括仿真TB，所述仿真TB包括多个子TB，各子TB部署有芯片的DUT文件的不同子DUT文件；
    所述装置包括：
    控制模块，用于通过控制通道控制头部TB启动验证，以使得所述头部TB生成仿真输入信号，所述头部TB为：部署有业务仿真任务的首个子DUT文件的子TB；
    业务信息接收模块，用于接收所述头部TB通过业务通道发送的所述仿真输入信号；接收尾部TB通过业务通道反馈的针对所述业务仿真任务的仿真结果，所述尾部TB为：部署有业务仿真任务的最后一个子DUT文件的子TB；
    芯片验证模块，用于基于所述仿真输入信号获得所述业务仿真任务的基准结果，并根据所述基准结果和所述仿真结果，对所述芯片进行验证。
  15. 一种芯片验证装置，其特征在于，应用于芯片验证系统中仿真TB包括的子TB，所述芯片验证系统还包括管理TB，各子TB部署有芯片的DUT文件的不同子DUT文件；
    所述装置包括：
    控制响应模块，用于若所述仿真TB为头部TB，响应于所述管理TB的启动验证控制，生成仿真输入信号，基于所述仿真输入信号运行本地部署的本地子DUT文件得到中间结果，所述头部TB为：部署有业务仿真任务的首一个子DUT文件的子TB；
    数据收发模块，用于若所述仿真TB为头部TB，通过数据通道向下游TB发送所得中间结果；若所述子TB为中间TB，接收上游TB发送的中间结果，以所接收中间结果为输入运行本地部署的本地子DUT文件得到中间结果，通过自身与下游TB之间的数据通道向下游TB发送所得中间结果；若所述子TB为尾部TB，接收上游TB发送的中间结果，以所接收中间结果为输入运行本地部署的本地子DUT文件得到仿真结果,其中，所述尾部TB为：部署有业务仿真任务的最后一个子DUT文件的子TB，所述中间TB为除头部TB和尾部TB之外的子TB，下游TB部署的子DUT文件为本地子DUT文件的下游子DUT文件，上游TB部署的子DUT文件为本地子DUT文件的上游子DUT文件；
    业务信息发送模块，用于若所述仿真TB为头部TB，通过业务通道向所述管理TB发送所述仿真输入信号；若所述子TB为尾部TB，通过业务通道向所述管理TB发送所述仿真结果，以使得所述管理TB基于所述仿真输入信号和所述仿真结果对所述芯片进行验证。
  16. 一种验证平台，其特征在于，包括处理器和机器可读存储介质，所述机器可读存储介质存储有能够被所述处理器执行的机器可执行指令，所述处理器被所述机器可执行指令促使实现权利要求8-10或11-13中任一所述的方法步骤。
  17. 一种计算机可读存储介质，其特征在于，存储有机器可执行指令，在被处理器调用和执行时，所述机器可执行指令促使所述处理器实现权利要求8-10或11-13中任一所述的方法步骤。
PCT/CN2022/134106 2022-11-24 2022-11-24 一种芯片验证系统、方法、装置、设备及存储介质 Ceased WO2024108496A1 (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP22966012.1A EP4425337A4 (en) 2022-11-24 2022-11-24 Chip verification system, method and apparatus, device, and storage medium
PCT/CN2022/134106 WO2024108496A1 (zh) 2022-11-24 2022-11-24 一种芯片验证系统、方法、装置、设备及存储介质
CN202280004684.5A CN118401925A (zh) 2022-11-24 2022-11-24 一种芯片验证系统、方法、装置、设备及存储介质
US18/714,972 US20250278543A1 (en) 2022-11-24 2022-11-24 Chip verification system, method, device, apparatus and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/134106 WO2024108496A1 (zh) 2022-11-24 2022-11-24 一种芯片验证系统、方法、装置、设备及存储介质

Publications (1)

Publication Number Publication Date
WO2024108496A1 true WO2024108496A1 (zh) 2024-05-30

Family

ID=91194808

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/134106 Ceased WO2024108496A1 (zh) 2022-11-24 2022-11-24 一种芯片验证系统、方法、装置、设备及存储介质

Country Status (4)

Country Link
US (1) US20250278543A1 (zh)
EP (1) EP4425337A4 (zh)
CN (1) CN118401925A (zh)
WO (1) WO2024108496A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN119558269A (zh) * 2025-01-24 2025-03-04 格创通信(浙江)有限公司 一种芯片设计验证系统、方法

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN119420686B (zh) * 2024-11-27 2025-12-19 新华三半导体技术有限公司 一种芯片验证装置、方法、电子设备及存储介质
CN119397994B (zh) * 2024-12-31 2025-04-11 北京开源芯片研究院 片上网络的验证方法、装置、电子设备及可读存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106777665A (zh) * 2016-12-07 2017-05-31 盛科网络（苏州）有限公司 提高协同仿真平台验证效率的方法及系统
CN113342583A (zh) * 2021-06-08 2021-09-03 海光信息技术股份有限公司 芯片验证系统、方法、装置、设备和存储介质
US11308008B1 (en) * 2020-12-31 2022-04-19 Cadence Design Systems, Inc. Systems and methods for handling DPI messages outgoing from an emulator system
CN115086214A (zh) * 2022-06-13 2022-09-20 新华三半导体技术有限公司 一种套片检测系统、方法、电子设备及存储介质

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7051304B2 (en) * 2003-05-01 2006-05-23 Sun Microsystems, Inc. Distributed infiniband verification protocol

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106777665A (zh) * 2016-12-07 2017-05-31 盛科网络（苏州）有限公司 提高协同仿真平台验证效率的方法及系统
US11308008B1 (en) * 2020-12-31 2022-04-19 Cadence Design Systems, Inc. Systems and methods for handling DPI messages outgoing from an emulator system
CN113342583A (zh) * 2021-06-08 2021-09-03 海光信息技术股份有限公司 芯片验证系统、方法、装置、设备和存储介质
CN115086214A (zh) * 2022-06-13 2022-09-20 新华三半导体技术有限公司 一种套片检测系统、方法、电子设备及存储介质

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN119558269A (zh) * 2025-01-24 2025-03-04 格创通信(浙江)有限公司 一种芯片设计验证系统、方法

Also Published As

Publication number Publication date
EP4425337A1 (en) 2024-09-04
EP4425337A4 (en) 2025-03-05
US20250278543A1 (en) 2025-09-04
CN118401925A (zh) 2024-07-26

Similar Documents

Publication Publication Date Title
WO2024108496A1 (zh) 一种芯片验证系统、方法、装置、设备及存储介质
CN107612962B (zh) 一种分布式仿真评估试验管理系统
CN108809722A (zh) 一种部署Kubernetes集群的方法、装置和存储介质
CN112035216B (zh) 一种Kubernetes集群网络和OpenStack网络的打通方法
CN113946559B (zh) 数据处理方法、目标数据库系统及数据处理系统
CN116029242B (zh) 一种云原生的硬件逻辑仿真fpga加速方法及系统
CN112039722A (zh) 一种mqtt协议仿真方法及仿真设备
CN117170822B (zh) 使用分布式网络中间件的系统模型和代码联合仿真系统
WO2021233313A1 (zh) 配置端口状态的方法、装置、系统及存储介质
CN111382201A (zh) 异构数据库同步方法、装置、计算机设备及存储介质
CN111371578A (zh) 部署虚拟化网络功能的方法和装置
WO2021175105A1 (zh) 连接方法、装置、设备和存储介质
CN109756514B (zh) 一种航天器复杂协议的遥测数据动态处理方法
CN115952074B (zh) 片上系统的性能验证方法及装置
CN109062820A (zh) 一种软件性能测试方法和装置
US8254267B2 (en) Extensible traffic generator for synthesis of network data traffic
CN116056126A (zh) 仿真测试方法、装置、计算机设备和计算机可读存储介质
CN106990974A (zh) 一种app应用更新方法、装置及电子设备
CN118540256A (zh) 车载网络仿真测试方法、装置、设备、存储介质和程序产品
CN103152380B (zh) 分布式的仿真通信框架和通信效能计算方法
US20140026139A1 (en) Information processing apparatus and analysis method
CN109656674B (zh) 一种计算机设备、虚拟化芯片及数据传输方法
CN115967626A (zh) 交换机配置装置、车辆控制器、车辆及交换机配置方法
CN114741448A (zh) 一种Redis集群服务异地同步方法及装置
CN102740166B (zh) 一种远程视频插播的系统和方法

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 202280004684.5

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2022966012

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 18714972

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2022966012

Country of ref document: EP

Effective date: 20240529

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22966012

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 18714972

Country of ref document: US