Bus performance test method and device, storage medium and electronic equipment

Abstract

The application provides a bus performance test method and device, a storage medium and an electronic device, and relates to the chip design field. In the method, the electronic device acquires chip design code, wherein the chip design code designs a to-be-tested bus and a sending end and a receiving end capable of communicating through the to-be-tested bus; the chip design code is loaded into a simulation environment, and the used bandwidth and the bandwidth upper limit of the to-be-tested bus at present are acquired through the simulation environment; if the used bandwidth is less than the bandwidth upper limit, the data sending rate of the sending end is increased to obtain test information of the to-be-tested bus after the bandwidth upper limit is reached. In this way, the running effect of the chip is simulated in the simulation environment, and when the designed bandwidth upper limit cannot be reached, the sending rate of the sending end is automatically increased to promote the to-be-tested bus to reach the bandwidth upper limit, so that manual intervention is reduced, the verification period is shortened, and the production efficiency is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of chip design, in particular to a bus performance testing method and device, a storage medium and an electronic device. BACKGROUND

[0002] In the complex process of chip design, the verification of bus performance is a crucial link. This link not only needs to check whether the bus design can achieve the established bandwidth target, to ensure that it has sufficient data transmission capability to meet the efficient operation demand of the system. More importantly, it also needs to further study whether its performance can remain stable under extreme scenarios, that is, when the bus load reaches the maximum bandwidth.

[0003] In practice, it is found that the current traditional bus verification method still relies on manual intervention. This includes constantly adjusting and writing new test cases according to test feedback, which may lead to a long cycle of feedback and optimization, thereby affecting the overall efficiency of verification. SUMMARY

[0004] In order to overcome at least one deficiency in the prior art, the present application provides a bus performance testing method, device, storage medium and electronic device, which specifically includes:

[0005] In a first aspect, the present application provides a bus performance testing method, which includes:

[0006] Obtaining a chip design code, wherein the chip design code designs a to-be-tested bus and a sending end and a receiving end capable of communicating through the to-be-tested bus;

[0007] Loading the chip design code into a simulation environment, and obtaining the current used bandwidth and the bandwidth upper limit of the to-be-tested bus through the simulation environment;

[0008] If the used bandwidth is less than the bandwidth upper limit, increasing the data sending rate of the sending end to obtain the test information of the to-be-tested bus after reaching the bandwidth upper limit.

[0009] In combination with the optional implementation manner of the first aspect, the sending end includes a working core that sends data to the receiving end and a standby core that does not send data to the receiving end, and the increasing the data sending rate of the sending end includes:

[0010] Increasing the data sending rate of the working core; and / or

[0011] Selecting a target core from the standby core and configuring the target core as a working core that sends data to the receiving end.

[0012] In combination with the optional implementation of the first aspect, the working core comprises a configuration register for controlling the data transmission rate, and the method for increasing the data transmission rate of the working core comprises:

[0013] According to the bandwidth upper limit, a target transmission rate required by the working core is obtained;

[0014] The target transmission rate is mapped to a target configuration parameter of the configuration register through a parameter mapping relationship;

[0015] The configuration register is configured by using the target configuration parameter, so as to increase the data transmission rate of the working core.

[0016] In combination with the optional implementation of the first aspect, before the target transmission rate is mapped to the target configuration parameter of the configuration register through the parameter mapping relationship, the method further comprises:

[0017] A preset test transmission rate is mapped to a test configuration parameter through a theoretical mapping relationship, wherein the test transmission rate is less than the transmission rate required by the bandwidth upper limit;

[0018] An actual measurement transmission rate of the working core after the configuration register is configured by using the test configuration parameter is obtained;

[0019] According to the actual measurement transmission rate and the test transmission rate, a correction coefficient of the theoretical mapping relationship is obtained;

[0020] The theoretical mapping relationship is corrected through the correction coefficient, so as to obtain the parameter mapping relationship.

[0021] In combination with the optional implementation of the first aspect, the working core comprises a configuration register for controlling the data transmission rate, and the method for increasing the data transmission rate of the working core comprises:

[0022] The current residual bandwidth of the bus to be tested is obtained;

[0023] According to the current residual bandwidth, a target configuration parameter of the configuration register is determined, wherein the data transmission rate increased by the target configuration parameter is positively correlated with the residual bandwidth;

[0024] If the bus to be tested does not reach the bandwidth upper limit after the configuration register is configured by using the target configuration parameter, the step of obtaining the current residual bandwidth of the bus to be tested is executed until the bus to be tested reaches the bandwidth upper limit.

[0025] In combination with the optional implementation of the first aspect, the current bandwidth upper limit of the bus to be tested is obtained through the simulation environment, and the method comprises:

[0026] grabbing a data packet transmitted on the bus to be tested;

[0027] parsing state information of the bus to be tested from the data packet;

[0028] determining a current bandwidth upper limit of the bus to be tested according to the current state information.

[0029] With reference to the optional implementation manner of the first aspect, the sending end comprises a working core for sending data to the receiving end, and the working core comprises a state register of the bus to be tested, and the obtaining of the current bandwidth upper limit of the bus to be tested through the simulation environment comprises:

[0030] reading the state information in the state register;

[0031] determining the current bandwidth upper limit of the bus to be tested according to the state information.

[0032] With reference to the optional implementation manner of the first aspect, the obtaining of the current used bandwidth of the bus to be tested through the simulation environment comprises:

[0033] counting a data amount transmitted on the bus to be tested within a preset time length;

[0034] obtaining the current used bandwidth of the bus to be tested according to the data amount transmitted within the preset time length.

[0035] In a second aspect, the application further provides a bus performance testing device, which comprises:

[0036] a code simulation module for obtaining chip design code, wherein the chip design code designs a bus to be tested and a sending end and a receiving end capable of communicating through the bus to be tested;

[0037] the code simulation module is further configured to load the chip design code into a simulation environment and obtain a current used bandwidth and a bandwidth upper limit of the bus to be tested through the simulation environment;

[0038] a bus testing module for increasing a data sending rate of the sending end if the used bandwidth is less than the bandwidth upper limit, so as to obtain testing information of the bus to be tested after the bandwidth upper limit is reached.

[0039] With reference to the optional implementation manner of the second aspect, the sending end comprises a working core for sending data to the receiving end and a standby core not sending data to the receiving end, and the bus testing module is further configured to:

[0040] increase the data sending rate of the working core; and / or

[0041] selecting a target core from the standby cores, and configuring the target core as a working core for sending data to the receiving end.

[0042] In combination with the optional implementation of the second aspect, the working core comprises a configuration register for controlling a data sending rate, and the bus testing module is further configured to:

[0043] obtaining a target sending rate required by the working core according to the bandwidth upper limit;

[0044] mapping the target sending rate to a target configuration parameter of the configuration register through a parameter mapping relationship;

[0045] configuring the configuration register with the target configuration parameter to improve the data sending rate of the working core.

[0046] In combination with the optional implementation of the second aspect, before the target sending rate is mapped to the target configuration parameter of the configuration register through the parameter mapping relationship, the bus testing module is further configured to:

[0047] mapping a preset test sending rate to a test configuration parameter through a theoretical mapping relationship, wherein the test sending rate is less than a sending rate required by the bandwidth upper limit;

[0048] obtaining an actual sending rate of the working core after the configuration register is configured with the test configuration parameter;

[0049] obtaining a correction coefficient of the theoretical mapping relationship according to the actual sending rate and the test sending rate;

[0050] correcting the theoretical mapping relationship through the correction coefficient to obtain the parameter mapping relationship.

[0051] In combination with the optional implementation of the second aspect, the working core comprises a configuration register for controlling a data sending rate, and the bus testing module is further configured to:

[0052] obtaining a current residual bandwidth of the bus under test;

[0053] determining a target configuration parameter of the configuration register according to the current residual bandwidth, wherein the data sending rate increased by the target configuration parameter is positively correlated with the residual bandwidth;

[0054] if the bus under test does not reach the bandwidth upper limit after the configuration register is configured with the target configuration parameter, returning to the step of obtaining the current residual bandwidth of the bus under test until the bus under test reaches the bandwidth upper limit.

[0055] In combination with the optional implementation of the second aspect, the code simulation module is further specifically configured to:

[0056] grab the data packet transmitted on the bus under test;

[0057] parse the state information of the bus under test from the data packet;

[0058] determine the current bandwidth upper limit of the bus under test according to the current state information.

[0059] In combination with the optional implementation of the second aspect, the sending end comprises a working core for sending data to the receiving end, and the working core comprises a state register of the bus under test, and the code simulation module is further specifically configured to:

[0060] read the state information in the state register;

[0061] determine the current bandwidth upper limit of the bus under test according to the state information.

[0062] In combination with the optional implementation of the second aspect, the code simulation module is further specifically configured to:

[0063] count the data amount transmitted on the bus under test within a preset time length;

[0064] obtain the current used bandwidth of the bus under test according to the data amount transmitted within the preset time length.

[0065] In the third aspect, the application further provides a storage medium, wherein the storage medium stores a computer program, and the computer program is executed by a processor to implement the bus performance test method.

[0066] In the fourth aspect, the application further provides an electronic device, wherein the electronic device comprises a processor and a memory, the memory stores a computer program, and the computer program is executed by the processor to implement the bus performance test method.

[0067] Compared with the prior art, the application has the following beneficial effects:

[0068] The application provides a bus performance test method, device, storage medium and electronic equipment. In the method, the electronic equipment acquires chip design code, wherein the chip design code designs a to-be-tested bus and a sending end and a receiving end capable of communicating through the to-be-tested bus; the chip design code is loaded into a simulation environment, and the used bandwidth and the upper limit of the bandwidth of the to-be-tested bus are acquired through the simulation environment; if the used bandwidth is less than the upper limit of the bandwidth, the data sending rate of the sending end is increased to obtain test information of the to-be-tested bus after reaching the upper limit of the bandwidth. In this way, the running effect of the chip is simulated in the simulation environment, and when the designed upper limit of the bandwidth cannot be reached, the sending rate of the sending end is automatically increased to promote the to-be-tested bus to reach the upper limit of the bandwidth, so that manual intervention is reduced, the verification period is shortened, and the production efficiency is improved. BRIEF DESCRIPTION OF DRAWINGS

[0069] In order to more clearly illustrate the technical solutions of the embodiments of the application, the following will briefly introduce the drawings needed to be used in the embodiments. It should be understood that the following drawings only show some of the embodiments of the application, and therefore should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can also be obtained without creative labor.

[0070] Figure 1 The flowchart of the bus performance test method provided by the embodiments of the application;

[0071] Figure 2 The function diagram of the AMBA bus provided by the embodiments of the application;

[0072] Figure 3 The structural diagram of the bus performance test device provided by the embodiments of the application;

[0073] Figure 4 The structural diagram of the electronic equipment provided by the embodiments of the application. DETAILED DESCRIPTION

[0074] In order to make the purpose, technical solutions and advantages of the embodiments of the application more clear, the following will combine the drawings in the embodiments of the application to clearly and completely describe the technical solutions in the embodiments of the application. Obviously, the described embodiments are only some of the embodiments of the application, not all. The components of the embodiments of the application described and shown in the drawings can be arranged and designed in various different configurations.

[0075] Therefore, the following detailed description of the embodiments of the application provided in the drawings is not intended to limit the scope of the claimed application, but only represents selected embodiments of the application. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the application.

[0076] It should be noted that like reference numerals and characters refer to like elements throughout the following figures and description, and thus, once certain terminologies are defined in one figure, there is no need to further define and explain them in the subsequent figures.

[0077] In the description of the present application, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", and the like, indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, or the orientation or positional relationship in which the product of the present application is usually placed during use, and are merely for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as limiting the present application. In addition, the terms "first", "second", "third", and the like are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0078] In addition, the terms "include", "contain" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. Without more limitation, the element defined by the statement "including a" does not exclude the presence of another identical element in the process, method, article or device including the element.

[0079] In addition, the terms "horizontal", "vertical", "overhanging", and the like do not mean that the component must be absolutely horizontal or overhanging, but can be slightly inclined. For example, "horizontal" only means that its direction is more horizontal relative to "vertical", and does not mean that the structure must be completely horizontal, but can be slightly inclined.

[0080] In the description of the present application, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set", "mount", "connected", "connected" should be understood broadly, for example, it can be fixedly connected, or it can be detachably connected, or integrally connected; it can be mechanically connected, or it can be electrically connected; it can be directly connected, or it can be indirectly connected through an intermediate medium, or it can be the communication between two elements. For those skilled in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances.

[0081] Based on the above statement, as introduced in the background art, the current traditional bus verification method still relies on manual intervention. This includes constantly adjusting and writing new test cases according to test feedback, which can result in a long cycle of feedback and optimization, thereby affecting the overall efficiency of verification.

[0082] For example, the AMBA (Advanced Microcontroller Bus Architecture) bus is taken as an example. In the chip design process, if it is verified whether the AMBA bus can achieve a design bandwidth of 2 GB / s. The engineer first needs to manually write and execute a series of complex test scripts to simulate different data transmission scenarios. However, the gap between ideal and reality will be found in the actual test process, that is, the expected high bandwidth is difficult to achieve in actual testing. This is not only because there may be omissions in the script writing, but also because the prediction of the bus behavior is not accurate enough, or the coverage of the test scenario is not comprehensive enough. At this time, the engineer needs to redesign more detailed and rigorous test cases and simulate and verify the bus design again. This iterative process of repeatedly adjusting and optimizing test cases consumes a lot of time, thereby reducing the speed and efficiency of the entire verification process.

[0083] Based on the discovery of the above technical problems, the inventors propose the following technical solutions after creative labor to solve or improve the above problems. It should be noted that the defects in the above prior art solutions are the result of the inventors' careful research after practice, so the discovery process of the above problems and the solutions proposed by the embodiments of the present application to solve the above problems should be the contribution of the inventors to the present application during the invention and creation process, and should not be understood as technical content known to those skilled in the art.

[0084] Therefore, the embodiment provides a bus performance test method. In the method, an electronic device obtains chip design code, wherein the chip design code designs a to-be-tested bus and a sending end and a receiving end capable of communicating through the to-be-tested bus; loads the chip design code into a simulation environment, and obtains a used bandwidth and an upper limit of the bandwidth of the to-be-tested bus through the simulation environment; if the used bandwidth is less than the upper limit of the bandwidth, increases a data sending rate of the sending end to obtain test information of the to-be-tested bus after reaching the upper limit of the bandwidth. In this way, the running effect of the chip is simulated in the simulation environment, and when the upper limit of the bandwidth designed cannot be reached, the sending rate of the sending end is automatically increased to promote the to-be-tested bus to reach the upper limit of the bandwidth; thereby, manual intervention is reduced, the verification period is shortened, and the production efficiency is improved.

[0085] It should be noted that the electronic device implementing the method can be, but is not limited to, a mobile terminal, a tablet computer, a laptop computer, a desktop host, a server, and the like. When it is a server, the server can be a single server or a server group. The server group can be centralized or distributed (for example, the server can be a distributed system). In some embodiments, the server can be local or remote relative to the user terminal. In some embodiments, the server can be implemented on a cloud platform; for example, the cloud platform can include a private cloud, a public cloud, a hybrid cloud, a community cloud, a distributed cloud, an inter-cloud, a multi-cloud, and the like, or any combination thereof. In some embodiments, the server can be implemented on an electronic device with one or more components.

[0086] To make the scheme provided by the present embodiment more clear, the following takes a server as the electronic device implementing the method, and combines the server with the AMBA bus as an example to describe the method in detail. Figure 1 The various steps of the method are described in detail. However, it should be understood that the operations of the flowchart can not be implemented in sequence, and the steps without logical context relationship can be reversed in sequence or implemented simultaneously. In addition, one or more other operations can be added to the flowchart or one or more operations can be removed from the flowchart under the guidance of the content of the present application. For example, as shown in the flowchart of FIG. 1, the method includes: Figure 1

[0087] S1, obtaining a chip design code.

[0088] In the present embodiment, the chip design code includes a function code of the chip itself and an optimization code, wherein the function code is used to implement the chip function of the chip itself, for example, the function code implements a to-be-tested bus and a sending end and a receiving end capable of communicating through the to-be-tested bus; and the test of the to-be-tested bus needs to be assisted by the optimization code. For example, the optimization code is used to optimize the sending end of the to-be-tested bus when it is monitored that the bandwidth on the to-be-tested bus does not reach the designed upper limit of the bandwidth, so that the optimized chip can fully utilize the performance upper limit of the to-be-tested bus.

[0089] In addition, the to-be-tested bus can be the AMBA bus described above, but can also be an OCP (Open Core Protocol) bus, a PCI Express (Peripheral Component Interconnect Express) bus, a NoC (Network-on-Chip) bus, and the like. Continuing to take the AMBA bus as an example, as shown in FIG. 2, the AMBA bus includes a bus master and a bus slave. Figure 2 ​As shown, the cores, memories, peripherals, caches, etc. in the multi-core processor are directly or indirectly connected for communication through the AMBA bus. Therefore, in this embodiment, the sending end of the bus to be tested can include multiple cores, which can be pre-designed IP cores and / or self-developed cores. The core that sends data to the receiving end is referred to as the working core, and the core that does not send data to the receiving end is referred to as the standby core. The receiving end can include the remaining cores, memories, peripherals, caches, etc.

[0090] Based on the above introduction of the chip design code, continue to refer to Figure 1 The method provided in this embodiment further includes:

[0091] S2, load the chip design code into the simulation environment, and obtain the current used bandwidth and the bandwidth upper limit of the bus to be tested through the simulation environment.

[0092] It should be noted that in the field of chip design, simulation is an important measure to verify the correctness of the design. Chip design code written in hardware description languages (such as Verilog or VHDL) can be run in a simulation environment provided by a simulation tool to verify its function. The simulation environment can parse these codes, generate a behavioral model of the logic circuit, and then perform timing or functional simulation. In addition, the simulation environment creates a test platform to drive the chip design through given input signals and timing conditions, and observes whether the output results meet the expectations. In this way, designers can find and fix potential design errors before actually manufacturing the chip, ensuring the correctness of the chip function and the achievement of performance indicators, thereby reducing development costs and cycle.

[0093] Research has found that the bandwidth upper limit of the bus to be tested does not remain unchanged at all times, but changes with the current working phase of the bus. For this purpose, taking the AMBA bus as an example, the AMBA bus includes an initial phase, a stable working phase, a low-power mode, a burst transmission phase, etc. The characteristics of each phase are as follows:

[0094] Initial phase: When the system starts, the AMBA bus can be in the initial phase, at which time the upper limit of the bus bandwidth can be low, because the system is configuring and initializing various IP cores, and data transmission on the bus is not the top priority.

[0095] Stable working phase: Once the system enters a stable working state, the bandwidth upper limit of the AMBA bus will be increased to meet the needs of high-performance data transmission. For example, when the processor core needs to frequently read instructions and data from the memory, the bandwidth of the AHB system bus will reach a high level.

[0096] Low power mode: in the low power mode of the system, in order to save energy, the bandwidth limit of the AMBA bus can be limited. For example, when the system detects that the processor core is in an idle state, the bandwidth of the APB peripheral bus can be reduced, because the communication demand of the peripheral device is not high at this time.

[0097] Burst transfer phase: when performing burst transfer, such as high-speed transmission of a large amount of data through the AXI bus, the bandwidth limit of the bus is temporarily increased to support this high-throughput data transmission mode.

[0098] And when the change between the above stages occurs, the relevant configuration information is transmitted in the AMBA bus, so the state information of the AMBA can be parsed therefrom. Based on this finding, the present embodiment provides the following optional implementation of step S2:

[0099] S2-1A, capturing the data packet transmitted on the bus to be tested.

[0100] S2-2A, parsing the state information of the bus to be tested from the data packet.

[0101] S2-3A, determining the current bandwidth limit of the bus to be tested according to the current state information.

[0102] In this way, since the chip will send the relevant configuration information on the bus at the beginning of each working stage, the working stage of the bus to be tested can be determined when the state information of the bus to be tested is parsed from the captured configuration information by continuously capturing the data packet on the bus.

[0103] In addition, it is also found that the working core that sends data to the receiving end is provided with a state register that records the state of the bus, so the present embodiment also provides another implementation of step S2:

[0104] S2-1B, reading the state information in the state register.

[0105] S2-2B, determining the current bandwidth limit of the bus to be tested according to the state information.

[0106] In this way, since the state register has the state information of the bus to be tested, the working stage of the bus to be tested can be determined by reading the state information in the state register of the working core, and then the bandwidth limit in the working state is determined.

[0107] And for the current used bandwidth of the bus to be tested, the server in the present embodiment can count the amount of data transmitted by the bus to be tested within a preset time period; and the current used bandwidth of the bus to be tested is obtained according to the amount of data transmitted within the preset time period.

[0108] For example, the server captures the data packets on the bus within 10 μs and performs statistics to obtain the data amount within 10 μs, and the data amount is divided by 10 μs to obtain the used bandwidth of the bus to be tested.

[0109] Based on the above description of the used bandwidth of the bus to be tested and the upper limit of the bandwidth, with reference to Figure 1 , the method further comprises:

[0110] S3, if the used bandwidth is less than the upper limit of the bandwidth, increasing the data sending rate of the sending end to obtain the test information of the bus to be tested after reaching the upper limit of the bandwidth.

[0111] For the test information of the bus to be tested, taking the AMBA bus as an example, after reaching the upper limit of the bandwidth of the AMBA bus, the data packets of the AMBA bus communication can be collected and parsed in real time, the frequency, timing and resource usage of the bus operation are monitored. On this basis, the function of the AMBA bus transaction is captured, and the correctness and performance index of the transaction are confirmed through an efficient analysis algorithm. In addition, through the performance analysis algorithm, including consistency check, exception detection and performance benchmark comparison, the throughput, delay and resource occupancy rate of the bus to be tested are comprehensively evaluated. In this way, the test information of the AMBA bus after reaching the upper limit of the bandwidth is obtained.

[0112] In this embodiment, it is considered that the sending end includes a working core that sends data to the receiving end and a standby core that does not send data to the receiving end. Therefore, this embodiment provides multiple ways for increasing the data sending rate of the sending end. That is, the optional implementation of step S3 can include:

[0113] S3-1A, increasing the data sending rate of the working core; and / or

[0114] S3-1B, selecting a target core from the standby cores and configuring the target core as a working core that sends data to the receiving end.

[0115] Wherein, when selecting the target core, the standby core with a high priority is preferentially selected as a new working core, and the priority of the standby core is determined by the working scene of the simulation test. For example, in a video playing scene, the standby core participating in video coding has a higher priority. In a user interaction application scene, the standby core responsible for processing input and output has a higher priority.

[0116] It can be understood that when it is detected that the used bandwidth is less than the upper limit of the bandwidth, the server can increase the data sending amount of the current working core, or select more cores to participate in data sending, or increase the data sending amount of the current working core while also selecting more cores to participate in data sending.

[0117] In practice, it is found that since the bus in the entity chip is not tested and verified in this embodiment, but the designed chip code is verified in the simulation environment, there may be a certain deviation between the simulation result of the chip and the performance of the actual physical chip. Due to these performance differences, there may be a deviation between the expected data transmission rate of the working core and the actually measured data transmission rate. For example, according to the design expectation, the data transmission rate of the working core should reach 16Gbps under the existing configuration parameters, but the actual measurement result is only 15Gbps. In addition, if there is a defect in the chip code design, it will also cause the inconsistency between the design expectation and the actual performance.

[0118] For the above S3-1A, the data transmission rate of the working chip can be gradually increased to approach the upper limit of the bandwidth of the bus to be tested. For this purpose, the present embodiment provides the following optional implementation manner:

[0119] The server acquires the current residual bandwidth of the bus to be tested; according to the current residual bandwidth, the target configuration parameter of the configuration register is determined, wherein the data transmission rate increased by the target configuration parameter is positively correlated with the residual bandwidth; if the bus to be tested does not reach the upper limit of the bandwidth after the configuration register is configured by the target configuration parameter, the step of acquiring the current residual bandwidth of the bus to be tested is returned to execute until the bus to be tested reaches the upper limit of the bandwidth.

[0120] For example, the transmission data related registers include control registers, configuration registers, and terminal registers, and the functions of each register are as follows:

[0121] The control register is used to start or stop the transmission of data, affect the transmission speed, and shorten the total time of pausing the transmission of data during the transmission process.

[0122] The configuration register can be used to configure the clock frequency and the data bit width. The clock frequency determines the working mode of the core. If the core works in high-speed or low-speed mode, the data processing speed in the core will be faster in high-speed mode, and more data packets will be processed and sent to the bus in a unit of time. The data bit width affects the bit width of each transmission of data, for example, 8, 16, 32, 64, 128 bits, etc.

[0123] The interrupt register: if the transmission of the IP is affected by the interrupt, the interrupt can be responded after the next data transmission is continued, then the interrupt priority can be changed to make the interrupt related to the bus to be tested be processed preferentially.

[0124] In this example, the clock frequency and the bit width are adjusted by the configuration register to jointly determine the data transmission rate of the working core, and the relationship is as follows:

[0125] Data transmission rate (bps) = Clock frequency (Hz) x Bit width of data transmission (bits)

[0126] Assuming the clock frequency is 200MHz and the bit width of data transmission is 64 bits each time, the data transmission rate is 12.8Gbps (gigabit per second).

[0127] Therefore, assuming the current bit width is 16, when the server detects that the remaining bandwidth is small, the bit width is configured to 32, and vice versa, when the remaining bandwidth is large, the bit width is configured to 64. Then, it is continuously checked whether the bandwidth upper limit of the bus under test is reached, and if not, the bit width is continuously increased. If the bit width is increased to the maximum, the bandwidth upper limit is still not reached. The clock frequency is further increased. In this way, the bandwidth upper limit of the bus under test is reached.

[0128] Compared with the above embodiment, the bandwidth upper limit of the bus under test is reached after multiple adjustments. The present embodiment further provides another embodiment of step S3-1A:

[0129] The server obtains a target transmission rate required by the working core according to the bandwidth upper limit, maps the target transmission rate to a target configuration parameter of the configuration register through a parameter mapping relationship, and configures the configuration register by using the target configuration parameter to improve the data transmission rate of the working core. In this way, the data transmission rate of the working core can be quickly made to reach the bandwidth upper limit of the bus under test through calculation, without repeated configuration.

[0130] The parameter mapping relationship is the relationship among the clock frequency, the bit width, and the data transmission rate. However, it is found in practice that there may be a certain deviation between the simulation result of the chip and the performance of the actual physical chip when the designed chip code is verified in the simulation environment. For example, according to the designed configuration specification, the clock frequency is configured to 200MHz, but in the simulation environment, due to factors such as context switching consumption of the simulation program and performance of the simulation platform processor, the actual frequency will not be 200MHz. To this end, the present embodiment provides the following embodiments to obtain the above parameter mapping relationship:

[0131] The server maps a preset test transmission rate to a test configuration parameter through a theoretical mapping relationship, wherein the test transmission rate is less than the transmission rate required by the bandwidth upper limit. In this regard, it should be understood that the test transmission rate is less than the transmission rate required by the bandwidth upper limit to avoid that when the test transmission rate is too large, i.e., much larger than the bandwidth upper limit of the bus under test, the bus under test will be abnormal after being configured by the corresponding test configuration parameter. In addition, the theoretical mapping relationship is the above data transmission rate (bps) = clock frequency (Hz) x bit width of data transmission (bits).

[0132] Then, the server obtains the actual sending rate of the working core after the configuration register is configured with the tested configuration parameter, and obtains a correction coefficient of the theoretical mapping relationship according to the actual sending rate and the test sending rate.

[0133] Finally, the server corrects the theoretical mapping relationship by using the correction coefficient to obtain the parameter mapping relationship.

[0134] It should be noted that a large number of tests show that, due to different design methods of different simulation platforms, the correction coefficient is the difference between the actual sending rate and the test sending rate under some simulation platforms, that is, the difference between the two is close to the difference under any clock frequency. Under other simulation platforms, the correction coefficient is the ratio of the actual sending rate to the test sending rate, that is, the two satisfy a certain proportional relationship under any clock frequency. For example, the actual sending rate is 0.8 times the theoretical test sending rate.

[0135] Based on the same inventive concept as the bus performance testing method provided in the embodiment, the embodiment further provides a bus performance testing device. The device includes at least one software function module stored in a memory in a software form or solidified in an electronic device. A processor 22 in the electronic device is configured to execute the executable module stored in the memory. For example, the bus performance testing device includes software function modules and computer programs. Please refer to Figure 3 From a functional point of view, the device can include:

[0136] A code simulation module 11 is configured to obtain chip design code, wherein the chip design code designs a bus under test and a sending end and a receiving end capable of communicating through the bus under test;

[0137] The code simulation module 11 is further configured to load the chip design code into a simulation environment and obtain a currently used bandwidth and an upper limit of the bandwidth of the bus under test through the simulation environment.

[0138] A bus testing module 12 is configured to increase the data sending rate of the sending end if the used bandwidth is less than the upper limit of the bandwidth, to obtain test information of the bus under test after reaching the upper limit of the bandwidth.

[0139] In the embodiment, the code simulation module 11 is configured to implement steps S1 and S2 in Figure 1 The bus testing module 12 is configured to implement step S3 in 1, and therefore, the detailed description of each module can be referred to the specific embodiments of the corresponding steps. In addition, it should be noted that, since the bus performance testing device has the same inventive concept as the bus performance testing method, the bus performance testing device can also implement other steps or sub-steps of the method through the above modules or other modules.

[0140] In addition, each functional module in each embodiment of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0141] It should also be understood that the above embodiments, if implemented in the form of software functional modules and sold or used as independent products, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the parts of the technical solutions that make contributions to the prior art, or parts of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application.

[0142] Therefore, the present embodiment also provides a storage medium, which is a computer readable storage medium. The storage medium stores a computer program, and the computer program is executed by a processor to implement the bus performance testing method provided by the present embodiment. The storage medium can be a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes.

[0143] The present embodiment provides an electronic device for implementing the bus performance testing method. As shown in the figure, the electronic device can include a processor 22 and a memory 21. Moreover, the memory 21 stores a computer program, and the processor implements the bus performance testing method provided by the present embodiment by reading and executing the computer program corresponding to the above embodiments in the memory 21. Figure 4

[0144] Continuing to refer to Figure 4 The electronic device can further include a communication unit 23. The memory 21, the processor 22 and the communication unit 23 are directly or indirectly electrically connected to each other through a system bus 24 to realize data transmission or interaction.

[0145] The memory 21 can be an information recording device based on any electronic, magnetic, optical or other physical principles for recording execution instructions, data, etc. In some embodiments, the memory 21 can be, but is not limited to, a volatile memory, a non-volatile memory, a storage drive, etc.

[0146] ​In some embodiments, the volatile memory can be a Random Access Memory (RAM); in some embodiments, the non-volatile memory can be a Read Only Memory (ROM), a Programmable Read-Only Memory (PROM), an Erasable Programmable Read-Only Memory (EPROM), an Electric Erasable Programmable Read-Only Memory (EEPROM), a flash memory, or the like; in some embodiments, the storage drive can be a magnetic disk drive, a solid state drive, any type of storage disk (such as an optical disk, a DVD, and the like), or a similar storage medium, or a combination thereof, and the like.

[0147] The communication unit 23 is configured to transceive data over a network. In some embodiments, the network can include a wired network, a wireless network, a fiber optic network, a telecommunications network, an intranet, the Internet, a Local Area Network (LAN), a Wide Area Network (WAN), a Wireless Local Area Network (WLAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a Public Switched Telephone Network (PSTN), a Bluetooth network, a ZigBee network, or a Near Field Communication (NFC) network, or the like, or any combination thereof. In some embodiments, the network can include one or more network access points. For example, the network can include wired or wireless network access points, such as base stations and / or network switching nodes, through which one or more components of the service request processing system can connect to the network to exchange data and / or information.

[0148] The processor 22 can be an integrated circuit chip with processing capability and can include one or more processing cores (e.g., a single-core processor or a multi-core processor). By way of example only, the processor can include a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), an Application Specific Instruction-set Processor (ASIP), a Graphics Processing Unit (GPU), a Physics Processing Unit (PPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a microcontroller unit, a Reduced Instruction Set Computing (RISC), or a microprocessor, or any combination thereof.

[0149] It can be understood that, Figure 4 The structure shown is merely schematic. The electronic device can also have more or fewer components than those shown, or have a different configuration from that shown. Figure 4 The components shown can be implemented in hardware, software, or a combination thereof. Figure 4 The components shown can be implemented in hardware, software, or a combination thereof. Figure 4 The components shown can be implemented in hardware, software, or a combination thereof.

[0150] It should be understood that all the devices and methods disclosed in the above embodiments can also be implemented in other ways. The device embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the drawings show the possible implementation architectures, functions and operations of the devices, methods and computer program products according to the embodiments of the present application. In this regard, each block in the flowcharts or block diagrams can represent a module, a program segment or a part of code, which contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur in different orders from those noted in the drawings. For example, two consecutive blocks can actually be executed substantially in parallel, and sometimes they can be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and the combination of blocks in the block diagrams and / or flowcharts, can be implemented by a dedicated hardware-based system that performs the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0151] The above describes only various embodiments of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or replacements within the technical scope disclosed by the present application, which should be covered by the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method of testing bus performance, characterized by, The method comprises: acquiring chip design code, wherein the chip design code designs a bus under test and a sending end and a receiving end capable of communicating through the bus under test, wherein the sending end comprises a working core for sending data to the receiving end and a standby core not sending data to the receiving end, and the working core comprises a configuration register for controlling a data sending rate; loading the chip design code into a simulation environment and acquiring a current used bandwidth and an upper limit of the bus under test through the simulation environment; if the used bandwidth is less than the upper limit of the bandwidth: obtaining a target sending rate required by the working core according to the upper limit of the bandwidth; mapping the target sending rate into a target configuration parameter of the configuration register through a parameter mapping relationship; configuring the configuration register by using the target configuration parameter to improve the data sending rate of the working core; and / or selecting a target core from the standby core and configuring the target core as the working core for sending data to the receiving end to obtain test information of the bus under test after reaching the upper limit of the bandwidth.

2. The bus performance test method of claim 1, wherein, Before the target sending rate is mapped into the target configuration parameter of the configuration register through the parameter mapping relationship, the method further comprises: mapping a preset test sending rate into a test configuration parameter through a theoretical mapping relationship, wherein the test sending rate is less than a sending rate required by the upper limit of the bandwidth; acquiring an actual measured sending rate of the working core after the configuration register is configured by the test configuration parameter; obtaining a correction coefficient of the theoretical mapping relationship according to the actual measured sending rate and the test sending rate; correcting the theoretical mapping relationship through the correction coefficient to obtain the parameter mapping relationship.

3. The method of claim 1, wherein, The acquisition of the current upper limit of the bus under test through the simulation environment comprises: grabbing a data packet transmitted on the bus under test; parsing state information of the bus under test from the data packet; determining the current upper limit of the bus under test according to the current state information.

4. The method of claim 1, wherein, The sending end comprises a working core for sending data to the receiving end, and the working core comprises a state register of the bus under test, and the acquisition of the current upper limit of the bus under test through the simulation environment comprises: reading state information in the state register; determining the current upper limit of the bus under test according to the state information.

5. The method of claim 1, wherein, The acquisition of the current used bandwidth of the bus under test through the simulation environment comprises: counting a data amount transmitted within a preset time length; obtaining the current used bandwidth of the bus under test according to the data amount transmitted within the preset time length.

6. A bus performance testing apparatus characterized by comprising: The device comprises: a code simulation module for acquiring chip design code, wherein the chip design code designs a bus under test and a sending end and a receiving end capable of communicating through the bus under test, wherein the sending end comprises a working core for sending data to the receiving end and a standby core not sending data to the receiving end, and the working core comprises a configuration register for controlling a data sending rate; The code simulation module is further configured to load the chip design code into a simulation environment, and obtain the used bandwidth and the bandwidth upper limit of the to-be-tested bus currently through the simulation environment; The bus testing module is configured to, if the used bandwidth is less than the bandwidth upper limit, then: obtain a target sending rate required by the working core according to the bandwidth upper limit; map the target sending rate to a target configuration parameter of the configuration register through a parameter mapping relationship; configure the configuration register by using the target configuration parameter, so as to improve the data sending rate of the working core; and / or select a target core from the standby cores, and configure the target core as a working core for sending data to the receiving end, so as to obtain testing information of the to-be-tested bus after the bandwidth upper limit is reached.

7. A storage medium, characterized by The storage medium stores a computer program, and the computer program is executed by the processor to implement the bus performance testing method in any one of claims 1-5.

8. An electronic device, comprising: The electronic device includes a processor and a memory, and the memory stores a computer program, and the computer program is executed by the processor to implement the bus performance testing method in any one of claims 1-5.

Images