Script integrated in eda tool real-time debugging method and system

Abstract

The application relates to a script real-time debugging method and system integrated in an EDA tool. The debugging method comprises the following steps: controlling a main event loop to run, wherein the main event loop is used for processing user operations and system messages in a main thread; in response to an interpreter triggering a preset debugging event, calling a callback function to process current frame information, and creating a local event loop, wherein the local event loop is used for processing the preset debugging event, and the local event loop runs asynchronously with the main event loop. By creating a local event loop in parallel with the main event loop and processing the preset debugging event by using the local loop event, the normal running of the main event loop is not affected, so that the probability of the interpreter blocking the main process is reduced, and the debugging efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of electronic design automation (EDA) technology, and in particular to a method and system for real-time script debugging integrated into EDA tools. Background Technology

[0002] With the continuous development of Electronic Design Automation (EDA) tools, the functions of EDA are constantly being improved. Python, due to its ease of use and robust ecosystem, has become a widely used scripting language for secondary development of EDA software. More and more EDA platforms support secondary development through Python script interfaces to achieve advanced functions such as automated design, layout manipulation, data analysis, and process customization that meet users' actual needs.

[0003] In current technologies, debugging Python code mainly relies on general-purpose Integrated Development Environments (IDEs). While IDEs have common debugging functions such as breakpoints, variable monitoring, and single-step execution, their integration with EDA tools is not yet perfect, which reduces the user experience. Summary of the Invention

[0004] To address the aforementioned technical problems, this application provides a real-time script debugging method and system integrated into EDA tools, aiming to solve the problems of existing technologies.

[0005] A first aspect of this application provides a real-time script debugging method integrated into an EDA tool, the real-time script debugging method integrated into the EDA tool comprising: Control the operation of the main event loop, which is used to process user operations and system messages in the main thread; In response to the interpreter triggering a preset debug event, a callback function is invoked to process the current frame information and a local event loop is created. The local event loop is used to process the preset debug event and runs asynchronously with the main event loop.

[0006] In some embodiments of this application, the method further includes: The callback function is controlled to send the processed frame information to the local event loop; The local event loop is controlled to trigger pause or resume events based on the current debugging session's stepping mode and call level.

[0007] In some embodiments of this application, the method further includes: If a pause event is triggered, determine the variable object reference of the currently executing frame; If the variable object reference contains a pointer and the variable object reference is bound to an image class instance, the pointer is sent to the rendering engine, which is used to locate the graphics rendering process.

[0008] In some embodiments of this application, the method further includes: In response to the interpreter triggering a debug completion event or a debug interruption event, the local event loop is destroyed.

[0009] In some embodiments of this application, the stepping mode includes at least one of the following: Step into, step skip, step out, and continue running; The conditions for triggering the pause event include at least one of the following: The next event is triggered when the current debugging session is in single-step mode; When the current debugging session's step mode is single-step skip, the same level is triggered and the next line event is executed; When the current debugging session's step mode is single-step exit, the execution level returns to the previous level and triggers the next line event; When the current debugging session's step mode is set to continue running, trigger the line number corresponding to the preset breakpoint.

[0010] In some embodiments of this application, the preset breakpoint is set at a preset node, and the preset node includes at least one of function call, parameter passing, rule judgment, and layout generation.

[0011] In some embodiments of this application, the preset debugging event includes at least one of the following: Line execution, function call, function return, exception.

[0012] A second aspect of this application provides a real-time script debugging system integrated into an EDA tool, the real-time script debugging system integrated into the EDA tool comprising: The first control module is configured to control the operation of the main event loop, which is used to process user operations and system messages in the main thread. The second control module is configured to respond to a preset debug event triggered by the interpreter, call a callback function to process the current frame information, and create a local event loop. The local event loop is used to process the preset debug event and runs asynchronously with the main event loop.

[0013] The technical solutions provided by the embodiments of this application may include the following beneficial effects: By creating a local event loop that runs parallel to the main event loop, preset debugging events can be handled using the local loop events without affecting the normal operation of the main event loop. This reduces the probability of the interpreter blocking the main process and improves debugging efficiency.

[0014] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and do not limit this document. Attached Figure Description

[0015] The accompanying drawings, which form part of this document, are used to provide a further understanding of the document. The illustrative embodiments and descriptions herein are used to explain the document and do not constitute an undue limitation thereof. In the drawings: Figure 1 This is a debugging method flow illustrated in an exemplary embodiment of this application. Figure 1 ; Figure 2 This is a debugging method flow illustrated in an exemplary embodiment of this application. Figure 2 ; Figure 3 This is a debugging method flow illustrated in an exemplary embodiment of this application. Figure 3 ; Figure 4 This is a debugging method flow illustrated in an exemplary embodiment of this application. Figure 4 ; Figure 5 This is a debugging method flow illustrated in an exemplary embodiment of this application. Figure 5 ; Figure 6 This is a block diagram illustrating a debugging system in an exemplary embodiment of this application; Figure 7 This is a block diagram of an electronic device illustrated in an exemplary embodiment of this application. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other.

[0017] In related technologies, debugging Python code primarily relies on general-purpose IDEs such as PyCharm and VSCode. While these IDEs offer standard debugging features like breakpoints, variable monitoring, and single-step execution, deep integration with EDA tools may present the following technical challenges: For example, existing debugging methods are prone to blocking the main process. Currently, most Python debuggers are based on a blocking architecture. When a debugging session starts, the debugger pauses or suspends the main process being debugged (i.e., the main process of the EDA tool), preventing users from interacting in real-time or viewing layout updates during debugging, thus hindering them from obtaining immediate feedback on the code execution results.

[0018] Based on this, this application provides a real-time script debugging method and system integrated into EDA tools. During the execution of the main event loop in the main thread of the EDA tool, a local event loop that runs asynchronously with the main event loop is added to handle the preset debugging events triggered by the interpreter. This eliminates the need for complex configuration operations, improves debugging efficiency, reduces the probability of the interpreter blocking the main process, and facilitates timely feedback during the debugging process.

[0019] Combination Figure 1 As shown, an exemplary embodiment of this application provides a real-time script debugging method integrated into an EDA tool, applied to a system of an electronic device, such as the main thread of an operating system or control system of the electronic device. The method includes: S110, controls the main event loop.

[0020] In step S110, the main event loop is used to process user operations and system messages in the main thread.

[0021] In step S110, the main thread executes the main event loop, for example, the main thread of an EDA tool controls the operation of the main event loop.

[0022] S120. In response to the interpreter triggering a preset debug event, call the callback function to process the current frame information and create a local event loop.

[0023] In step S120, the interpreter is a Python interpreter. After the EDA tool starts, the main process loads the PyAether module and initializes the Python interpreter. It registers the tracing callback function through the PyEval_SetTrace interface. After registration, the system enters the debugging state.

[0024] In step S120, the user initiates a debugging task, for example, by selecting the "Start Debugging" control in the EDA tool interface. The system creates a debugging session context, initializes the call depth markers and breakpoint list, and enters debug mode. The main thread executes code line by line in debug mode; at this time, the main event loop is not blocked, and no local event loops are created or running.

[0025] In step S120, the local event loop (Local QEventLoop) is used to handle preset debug events. The local event loop is temporarily created by the system and runs asynchronously with the main event loop for asynchronous processing of the current debug event. Each debug instruction is encapsulated as an event object and submitted to an independent local event loop unit for execution. This local event loop runs independently of the main event loop, thereby achieving non-blocking execution of debug commands within the same process.

[0026] During code execution, when the interpreter triggers a preset debug event, it invokes a callback function previously registered in the PyEval_SetTrace interface. Preset debug events include at least one of the following: line execution, function call, function return, or exception. The callback function can capture execution frame information and preset breakpoint hit status, and manage the execution flow of debug commands through an event loop mechanism. For example, the callback function performs lightweight operations on the current frame information, such as reading the pointer, line number, and call depth of the current execution frame, and then uses the event loop mechanism to post this information to the main thread to implement the execution flow of debug commands.

[0027] The debugging method provided in this embodiment creates a local event loop that runs parallel to the main event loop. This local loop handles preset debugging events without affecting the normal operation of the main event loop, thereby reducing the probability of the interpreter blocking the main process and improving debugging efficiency. By innovatively embedding Python debugging logic within the EDA main process and employing non-blocking communication and event-driven mechanisms, the method avoids the main process suspension problem caused by traditional debuggers, achieving parallel execution of code and user interface interaction.

[0028] Existing debugging methods involve complex environment configurations. For example, current IDEs typically require additional configuration of the Python interpreter path, environment variables, and interface modules for EDA tools (such as PyAether) to communicate with the EDA runtime environment. For layout designers who are not professional software engineers, the configuration process is cumbersome and error-prone, severely impacting debugging efficiency.

[0029] Therefore, refer to Figure 2As shown, this application provides a real-time script debugging method integrated into EDA tools, which may include... Figure 1 The steps S110 and S120 shown are provided, wherein step S120 may include the following steps S121 to S122: S121. Control the callback function to send the processed frame information to the local event loop.

[0030] In step S121, the main thread controls the callback function to send the lightweight operations performed on the frame information in step S120, such as pointers, line numbers, and call depth, to the local event loop.

[0031] S122. Control the local event loop to trigger pause or resume events based on the current debugging session's step mode and call level.

[0032] In step S122, the lifecycle of the local event loop is limited to the current debugging phase. For example, when the local event loop enters, it receives and processes signals, performing tasks such as pause determination, variable resolution, and highlight triggering. When the user executes the "Continue" or "Next" command, the event loop calls `quit` to exit and destroy itself, and then a new event loop is created when the next callback is triggered. This "create-execute-exit" loop mechanism allows the system to perform asynchronous task processing in the same thread without affecting the operation of the main process, such as UI rendering.

[0033] This embodiment supports Python 2.6 and multiple versions, and features callback function debugging and hot reloading, adapting to the complex callback mechanisms and dynamic code modification requirements in EDA script development. Through deep integration of the debugger with the EDA environment, users can directly start debugging without additional configuration of a Python interpreter or PyAether environment, effectively lowering the barrier to entry and reducing environment dependencies; it also consumes minimal system resources, making it suitable for embedding and deployment in large-scale EDA platforms.

[0034] In step S122, the stepping mode of the current debugging session is a user-preset mode, wherein the stepping mode supports standard debugging operations, such as including at least one of the following: Step Into, Step Over, Step Out, and Continue.

[0035] In step S122, the system maintains the current execution depth and compares the current execution depth with the hierarchical change at the time the event was triggered to determine whether the function has entered, returned, or is executing at the same level, thereby achieving step control. For example, based on the step mode and call hierarchy of the current debugging session, the conditions for triggering a pause event include at least one of the following: The next event is triggered when the current debugging session is in single-step mode; When the current debugging session's step mode is single-step skip, the same level is triggered and the next line event is executed; When the current debugging session's step mode is single-step exit, the execution level returns to the previous level and triggers the next line event.

[0036] For example, when the hierarchy remains unchanged, it is considered that the function is executed within the same function body. When the hierarchy increases, it indicates that the function is entering a sub-function call. When the hierarchy decreases, it indicates that the function is returning.

[0037] When the stepping mode of the debugging session selected by the user is single step, as long as the line execution event is triggered, it will be directly determined that "pause is required". For example, if there are many lines of code, regardless of whether a sub-function is entered, the execution will pause after each line is executed and wait for the user's instruction.

[0038] When the stepping mode of the debug session selected by the user is single-step skip, in addition to triggering the line execution event, the current call level also needs to remain unchanged. For example, it should be executed within the same function body, without entering sub-functions (the sub-function level is the next level of the current function), and after all sub-functions have completed execution and returned, the pause operation should be performed on the next line at the same level.

[0039] When the stepping mode of the debug session selected by the user is single-step, in addition to triggering the line execution event, a pause operation is also required on the next line of the previous function level when the current call level returns to the previous function level.

[0040] In related technologies, when IDEs are deeply integrated with EDA tools, existing debugging methods may not yet cover the development and debugging of Process Design Kits (PDKs) implemented in Python. Currently, foreign EDA platforms only support debugging of PDK scripts based on their proprietary scripting languages. For PDKs implemented in Python, existing systems cannot implement source-level breakpoints and debugging within the EDA environment. Developers can only rely on external IDEs to indirectly verify the logic, lacking the debugging capabilities that integrate with the EDA environment.

[0041] Therefore, in step S122, the conditions for triggering the pause event, based on the current debugging session's stepping mode and call level, may also include: When the current debugging session's step mode is set to continue running, trigger the line number corresponding to the preset breakpoint.

[0042] For example, when the step mode of the debugging session selected by the user is to continue running, local events are executed line by line without pausing until the next preset breakpoint is reached. If there is no breakpoint, execution continues until the end of the script.

[0043] In step S122, the system's main process can open and debug the Python PDK script, allowing PDK developers to directly debug their Python-implemented PDK logic in the EDA main environment. Preset breakpoints can be set at preset nodes, and parameter variables in the PDK script can be displayed when debugging is paused. Preset nodes include at least one of function calls, parameter passing, rule judgment, and layout generation, realizing debugging capabilities that are linked with the internal EDA.

[0044] In step S122, it should be understood that if the events received by the local event loop do not meet the above-mentioned pause conditions, the interpreter will continue to execute the events and will not pause.

[0045] For example, if the pause condition is met, the local event loop updates the debug status to "PAUSED" and asynchronously notifies the UI layer to refresh the current execution line and variable tree via a signal-slot mechanism. If the pause condition is not met, the local event loop exits immediately, allowing the interpreter to continue execution, thus ensuring a non-blocking debugging experience.

[0046] In this embodiment, the local event loop determines whether to trigger a pause event, thereby achieving effective scheduling of the interpreter, improving debugging efficiency, without affecting the normal operation of the main event loop, reducing the possibility of blocking the main process, and supporting line-level debugging and breakpoint control of the Python version of PDK source code in the EDA environment.

[0047] In related technologies, when IDEs are deeply integrated with EDA tools, existing debugging methods may still lack linkage with EDA tools. Existing debuggers cannot deeply link with the EDA layout environment, and cannot highlight graphical objects (such as figures or layout elements) related to the current code execution position in real time in the layout interface, thus failing to help engineers intuitively locate problems in complex layout logic.

[0048] Therefore, an exemplary embodiment of this application also provides a real-time script debugging method integrated into an EDA tool, the method including as follows Figure 1 The steps S110 and S120 shown are exemplary, wherein step S120 may include, for example, Figure 2 The steps S121 to S122 are shown. In the method of this embodiment, after the pause event is triggered in step S122, it may further include steps such as... Figure 3 The following steps S1221 to S1222 are shown: S1221. In the event of a pause event, determine the variable object reference of the current execution frame.

[0049] In step S1221, during debugging, global and local variables in the Python execution context are parsed, and the variable names, types, and current values ​​are displayed in a tree structure. When the user selects a variable in the variable tree, the system first extracts the variable object reference from the Python execution frame. The variable object reference includes the object reference of the variable. In the paused state, the system parses the object references of variables in the current execution frame, where variables include global and local variables. When a variable is detected as a graphics class object (such as a geometric figure, device, or layout element) generated by the PyAether extension, the native pointer of the C++ graphics entity stored in the Python object is directly read. When the user selects a variable in the variable tree control, the system first extracts the variable object reference from the Python execution frame.

[0050] S1222. If the variable object reference contains a pointer, and the variable object reference is bound to an image class instance, send the pointer to the rendering engine.

[0051] In step S1222, the image class instance can be, for example, a geometric shape, a device, or other layout element. If the object is a graphics class instance bound through the PyAether extension module, then the native pointer maintained internally by the Python object pointing to the C++ graphics entity is passed to the EDA rendering engine. The rendering engine locates the corresponding graphics entity in memory based on the pointer and triggers the highlighting process.

[0052] In step S1222, the rendering engine is used for graphics rendering processing to position the pointer.

[0053] In step S1222, the rendering engine locates the corresponding graphic entity in memory based on the pointer and triggers the highlight drawing process using the pointer. For example, the position of the object is displayed in the layout interface in the form of an outline or overlay to achieve graphic rendering processing.

[0054] In this embodiment, by obtaining the pointers corresponding to the variables of the graphical objects when debugging is paused, and then performing graphical highlighting through the rendering engine interface, the debugging results are presented in real time. This avoids the time-consuming operation of looking up graphical objects by variable names or indexes, and directly utilizes cross-language object pointer association to achieve zero-latency, high-precision visual linkage between variables and layout objects. The graphical object corresponding to the current breakpoint is synchronously highlighted in the layout interface, allowing users to intuitively observe the layout changes after each line of code is executed, significantly improving the visualization experience of debugging. By providing a real-time, visual, and non-blocking debugging method, the time for locating code problems is significantly shortened, improving the development efficiency of layout engineers and the system interaction experience.

[0055] In one exemplary embodiment, reference Figure 4As shown, a method for real-time script debugging integrated into EDA tools is provided, which may include... Figure 1 The steps S110 and S120 shown also include step S130: S110, controls the main event loop.

[0056] S120. In response to the interpreter triggering a preset debug event, call the callback function to process the current frame information and create a local event loop.

[0057] S130. In response to an interpreter-triggered debug completion event or debug interruption event, destroy the local event loop.

[0058] In step S130, after debugging is completed, the local event loop automatically exits or switches to the next debugging state to ensure real-time system response. The debugging completion event can be generated in response to a user-triggered operation, such as the user selecting "next" or "continue" after pausing, indicating the completion of debugging in the current local loop. The debugging completion event can also be the execution of the last line of code. Debugging interruption events can be active interruptions or exception interruptions. For example, if the user selects to stop debugging during a non-paused period, the system calls the Python interrupt exception triggering interface (calling the PyErr_SetInterrupt function) to trigger an interruption and clears the exception caused by the interruption in the next event loop. Alternatively, if the script encounters an infinite loop or blocks the main process, preventing further execution, the system responds to the user-triggered Ctrl+C keyboard event through an internal event listening mechanism, immediately suspending code execution.

[0059] Optionally, when the user selects "Next" or "Continue," the session state machine updates its flags and restarts the local event loop, allowing the interpreter to resume execution in the next callback event. The session state machine update flags refer to updating some data structures that store frame information. For example, when the user selects the "Continue" or "Step through" command, the system removes the pause flag and calls the `quit` method of the local event loop. At this point, the loop ends and is destroyed, and the interpreter continues execution. When a new debug event arrives, the system creates a new instance of the local event loop, thus implementing an independent event context for each debugging phase and preventing the main event loop from being occupied for an extended period.

[0060] In this embodiment, by monitoring the events triggered by the interpreter, it is determined whether to create or destroy a local event loop. This helps to achieve an independent event context for each debugging stage and avoids the main event loop being occupied for a long time.

[0061] refer to Figure 5As shown, when a user initiates debugging, the Python interpreter triggers a callback event upon executing each statement. The callback function collects information from the current execution frame (line number, function identifier, variable pointer, etc.) and submits the event to the event loop. The interpreter then triggers a preset debug event. The callback function processes the frame information and submits it to the local event loop of the main thread. The local event loop receives the event and determines whether to pause the event based on the current session's stepping mode and call level changes. If the pause condition is met, a pause signal is emitted and the interface display is updated. If not, execution resumes or continues to the next step. When the user selects to proceed to the next step or continue execution, the session state machine updates its flags and restarts the event loop.

[0062] The above-described contents can be implemented individually or in various combinations, and these variations are all within the scope of protection of this application.

[0063] Combination Figure 6 As shown, this disclosure also provides a real-time script debugging system 60 integrated into EDA tools, comprising: The first control module 61 is configured to control the main event loop to run. The main event loop is used to process user operations and system messages in the main thread. The second control module 62 is configured to respond to a preset debug event triggered by the interpreter, call a callback function to process the current frame information, and create a local event loop. The local event loop is used to process the preset debug event and runs asynchronously with the main event loop.

[0064] Furthermore, based on the above embodiments, the second control module 62 can also be used for: The callback function is controlled to send the processed frame information to the local event loop; The local event loop is controlled to trigger pause or resume events based on the current debugging session's step mode and call level.

[0065] Optionally, the second control module 62 is specifically used for: If a pause event is triggered, determine the variable object reference of the currently executing frame; If the variable object reference contains a pointer, and the variable object reference is bound to an image class instance, the pointer is sent to the rendering engine, which uses the pointer to locate the graphics rendering process.

[0066] Furthermore, based on the above embodiments, the second control module 62 can also be used for: In response to an interpreter-triggered debug completion event or debug interruption event, destroy the local event loop.

[0067] Optionally, the stepping mode includes at least one of the following: Step into, step skip, step out, and continue running; The conditions that trigger a pause event include at least one of the following: The next event is triggered when the current debugging session is in single-step mode; When the current debugging session's step mode is single-step skip, the same level is triggered and the next line event is executed; When the current debugging session's step mode is single-step exit, the execution level returns to the previous level and triggers the next line event; When the current debugging session's step mode is set to continue running, trigger the line number corresponding to the preset breakpoint.

[0068] Furthermore, preset breakpoints are set at preset nodes, which include at least one of function calls, parameter passing, rule judgments, and layout generation.

[0069] Optionally, the default debug events include at least one of the following: Line execution, function call, function return, exception.

[0070] The debugging device provided in this embodiment can execute the debugging method of the above embodiment. Its implementation principle and technical effect are similar, and will not be described again in this embodiment.

[0071] In this embodiment of the invention, electronic devices or main control devices can be divided into functional modules according to the above method examples. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional module. It should be noted that the module division in this embodiment of the invention is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0072] In the specific implementation of the aforementioned debugging equipment, each module can be implemented as a processor. The processor can execute computer execution instructions stored in the memory, thereby enabling the processor to perform the aforementioned debugging method.

[0073] Combination Figure 7 As shown, the electronic device 70 includes: At least one processor 71 and memory 72.

[0074] The electronic device also includes a communication component 73.

[0075] The processor 71, memory 72, and communication component 73 are connected via bus 74.

[0076] In the specific implementation process, at least one processor 71 executes computer execution instructions stored in memory 72, causing at least one processor 71 to execute the debugging method as described above.

[0077] The specific implementation process of processor 71 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0078] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method claimed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0079] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage.

[0080] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0081] The above describes the solutions provided by the embodiments of the present invention for the functions implemented by the electronic device and the main control device.

[0082] It is understandable that electronic devices or main control devices include hardware structures and / or software modules that perform the above functions in order to achieve the above functions.

[0083] By combining the units and algorithm steps of the various examples described in the embodiments of this invention, the embodiments of this invention can be implemented in hardware or a combination of hardware and computer software. Whether a certain function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered as exceeding the scope of the technical solution of the embodiments of this invention.

[0084] This application also provides a computer program product, including a computer program that implements a debugging method when executed by a processor.

[0085] The computer program product provided in this embodiment can execute the debugging method of the above embodiment. Its implementation principle and technical effect are similar, and will not be described again in this embodiment.

[0086] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described debugging method.

[0087] The computer-readable storage medium provided in this embodiment can execute the debugging method of the above embodiment. Its implementation principle and technical effect are similar, and will not be described again in this embodiment.

[0088] The aforementioned computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0089] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (devices), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0090] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0091] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0092] In this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that an article or device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such an article or device. Without further limitation, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the article or device that includes said element.

[0093] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0094] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if these modifications and variations fall within the scope of the claims of this application and their equivalents, the intent of this application also includes these modifications and variations.

Claims

1. A method for real-time script debugging integrated into EDA tools, characterized in that, include: Control the operation of the main event loop, which is used to process user operations and system messages in the main thread; In response to the interpreter triggering a preset debug event, a callback function is invoked to process the current frame information and a local event loop is created. The local event loop is used to process the preset debug event and runs asynchronously with the main event loop.

2. The real-time script debugging method integrated into EDA tools according to claim 1, characterized in that, The method further includes: The callback function is controlled to send the processed frame information to the local event loop; The local event loop is controlled to trigger pause or resume events based on the current debugging session's stepping mode and call level.

3. The real-time script debugging method integrated into EDA tools according to claim 2, characterized in that, The method further includes: If a pause event is triggered, determine the variable object reference of the currently executing frame; If the variable object reference contains a pointer and the variable object reference is bound to an image class instance, the pointer is sent to the rendering engine, which is used to locate the graphics rendering process.

4. The real-time script debugging method integrated into EDA tools according to any one of claims 1 to 3, characterized in that, The method further includes: In response to the interpreter triggering a debug completion event or a debug interruption event, the local event loop is destroyed.

5. The real-time script debugging method integrated into EDA tools according to claim 2, characterized in that, The stepping mode includes at least one of the following: Step into, step skip, step out, and continue running; The conditions for triggering the pause event include at least one of the following: The next event is triggered when the current debugging session is in single-step mode; When the current debugging session's step mode is single-step skip, the same level is triggered and the next line event is executed; When the current debugging session's step mode is single-step exit, the execution level returns to the previous level and triggers the next line event; When the current debugging session's step mode is set to continue running, trigger the line number corresponding to the preset breakpoint.

6. The real-time script debugging method integrated into EDA tools according to claim 5, characterized in that, The preset breakpoint is set at a preset node, which includes at least one of function call, parameter passing, rule judgment, and layout generation.

7. The real-time script debugging method integrated into EDA tools according to any one of claims 1 to 3, characterized in that, The preset debugging event includes at least one of the following: Line execution, function call, function return, exception.

8. A real-time script debugging system integrated into EDA tools, characterized in that, include: The first control module is configured to control the operation of the main event loop, which is used to process user operations and system messages in the main thread. The second control module is configured to respond to a preset debug event triggered by the interpreter, call a callback function to process the current frame information, and create a local event loop. The local event loop is used to process the preset debug event and runs asynchronously with the main event loop.

9. The real-time script debugging system integrated into EDA tools according to claim 8, characterized in that, The second control module is also configured as follows: The callback function is controlled to send the processed frame information to the local event loop; The local event loop is controlled to trigger pause or resume events based on the current debugging session's step mode and call level.

10. The real-time script debugging system integrated into EDA tools according to claim 8, characterized in that, The second control module is also configured as follows: In response to the interpreter triggering a debug completion event or a debug interruption event, the local event loop is destroyed.

Images