A chip simulation acceleration method and device, electronic equipment and storage medium
Patent Information
- Application Number
- CN202211026233.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-08-25
- Publication Date
- 2026-09-18
- Estimated Expiration
- 2042-08-25
AI Technical Summary
[0004]鉴于此,本申请的目的在于提供一种芯片仿真加速方法、装置、电子设备及存储介质,以改善当前技术中由于后仿真的时间非常紧迫,容易导致流片时间推迟的问题
[0008] In this embodiment, timing correction is performed on registers in the synthesized netlist that do not meet the timing requirements so that the timing information of the registers meets the timing requirements. Then, based on the timing-corrected synthesized netlist, the SDF file required for post-simulation is simulated. The delay information in this file meets the timing requirements, which enables the internal registers to be sampled correctly. Verification personnel can use this simulated SDF file to prepare for post-simulation in advance.
Smart Images

Figure CN115470748B_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of integrated circuits, and specifically relates to a chip simulation acceleration method, apparatus, electronic device and storage medium. Background Technology
[0002] According to the chip front-end and back-end development process, after the designers complete the RTL (Register Transfer Level) code, the front-end design team writes the timing constraint SDC (Synopsys Design Constraints) file, and then performs synthesis to obtain the synthesis netlist. After synthesis, the verification team completes the physical placement and routing (PR) and timing closure operations, ultimately generating a GDS11 file (a database file format) for tapeout, and providing the final post-simulation netlist and SDF (Standard Delay Format) file. The verification team needs to perform post-simulation based on this post-simulation netlist, SDF file, and ARL (Async Register List, a summary list of the first clock registers across clock domains in digital chip design). The schematic diagram is shown below. Figure 1 As shown. It should be noted that, Figure 1 This is a schematic diagram illustrating the overall process from RTL code to simulation of an asynchronous chip. If it is a synchronous chip, the ARL list is not needed during post-simulation.
[0003] Because post-simulation of chips is relatively slow, setting up and debugging the post-simulation environment takes a lot of time; at the same time, debugging post-simulation test cases also takes a long time. On the other hand, the time interval between the verification team providing the final post-simulation netlist and SDF file and tape-out is very short, leaving very little time for post-simulation. The time allotted for post-simulation significantly impacts the progress of chip development and tape-out. Summary of the Invention
[0004] Therefore, the purpose of this application is to provide a chip simulation acceleration method, apparatus, electronic device and storage medium to improve the problem in the current technology that the tape-out time is easily delayed due to the very tight time of post-simulation.
[0005] The embodiments of this application are implemented as follows:
[0006] In a first aspect, embodiments of this application provide a chip simulation acceleration method, comprising: acquiring a synthesis netlist, an SDC constraint file, and a library file; simulating an SDF file required for post-simulation based on the synthesis netlist, the SDC constraint file, and the library file before completing physical placement and routing; and performing post-simulation simulation based on the SDF file and the synthesis netlist.
[0007] In this embodiment, before completing physical placement and routing, an SDF file is simulated in advance based on the synthesis netlist, SDC constraint file, and library files. This allows for earlier debugging and preparation for post-simulation (as opposed to actual post-simulation). Early post-simulation means design problems can be identified and resolved earlier, reducing chip development risks and the risk of tape-out delays due to design issues. In one possible implementation of the first aspect embodiment, simulating the SDF file required for post-simulation based on the synthesis netlist, SDC constraint file, and library files includes: performing static timing analysis on the synthesis netlist, SDC constraint file, and library files using analysis tools to obtain timing information for each register in the synthesis netlist; timing correction for registers in the synthesis netlist that do not meet timing requirements, so that the timing information of the register meets the timing requirements; and simulating the SDF file required for post-simulation based on the timing-corrected synthesis netlist.
[0008] In this embodiment, timing correction is performed on registers in the synthesized netlist that do not meet the timing requirements so that the timing information of the registers meets the timing requirements. Then, based on the timing-corrected synthesized netlist, the SDF file required for post-simulation is simulated. The delay information in this file meets the timing requirements, which enables the internal registers to be sampled correctly. Verification personnel can use this simulated SDF file to prepare for post-simulation in advance.
[0009] In one possible implementation of the first aspect embodiment, timing correction is performed on registers in the synthesized netlist that do not meet timing requirements, including: adding specified delay information to the registers in the synthesized netlist that do not meet timing requirements, wherein the specified delay information is the difference between the delay information required for timing convergence and the current delay information.
[0010] In this embodiment of the application, by adding specified delay information to the input of a register that does not meet the timing requirements for correction, the timing of the register can be quickly converged.
[0011] In one possible implementation of the first aspect embodiment, post-simulation simulation based on the SDF file and the synthesized netlist includes: performing post-simulation simulation based on the ARL list, the SDF file, and the synthesized netlist, wherein the ARL list is obtained based on the synthesized netlist, the SDC constraint file, and the library file.
[0012] In this embodiment, the chip simulation acceleration method is applied to the post-simulation of asynchronous chips by obtaining the ARL list and performing post-simulation based on the ARL list, SDF file, and synthesized netlist. Furthermore, since this ARL list is generated entirely from a real synthesized netlist, it has high compatibility, can be used entirely for post-simulation, and does not rely on a deep understanding of the design code. It is compatible with different integrated circuit IP cores, even encrypted integrated circuit IP cores.
[0013] In one possible implementation of the first aspect embodiment, the step of obtaining the ARL list based on the synthesized netlist, the SDC constraint file, and the library file includes: performing design analysis on the synthesized netlist, the SDC constraint file, and the library file using analysis tools to obtain register information across all clock domains in the synthesized netlist; and obtaining the ARL list required for post-simulation based on the SDC constraint file and all register information across clock domains.
[0014] In this embodiment of the application, the required ARL list can be obtained quickly by adopting the above method, thereby solving the existing problem of difficulty in obtaining the ARL list.
[0015] In one possible implementation of the first aspect embodiment, the synthesis netlist, the SDC constraint file, and the library file are analyzed using analysis tools to obtain register information across all clock domains in the synthesis netlist. This includes: analyzing the synthesis netlist, the SDC constraint file, and the library file using analysis tools to obtain the synchronous / asynchronous relationship of each register clock in the synthesis netlist; capturing all cross-clock domains in the synchronous / asynchronous relationship; and capturing register information for each cross-clock domain.
[0016] In this embodiment of the application, by adopting the above method, the register information of all cross-clock domains in the integrated netlist can be obtained quickly, thereby quickly obtaining the required ARL list and solving the existing problem of difficulty in obtaining the ARL list.
[0017] In one possible implementation of the first aspect embodiment, the ARL list required for post-simulation is obtained based on the SDC constraint file and all cross-clock domain register information, including: classifying all cross-clock domain register information according to the clock definition in the SDC constraint file; filtering out all cross-clock domain register information with completely asynchronous clocks from the classification results to obtain the ARL list required for post-simulation.
[0018] In this embodiment, by classifying the registers and filtering out all cross-clock domain register information with completely asynchronous clocks from the classification results, the ARL list can be obtained, which allows for a faster acquisition of the required ARL list.
[0019] In one possible implementation of the first aspect embodiment, after filtering out all cross-clock domain register information with completely asynchronous clocks from the classification results to obtain the ARL list required for the post-simulation, the method further includes: outputting all cross-clock domain register information of other categories in the classification results.
[0020] In this embodiment, the register information of all cross-clock domains in other categories of the classification results is output so that designers can verify and determine whether the ARL list is correct.
[0021] Secondly, embodiments of this application also provide a chip simulation acceleration device, including: an acquisition module, an analysis module, and a processing module; the acquisition module is used to acquire a synthesis netlist, an SDC constraint file, and a library file; the analysis module is used to simulate an SDF file required for post-simulation based on the synthesis netlist, the SDC constraint file, and the library file before completing placement and routing; the processing module is used to perform post-simulation simulation based on the SDF file and the synthesis netlist.
[0022] Thirdly, embodiments of this application also provide an electronic device, including: a memory and a processor, the processor being connected to the memory; the memory being used to store a program; the processor being used to invoke the program stored in the memory to execute the method provided by any possible implementation of the first aspect embodiment and / or in combination with the first aspect embodiment.
[0023] Fourthly, embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, performs the method provided by any possible implementation of the first aspect embodiments and / or in combination with the first aspect embodiments.
[0024] Other features and advantages of this application will be set forth in the following description. The objectives and other advantages of this application can be realized and obtained through the structures particularly pointed out in the written description and the accompanying drawings. Attached Figure Description
[0025] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly described below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. The above and other objects, features, and advantages of this application will become clearer through the drawings. The same reference numerals indicate the same parts in all the drawings. The drawings are not intentionally drawn to scale to actual size; the focus is on illustrating the main points of this application.
[0026] Figure 1 This is a schematic diagram of the overall process from RTL code to simulation after completion in the current technology.
[0027] Figure 2 A schematic flowchart of a chip simulation acceleration method provided in an embodiment of this application is shown.
[0028] Figure 3 A schematic diagram of a register classification provided in an embodiment of this application is shown.
[0029] Figure 4 This illustration shows a schematic diagram of the overall process from RTL code to simulation after completion, provided by an embodiment of this application.
[0030] Figure 5 A schematic diagram of a chip emulation acceleration device provided in an embodiment of this application is shown.
[0031] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation
[0032] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.
[0033] It should be noted that similar reference numerals and letters in the following figures denote similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, relational terms such as "first," "second," etc., in the description of this application are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one…" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0034] Furthermore, the term "and / or" in this application is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.
[0035] To address the issue of tight post-simulation time, this application proposes the following technical solution: after synthesis is completed, the SDF file required for post-simulation is obtained in advance based on the synthesized netlist, so as to carry out post-simulation simulation.
[0036] Since the convergence time from the integrated netlist to the completion of the final physical layout and routing can be between 1 and 6 months depending on the project size, the technical solution shown in this application can start the post-simulation work 1 to 6 months earlier, which can help to discover some design problems in advance and greatly reduce the risks that may be encountered when the post-simulation actually begins.
[0037] The following will combine Figure 2 The chip simulation acceleration method provided in the embodiments of this application will be described.
[0038] S1: Obtain the integrated netlist, SDC constraint file, and library files.
[0039] Obtain the simulation parameters required for post-simulation, such as the chip's ARL list, synthesis netlist, SDC constraint file, and library files.
[0040] A composite netlist is a digital schematic composed of standard logic units of a specific process.
[0041] The SDC constraint file contains information such as the chip's frequency and input / output delay.
[0042] The library file (lib) contains timing information for all cells (standard units) involved in the chip.
[0043] The ARL list is a summary list of registers that cross clock domains in a digital chip design. A key purpose of post-simulation is to examine asynchronous cross-clock domain designs and timing issues. Therefore, it's necessary to know which logic in the design crosses clock domains and which registers are involved in the first clock domain cross-domain operation; hence, the ARL list is required. This ARL list can be provided by the designer, and it will be added to the simulation environment during post-simulation.
[0044] As chips become increasingly larger, and many integrated circuit IP cores are used in the chip design process, some of which are even encrypted codes, designers often find it difficult to provide a complete ARL list to the verification team without sufficient understanding of the internal design of the IP. This results in repeated debugging and iterations in post-simulation work, ultimately affecting the chip tape-out time, chip testing, and mass production schedule.
[0045] To address the difficulty in extracting the ARL list, this application's embodiments can quickly obtain the ARL list by integrating netlists, SDC constraint files, and library files. The method described in this application allows for rapid acquisition of the ARL list without relying on a deep understanding of the design code, and is compatible with different integrated circuit IP cores, even encrypted integrated circuit IP cores.
[0046] In one implementation, the steps for obtaining the ARL list of a chip include: obtaining the ARL list required for post-simulation based on the synthesized netlist, SDC constraint file, and library files. Since this ARL list is generated entirely from the actual synthesized netlist, it has high compatibility and can be fully used for post-simulation. Furthermore, it does not rely on a deep understanding of the design code and is compatible with different integrated circuit IP cores, even encrypted integrated circuit IP cores.
[0047] The process of obtaining the ARL list required for post-simulation based on the synthesized netlist, SDC constraint file, and library file can be as follows: Use analysis tools to perform design analysis on the synthesized netlist, SDC constraint file, and library file to obtain the register information across all clock domains in the synthesized netlist. Then, based on the SDC constraint file and the register information across all clock domains, obtain the ARL list required for post-simulation.
[0048] In one implementation, the process of using analysis tools to design and analyze the synthesized netlist, SDC constraint file, and library file to obtain the register information of all cross-clock domains in the synthesized netlist can be as follows: using analysis tools to design and analyze the synthesized netlist, SDC constraint file, and library file to obtain the synchronous and asynchronous relationships of the clocks of each register in the synthesized netlist, capturing all cross-clock domains in the synchronous and asynchronous relationships, capturing the register information of each cross-clock domain, and obtaining the ARL list required for post-simulation based on the SDC constraint file and the register information of all cross-clock domains.
[0049] Taking EDA (Electronic Design Automation) tools as an example: Analysis tools (such as PTC, a branch of PT (Prime Time) tools, primarily used to check the quality of SDC files and analyze relationships between clock domains) are used to perform design analysis on the synthesis netlist, SDC constraint file, and lib file. This involves using analysis tools to read the synthesis netlist, SDC constraint file, and lib file for design analysis, obtaining the synchronous and asynchronous relationships of the clocks of each register in the synthesis netlist. The `report_clock_crossing` command in the PTC tool (a command used to capture interaction information between all clocks) is then used to obtain all cross-clock domains. Finally, `get_clock_crossing_points-from` is used... <launchclocks>-to<capture clock> The command (used to capture register information across clocks between two clocks) is used to obtain register information for each clock domain. Then, based on the SDC constraint file and the captured register information across all clock domains, the ARL list required for post-simulation can be obtained.
[0050] This application provides a method for quickly obtaining an ARL list, and is not limited to specific implementation commands. The commands in the above examples are used to illustrate a particular EDA tool, but are not specifically limited to any particular type of EDA tool.
[0051] The process of obtaining the ARL list required for post-simulation based on the SDC constraint file and all cross-clock domain register information can be as follows: Classify all cross-clock domain register information according to the clock definitions in the SDC constraint file; filter out all cross-clock domain register information with completely asynchronous clocks from the classification results to obtain the ARL list required for post-simulation. For example, all cross-clock domain register information can be divided into three categories: the first category is completely asynchronous clocks (Fullasync), the second category is partially asynchronous clocks (Part async), and the third category is fake asynchronous clocks (Fake async). The schematic diagram is shown below. Figure 3 As shown. For Figure 3 In the Full async type, we can see that the clocks of reg1 and reg2 are asynchronous. For Figure 3 In the `Part async` type, we can see that the clocks of `reg1` and `reg2` are asynchronous, while the clocks of `reg2` and `reg3` are synchronous; only some clocks are asynchronous. For Figure 3 In the Fake async type, we can see that the clocks of reg1 and reg2 are synchronized, which means they are pseudo-asynchronous.
[0052] The register information in the first category is the ARL list required for post-simulation. Registers in the second category are theoretically unnecessary and can be further verified by the designer. Registers in the third category are pseudo-ARL lists introduced by the constraint methods in SDC and can be deleted.
[0053] In one alternative implementation, after filtering out all cross-clock domain register information with completely asynchronous clocks from the classification results to obtain the ARL list required for post-simulation, the chip simulation acceleration method further includes: outputting all cross-clock domain register information of other categories in the classification results, for example, outputting register information of the second and third categories.
[0054] S2: Before completing the physical layout and routing, based on the synthesized netlist, the SDC constraint file and the library file, simulate the SDF file required for post-simulation.
[0055] After obtaining the above parameters, the SDF file required for post-simulation can be simulated in advance based on the synthesized netlist, SDC constraint file, and library files before completing the physical placement and routing. The SDF file records the delay information between each standard cell in the synthesized netlist. Post-simulation requires this delay information to perform realistic functional simulation in order to confirm the correctness of the chip's timing functions.
[0056] In one optional implementation, the process of simulating the SDF file required for post-simulation based on the synthesized netlist, SDC constraint file, and library file can be as follows: using analysis tools to perform static timing analysis on the synthesized netlist, SDC constraint file, and library file, obtaining the timing information of each register in the synthesized netlist, performing timing correction on registers in the synthesized netlist that do not meet the timing requirements (such as timing non-convergence) so that the timing information of the register meets the timing requirements, and then simulating the SDF file required for post-simulation based on the timing-corrected synthesized netlist.
[0057] The process of timing correction for registers in the synthesized netlist that do not meet timing requirements can be as follows: add specified delay information to the registers in the synthesized netlist that do not meet timing requirements. The specified delay information added is the difference between the delay information required for timing convergence and the current delay information.
[0058] Taking an EDA tool as an example: After synthesis is complete, the PT tool is used to read the lib file and SDC constraint file, and perform static timing analysis on the synthesized netlist. This step mainly involves checking the existing timing conditions, including setup time (register data setup time), hold time (register data retention time), recovery time (register reset setup time), and removal time (register reset hold time). For registers that do not meet the timing requirements, the `set_annotated_delay` command (a PT tool command used to add a virtual delay at a certain point to correct timing problems) is used in the PT tool to add appropriate delay information to the inputs of the registers that do not meet the timing requirements in the netlist, thereby fixing the corresponding hold time and removal time timing problems until timing convergence is achieved. Afterwards, the `write_sdf` command (a PT tool command used to generate an SDF file for post-simulation) can be used in the PT tool to simulate the SDF file required for post-simulation based on the timing-corrected synthesized netlist.
[0059] This application provides a method for obtaining SDF files in advance, without being limited to specific implementation commands. The commands in the above examples are used to illustrate a particular EDA tool, but are not specifically limited to any particular type of EDA tool.
[0060] Understandably, this correction is virtual because the synthesized netlist has not yet undergone physical placement and routing, so there is no physical delay. However, after this virtual correction, an SDF file can be written using the `write_sdf` command in the PT tool. The delay information in this file meets the timing requirements, ensuring correct sampling of internal registers. Verification personnel can use this simulated SDF file to prepare for post-simulation in advance.
[0061] S3: Perform post-simulation based on the SDF file and the integrated netlist.
[0062] After obtaining the SDF file through pre-simulation, post-simulation can be performed sequentially. For synchronous chips, post-simulation can be performed based on the SDF file and the synthesized netlist.
[0063] When the chip is an asynchronous chip, post-simulation also needs to be combined with the aforementioned ARL list. That is, in one implementation, the post-simulation process based on the SDF file and the synthesized netlist can be: performing post-simulation based on the ARL list, SDF file, and synthesized netlist.
[0064] The post-simulation process based on SDF files, synthesis netlists, and ARL lists is similar to existing post-simulation processes based on SDF files, post-simulation netlists, and ARL lists. Both require setting up and debugging the post-simulation verification environment. By conducting post-simulation, the environment can be set up and debugged in advance, allowing for faster initiation of post-simulation verification testing. Early post-simulation means design problems can be identified and resolved earlier, reducing chip development risks and the risk of tape-out delays due to design issues. It's understood that this post-simulation is only a trial, not the final, true post-simulation, but it allows for the preparation of the post-simulation environment, removing potential obstacles for the final simulation and enabling the early identification and resolution of design problems, preventing fatal design issues from being overlooked later and impacting chip tape-out progress. Furthermore, because the post-simulation process requires setting up and debugging the verification environment, the subsequent actual post-simulation can skip these steps, improving the efficiency of the final post-simulation.
[0065] In one implementation, in Figure 1 Based on the existing post-simulation method shown, by employing the chip simulation acceleration method described in this application, the following can be obtained: Figure 4 The schematic diagram is shown. By comparison... Figure 4 and Figure 1 As can be seen, this application can obtain the ARL list and SDF file required for post-simulation by synthesizing the netlist, SDC constraint file, and library files after synthesis and before physical placement and routing. This allows for the early setup and debugging of the post-simulation verification environment, enabling rapid initiation of post-simulation verification testing. This eliminates the need for extensive setup and debugging of the post-simulation verification environment when actual post-simulation begins, significantly shortening the testing time. In a normal chip development process, physical placement and routing typically lasts about 3 months, while post-simulation preparation and simulation time can take more than 2 months. Traditional chip development processes begin post-simulation only after physical placement and routing are fully completed, requiring at least 5 months (3 months for physical placement and routing + 2 months for post-simulation). The chip simulation acceleration method shown in this application allows for the generation of simulation SDF files in advance while performing physical placement and routing in the backend, enabling early debugging of the post-simulation environment. Based on experience from different projects, the time for chip backend implementation and post-simulation is reduced from 5 months to 3 months.
[0066] Based on the same inventive concept, this application also provides a chip simulation acceleration device 100, such as... Figure 5 As shown. The chip simulation acceleration device 100 includes: an acquisition module 110, an analysis module 120, and a processing module 130.
[0067] Module 110 is used to acquire the integrated netlist, SDC constraint file, and library file.
[0068] Analysis module 120 is used to simulate and obtain the SDF file required for post-simulation based on the synthesized netlist, the SDC constraint file and the library file before completing the layout and routing.
[0069] The processing module 130 is used to perform post-simulation based on the SDF file and the integrated netlist.
[0070] Analysis module 120 is used to perform static timing analysis on the synthesized netlist, the SDC constraint file, and the library file using analysis tools to obtain the timing information of each register in the synthesized netlist; to perform timing correction on registers in the synthesized netlist that do not meet the timing requirements so that the timing information of the register meets the timing requirements; and to simulate the SDF file required for post-simulation based on the timing-corrected synthesized netlist.
[0071] Analysis module 120 is used to add specified delay information to registers in the integrated netlist that do not meet timing requirements. The specified delay information is the difference between the delay information required for timing convergence and the current delay information.
[0072] Optionally, the processing module 130 is used to perform post-simulation based on the ARL list, the SDF file, and the synthesized netlist, wherein the ARL list is obtained based on the synthesized netlist, the SDC constraint file, and the library file.
[0073] The step of obtaining the ARL list for the chip includes: obtaining the ARL list required for post-simulation based on the synthesized netlist, the SDC constraint file, and the library file. Optionally, the analysis module 120 is further configured to obtain the ARL list required for post-simulation based on the synthesized netlist, the SDC constraint file, and the library file.
[0074] Analysis module 120 is used to perform design analysis on the synthesized netlist, the SDC constraint file and the library file using analysis tools to obtain the register information of all cross-clock domains in the synthesized netlist; and to obtain the ARL list required for post-simulation based on the SDC constraint file and the register information of all cross-clock domains.
[0075] Analysis module 120 is used to perform design analysis on the synthesized netlist, the SDC constraint file and the library file using analysis tools to obtain the synchronous and asynchronous relationships of the clocks of each register in the synthesized netlist; capture all cross-clock domains in the synchronous and asynchronous relationships; and capture the register information of each cross-clock domain.
[0076] Analysis module 120 is used to classify all cross-clock domain register information according to the clock definition in the SDC constraint file; and to filter out all cross-clock domain register information with completely asynchronous clocks from the classification results to obtain the ARL list required for the post-simulation.
[0077] The chip simulation acceleration device 100 provided in this application embodiment has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned method embodiment.
[0078] like Figure 6 As shown, Figure 6 This diagram illustrates a structural block diagram of an electronic device 200 provided in an embodiment of this application. The electronic device 200 includes: a transceiver 210, a memory 220, a communication bus 230, and a processor 240.
[0079] The transceiver 210, the memory 220, and the processor 240 are electrically connected to each other directly or indirectly to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses 230 or signal lines.
[0080] The transceiver 210 is used for sending and receiving data. The memory 220 is used to store computer programs, such as... Figure 5 The software functional module shown is the chip simulation acceleration device 100. The chip simulation acceleration device 100 includes at least one software functional module that can be stored in the memory 220 in the form of software or firmware, or embedded in the operating system (OS) of the electronic device 200. The processor 240 is used to execute executable modules stored in the memory 220, such as the software functional modules or computer programs included in the chip simulation acceleration device 100. For example, the processor 240 is used to acquire a synthesis netlist, an SDC constraint file, and a library file; before completing physical placement and routing, it simulates the SDF file required for post-simulation based on the synthesis netlist, the SDC constraint file, and the library file; and performs post-simulation simulation based on the SDF file and the synthesis netlist.
[0081] The memory 220 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.
[0082] Processor 240 may be an integrated circuit chip with signal processing capabilities. The aforementioned processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor, or processor 240 can be any conventional processor.
[0083] The aforementioned electronic devices 200 include, but are not limited to, computers, servers, etc.
[0084] This application embodiment also provides a non-volatile computer-readable storage medium (hereinafter referred to as storage medium) storing a computer program, which is executed by a computer such as the above-described electronic device 200 to perform the chip emulation acceleration method described above.
[0085] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.
[0086] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
[0087] In addition, the functional modules in the various embodiments of this 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.
[0088] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a computer-readable storage medium and includes several instructions to cause a computer device (which may be a personal computer, laptop, server, or electronic device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned computer-readable storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0089] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.< / launchclocks>
Claims
1. A chip simulation acceleration method, characterized in that, include: Obtain the integrated netlist, SDC constraint file, and library files; Before completing the physical layout and routing, the SDF file required for post-simulation is simulated based on the synthesized netlist, the SDC constraint file, and the library file. Post-simulation is performed based on the SDF file and the synthesized netlist. The post-simulation simulation based on the SDF file and the synthesized netlist includes: performing post-simulation simulation based on the ARL list, the SDF file, and the synthesized netlist, wherein the step of obtaining the ARL list based on the synthesized netlist, the SDC constraint file, and the library file includes: The synthesis netlist, the SDC constraint file, and the library file are analyzed using analysis tools to obtain the register information across clock domains in the synthesis netlist. Based on the SDC constraint file and all cross-clock domain register information, the ARL list required for the post-simulation is obtained.
2. The method according to claim 1, characterized in that, Based on the synthesized netlist, the SDC constraint file, and the library file, the SDF file required for post-simulation is obtained, including: Static timing analysis is performed on the synthesized netlist, the SDC constraint file, and the library file using analysis tools to obtain the timing information of each register in the synthesized netlist; Timing correction is performed on registers in the synthesized netlist that do not meet the timing requirements, so that the timing information of the register meets the timing requirements; Based on the timing-corrected synthesized netlist, the SDF file required for post-simulation is obtained through simulation.
3. The method according to claim 2, characterized in that, Timing correction is performed on registers in the synthesized netlist that do not meet timing requirements, including: Add specified delay information to registers in the synthesized netlist that do not meet timing requirements. The specified delay information is the difference between the delay information required for timing convergence and the current delay information.
4. The method according to claim 1, characterized in that, Using analysis tools, the synthesized netlist, the SDC constraint file, and the library files are designed and analyzed to obtain register information across all clock domains in the synthesized netlist, including: The synthesis netlist, the SDC constraint file, and the library file are analyzed using analysis tools to obtain the synchronous and asynchronous relationships of the clocks of each register in the synthesis netlist. Capture all cross-clock domains in the synchronous-asynchronous relationship; Capture register information for each of the aforementioned cross-clock domains.
5. The method according to claim 1, characterized in that, Based on the SDC constraint file and all cross-clock domain register information, the ARL list required for the post-simulation is obtained, including: All register information across clock domains is categorized according to the clock definitions in the SDC constraint file; The ARL list required for post-simulation is obtained by filtering out all cross-clock domain register information with completely asynchronous clocks from the classification results.
6. The method according to claim 5, characterized in that, After filtering out all cross-clock domain register information with completely asynchronous clocks from the classification results to obtain the ARL list required for post-simulation, the method further includes: Output the register information across clock domains for all other categories in the classification results.
7. A chip emulation acceleration device, characterized in that, include: The acquisition module is used to acquire the integrated netlist, SDC constraint file, and library files; The analysis module is used to simulate and obtain the SDF file required for post-simulation based on the synthesized netlist, the SDC constraint file, and the library file before the placement and routing are completed. The processing module is used to perform post-simulation based on the SDF file and the integrated netlist; The post-simulation simulation based on the SDF file and the synthesized netlist includes: performing post-simulation simulation based on the ARL list, the SDF file, and the synthesized netlist, wherein the step of obtaining the ARL list based on the synthesized netlist, the SDC constraint file, and the library file includes: The synthesis netlist, the SDC constraint file, and the library file are analyzed using analysis tools to obtain the register information across clock domains in the synthesis netlist. Based on the SDC constraint file and all cross-clock domain register information, the ARL list required for the post-simulation is obtained.
8. An electronic device, characterized in that, include: A memory and a processor, wherein the processor is connected to the memory; The memory is used to store programs; The processor is configured to invoke a program stored in the memory to execute the method as described in any one of claims 1-6.
9. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by a processor, performs the method as described in any one of claims 1-6.
Citation Information
Patent Citations
Timing constraint checking method
CN106407489A