A chip function debugging system
By designing a chip function debugging system, including fifo_mux in the debugging unit, synchronous packaging, parameter configuration and data access module, the problem of low streaming success rate caused by the lack of debugging function after chip production is solved, effective debugging and data analysis of chip modules are realized, and the success rate of streaming is improved.
Patent Information
- Application Number
- CN202210583277.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-05-25
- Publication Date
- 2025-06-13
- Estimated Expiration
- 2042-05-25
AI Technical Summary
After the chip production is completed, the chip is lacking the function of debugging, resulting in a low chip success rate.
A chip function debugging system is designed, including at least one set of debugging units, each set of debugging units includes a fifo_mux module, a synchronization packaging module, a parameter configuration module and a data access module. Through these modules, debug nodes can be selected from the chip to be debugged, data can be packaged synchronously, and cached into external memory through the data bus.
Through this debugging system, the data of each debug node in the chip to be debugged can be read, and the data can be analyzed to determine whether the chip module is operating normally, thereby improving the success rate of chip streaming.
Smart Images

Figure CN114968691B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a chip function debugging system, belonging to the technical field of chip design. Background Art
[0002] During the R & D stage of a chip, FPGA's chip scope can be used to collect internal nodes of the chip and locate related problems of the FPGA. However, after the chip production is completed, there will be no function to debug internal signals. Moreover, the simulation of the chip algorithm may not be comprehensive, and the chip application environments are also different. Therefore, it cannot be guaranteed that the algorithm can be fully verified before tape-out. So, it is necessary to add a part of debugging functions. In this way, after the chip is tape-out and returned, the data transmitted through the debugging interface can still be used to check which module inside the chip has an abnormality. Some of the abnormalities can be improved in performance by adjusting parameters and coefficients. Therefore, if debugging can be carried out before the chip is tape-out to find the abnormal module, the success rate of chip tape-out can be greatly improved. Summary of the Invention
[0003] The purpose of the present invention is to provide a chip function debugging system to solve the problem that the success rate of chip tape-out is low due to the lack of chip debugging after the chip production is completed.
[0004] The present invention provides a chip function debugging system to solve the above technical problems. The debugging system includes at least one group of debugging units. Each group of debugging units includes a fifo_mux module, a synchronization and packaging module, a parameter configuration module, and a data access module. The fifo_mux module is used to select debugging nodes from the chip to be debugged; the synchronization and packaging module is used to synchronize the node signals according to the trigger signal and the data valid signal, and package the synchronized signals; the parameter configuration module is used to configure the parameters during the debugging process; the data access module is used to cache the data packaged by the synchronization and packaging module into the memory outside the chip to be debugged through the data bus.
[0005] The present invention sets at least one group of debugging units, selects any module in the chip to be debugged as a debugging node, uses the synchronization and packaging module of the debugging unit to synchronize and package the data in the debugging node, and uses the data access module to cache the data bus after synchronization and packaging into the memory outside the chip to be debugged. Through the debugging system of the present invention, the data of each debugging node in the chip to be debugged can be read out, which is convenient for subsequent analysis of the read data, provides a reliable data source for judging whether each debugging module in the chip to be debugged is running normally, and further can improve the success rate of chip tape-out.
[0006] Further, the data access module uses the DMA method or controls the data bus by using the CPU of the chip to be debugged for data caching.
[0007] The present invention provides multiple bus control methods for data caching. To avoid the impact of data caching on the CPU, the DMA method can be used for data caching; or the CPU can be used to control the data bus for data caching when the CPU resources are less occupied.
[0008] Further, the DMA method is a software DMA method, which uses the CPU of the chip to be debugged to generate an interrupt signal, and the software DMA module is triggered by the interrupt to control the data bus for data caching.
[0009] By using the software DAM method for data caching, only an interrupt signal needs to be generated by the CPU. It occupies the resources of the CPU during the caching process and does not require additional hardware costs.
[0010] Further, the DMA method is a hardware DMA method. When data caching is required, a request signal is generated by the debugging system and sent to the hardware DMA module, and the hardware DMA module controls the data bus for data caching.
[0011] Further, the data bus is an AHB bus.
[0012] Further, the synchronization and packing module packs data according to the data bit width of the data bus when packing data.
[0013] The present invention packs data according to the data bit width of the data bus, so that the length of each data packet is equal to the data bit width of the data bus, thereby improving the transmission efficiency of the data bus.
[0014] Further, the parameters configured by the parameter configuration module include the data volume required for debugging and the caching method adopted by the data access module.
[0015] Further, the debugging system includes two sets of debugging units, which are respectively used to connect the input end and the output end of any module in the chip to be debugged to realize the debugging of the corresponding module.
[0016] To facilitate the simultaneous transfer of input data and data of a certain module in the chip to be debugged, the present invention sets two sets of debugging units to provide accurate and reliable data sources for subsequent abnormal judgment of the module.
[0017] Further, the data sampling rate of the debugging system is less than the clock frequency of the data bus.
[0018] To avoid the newly arrived data from overwriting the data before it is carried away by the data bus, the present invention makes the data sampling rate of the debugging system less than the clock frequency of the data bus, so that the data sampled by the debugging system can be carried away by the data bus in time. Brief Description of the Drawings
[0019] Figure 1 is the structural block diagram of the chip function debugging system of the present invention;
[0020] Figure 2 is the working flowchart of the chip function debugging system of the present invention. Detailed Embodiments
[0021] The following further describes the detailed embodiments of the present invention with reference to the accompanying drawings.
[0022] Embodiment of the Debugging System
[0023] The debugging system includes at least one group of debugging units. Each group of debugging units includes a fifo_mux module, a synchronization and packing module, a parameter configuration module, and a data access module. The fifo_mux module is used to select debugging nodes from the chip to be debugged; the synchronization and packing module is used to synchronize the node signals according to the trigger signal and the data valid signal, and pack the synchronized signals; the parameter configuration module is used to configure the parameters during the debugging process; the data access module is used to cache the data packed by the synchronization and packing module to the memory outside the chip to be debugged through the data bus. Through this debugging system, the data of each debugging node in the chip to be debugged can be read out, which is convenient for subsequent analysis of the read data, and then used to judge whether each debugging module in the chip to be debugged is operating normally.
[0024] The following takes the high-speed power line carrier communication chip as an example to describe the chip function debugging system of the present invention in detail. The high-speed power line carrier communication chip is abbreviated as the modem communication chip. This communication chip includes an adc module, a dcrm module, an AGC module, an FOE module, and an fft module. To implement the debugging of this communication chip, it is necessary to debug each module in this communication chip. There are two main factors affecting the functions of each module. One is that the corresponding algorithm model is problematic, and the other is that there are problems in the module manufacturing process. The purpose of the debugging system of the present invention is to find the module with problems and promptly correct the module with problems, so as to improve the chip yield rate of this communication chip.
[0025] Such as Figure 1As shown in the figure, the debugging system of the present invention includes two groups of debugging units. Each group of debugging units includes a fifo_mux module, a synchronous packaging module, a parameter configuration module, and a data access module. Each group of debugging units is connected to each module in the chip to be debugged. For this embodiment, after determining the nodes of the module to be debugged, the inputs and outputs of each module are generally selected as the debugging nodes, and then the nodes to be debugged are connected to the top layer of the debug_top module. For this embodiment, all nodes are connected to fifo_mux0 (the fifo_mux module of the first group of debugging units) and fifo_mux1 (the fifo_mux module of the second group of debugging units). Then, the fifo_mux module selects one node to be debugged according to the nodes selected by the software. For example, it can be the input and output of the DC conversion module (dcrm module). Among them, the input of the dcrm module is connected to fifo_mux0, and the output of the dcrm module is connected to fifo_mux1. As another real-time method, only one debugging node can also be selected. For example, only the output signal of the adc module is transported.
[0026] The synchronous packaging module cap2ram_wrap is responsible for packaging node data and performing data synchronization, and is used to synchronize and package the data on the nodes connected to the fifo_mux module. Since the ahb bus is used for data storage in this embodiment, and the clock of the ahb bus is hclk, while the working clock of the module is generally not hclk, it is necessary to synchronize the data of the module to the ahb bus clock. This requires that the working clock frequency of this debugging module cannot be higher than the bus clock frequency, otherwise data loss will occur, and the collected data will lose the meaning of analysis. At the same time, to ensure that the data during analysis is synchronous data, it is also necessary to synchronize the input and output data of the module, which is realized according to the trigger pulse and the data valid signal. According to this trigger pulse, the input and output data of the module to be debugged are collected simultaneously. When collecting, only useful signals are collected, and the judgment of whether a signal is a useful signal is determined according to the attribute of the signal. If the signal attribute is the data valid signal, then the signal is judged to be a useful signal, and the input and output of the module to be debugged can be synchronized under the trigger pulse. To improve the efficiency of the bus, packaging can be performed according to the data bus bandwidth. For this embodiment, the bandwidth of the ahb bus is 32bit, and 32bit can be transmitted each time the bus transfers. If the data is less than 32bit, it can be packaged into 32bit data through the cap2ram_wrap module.
[0027] The parameter configuration module cap2ram_wr is responsible for writing the synchronized data into sram_buff according to the configured parameters. The module will first confirm the data trigger acquisition method, including software trigger or hardware trigger. The software trigger triggers the node data acquisition by writing the software register. The hardware method can select the internal pulse signal to automatically trigger the start of the acquisition. The module does not work before the acquisition starts. The maximum value of the collected data can be configured, and the starting position of the collected data can also be configured. For this embodiment, the size of sram_buffer can be configured to 512x32bit, and the depth can also be appropriately increased or decreased according to the data rate of the collected data.
[0028] The data access module ahb_to_sram is used to access the data in sram_buffer. There are two access methods. One is direct access by the CPU in the chip to be debugged through the control bus; the other is access through DMA. Compared with the previous method, the DMA method can avoid using the CPU or reduce the use of the CPU when accessing data. There are two DMA methods. One is the software DMA method. This method requires the CPU in the chip to be debugged. The CPU generates an interrupt signal. Under this interrupt signal, the software DMA module controls the data bus to store the packaged data in the memory outside the chip to be debugged; the other is the hardware DMA method. By setting a hardware DMA module, when data caching is required, the data access module in the debugging system generates a request signal and sends it to the hardware DMA module, and the hardware DMA module controls the data bus to cache the data.
[0029] The principle of interrupt signal generation is that the sram_buff cache is half full. The principle of DMA hardware generation is: dma_s_req0 / 1, indicating that the debug_top module initiates a DMA hardware single request, that is, when the cache buffer is not empty, the debug_top module initiates a request until dma_clr_0 / 1 receives a high pulse and then pulls low. dma_s_req0 / 1 indicates that the debug_top module has cached half of the buffer size, that is, 256 32-bit data, and dma can move data with a length of 256 data. The minimum size of the fifo cache can be set to the length of the dma burst, which places higher requirements on the bus and data sampling rate. That is, each burst must be able to respond in a timely manner, otherwise the data will be overwritten and not moved in time. The depth of the fifo can be set deeper, and the real-time requirements of the software are not high. The specific settings can be determined according to actual needs.
[0030] In order to automatically detect whether all the received data has been removed, the debug module also designs a debug_err_int interrupt for alarm. If the sampled data is not removed and is overwritten by new data in the buffer, then debug_err_int will be generated. After this interrupt is generated, the module needs to be reset to reach the initial state. In order not to generate this interrupt, the data sampling rate of the debug sampling node must be less than the clock frequency of the AHB bus. Generally, when the bus clock frequency is about twice the sampling data frequency, safe sampling can be achieved.
[0031] The working process of this debug system is as Figure 2 shown below. The specific process is as follows:
[0032] 1) First, it is necessary to determine whether to use the interrupt method or the DMA method to transfer data. If the interrupt method is used to transfer data, the interrupt controller needs to be initialized, and in the interrupt service subroutine, the CPU is used to move the debug data to the memory outside the modem. If the DMA method is used to transfer data, the DMA controller needs to be initialized. DMA can use the linked list mode to transfer data, so that it is not necessary to initialize DMA every time the hardware dma_s_req or dma_b_req is received.
[0033] 2) Initialize the debug_top module: Configure cap_sel to select the node to be monitored; Configure the total number of data debug_data_num for this transmission; Configure how many data to skip before starting to store debug_skip_num after the data is valid; Configure the trigger mode debug_trigger_mode for starting data acquisition, which can select software trigger or the burst frame arrival signal inside the hardware to trigger data acquisition.
[0034] 3) Control the debug_top module to be enabled.
[0035] 4) The hardware starts to work. The hardware judges the trigger mode. When the trigger condition is met, it automatically acquires and packs data, synchronizes the data, and stores the data in the internal buffer.
[0036] 5) If the software selects the interrupt method to transfer data, then the CPU will wait until debug_int arrives, start reading the data cached in debug_top, and store it in the cache outside the chip to be debugged.
[0037] 6) If the software selects the DMA method to transfer data, mask the interrupt signal, and the hardware DMA request will automatically apply for DMA to transfer data to the memory outside the chip to be debugged.
[0038] 7) After the number of transferred data reaches debug_data_num, the node data transfer ends.
[0039] Repeating 1)-6) can initiate the next data acquisition.
[0040] Through the above process, the debugging system of the present invention can read out the data of each debugging node in the chip to be debugged, facilitating subsequent analysis of the read data and providing a reliable data source for determining whether each debugging module in the chip to be debugged is operating normally.
Claims
1. A chip function debugging system, characterized in that, the debugging system includes at least two groups of debugging units, and each group of debugging units includes a fifo_mux module, a synchronous packaging module, a parameter configuration module, and a data access module. The fifo_mux module is used to connect to the inputs and outputs of each module in the chip to be debugged, and is used to select debugging nodes from the inputs and outputs of each module in the chip to be debugged; the synchronous packaging module is used to synchronize the node signals according to the trigger signal and the data valid signal, and package the synchronized signals; the parameter configuration module is used to configure the parameters during the debugging process; the data access module is used to cache the data packaged by the synchronous packaging module into the memory outside the chip to be debugged through the data bus.
2. The chip function debugging system according to claim 1, characterized in that, the data access module uses the DMA method or uses the CPU of the chip to be debugged to control the data bus for data caching.
3. The chip function debugging system according to claim 2, characterized in that, the DMA method is a software DMA method, and the CPU of the chip to be debugged is used to generate an interrupt signal, and the software DMA module is triggered through the interrupt to control the data bus for data caching.
4. The chip function debugging system according to claim 2, characterized in that, the DMA method is a hardware DMA method. When data caching is required, a request signal is generated by the debugging system and sent to the hardware DMA module, and the hardware DMA module controls the data bus for data caching.
5. The chip function debugging system according to claim 3 or 4, characterized in that, the data bus is an AHB bus.
6. The chip function debugging system according to claim 3 or 4, characterized in that, the synchronous packaging module packages the data according to the data bit width of the data bus when packaging the data.
7. The chip function debugging system according to claim 3 or 4, characterized in that, the parameters configured by the parameter configuration module include the amount of data required for debugging and the caching method used by the data access module.
8. The chip function debugging system according to claim 1, characterized in that, the debugging system includes two groups of debugging units, which are respectively used to connect to the input end and the output end of any module in the chip to be debugged to realize the debugging of the corresponding module.
9. The chip function debugging system according to claim 1, characterized in that, the data sampling rate of the debugging system is less than the clock frequency of the data bus.
Citation Information
Patent Citations
Navigating-SoC (System On Chip) simulating, verifying and debugging platform
CN102411535A
Universal debugging interface-based SoC (System on Chip) hardware debugger
CN102968364A