Verification system and method for flexray bus controller in soc

Abstract

The application discloses a verification system and method for a Flexray bus controller in an SoC (System on Chip), belongs to the technical field of integrated circuit verification, and provides a verification method for a Flexray bus controller in an SoC (System on Chip), wherein the method uses a plurality of off-chip Flexray bus nodes and bus coding and decoding models to complete networking, synchronization, analysis and data comparison functions of a to-be-tested Flexray bus controller node, and uses related models and application configuration functions to initialize the to-be-tested Flexray bus controller in the SoC and configure transmission data of the to-be-tested Flexray bus controller. The verification method can effectively improve the test efficiency of Flexray nodes in the SoC.

Description

Technical Field

[0001] This invention belongs to the field of integrated circuit verification technology, specifically relating to a verification system and method for Flexray bus controllers in SoCs. Background Technology

[0002] Flexray is a next-generation high-performance bus that, compared to the CAN bus, offers more flexible data communication, faster data rates, more comprehensive topology options, and better fault tolerance. It is currently widely used in automotive control systems. The security of automotive network control systems is crucial, and network topology plays a significant role in automotive networks. The Flexray bus provides flexible configuration, supporting various topologies such as bus, star, and hybrid topologies. Flexray utilizes two independent physical lines for communication, each with a data rate of 10 Mbps. These two communication lines primarily serve as redundancy, thus providing fault tolerance for message transmission. Different messages can also be transmitted using the two lines, effectively doubling the data throughput. Therefore, the Flexray bus provides the speed and reliability required for next-generation in-vehicle control systems.

[0003] Testing the Flexray bus controller in traditional SoCs requires software involvement in frame encoding, frame parsing, and result comparison. These tasks often consume significant system resources and simulation time. Furthermore, due to differences in various SoC architectures, the relevant test environments and test cases may not be reusable, further impacting the verification progress. Summary of the Invention

[0004] In order to overcome the shortcomings of the prior art, the present invention aims to provide a verification system and method for Flexray bus controllers in SoC, improve the verification efficiency in the system, and provide effective guidance for the verification of similar products.

[0005] To achieve the above objectives, the present invention employs the following technical solution:

[0006] This invention discloses a verification system for a Flexray bus controller in a SoC, comprising: a system bus encoding model, a multi-buffered software data sending and receiving unit, a marking and acquisition unit for application-side data transmission, a driver structure, and a scoring board. The multi-buffered software data sending and receiving unit interacts with the marking and acquisition unit for application-side data transmission. The marking and acquisition unit for application-side data transmission notifies the system bus encoding model to start analyzing and encoding the system bus data, and writes the encoded data to the scoring board. The driver structure is connected to the Flexray controller, drives the Flexray bus node to transmit data, monitors the transmission of the Flexray bus controller node on the Flexray bus, and writes the data to the scoring board. The scoring board implements indexed data checking.

[0007] Preferably, the system bus encoding model is used to monitor the data interaction between the host and the Flexray bus controller on the SoC bus, extract the data sent or received by the Flexray bus controller according to the register and memory address, analyze the data on the system bus, encode it according to the Flexray bus data frame format, directly obtain the data type consistent with the transmission format on the Flexray bus, and send it into the Scoreboard.

[0008] Preferably, the multi-buffered software data transmission and reception unit is used to plan the data to be transmitted or received by the Flexray bus controller in advance in the MEM by simulating multiple sets of Message Buffer operations on the software application side. The data to be transmitted is written into the planned transmission Message Buffer address space in advance by the software side, and the data to be received reserves free reception Message Buffer address space in advance. After the Flexray bus controller starts transmitting or receiving data, the host side updates the MEM address corresponding to the transmission or reception Message Buffer of the Flexray bus controller to complete the transmission and reception of data.

[0009] Preferably, the data planning in the MEM is to divide the internal related MEM into multiple independent Message Buffer storage spaces.

[0010] Preferably, the application-side data transmission marking and acquisition unit is used to mark certain special application-side data streams by selecting access to some reserved address spaces within the Flexray bus controller.

[0011] Preferably, the drive structure is connected to the Flexray controller via Flexray bus A channel and Flexray bus B channel.

[0012] Preferably, the driving structure includes A_node_1, A_node_2, A_node_3, P_node_4, and Flexray bus A and B channels; A_node_1 is a dual-channel transmission node connected to A and B channels, A_node_2 is a single-channel transmission node connected to A channel, A_node_3 is a single-channel transmission node connected to B channel, and P_node_4 is connected to A and B channels to monitor the Flexray controller node under test.

[0013] Preferably, the scoring board is used to retrieve the system bus-side data FIFO or the Flexray bus-side data FIFO and determine the correctness of the data comparison.

[0014] This invention also discloses a Flexray bus controller data transmission verification based on a verification system for Flexray bus controllers in SoCs, comprising:

[0015] S1: Initialize the host configuration of the Flexray controller to transmit mode;

[0016] S2: The multi-buffered software data transmission and reception unit configures the MEM inside the SoC and plans the storage space for transmitted data within the MEM;

[0017] S3: The tagging and acquisition unit for data transmission from the application end writes the data from the application end to the MEM via the bus and simultaneously writes the tag;

[0018] S4: The application-side data transmission marking and acquisition unit monitors the marking notification system bus-side encoding model;

[0019] S5: The system bus end encoding model collects and encodes the application-end data sent from the system bus into Flexray bus format data, and writes it into the system bus data FIFO in the scoring board;

[0020] S6: The P_node_4 node in the driver structure monitors the Flexray bus controller under test sending a data frame to the Flexray bus, writes the data into the Flexray bus data FIFO in the scoring board, and triggers the scoring board to start checking the current data.

[0021] S7: The scoreboard index system bus sends data. If the same data exists, the test passes; if the corresponding data does not exist, the test fails.

[0022] This invention also discloses a verification method for Flexray bus controller data reception based on a verification system for Flexray bus controllers in SoCs, comprising:

[0023] S8: Initialize the host configuration to set the Flexray controller to receive mode;

[0024] S9: The multi-buffered software data transmission and reception unit configures the MEM inside the SoC and plans the storage space for received data within the MEM;

[0025] S10: Nodes A_node_1, A_node_2, and A_node_3 in the drive structure send data through the Flexray bus, and node P_node_4 writes the data received by the monitored Flexray bus controller into the Flexray bus data FIFO in the scoring board.

[0026] S11: After the Flexray bus controller finishes receiving data, it calls the application-side data transmission tag and acquisition unit to read the received data from the corresponding MEM through the bus and write it to the tag;

[0027] S12: After the application-side data transmission marking and acquisition unit detects the mark, it notifies the system bus-side encoding model to acquire the received data from the system bus and encode it into Flexray bus format data.

[0028] S13: The system bus end encoding model is encoded into Flexray bus format data and written into the system bus data FIFO in the scoreboard, and the scoreboard is triggered to start checking the current data.

[0029] S14: The scoreboard indexes the Flexray bus to receive data. If the same data exists, the test passes; otherwise, the test fails.

[0030] Compared with the prior art, the present invention has the following beneficial effects:

[0031] This invention discloses a verification system for a Flexray bus controller in a SoC, comprising: a system bus encoding model, a multi-buffered software data transmission and reception unit, an application-side data marking and acquisition unit, a driver structure, and a scoring board. The system bus encoding model analyzes and encodes data from the system bus and writes the encoded data to the scoring board. The multi-buffered software data transmission and reception unit transmits and receives data. The application-side data marking and acquisition unit marks the data and notifies the system bus encoding model after acquiring the mark. The driver structure sends bus data to the Flexray bus controller or monitors the data of the Flexray bus controller and writes the data to the scoring board. The scoring board checks the data and outputs the result. Through the collaborative work of the above five parts, the construction of the application-side Flexray protocol data frame, the parsing of the received frame, and the comparison of the transmitted and received frames during transmission do not require CPU participation. If all of these are completed by the CPU in the SoC, it will consume a lot of system simulation time and increase the server load. Therefore, this application can significantly improve the testing efficiency of the Flexray bus controller and accelerate the testing process.

[0032] Furthermore, the principle of the Flexray bus controller data transmission and reception verification disclosed in this application is as follows: The host initializes the Flexray bus controller under test and plans and configures the MEM memory space in the SoC, decomposing it into multiple independent receive or transmit message buffer address spaces to store application-side data. When the Flexray controller is controlled for data transmission at the system bus end in the SoC, the transmitted data from the application end is marked and collected. The transmitted or received data from the application end is converted into data frames conforming to the Flexray bus format through the bus encoding model and sent to the scoring board. Simultaneously, the node model in the Flexray bus driver structure sends or monitors the transmitted and received data of the Flexray bus controller node under test. The data transmitted or received by the Flexray bus controller node under test at the Flexray bus end is sent to the scoring board, and finally, index-based data checks are performed on the scoring board. This method and principle can be applied to the testing of Flexray bus controllers in SoCs with different bus architectures and has good application prospects. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the driving structure of the present invention;

[0034] Figure 2 This is a schematic diagram of the verification method of the present invention;

[0035] Figure 3 This is a flowchart of the data reception and verification process of the present invention;

[0036] Figure 4 This is a flowchart illustrating the data transmission verification process of the present invention. Detailed Implementation

[0037] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0038] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0039] The present invention will now be described in further detail with reference to the accompanying drawings:

[0040] A verification method for the Flexray bus controller in a System on Chip (SoC) is disclosed. The verification method utilizes UVM and SystemVerilog languages ​​to implement a verification system. This system includes a system bus data encoding model 1; a multi-buffered software data sending and receiving unit 2; an application-side data marking and acquisition unit 3; a driver structure 4 for different transmission types; and a scoring board 5. The multi-buffered software data sending and receiving unit 2 interacts with the application-side data marking and acquisition unit 3. The application-side data marking and acquisition unit 3 notifies the system bus encoding model 1 to begin analyzing and encoding the system bus data, and writes the encoded data to the scoring board 5. The driver structure 4 is connected to the Flexray controller, monitors the Flexray bus controller, and writes data to the scoring board 5. The scoring board 5 implements indexed data checking.

[0041] System bus data encoding model 1: By monitoring the data interaction between the host and the Flexray bus controller on the SoC bus, the data sent or received by the Flexray bus controller is extracted according to the relevant registers and memory addresses. The system bus data is analyzed, encoded according to the Flexray bus data frame format, and the data type consistent with the transmission format on the Flexray bus is directly obtained and sent to the scoring board 5.

[0042] Multi-buffered software data transmission and reception unit 2: On the software side, multiple sets of message buffer operations are simulated to pre-plan the data to be transmitted or received by the Flexray bus controller in the MEM. The method is to divide the relevant internal MEM into multiple independent message buffer storage spaces. The data to be transmitted is written into the planned transmission message buffer address space in advance by the software side, and the data to be received is reserved in the idle reception message buffer address space in advance. After the Flexray bus controller starts transmitting or receiving data, it is only necessary to update the address of the transmission or reception message buffer of the Flexray bus controller through the host side to complete the transmission and reception of relevant data.

[0043] Application-side data transmission marking and acquisition unit 3: Since the MEM data address space in the SoC may be accessed by other hosts or peripherals, in addition to controlling the data, an additional marking access is added to the application side of the Flexray bus controller. By selecting access to some reserved address spaces inside the Flexray bus controller, certain special application-side data streams are marked. For example, after accessing the address space from the mark address A to the mark address B, the data accessed between the A and B marks is the data that the application needs to send through the Flexray bus controller. After accessing the address space from the mark address C to the mark address D, the data accessed between the C and D marks is the data that the application receives through the Flexray bus controller.

[0044] Drive structure 4: The following is designed in this method: Figure 1 The driving structure enables single A-channel transmission, single B-channel transmission, AB dual-channel redundant transmission, and AB dual-channel non-redundant transmission, which include static and dynamic segments.

[0045] in:

[0046] A_node_1 type nodes can send static and dynamic frames in the A and B channels of the Flexray bus. The data sent in the A and B channels can be sent separately, but the data is the same.

[0047] A_node_2 type nodes can send static and dynamic frames in the A channel of the Flexray bus.

[0048] A_node_3 type nodes can send static and dynamic frames in the B channel of the Flexray bus.

[0049] Nodes of type P_node_4 do not send any data; this node is only responsible for monitoring the Flexray bus to collect the sending and receiving information of the Flexray controller node under test.

[0050] The specific ways in which various types of nodes are used in combination to achieve the above transmission types are within the scope of protection of the invention patent.

[0051] Scoreboard 5: Due to the time-slot multiplexing transmission mode of the Flexray bus, during data monitoring, data that the application needs to send may not be sent in the current cycle or may be sent repeatedly in multiple cycles, placing high demands on the accuracy of data checking. This method utilizes the UVM's TLM transmission model to implement an indexed data checking mechanism. The Flexray bus model places the transmitted and received data monitored by the Flexray bus into the corresponding data FIFOs via TLM, while the system bus encoding model places the transmitted and received data monitored by the application into the corresponding data FIFOs via TLM. For transmitted data, when the Flexray bus monitors the completion of a data frame transmission, the scoreboard searches the system bus data FIFOs; if identical transmitted data is found, the data comparison is correct. For received data, when the system bus receives a data frame, the scoreboard searches the Flexray bus data FIFOs; if identical received data is found, the data comparison is correct.

[0052] Figure 2 This is a schematic diagram of a verification method for a Flexray bus controller in a SoC according to the present invention.

[0053] The following is combined Figure 2 This will provide a clearer and more complete description of the technical solution of the present invention. For example... Figure 2As shown, the Flexray bus controller test method includes a system bus encoding model 1, a multi-buffered software data sending and receiving unit 2, an application-side data marking and acquisition unit 3, a driver structure 4, and a scoring board 5. The multi-buffered software data sending and receiving unit 2, used for data transmission and reception, interacts with the application-side data marking and acquisition unit 3. The application-side data marking and acquisition unit 3 notifies the system bus encoding model 1 to start analyzing and encoding the system bus data, and writes the encoded data into the scoring board 5. The driver structure 4 is connected to the Flexray controller, monitors the Flexray bus controller, and writes data into the scoring board 5. The scoring board 5 implements indexed data checking.

[0054] See Figure 3 Flexray bus controller data transmission verification: In this scenario, the process is roughly as follows: After initializing and configuring the Flexray controller to transmit mode via the host, the tx_mb_cfg201 function in the multi-buffered software data transmission and reception unit 2 is first called to configure the MEM inside the SoC, and the storage space for the transmitted data is planned within the MEM, such as... Figure 2 The data is allocated from Buf1 to Bufn in the MEM shown. Next, the mem_write301 function in the application-side data transmission tagging and acquisition unit 3 is called to write the application-side data to the MEM via the bus and simultaneously write a tag. At this time, Flag_finder in the application-side data transmission tagging and acquisition unit 3 monitors the tag and notifies the system bus encoding model 1 to call the write_bus101 function to collect the application-side data sent from the system bus and encode it into Flexray bus format data, writing it into the system bus data FIFO in the scoring board 5. Then, when the P_node_4 node model monitors that the Flexray bus controller under test has sent a data frame to the Flexray bus, it calls the write_scb_tx401 function to write the data into the Flexray bus data FIFO in the scoring board 5 and triggers the scoring board 5 to start checking the current data. Finally, the find_frame501 function in the scoring board 5 is called to index the system bus data sent; if the same data exists, the test passes; if no corresponding data exists, the test fails.

[0055] See Figure 4 Flexray bus controller data reception verification: In this scenario, the general process is as follows: after initializing and configuring the Flexray controller to receive mode via the host, the MEM inside the SoC is first configured using the rx_mb_cfg202 function in the multi-buffered software data transmission and reception unit 2. This involves planning the storage space for the received data within the MEM, such as... Figure 2The MEM is allocated from Buf1 to Bufn; next, nodes A_node_1 to A_node_3 send data through the Flexray bus, while the P_node_4 node model writes the data received by the Flexray bus controller under test into the Flexray bus data FIFO in the scoring board 5 through the write_scb_rx402 function. After waiting for the Flexray bus controller to finish receiving the data, the mem_read302 function in the application-side data transmission marker and acquisition unit 3 is called to read the received data from the corresponding MEM through the bus and write it to the marker; at this time, the Flag_finder in the application-side data transmission marker and acquisition unit 3 monitors the marker and notifies the system bus encoding model 1 to call the write_bus101 function to acquire the received data from the system bus and encode it into Flexray bus format data, write it into the system bus data FIFO in the scoring board 5 and trigger the scoring board 5 to start checking the current data; finally, the find_frame501 function in the scoring board 5 is called to index the Flexray bus received data. If the same data exists, the test passes; if the corresponding data does not exist, the test fails.

[0056] For scenarios where data transmission and reception are tested simultaneously, the above processes can be performed concurrently.

[0057] The above content is only for illustrating the technical concept of the present invention and should not be construed as limiting the scope of protection of the present invention. Any modifications made to the technical solution based on the technical concept proposed in this invention shall fall within the scope of protection of the claims of this invention.

Claims

1. A verification system for a Flexray bus controller in a SoC, characterized in that It comprises a system bus end coding model (1), a multi-buffer type software data sending and receiving unit (2), an application end transmission data marking and collecting unit (3), a driving structure (4) and a score board (5); the multi-buffer type software data sending and receiving unit (2) for data transceiving and the application end transmission data marking and collecting unit (3) perform data interaction, the application end transmission data marking and collecting unit (3) informs the system bus end coding model (1) to start analyzing the data of the system bus end and coding, and writes the coded data into the score board (5), the driving structure (4) is connected with the Flexray controller, the driving structure (4) drives the Flexray bus node transmission and monitors the Flexray bus controller node transmission on the Flexray bus, and writes the data into the score board (5), and the score board (5) realizes index type data checking; the score board (5) is used for retrieving system bus end data FIFO or Flexray bus end data FIFO, and judging the correctness of data comparison; the driving structure (4) is connected with the Flexray controller through a Flexray bus A channel and a Flexray bus B channel; the driving structure (4) comprises an A_node_1 node, an A_node_2 node, an A_node_3 node, a P_node_4 node, a Flexray bus A channel and a B channel; the A_node_1 node is connected with the A channel and the B channel and is a double-channel transmission node, the A_node_2 node is connected with the A channel and is a single-channel transmission node, the A_node_3 node is connected with the B channel and is a single-channel transmission node, and the P_node_4 node is connected with the A channel and the B channel and monitors the Flexray controller node to be tested; the multi-buffer type software data sending and receiving unit (2) is used for planning the data to be sent or received through the Flexray bus controller in advance in the MEM through simulating multiple groups of Message Buffer operations, writing the data to be sent in advance into the planned sending Message Buffer address space through the software end, reserving the idle receiving Message Buffer address space in advance, and updating the MEM address corresponding to the Flexray bus controller sending or receiving Message Buffer through the host end to complete the data transceiving after the Flexray bus controller starts sending or receiving data. the system bus end coding model (1) is used for monitoring the data interaction of the host and the Flexray bus controller on the SoC inner bus, extracting the data sent or received by the Flexray bus controller according to the register and memory address, analyzing the data of the system bus end, coding according to the Flexray bus data frame format, directly obtaining the data type consistent with the transmission format of the Flexray bus, and sending the data into the Scoreboard score board.

2. The verification system for a Flexray bus controller in a SoC according to claim 1, characterized in that, ​ 3. The verification system for a Flexray bus controller in a SoC according to claim 1, characterized in that, The data in the MEM is planned to divide the internal related MEM into multiple independent Message Buffer storage spaces.

4. The verification system for a Flexray bus controller in a SoC according to claim 1, characterized in that, The application end transmission data marking and collecting unit (3) is used for marking some special application end data streams by selecting access of some reserved address spaces in the Flexray bus controller.

5. The Flexray bus controller data transmission verification for a verification system of a Flexray bus controller in a SoC according to any one of claims 1 to 4, characterized in that It comprises: S1: the host initializes the Flexray controller to be in a sending mode; S2: the multi-buffer software data sending and receiving unit (2) configures the MEM in the SoC, and plans the sending data storage space in the MEM; S3: the application end transmission data marking and collecting unit (3) writes the application end data into the MEM through the bus and writes the mark at the same time; S4: the application end transmission data marking and collecting unit (3) monitors the mark and notifies the system bus end coding model (1); S5: the system bus end coding model (1) collects the sent application end data from the system bus and codes the data into Flexray bus format data, and writes the data into the system bus data FIFO in the score board (5); S6: the P_node_4 node in the drive structure (4) writes the data into the Flexray bus data FIFO in the score board (5) after monitoring that the Flexray bus controller under test sends a data frame to the Flexray bus, and triggers the score board (5) to start checking the current data; S7: the score board (5) indexes the system bus sending data, and if there is the same data, the test passes, and if there is no corresponding data, the test fails.

6. FlexRay bus controller data reception verification for a verification system of a FlexRay bus controller in a SoC according to any one of claims 1 to 4, characterized in that It comprises: S8: the host initializes the Flexray controller to be in a receiving mode; S9: the multi-buffer software data sending and receiving unit (2) configures the MEM in the SoC, and plans the receiving data storage space in the MEM; S10: the A_node_1 node, the A_node_2 node and the A_node_3 node in the drive structure (4) send data through the Flexray bus, and the P_node_4 node writes the monitored data received by the Flexray bus controller under test into the Flexray bus data FIFO in the score board (5); S11: after the Flexray bus controller receives the data, the application end transmission data marking and collecting unit (3) reads out the received data from the corresponding MEM through the bus and writes the data into the mark; S12: after the application end transmission data marking and collecting unit (3) monitors the mark, the system bus end coding model (1) is notified to collect the received data from the system bus and code the data into Flexray bus format data; S13: the system bus end coding model (1) codes the data into Flexray bus format data, writes the data into the system bus data FIFO in the score board (5), and triggers the score board (5) to start checking the current data; S14: the score board (5) indexes the Flexray bus receiving data, and if there is the same data, the test passes, and if there is no corresponding data, the test fails.

Images