Hardware circuit module schematic diagram generation method and computing device

Abstract

Embodiments of the present application provide a hardware circuit module schematic diagram generation method and a computing device. The method comprises: obtaining module characteristic information corresponding to a target function module input by a user; determining a matched core device based on the module characteristic information, and determining a schematic diagram of an auxiliary device corresponding to the core device; inputting the schematic diagram of the auxiliary device, the core device and module interface information into a large language model to obtain an auxiliary device list and a device connection topology rule; generating a module netlist based on the auxiliary device list and the device connection topology rule, and generating a target sub-circuit schematic diagram based on the module netlist. By using the above method, through the cooperative action of the schematic diagram database and the large language model, the module netlist is generated based on the core device as the core and in combination with the auxiliary device and its connection rule, and the sub-circuit schematic diagram is constructed based on the module netlist, so that the demand-driven automatic generation of the circuit is realized, and the efficiency and accuracy of the generation of the sub-circuit schematic diagram are effectively improved.

Description

Technical Field

[0001] This application relates to the field of integrated circuit design technology, and in particular to a method and computing device for generating schematic diagrams of hardware circuit modules. Background Technology

[0002] Soldering printed circuit boards (PCBs) typically requires a pre-designed electronic design automation (EDA) circuit schematic. The schematic describes the types, parameters, and electrical connections of various electronic components in the circuit, providing a design basis for subsequent PCB layout, routing, and circuit board production.

[0003] As electronic products become increasingly complex, hardware systems are often divided into multiple functional modules to improve design efficiency. In engineering practice, it is necessary to "extract" the sub-circuit diagrams of specific hardware modules from the overall circuit schematic.

[0004] Currently, the design of sub-circuit diagrams mainly relies on retrieving existing modular sub-circuit diagrams from historical projects in a database to obtain those similar to or identical to the current requirements. Designers then manually adjust these diagrams according to the current needs. However, this process of generating sub-circuit diagrams is highly dependent on manual operation, which affects the efficiency and accuracy of the generation process. Summary of the Invention

[0005] This application provides a method and computing device for generating hardware circuit module schematics. By utilizing the synergy of a schematic database and a large language model, a module netlist is generated with core components as the core and auxiliary components and their connection rules as the core. Based on the module netlist, a hardware circuit module schematic is constructed, realizing the automatic generation of circuits driven by requirements, effectively improving the efficiency and accuracy of hardware circuit module schematic generation.

[0006] To achieve the above objectives, the embodiments of this application adopt the following technical solutions: In a first aspect, embodiments of this application provide a method for generating a hardware circuit module schematic diagram. The method includes: acquiring module feature information corresponding to a target functional module input by a user; wherein the module feature information is used to characterize the functional requirements and constraints of the target hardware circuit module schematic diagram; determining core devices matching the module feature information based on the module feature information; the core devices are used to characterize the main devices representing the core functions of the target functional module; retrieving a preset schematic diagram database based on the core devices to determine the auxiliary device schematic diagrams corresponding to the core devices; inputting the auxiliary device schematic diagrams, core devices, and user-inputted module interface information into a large language model to obtain an auxiliary device list and device connection topology rules; generating a module netlist corresponding to the target functional module based on the auxiliary device list and device connection topology rules; wherein the module netlist is used to characterize each device and the electrical connection relationships between devices; and generating a target hardware circuit module schematic diagram corresponding to the target functional module based on the module netlist.

[0007] Based on this scheme, by acquiring module feature information representing the target functional module and its electrical constraints, it is possible to accurately match the core device (target device) corresponding to the functional requirements, thereby ensuring reasonable device selection and functional compatibility, and laying the foundation for building reliable peripheral circuits. Furthermore, by intelligently parsing the schematic diagrams of core devices and auxiliary devices, as well as the module interface information provided by the user, using a large language model, a structured list of auxiliary devices and connection topology rules between devices can be automatically generated. This effectively ensures the reliability of auxiliary devices and the correctness of electrical connection relationships, thereby supporting the generation of a high-precision module netlist, and ultimately outputting a complete and standardized target hardware circuit module schematic diagram. In this way, by utilizing the synergy of the schematic database and the large language model, using the core device as the core, combining auxiliary devices and their connection rules to generate a module netlist, and constructing a hardware circuit module schematic diagram based on the module netlist, automatic circuit generation driven by requirements is achieved, effectively improving the efficiency and accuracy of hardware circuit module schematic diagram generation.

[0008] In one possible implementation, based on the core device, a preset schematic database is searched to determine the schematic diagram of the auxiliary device corresponding to the main device. This includes: based on the core device, querying the module feature data table in the schematic database to see if a target historical schematic diagram corresponding to the core device exists; if a target historical schematic diagram is found, it is determined as the auxiliary device schematic diagram; if no target historical schematic diagram is found, a standard circuit schematic diagram corresponding to the core device is obtained from the reference design table in the schematic database, and the standard circuit schematic diagram is determined as the auxiliary device schematic diagram; wherein, the reference design table stores general peripheral circuit schematic diagrams provided by device manufacturers that are applicable to the core device.

[0009] Based on this solution, by combining core components, the module feature data table in the preset schematic database is searched, prioritizing the matching of verified historical schematics. If a corresponding target historical schematic exists, the auxiliary circuit, which has been tested in actual applications, is directly reused to ensure design consistency, compatibility, and engineering reliability. If no matching historical data exists, the system automatically reverts to the reference design table, calling the standard peripheral circuit schematics provided by the component manufacturers as alternatives, ensuring the standardization and effectiveness of the peripheral circuits in terms of electrical characteristics and functional implementation. In this way, by prioritizing historical schematics and reverting to reference designs, the system fully utilizes existing project experience and relies on authoritative manufacturer reference designs as a backup, achieving a balance between high reusability and high reliability, and significantly improving the adaptability of auxiliary circuit selection.

[0010] In another possible implementation, determining the core device matching the module feature information based on module feature information includes: searching a preset schematic database based on the module feature information to determine a list of main devices matching the module feature information; calculating the similarity score of each main device in the main device list based on the target functional module; wherein the main device list includes at least one main device identifier and device features corresponding to each main device; sorting the main device list based on the similarity scores of each main device, and determining the core device matching the module feature information based on the sorted main device list.

[0011] Based on this scheme, a structured comparison is performed between module feature information and main component features in a pre-set schematic database. First, a list of candidate main components within the functional scope is retrieved. Then, considering the specific requirements of the target functional module (such as operating voltage, bandwidth, power consumption, and interface type), a similarity score is calculated for each main component in the list to match the user's requirements. This score comprehensively reflects the component's performance in terms of functional matching, electrical parameter fit, and application scenario adaptability. Finally, candidate components are ranked according to the similarity score, and core components are selected. This approach not only avoids the subjectivity and inefficiency of manual selection but also ensures that the selected core components are closest to the original design intent in terms of technical specifications and functional implementation. This provides a high-precision and highly adaptable core foundation for subsequent auxiliary circuit generation and automatic schematic construction, effectively improving the efficiency and accuracy of hardware circuit module schematic generation.

[0012] In another possible implementation, the main component list is sorted based on the similarity scores of each main component, and the core component matching the module feature information is determined based on the sorted main component list. This includes: sorting the main component list based on the similarity scores of each main component to obtain a sorted main component list; inputting the similarity scores and the structured constraint factors corresponding to the main components into a large language model to obtain at least one recommended main component; wherein, the structured constraint factors are used to characterize the constraints of the target functional module in the electrical design; and determining the core component from the at least one recommended main component.

[0013] Based on this scheme, after sorting the main component list by similarity score, the similarity score of each candidate main component and its complete structured constraints (such as package type, electrical parameters, operating environment requirements, cost information, and supply status) are further input into the large language model. The large language model, combining its understanding of electronic engineering knowledge, design constraints, and practical application context, comprehensively evaluates the applicability of each candidate component, thereby generating one or more recommended main component lists that better meet engineering practice needs. In this way, by integrating structured data with the reasoning capabilities of the large language model, the selected core components better meet user requirements, providing a foundation for the subsequent generation of sub-circuit diagrams.

[0014] In another possible implementation, based on module feature information, a preset schematic database is searched to determine a list of main devices that match the module feature information, including: based on the module feature information, searching in the module feature table of the schematic database for at least one device code that matches the module feature information; and determining the main device corresponding to the at least one device code as the list of main devices that match the module feature information.

[0015] Based on this scheme, the abstract functional requirements of a module are transformed into a specific list of selectable components by utilizing the standardized component codes already available in the schematic database. Compared to methods relying on fuzzy keyword searches or manual review, this method directly matches based on structured data, avoiding biases caused by semantic ambiguity and subjective judgment. Since the component codes are unique in the database and associated with complete technical parameters and application information, it ensures that the selected candidate components are strictly consistent with the module's feature information in terms of function and specifications, thereby comprehensively improving the efficiency of component selection in automated circuit design.

[0016] In another possible implementation, based on module feature information, a preset schematic database is searched to determine a list of main devices matching the module feature information. This includes: based on the module feature information, searching the module feature table of the schematic database for at least one device code matching the module feature information; determining the main device corresponding to the at least one device code as an initial device set; generating virtual device features based on the common features of devices of the same type in the initial device set; using the virtual device features to perform an extended search in the device feature table of the schematic database to obtain a supplementary device set; and determining a list of main devices matching the module feature information based on the initial device set and the supplementary device set.

[0017] Based on this scheme, matching device codes are retrieved from the schematic database using module feature information to obtain an initial device set. Common characteristics of similar devices (such as electrical parameters, packaging, and interfaces) are analyzed to generate virtual device features, which are then used for extended retrieval to obtain a supplementary device set. Finally, the initial and supplementary sets are merged to form a complete main device list. This approach preserves the accuracy of the original matching results and, by introducing a common feature-driven extended retrieval mechanism, effectively improves the breadth and diversity of candidate devices, avoiding the omission of potentially applicable devices due to keyword or parameter threshold limitations. This enhances the flexibility and completeness of device selection while ensuring technical consistency.

[0018] In another possible implementation, virtual device features are generated based on the common features of similar devices in the initial device set, including: selecting multiple similar devices from the initial device set; wherein, similar devices are used to characterize devices with the same or similar device features; inputting multiple similar devices and their corresponding first preset prompt words into a large language model, and outputting virtual device features; wherein, virtual device features are used to characterize the union of multiple similar device features.

[0019] Based on this scheme, multiple devices with the same device type and sharing some key features are selected from the initial device set. The feature information of these devices of the same type, along with their corresponding first preset prompts (such as functional descriptions, typical application scenarios, etc.), are used as input and fed into a large language model. The model then comprehensively analyzes and outputs a virtual device feature that can characterize the commonalities and feature coverage of this group of devices. This approach preserves the accuracy of the original matching results and, by introducing a common feature-driven extended retrieval mechanism, effectively improves the breadth and diversity of candidate devices, avoiding the omission of potentially applicable devices due to keyword or parameter threshold limitations. This enhances the flexibility and completeness of the selection process while ensuring technical consistency.

[0020] In another possible implementation, a module netlist corresponding to the target functional module is generated based on the auxiliary device list and device connection topology rules, including: obtaining the pin information of the core device; inputting the pin information of the core device, the auxiliary device list, the device connection topology rules, and the second preset prompt word into the large language model to generate the module netlist corresponding to the target functional module; wherein, the auxiliary device list includes at least one auxiliary device identifier and the device features corresponding to each auxiliary device; the device connection topology rules include the connection rules of the core device and the auxiliary devices.

[0021] Based on this scheme, when generating the module netlist corresponding to the target functional module, the pin information of the core device is first obtained. Then, this pin information, a list of auxiliary devices (including the identifiers of each auxiliary device and their corresponding device characteristics), device connection topology rules (defining the connection relationships between the core device and auxiliary devices), and a second preset prompt word are used as input to a large language model for structured reasoning and integration, thereby automatically generating a module netlist that conforms to electrical connection specifications and functional requirements. In this way, by integrating structured data and semantic guidance, the accuracy of netlist module generation is improved.

[0022] In another possible implementation, the method further includes: acquiring historical data corresponding to historical projects; wherein the historical data includes historical module feature function definitions, historical schematics, historical device features, historical reference designs, and historical module netlists; the historical module feature function definitions are used to characterize the functional attributes of hardware modules; a module feature data table is constructed based on the historical module feature function definitions, historical schematics, and historical module netlists; a reference design table is constructed based on historical reference designs; a device feature table is constructed based on historical device features; and the module feature data table, the historical reference design data table, and the device feature data table are associated to establish a correspondence between the three to form a schematic database.

[0023] Based on this solution, a structured schematic database is constructed by integrating multi-dimensional data from historical projects. This results in a schematic database that supports efficient retrieval and intelligent recommendations. This database provides the data foundation and knowledge support for subsequent modular design, component selection, and automatic netlist generation.

[0024] Secondly, embodiments of this application also provide a hardware circuit module schematic generation apparatus, which includes: an acquisition module for acquiring module feature information corresponding to a target functional module input by a user; wherein the module feature information is used to characterize the functional requirements and constraints of the target hardware circuit module schematic; a determination module for determining core devices matching the module feature information based on the module feature information; the core devices are used to characterize the main devices of the core function of the target functional module; the determination module is also used to search a preset schematic database based on the core devices to determine the auxiliary device schematics corresponding to the core devices; the determination module is also used to input the auxiliary device schematics, core devices, and user-input module interface information into a large language model to obtain an auxiliary device list and device connection topology rules; a generation module for generating a module netlist corresponding to the target functional module based on the auxiliary device list and device connection topology rules; wherein the module netlist is used to characterize each device and the electrical connection relationships between each device; the generation module is also used to generate a target hardware circuit module schematic corresponding to the target functional module based on the module netlist.

[0025] In one possible implementation, the determining module is further configured to query, based on the core device, whether a target historical schematic corresponding to the core device exists in the module feature data table of the schematic database; if a target historical schematic is found, the target historical circuit schematic is determined as the auxiliary device schematic; if no target historical schematic is found, a standard circuit schematic corresponding to the core device is obtained from the reference design table of the schematic database, and the standard circuit schematic is determined as the auxiliary device schematic; wherein, the reference design table stores general peripheral circuit schematics provided by device manufacturers that are applicable to the core device.

[0026] In another possible implementation, the determining module is further configured to retrieve a preset schematic database based on module feature information to determine a list of main components that match the module feature information; calculate a similarity score for each main component in the main component list based on the target functional module; wherein the main component list includes at least one main component identifier and the component features corresponding to each main component; sort the main component list based on the similarity scores of each main component, and determine the core component that matches the module feature information based on the sorted main component list.

[0027] In another possible implementation, the determining module is further configured to sort the list of main components based on the similarity scores of each main component, thereby obtaining a sorted list of main components; input the similarity scores and the structured constraint factors corresponding to the main components into a large language model to obtain at least one recommended main component; wherein, the structured constraint factors are used to characterize the constraints of the target functional module in the electrical design; and determine the core component from the at least one recommended main component.

[0028] In another possible implementation, a determining module is used to retrieve at least one device code that matches the module feature information from the module feature table of the schematic database based on the module feature information; and to determine the main device corresponding to the at least one device code as a list of main devices that match the module feature information.

[0029] In another possible implementation, a determination module is used to retrieve at least one device code that matches the module feature information from the module feature table of the schematic database based on module feature information; determine the main device corresponding to the at least one device code as an initial device set; generate virtual device features based on the common features of devices of the same type in the initial device set; perform an extended search in the device feature table of the schematic database using the virtual device features to obtain a supplementary device set; and determine a list of main devices that match the module feature information based on the initial device set and the supplementary device set.

[0030] In another possible implementation, a generation module is used to select multiple devices of the same type from an initial device set; wherein, devices of the same type are used to characterize devices with the same or similar device features; multiple devices of the same type and their corresponding first preset prompt words are input into a large language model, and virtual device features are output; wherein, virtual device features are used to characterize the union of features of multiple devices of the same type.

[0031] In another possible implementation, a generation module is used to obtain the pin information of the core device; input the pin information of the core device, the list of auxiliary devices, the device connection topology rules, and the second preset prompt word into the large language model to generate the module netlist corresponding to the target functional module; wherein, the list of auxiliary devices includes at least one auxiliary device identifier and the device features corresponding to each auxiliary device; the device connection topology rules include the connection rules of the core device and the auxiliary devices.

[0032] In another possible implementation, a construction module is used to acquire historical data corresponding to historical projects. This historical data includes historical module feature function definitions, historical schematics, historical device features, historical reference designs, and historical module netlists. The historical module feature function definitions characterize the functional attributes of the hardware modules. Based on the historical module feature function definitions, historical schematics, and historical module netlists, a module feature data table is constructed. Based on historical reference designs, a reference design table is constructed. Based on historical device features, a device feature table is constructed. The module feature data table, historical reference design data table, and device feature data table are associated to establish a correspondence between them, forming a schematic database.

[0033] Thirdly, embodiments of this application also provide a computing device, including: a processor and a memory; the processor and the memory are coupled; the memory is used to store program instructions; the processor is used to execute the program instructions to perform the method as described in any of the first aspects above.

[0034] Fourthly, embodiments of this application provide a chip for performing the methods described in any of the first aspects above.

[0035] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a computer, implement the method as described in any of the first aspects.

[0036] In a sixth aspect, embodiments of this application provide a program product including a computer program that, when executed by a processor, implements the method as described in any of the first aspects. Attached Figure Description

[0037] Figure 1 This is a scenario diagram of generating a PCB board based on a module circuit schematic provided in an embodiment of this application; Figure 2 This is a schematic diagram of a scenario for generating a hardware circuit module schematic diagram according to an embodiment of this application; Figure 3 This is a schematic diagram of a software module for generating a hardware circuit module schematic diagram, provided in an embodiment of this application. Figure 4 This is a schematic diagram of the execution logic of the software module of a hardware circuit module schematic generation method provided in an embodiment of this application; Figure 5 This is a schematic diagram illustrating a hardware deployment method for a software module provided in an embodiment of this application; Figure 6 This is a schematic diagram of the first method flow of a method for generating a hardware circuit module schematic diagram provided in an embodiment of this application; Figure 7 This is the first signaling interaction diagram of a method for generating a hardware circuit module schematic diagram provided in this application embodiment; Figure 8 This is a schematic diagram of an interactive interface provided in an embodiment of this application; Figure 9 This is a schematic flowchart illustrating the process of determining core components according to an embodiment of this application; Figure 10 This is a schematic flowchart of a method for obtaining virtual device features provided in an embodiment of this application; Figure 11 This is a schematic diagram of another user interface provided in an embodiment of this application; Figure 12 This is the second signaling interaction diagram of a method for generating a hardware circuit module schematic diagram provided in an embodiment of this application; Figure 13 This is a schematic diagram of a process for constructing a schematic database according to an embodiment of this application; Figure 14 This is a schematic diagram of a hardware circuit module generated according to an embodiment of this application; Figure 15 This is a schematic diagram of a computing device provided in an embodiment of this application. Detailed Implementation

[0038] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. To facilitate a clear description of the technical solutions of the embodiments of this application, the use of terms such as "first," "second," etc., in the embodiments of this application is for illustrative purposes and to distinguish the objects being described. There is no particular order between them, nor does it indicate a specific limitation on the number of devices in the embodiments of this application, and they do not constitute any limitation on the embodiments of this application.

[0039] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in 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, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of this application.

[0040] It should be noted that many specific details are set forth in the following description in order to provide a full understanding of this application. However, this application may also be implemented in other ways different from those described herein. Therefore, the scope of protection of this application is not limited to the specific embodiments disclosed below.

[0041] The following explanations of the technical terms mentioned in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0042] A printed circuit board (PCB) is a physical circuit carrier that uses an insulating substrate as its base. Conductive lines and soldering structures are formed on the surface and / or inside the insulating substrate to mount electronic devices and achieve electrical connections between them.

[0043] A circuit diagram is a graphical representation of the electrical connections between electronic devices. It uses pre-defined circuit symbols and lines to describe the connections and circuit structure between electronic devices.

[0044] Electronic design automation (EDA) refers to a class of technologies that use computer technology to assist in the design of electronic circuits or electronic systems. It is used to realize circuit schematic design, simulation verification, printed circuit board design, and related design processes. Within this technology framework, specific circuit diagram software tools, such as EDA software, can be used to complete operations at different design stages.

[0045] Large language models (LLMs) are deep learning-based natural language processing models that, through training on massive amounts of text data, can understand human language and generate coherent, context-sensitive text. These models typically contain billions or even hundreds of billions of parameters, possess strong generalization and multi-task processing capabilities, and can be applied to various scenarios such as question answering, translation, writing, and code generation. In this embodiment, the large language model serves as the target large model, which is fine-tuned on a first database to generate recommendation results; alternatively, resources in the first database are used to semantically enhance the model's output, thereby obtaining the final recommendation results.

[0046] A reference design is a standardized circuit design example provided by a device manufacturer or third-party design team to guide users on how to use devices correctly and efficiently. A reference design may include typical application circuit diagrams, a Bill of Materials (BOM), parameter calculation formulas, placement and routing suggestions, performance test data, and other information. The typical application circuit diagram refers to the manufacturer's recommended standard circuit topology; the BOM may include device models, parameters, and quantities; the parameter calculation formulas may include formulas for calculating resistance, inductance, etc.; the placement and routing suggestions refer to considerations for printed circuit board (PCB) design; and the performance test data may include efficiency, measured temperature rise curves, etc. The information included in the reference design can help users quickly verify design feasibility and shorten the development cycle. In this application, the large model generates a list of auxiliary devices and their connection rules by parsing and learning the types, functions, nominal values, and connection rules of the auxiliary devices in the reference design.

[0047] A netlist is a text or structured format (e.g., SPICE, Verilog, VHDL) describing the devices (also called components or parts) and their pin connections in a circuit. This netlist can be identified by circuit diagram software tools. Devices may include resistors, capacitors, integrated circuit (IC) chips, etc. The netlist may include device identifiers, device parameter information, connection relationships, and electrical rules. Each device has a corresponding identifier, such as R1, C2, U3; device parameter information may include resistance value, capacitance value, model number, etc.; connection relationships refer to the electrical connections between device pins, i.e., the wires or signal paths between device pins (e.g., R1:1 connected to U3:2); electrical rules refer to the basic specifications and constraints that ensure the safe, stable, and efficient operation of the electrical system (e.g., chip design, PCB routing, etc.), such as voltage range, current limits, and signal timing requirements. In this application, the netlist refers to a historical netlist. The large model generates a list of auxiliary devices and their connection rules by learning the types, functions, nominal values, and connection rules of auxiliary devices in the historical netlist.

[0048] A hardware circuit module refers to a sub-unit that divides the functionality of a circuit into independent logical or physical boundaries. In this application, a module can refer to a hardware module, and each module can contain a set of devices that perform a specific function and the connection relationships between the devices. For example, a module may include module 1 and module 2. For example, module 1 may be a processor module, which is used for computing tasks and may consist of a central processing unit (CPU) and its associated control logic; module 2 may be a memory module, which can be used for data storage, and may include random access memory (RAM) and read-only memory (ROM). Modular design can decompose complex systems into manageable, testable, and replaceable modular units, thereby improving the efficiency and reliability of circuit design.

[0049] A module schematic diagram is a technical drawing that graphically represents the electrical connections, signal flow, and functional logic of various components (such as resistors, capacitors, and integrated circuits) in a circuit. This schematic diagram not only clearly shows the role of each component in the circuit and their collaborative working mechanism, but also typically labels the component model, key electrical parameters, and pin definitions, providing a visual basis for the correct implementation of hardware functions. For example, in the schematic diagram of a power supply module, the complete energy conversion path can be clearly shown: AC input is stepped down by a transformer, rectified by a rectifier bridge, smoothed by a filter capacitor, and then outputs a stable DC voltage by a voltage regulator chip. In this application, "module schematic diagram" is also referred to as "hardware circuit module schematic diagram."

[0050] The embodiments of this application will now be described with reference to the accompanying drawings.

[0051] Soldering printed circuit boards (PCBs) typically requires a pre-designed electronic design automation (EDA) circuit schematic. The schematic describes the types, parameters, and electrical connections of various electronic components in the circuit, providing a design basis for subsequent PCB layout, routing, and circuit board production.

[0052] As electronic products become increasingly complex, hardware systems are often divided into multiple functional modules. For a specific functional module, a corresponding module circuit schematic (also known as a sub-circuit schematic) needs to be extracted or generated from the overall EDA circuit schematic. This module circuit schematic graphically and accurately describes the types, electrical parameters, pin definitions, and electrical connections between the electronic components (including but not limited to integrated circuits, resistors, capacitors, inductors, and connectors) contained within the module.

[0053] Figure 1 This is a scenario diagram of generating a PCB board based on a module circuit schematic provided in an embodiment of this application.

[0054] like Figure 1 As shown, based on the principle of modular circuits Figure 1 This allows the generation of a PCB layout that is strictly consistent with the design. The electronic components (including but not limited to integrated circuits, resistors, capacitors, inductors, and connectors) arranged on this PCB are completely matched to the design defined in the EDA circuit schematic in terms of type, electrical parameters, package form, and network connection relationship between them, ensuring accurate conversion from logic design to physical implementation.

[0055] Therefore, before PCB design, it is necessary to accurately generate the module circuit schematic (sub-circuit schematic).

[0056] Figure 2 This is a schematic diagram of a scenario for generating a sub-circuit schematic provided in an embodiment of this application.

[0057] like Figure 2 As shown, the scenario includes a terminal device 20 and a computing device 21. The terminal device 20 can be a user-side client (such as a PC, tablet, or mobile terminal), and the computing device 21 can be a server deployed in the cloud or locally.

[0058] In this scenario, the user inputs the characteristic information of the target functional module (such as function type, performance indicators, application scenarios, etc.) through terminal device 20 and sends this information to computing device 21. Computing device 21 analyzes and processes the module characteristic information, generates one or more recommended main device solutions, and returns the recommendation results to terminal device 20. The user views the recommended devices on terminal device 20, selects the target main device, confirms it, and then sends the selected main device information back to computing device 21.

[0059] Subsequently, the computing device 21 automatically generates a list of suitable auxiliary components based on the functional characteristics, module requirements, and historical design data of the target main component, and further determines the connection relationships between the components, ultimately generating a complete hardware circuit module schematic. This hardware circuit module schematic is sent back to the terminal device 20 for the user to view, edit, or use in subsequent PCB design processes.

[0060] In this way, by leveraging the synergy between the schematic database and the large language model, a module netlist is generated with core components as the core, combined with auxiliary components and their connection rules. Based on the module netlist, a hardware circuit module schematic is constructed, enabling the automatic generation of circuits driven by requirements. This eliminates the need for users to consult numerous reference books, effectively improving the efficiency and accuracy of hardware circuit module schematic generation.

[0061] In the above Figure 2 Based on this, further examples are provided for the software functional modules inside the terminal device and the computing device.

[0062] Figure 3 This is a schematic diagram of a software module for generating a hardware circuit module schematic provided in an embodiment of this application.

[0063] like Figure 3 As shown, the terminal device 20 includes a parameter receiving and parsing module 200. This module receives module feature information of the target functional module input by the user and performs format parsing and semantic verification on the input information to provide structured data for subsequent processing. Simultaneously, the parameter receiving and parsing module 200 also provides an interactive interface to the user, displaying at least one recommended main component returned by the computing device, and visually displays the generated circuit diagram after the hardware circuit module schematic is generated.

[0064] The computing device 21 includes a database retrieval module 211, a virtual device generation module 212, a similarity calculation module 213, a device scoring and recommendation module 214, a loading and parsing module 215, an auxiliary device generation module 216, a module netlist generation module 217, and a hardware circuit module schematic generation module 218. These modules work collaboratively to achieve automated generation from user requirements to hardware circuit module schematics.

[0065] The database retrieval module 211 is used to use the schematic database to match the structured data sent by the parameter receiving and parsing module 200, and search for matching core device codes in the module feature library to obtain a list of main devices including main device identifiers and device features.

[0066] The virtual device generation module 212 is used to extract common feature fields (such as input voltage range, maximum output current, number of pins, etc.) when multiple devices of the same type exist in the main device list, and input these field values ​​into a pre-trained AI large model. By setting a prompt, the large language model is instructed to perform a union operation on the value range of the same feature field, thereby generating a virtual core device feature that covers the capability boundaries of all similar devices. For example, a device that "supports input voltage 3.3V–12V, output current ≥2A, and number of pins ≥8".

[0067] The similarity calculation module 213 is used to quantitatively compare the feature parameters of each item in the main device list with the user's target functional module to generate a similarity score, so as to measure the degree of matching between each device and the user's needs (target functional module).

[0068] The device scoring and recommendation module 214 is used to constrain the device through multi-dimensional device parameters, such as proximity to the target functional module (reflected by similarity scores), historical usage frequency (high-frequency devices are prioritized), cost (low-price devices are prioritized), and manufacturer priority (e.g., user-specified brands or supply chain preferences). These parameters are structured and input into a large language model, which is then guided by customized prompts to perform multi-objective optimization scoring. Finally, the large language model outputs a ranked list of recommended main devices, i.e., at least one recommended main device in this embodiment.

[0069] The loading parsing module 215 is used to load the schematic diagram of the auxiliary device corresponding to the target main device after the user selects the target main device. The schematic diagram of the auxiliary device can be obtained from the historical schematic diagram or from the reference design.

[0070] The auxiliary device generation module 216 utilizes a large language model to obtain a list of auxiliary devices and device connection topology rules. Specifically, it takes multiple historical module netlists associated with the target main device and their functional definitions (such as power management, signal conditioning, protection circuits, etc.) as input and feeds them into the large language model. The generation requirements are explicitly specified in the prompt, for example: "Based on the pin functions and typical application scenarios of the main device, generate necessary auxiliary devices (such as decoupling capacitors, pull-up resistors, TVS diodes, etc.), and explain their connection rules with the main device and the basis for parameter values." The large language model then outputs the list of auxiliary devices and device connection topology rules accordingly.

[0071] The module netlist generation module 217 is used to generate the module netlist corresponding to the target functional module based on the list of auxiliary devices and device connection topology rules.

[0072] The hardware circuit module schematic generation module 218 is used to generate the target hardware circuit module schematic corresponding to the target functional module based on the module netlist.

[0073] Combination Figure 3 The software module structure shown, combined with Figure 4 The execution logic of the hardware circuit module schematic generation method provided in the embodiments of this application will be described.

[0074] Figure 4 This is a schematic diagram of the execution logic of the software module of a hardware circuit module schematic generation method provided in this application embodiment.

[0075] like Figure 4 As shown, the parameter receiving and parsing module 200 responds to the module feature information corresponding to the target function module input by the user, performs format parsing and semantic verification on the module feature information corresponding to the target function module input by the user, generates structured module feature information, and sends the module feature information to the database retrieval module 211 in the computing device 21.

[0076] Based on the received structured module feature information, the database retrieval module 211 performs a matching search in a preset module feature library to obtain an initial set of devices that initially match the module feature information. Subsequently, the database retrieval module 211 determines whether multiple main devices of the same type exist in this initial set. If so, it sends a list of these main devices to the virtual device generation module 212. The virtual device generation module 212 extracts common feature fields (such as input voltage range, maximum output current, number of pins, etc.) from each device in the list and uses these field values ​​as input to a pre-trained Large Language Model (LLM). By setting a prompt, the model is instructed to perform a union operation on the value range of the same feature field (e.g., merging "3.3V–5V" and "4.5V–12V" into "3.3V–12V"), ​​thereby generating a virtual device feature covering the capability boundaries of all similar devices. This virtual device feature is returned to the database retrieval module 211. The database retrieval module 211 uses the virtual device feature to perform an extended search in the schematic database to obtain a supplementary set of devices. Subsequently, the database retrieval module 211 merges the initial device set and the supplementary device set to form the final main device list, and sends it to the similarity calculation module 213. If there are no multiple main devices of the same type (i.e., the initial device set is empty, or contains only one main device, or the devices belong to different categories and cannot be merged), the database retrieval module 211 skips the virtual device generation and extended retrieval steps and directly uses the initial device set as the final main device list.

[0077] The similarity calculation module 213 compares the feature parameters of each item in the main component list with the user's target functional module to generate a similarity score, and sends the similarity score to the component scoring and recommendation module 214. Based on the similarity score, the component scoring and recommendation module 214 further integrates multi-dimensional engineering factors (such as historical usage frequency, cost, manufacturer priority, supply chain stability, etc.), and performs multi-objective optimization scoring through a large language model combined with structured prompts, finally outputting a sorted list of recommended main components. Further, the component scoring and recommendation module 214 sends the recommended main component list to the parameter receiving and parsing module 200. The parameter receiving and parsing module 200 responds to the user's selected core component, or selects the topmost component in the recommended main component list as the core component, and sends it to the loading and parsing module 215. After selecting the target main component, the loading and parsing module 215 loads the schematic diagram of the corresponding auxiliary component and sends it to the auxiliary component generation module 216. The auxiliary component generation module 216 obtains the auxiliary component list and component connection topology rules based on the auxiliary component schematic, and sends the auxiliary component list and component connection topology rules to the auxiliary component generation module 216. Based on the auxiliary component list and component connection topology rules, the auxiliary component generation module 216 generates a module netlist corresponding to the target functional module, and sends the module netlist to the hardware circuit module schematic generation module 218. The hardware circuit module schematic generation module 218 receives the circuit schematic and sends it to the parameter receiving and parsing module 200 for display to the user.

[0078] It should be noted that the above software modules can be deployed in different ways depending on actual needs. The following section will combine... Figure 5 An example is provided.

[0079] Figure 5 This is a schematic diagram of a hardware deployment method for a software module provided in an embodiment of this application.

[0080] like Figure 5 As shown, the various functional software modules in this application can be flexibly deployed on one or more physical computing devices according to the actual system architecture requirements. For example, as... Figure 5 As shown in (a), the parameter receiving and parsing module 200, database retrieval module 211, virtual device generation module 212, similarity calculation module 213, device scoring and recommendation module 214, loading and parsing module 215, auxiliary device generation module 216, module netlist generation module 217, and hardware circuit module schematic generation module 218 can all be integrated and deployed on the same computing device (e.g., computing device A). This deployment method is suitable for scenarios with high requirements for system response speed and inter-module communication efficiency.

[0081] It should be noted that computing device A is a terminal device with visual interaction capabilities (such as a desktop computer, workstation, or high-performance laptop). Because it needs to run a user interface to receive the user's input of the target function requirements and display the user with visual content such as recommendation results and schematic diagrams, it realizes a complete human-computer interaction process.

[0082] like Figure 5 As shown in (b), the parameter receiving and parsing module 200 can be deployed in the first computing device B1 to receive the target functional module requirements input by the user and perform preliminary parsing and structuring processing; while the database retrieval module 211, virtual device generation module 212, similarity calculation module 213, device scoring and recommendation module 214, loading and parsing module 215, auxiliary device generation module 216, module netlist generation module 217, and hardware circuit module schematic generation module 218 can be centrally deployed in the second computing device B2.

[0083] The modules interact efficiently through standardized interfaces and network communication protocols, ensuring process continuity and low-latency response. This distributed architecture not only supports flexible scheduling and horizontal scaling of computing resources.

[0084] Furthermore, in high-concurrency or large-scale application scenarios, the second computing device B2 can be expanded into multiple parallel-deployed computing nodes (i.e., multiple second computing devices B2_1, B2_2...B2_n) to form a service cluster, thereby achieving load balancing and high availability.

[0085] The following section, with reference to the accompanying drawings, explains the specific implementation process of the method for generating the schematic diagram of the hardware circuit module.

[0086] Figure 6 This is a schematic diagram of the first method flow of a method for generating a hardware circuit module schematic diagram provided in an embodiment of this application.

[0087] like Figure 6 As shown, the method for generating a hardware circuit module schematic includes the following steps: S1: Obtain the module feature information corresponding to the target function module input by the user.

[0088] Figure 7 This is the first signaling interaction diagram of a method for generating a hardware circuit module schematic diagram provided in this application embodiment.

[0089] like Figure 7 As shown, step S1 includes steps S1001-S1003.

[0090] S1001: The parameter receiving and parsing module obtains the module feature information corresponding to the target function module input by the user.

[0091] The target functional module refers to a specific functional unit that the user wants to implement in the circuit, i.e., a specific instance of a certain type of circuit function that the user wants to design or use (such as a step-down power supply circuit, an I2C communication interface, or a temperature acquisition module). Module characteristic information is used to characterize the functional requirements and constraints of the target hardware circuit module schematic. Module characteristic information can include, for example, functional type, performance indicators, interface protocols, and cost constraints. Functional type refers to the core hardware or logic role the module plays in the system, such as power management, clock generation, or I2C communication; performance indicators quantify its technical requirements, such as input / output voltage and current range, power consumption, accuracy, and operating frequency; interface protocols specify the communication standards followed by the module in interacting with other parts, such as I2C, SPI, UART, or analog signal level specifications; cost constraints set the economic boundaries for material selection, such as limiting the BOM cost of a single module to no more than a certain amount. Thus, the above elements together constitute a complete design constraint on the target functional module, providing a basis for subsequent automatic generation of schematics and component selection.

[0092] Figure 8 This is a schematic diagram of an interactive interface provided in an embodiment of this application.

[0093] like Figure 8 As shown in (a), in response to a user's input action when opening an interactive interface in browser page 1 (such as entering "locallhost / ........html"), the following is displayed: Figure 8 The first interactive interface 8 is shown in (b) above. The first interactive interface 8 includes a module library area 81, a drawing area 82, and a module configuration area 83. The module library area 81 displays a pre-built library of logical function modules, including various logical function modules such as a Power Module, Clock Module, Temperature Module, Memory Module, GPIO expansion module, and I2C interface control module. Users select the desired function module as the target function module for their current design.

[0094] Drawing area 82 is used to display the functional module layout structure of the circuit. Module configuration area 83 is used for parametric configuration of selected modules to extract their module characteristic information. Users can set module attributes, port definitions, interface types, power input methods, signal directions, and related electrical parameters in this area.

[0095] The module configuration area 83 is used to set parameter values ​​for logic function modules to obtain the corresponding target function module. Parameters such as input voltage range, output voltage value, maximum output current, and power supply type can be set. For example, the input voltage range can be 9V to 12V, the output voltage value can be 5V, the maximum output current can be 1A, and the power supply type can be a step-down regulated power supply.

[0096] Following the example above, combined with Figure 8 As shown in (c), when a user selects a power module in the module library area, the system displays the corresponding module attribute configuration interface in the module configuration area. The user can configure the module characteristic information of the target functional module in this interface. The module characteristic information includes structured attribute information and interface attribute information. The structured attribute information includes parameters such as input voltage range, output voltage value, maximum output current, and power supply type. The interface attribute information includes the connection type and name information of each port. Through the above configuration process, module characteristic information A corresponding to the selected power module is generated.

[0097] It should be noted that the above interface is only an example and does not impose any specific limitations on the layout.

[0098] Optionally, in order to ensure the consistency of data representation and the accuracy of subsequent processing, it is necessary to convert the module feature information into structured data. The following is an example description in conjunction with step S1002.

[0099] S1002: The parameter receiving and parsing module parses and transforms the module feature information corresponding to the target functional module to obtain structured data.

[0100] Structured data is used to uniformly represent the functional requirements and constraints in the module feature information, so as to facilitate subsequent device matching, rule generation and model input processing.

[0101] Following the example above, the parameter receiving and parsing module parses and transforms the module feature information corresponding to the target functional module to obtain structured data A'.

[0102] S1003: The parameter receiving and parsing module sends the structured data of the module feature information corresponding to the target functional module to the database retrieval module.

[0103] Continuing with the example above, the parameter receiving and parsing module sends structured data A' to the database retrieval module.

[0104] S2: Based on the module feature information, determine the core device that matches the module feature information.

[0105] Figure 9 This is a schematic diagram of a process for determining core components provided in an embodiment of this application.

[0106] like Figure 9 As shown, step S2 includes steps S21-S23.

[0107] S21: Based on the module feature information, search the preset schematic database to determine the list of main components that match the module feature information.

[0108] The schematic database is a dedicated structured database constructed in this application embodiment, containing three interrelated core data tables: a module feature table, a device feature table, and a reference design table. The module feature table stores feature description information of known functional modules, extracted from historical schematics. Each record in the module feature table corresponds to a circuit functional module, and the feature description information includes structured fields such as key electrical parameter requirements, functional tags, application scenario classifications, and compatibility constraints with other modules. Specifically, key electrical parameter requirements characterize the constraints of the circuit functional module in terms of voltage, current, power consumption, frequency, or signal type; functional tags characterize the functional attributes or categories of the circuit functional module; application scenario classifications characterize the applicable application areas of the circuit functional module; and compatibility constraints with other modules characterize the matching relationship between the circuit functional module and other modules in terms of interfaces, electrical characteristics, or communication protocols.

[0109] For example, the module feature table may include power management modules, such as LDO voltage regulator modules and DC-DC buck modules; interface communication modules, such as USB interface modules and UART communication modules; signal processing modules, such as operational amplifier amplification modules and filtering modules; clock and timing modules, such as crystal oscillator modules; control modules, such as reset control modules; and protection modules, such as overvoltage protection modules and overcurrent protection modules.

[0110] The device characteristic table stores characteristic information for various electronic devices. Each record corresponds to one device, and the device characteristic information includes structured fields such as device identifier, device type, specifications, manufacturer information, electrical parameters, package type, and pin information. Specifically, the device identifier uniquely identifies the device; the device type characterizes the device category; the specifications characterize the device model, rated parameters, or selection range; the manufacturer information characterizes the manufacturer or brand; the electrical parameters characterize the device's performance indicators in terms of voltage, current, power consumption, or frequency; the package type characterizes the physical package type; and the pin information characterizes the pin number, functional definition, electrical attributes, and connection constraints.

[0111] For example, the device characteristic table may include passive devices (such as resistors, capacitors, and inductors) and active devices (such as diodes, transistors, and integrated circuit chips).

[0112] The reference circuit design data in the reference design table comes from standard reference designs provided by component manufacturers. It is used to store historical reference circuit design data, with each record corresponding to a reference circuit module. The reference circuit design data includes structured fields such as component composition information, connection relationships between components, and corresponding module netlist or schematic information. Specifically, component composition information characterizes the core and auxiliary components that make up the reference circuit module; connection relationships characterize the electrical connections between components, including pin correspondences; and module netlist or schematic information characterizes the circuit structure data of the reference circuit module.

[0113] For example, a reference design sheet may include different types of reference circuit design records. These records are derived from standard reference designs or historical project design data provided by device manufacturers and may include power conversion circuits, interface adapter circuits, analog signal processing circuits, and digital communication circuits.

[0114] In step S21, the main device list is determined by directly obtaining the corresponding main device based on the module feature table, or by further combining devices in the device feature table that meet preset matching conditions as a supplement to the module feature table, so as to jointly constitute the main device list. In this embodiment, the example of forming the main device list by introducing devices in the device feature table that meet the conditions as a supplement to the module feature table is used for illustration.

[0115] Continue to combine Figure 7 As shown, step S21 includes steps S1004-S1008.

[0116] S1004: The database retrieval module retrieves at least one device code that matches the module feature information from the schematic database based on the module feature information.

[0117] Optionally, retrieving at least one device code that matches the module feature information from the schematic database can be achieved by calculating the similarity between the module feature information and the feature information of each device, and determining at least one device code based on the similarity; wherein, the similarity calculation can be performed using the Euclidean distance calculation method or the weighted scoring method.

[0118] Continuing with the example above, the database retrieval module searches the schematic database for five device codes that match the module feature information, such as device B11, device C11, device D11, device B14, and device B15.

[0119] S1005: The database retrieval module determines the master device corresponding to at least one device code as the initial device set.

[0120] Continuing with the example above, the main devices corresponding to devices B11, C11, D11, B41, and B54 are determined as the initial device set. For example, the initial device set S1 includes: { Device B1, Device C1, Device D1, Device B4, Device B5}.

[0121] Optionally, in order to improve the stability and generalization ability of device feature representation and avoid interference from individual differences of a single device on feature modeling, it is necessary to classify devices of the same type. The following is an example of step S1006.

[0122] S1006: The database retrieval module determines whether there are devices of the same type in the initial device set.

[0123] Optionally, the similarity between the features of each device can be calculated to determine whether they are of the same type. When the similarity is greater than a preset threshold, the corresponding devices are determined to be of the same type. The similarity calculation can be based on any one or a combination of Euclidean distance, cosine similarity, or weighted scoring methods.

[0124] Continuing with the example above, in the initial device set S1, it is assumed that the similarity between devices B1, B4, and B5 is greater than a preset threshold, and devices B1, B4, and B5 are determined to be devices of the same type B.

[0125] S1007: When there are devices of the same type, the database retrieval module sends the initial device set to the virtual device generation module.

[0126] Continuing with the example above, if there are devices of the same type, the initial device set S11 is sent to the virtual device generation module.

[0127] S1008: The virtual device generation module generates virtual device features based on the common characteristics of devices of the same type in the initial device set.

[0128] Figure 10 This is a schematic flowchart of a method for obtaining virtual device features provided in an embodiment of this application.

[0129] like Figure 10 As shown, step S1008 includes S041-S042.

[0130] S041: Select similar devices with the same or similar device characteristics from the initial device set.

[0131] Continuing with the example above, in the initial device set S11, it is assumed that the similarity between devices B1, B4, and B5 is greater than a preset threshold, and devices B1, B4, and B5 are determined to be devices of the same type B.

[0132] S042: Input multiple devices of the same type and their corresponding first preset prompt words into the large language model, and output the virtual device features.

[0133] The first preset prompt is used to instruct the large language model to summarize and abstract the device characteristics of multiple similar devices. For example, it could be: "Based on the input device type, electrical parameters, package form, and pin information of multiple similar devices, please summarize and abstract their features, extract their common features, and generate a unified virtual device feature that can be used to characterize this type of device." The virtual device feature is used to characterize the union of features of multiple similar devices. For example, when the electrical parameter ranges of similar devices are 2V~3V and 4V respectively, the corresponding electrical parameters in the virtual device feature can be expanded to a unified range of 2V~4V; or when different device parameters have a discrete distribution, they can be summarized into a parameter set or equivalent parameter range containing all values ​​to characterize the overall characteristic boundary of this type of device.

[0134] Continuing with the example above, multiple devices of the same type B {device B1, device B4, device B5} and their corresponding first preset prompt words are input into the large language model, and the virtual device feature B' is output.

[0135] S1009: The virtual device generation module sends the virtual device characteristics to the database retrieval module.

[0136] Following the example above, the virtual device generation module sends virtual device feature B' to the database retrieval module.

[0137] S1010: The database retrieval module uses virtual device features to perform extended searches in the device feature table of the schematic database to obtain a supplementary set of devices.

[0138] Extended retrieval is achieved by calculating the similarity between the virtual device features and the features of each device in the device feature table. When the similarity meets the preset threshold condition, the corresponding device is identified as a supplementary device.

[0139] Continuing with the example above, the database retrieval module uses virtual device features to perform an extended search in the device feature table of the schematic database to obtain a supplementary device set, assuming the supplementary device set S2: {device D1, device H1}.

[0140] It should be noted that the supplementary device set may also include only one device.

[0141] S1011: The database retrieval module determines a list of main devices that match the module's feature information based on the initial device set and the supplementary device set.

[0142] Following the example above, the database retrieval module determines the main device list A1 that matches the module feature information from the initial device set S1: {device B1, device C1, device D1, device B4, device B5} and the supplementary device set S2: {device D11, device H1}.

[0143] S1012: The database retrieval module sends the main device list to the similarity calculation module.

[0144] Following the example above, the database retrieval module sends the main device list A1 to the similarity calculation module.

[0145] S22: Based on the target functional module, calculate the similarity score of each main device in the main device list.

[0146] The main device list includes at least one main device identifier and the device characteristics corresponding to each main device.

[0147] Continue to combine Figure 7 As shown, step S23 includes step S1013.

[0148] S1013: The similarity calculation module calculates the similarity score of each main device in the main device list based on the target function module.

[0149] Optionally, for each device in the extended list, a quantitative comparison is performed based on the target functional module and device characteristics. The target functional module represents the specific performance requirements and constraints proposed by the user in the current design task, including design constraints such as voltage range, output current range, and pin count. The quantitative comparison includes calculating the differences in voltage range, output current, and pin count. For example, the similarity score can be calculated using either a method based on Euclidean distance or a method based on weighted scoring, or a combination thereof. The Euclidean distance calculation represents the spatial distance between the target functional module and device characteristics; a smaller distance indicates a higher degree of matching.

[0150] Continuing with the example above, the similarity calculation module calculates the similarity score of each main device in the main device list based on the target functional module. For example, the similarity score corresponding to device B1 is SCORE1, the similarity score corresponding to device C1 is SCORE2, the similarity score corresponding to device D11 is SCORE3, the similarity score corresponding to device B4 is SCORE4, the similarity score corresponding to device B5 is SCORE5, the similarity score corresponding to device D1 is SCORE6, and the similarity score corresponding to device H1 is SCORE7.

[0151] S23: Sort the list of main components based on the similarity scores of each main component, and determine the core components that match the module feature information based on the sorted list of main components.

[0152] Continue to combine Figure 7 As shown, step S23 includes steps S1014-S1017.

[0153] S1014: The similarity calculation module sorts the main component list based on the similarity score of each main component to obtain the sorted main component list.

[0154] The sorting is based on the similarity score from highest to lowest.

[0155] Following the example above, the similarity calculation module sorts the main device list based on the similarity scores of each main device, resulting in the sorted main device list A2: {device D1, device B1, device C1, device D11, device B4, device B5, device H1}.

[0156] S1015: The similarity calculation module sends the sorted list of main devices to the device scoring and recommendation module.

[0157] Continuing with the example above, the similarity calculation module sends the sorted main device list A2 to the device scoring and recommendation module: {device D1, device B1, device C1, device D11, device B4, device B5, device H1}.

[0158] The similarity score only reflects the degree of local feature matching and cannot cover unstructured factors such as the device's system-level functional adaptability, engineering constraints, and design experience. Therefore, it is necessary to combine a large language model to conduct a comprehensive analysis and recommendation of candidate main devices. The following is an example of step S1016.

[0159] S1016: The device scoring and recommendation module inputs the similarity score and the structured constraints corresponding to the main device into the large language model to obtain at least one recommended main device.

[0160] Among them, structured constraints are used to characterize the constraints and selection preferences of the target functional module in electrical design. Structured constraints include voltage range constraints, current range constraints, power consumption constraints, frequency constraints, and constraints such as the number of pins or pin functions. They also include device selection strategy factors, such as device usage frequency, cost constraints, and manufacturer priority constraints. Usage frequency is used to characterize the frequency of device use in historical designs, cost constraints are used to characterize the restrictions on device prices, and manufacturer priority is used to characterize the selection preference for a specific brand or supplier.

[0161] Following the example above, the similarity calculation module inputs the similarity score and the structured constraints corresponding to the main device into the large language model to obtain two recommended main devices: {device D1, device B1}.

[0162] S1017: The device scoring and recommendation module sends at least one recommended master device to the parameter receiving and parsing module.

[0163] Following the example above, the similarity calculation module sends the two recommended main devices: {device D1, device B1} to the parameter receiving and parsing module so that the parameter receiving and parsing module can display them to the user.

[0164] S1018: The parameter receiving and parsing module determines the core device from at least one recommended master device.

[0165] Core components are the main components used to characterize the core functions of the target functional module. Optionally, the core component can be determined by selecting the top-ranked main component from the recommended main components; or by receiving the main component selected by the user from the recommended main components as the core component. The following example illustrates the method of "receiving the main component selected by the user from the recommended main components as the core component".

[0166] Figure 11 This is a schematic diagram of another user interface provided in an embodiment of this application.

[0167] like Figure 11 and Figure 8 As shown in (c), in response to the user's selection operation of "Select Device" 831, the parameter receiving and parsing module displays the second interactive interface 111. The second interactive interface 111 is a device recommendation interface used to present recommendation results to the user. This interface includes a device list area and a device preview area. The device list area is used to display the relevant attribute information, device location, and circuit structure information of each recommended core device. The attribute information may include the core device's code, classification, description, recommendation score, and corresponding symbol file, etc. Among them, the symbol file is used to represent the graphical representation of the core device.

[0168] Continuing with the example above, the parameter receiving and parsing module receives the main device selected by the user from the recommended main devices: {device D1, device B1} as the core device: device D1.

[0169] S1019: The parameter receiving and parsing module sends the core components to the loading and parsing module.

[0170] Continuing with the example above, the parameter receiving and parsing module sends the core device, device D1, to the loading and parsing module.

[0171] S3: Based on the core device, search the preset schematic database to determine the schematic diagram of the auxiliary device corresponding to the core device.

[0172] Among them, the schematic diagram of auxiliary devices is used to characterize the composition and connection relationship of auxiliary devices that are electrically connected to the core device in the same circuit module.

[0173] The schematics for auxiliary components are sourced from historical schematics and schematics extracted from reference designs, with historical schematics being used first. Schematics extracted from reference designs are used only when no historical schematic matching the core component is available. Continuing with... Figure 7 As shown, step S3 includes steps S1020-S1021.

[0174] S1020: Load the parsing module based on the core device and query the module feature data table in the schematic database to see if there is a target historical schematic corresponding to the core device.

[0175] Optionally, the query results are used to indicate whether there is a target historical schematic corresponding to the core device in the module feature data table of the schematic database. The query results can be a single target historical schematic or a set of multiple candidate historical schematics.

[0176] For example, if multiple matching historical schematics exist, the query results are sorted according to the matching degree or priority rules, and the historical schematic with the highest ranking is selected as the target historical schematic; if no matching historical schematic exists, the reference design extraction process is triggered to obtain the corresponding auxiliary device schematic.

[0177] In this embodiment of the application, the example of querying the target historical schematic diagram P1 is used for illustration.

[0178] S1021: When the target historical schematic is found, the loading parsing module determines the target historical circuit schematic as the schematic of the auxiliary device.

[0179] Following the example above, when the parsing module finds the target historical schematic, it identifies the target historical circuit schematic P1 as the auxiliary device schematic M.

[0180] S1022: The loading parsing module sends the auxiliary device schematic diagram to the auxiliary device generation module.

[0181] Following the example above, the loading parsing module sends the auxiliary device schematic M to the auxiliary device generation module.

[0182] S4: Input the schematic diagrams of auxiliary devices, core devices, and user-inputted module interface information into the large language model to obtain a list of auxiliary devices and device connection topology rules.

[0183] The module interface information is used to characterize the connection requirements and signal interaction constraints between the core device and the external circuit, including signal type, power interface, level standard and communication protocol.

[0184] The auxiliary device list is used to characterize the set of auxiliary devices required to form a circuit function in the same circuit module as the core device, including auxiliary device identifiers and device characteristics corresponding to each auxiliary identifier.

[0185] Device connection topology rules are used to characterize the electrical and pin-level connection relationships between core devices and auxiliary devices. It should be noted that the devices in a device connection topology rule include both core devices and auxiliary devices. Specifically, a device connection topology rule includes at least the connection relationships between auxiliary devices and the connection relationships between core devices and auxiliary devices; when multiple core devices are included, it may further include the connection relationships between each core device. In other words, a device connection topology rule includes connection rules for both core devices and auxiliary devices.

[0186] Continue to combine Figure 7 As shown, step S4 includes step S1023.

[0187] S1023: The auxiliary device generation module inputs the auxiliary device schematic, core device, and user-inputted module interface information into the large language model to obtain the auxiliary device list and device connection topology rules.

[0188] Continuing with the example above, the auxiliary device generation module inputs the auxiliary device schematic, core device, and user-inputted module interface information into the large language model to obtain the auxiliary device list K and device connection topology rules J. Here, it is assumed that the auxiliary device list includes: {device K11, device K21, device K41}.

[0189] S1024: The auxiliary device generation module sends the auxiliary device list and device connection topology rules to the module netlist generation module.

[0190] Continuing with the example above, the auxiliary device generation module sends the auxiliary device list K and device connection topology rule J to the module netlist generation module.

[0191] S5: Based on the list of auxiliary devices and the device connection topology rules, generate the module netlist corresponding to the target functional module.

[0192] The module netlist is used to characterize each device and the electrical connections between them, and the module netlist is structured circuit data that can be recognized by electronic design automation (EDA) software.

[0193] Continue to combine Figure 7 As shown, step S5 includes steps S1025-S1026.

[0194] S1025: The module netlist generation module obtains the pin information of the core components.

[0195] Optionally, the module netlist generation module can obtain the pin information of the core device from the master device list. This pin information is used to characterize the pin number, pin function attributes, and electrical connectivity of each pin.

[0196] Following the example above, the module netlist generation module obtains the pin information pin1 of the core device.

[0197] S1026: The module netlist generation module inputs the pin information of the core device, the list of auxiliary devices, the device connection topology rules, and the second preset prompt words into the large language model to generate the module netlist corresponding to the target functional module.

[0198] The second preset prompt is used to instruct the large language model to generate a module netlist conforming to a preset netlist format based on the pin information of the core device, the list of auxiliary devices, and the device connection topology rules, and to define the electrical connection relationships between each device. For example, the second preset prompt could be "Please generate the corresponding module netlist based on the input core device pin information, the list of auxiliary devices, and the device connection topology rules. The netlist must use a preset format (such as SPICE format) and clearly define the pin connection relationships and electrical connection paths of each device."

[0199] Following the example above, the module netlist generation module inputs the pin information of the core device, the list of auxiliary devices, the device connection topology rules, and the second preset prompt word into the large language model to generate the module netlist Q1 corresponding to the target functional module.

[0200] S1027: The module netlist generation module sends the module netlist to the hardware circuit module schematic generation module.

[0201] Continuing with the example above, the module netlist generation module sends module netlist Q1 to the hardware circuit module schematic generation module.

[0202] S6: Based on the module netlist, generate the schematic diagram of the target hardware circuit module corresponding to the target functional module.

[0203] Continue to combine Figure 7 As shown, step S6 includes step S1028.

[0204] S1028: The hardware circuit module schematic generation module uses electronic design automation software to process the module netlist and generate the target hardware circuit module schematic corresponding to the target functional module.

[0205] Continuing with the example above, the hardware circuit module schematic generation module uses electronic design automation software to process the module netlist and generate the target hardware circuit module schematic Q2 corresponding to the target functional module.

[0206] In summary, by introducing virtual device features to expand and summarize the candidate device space, and combining it with a mechanism that prioritizes historical schematics for acquiring auxiliary devices, the synergistic effect of the schematic database and the large language model is achieved. On this basis, a module netlist is generated with core devices as the core and auxiliary devices and their connection rules as the core. Hardware circuit module schematics are then constructed based on the module netlist, thereby realizing the automatic generation of circuits driven by requirements and effectively improving the efficiency and accuracy of hardware circuit module schematic generation.

[0207] Corresponding to the above embodiments, this application also provides another embodiment of a method for generating hardware circuit module schematic diagrams, which will be further described below. Figure 6 and Figure 12 The following explanation is provided.

[0208] like Figure 6 As shown, the method for generating a hardware circuit module schematic includes the following steps: S1: Obtain the module feature information corresponding to the target function module input by the user.

[0209] Figure 12 This is the second signaling interaction diagram of a method for generating a hardware circuit module schematic diagram provided in this application embodiment.

[0210] like Figure 12 As shown, step S1 also includes steps S2001-S2003.

[0211] S2001: The parameter receiving and parsing module obtains the module feature information corresponding to the target function module input by the user.

[0212] For example, if a user selects a power module, they can set its input voltage range (e.g., 9V to 12V), output voltage value (e.g., 5V), maximum output current (e.g., 1A), and power supply type (e.g., buck regulator) in the module configuration area 83, thereby clarifying the module characteristic information A corresponding to the target functional module.

[0213] S2002: The parameter receiving and parsing module parses and transforms the module feature information corresponding to the target functional module to obtain structured data.

[0214] Following the example above, the parameter receiving and parsing module parses and transforms the module feature information corresponding to the target functional module to obtain structured data A'.

[0215] S2003: The parameter receiving and parsing module sends the structured data of the module feature information corresponding to the target functional module to the database retrieval module.

[0216] Continuing with the example above, the parameter receiving and parsing module sends structured data A' to the database retrieval module.

[0217] The specific details of steps S2001-S2003 can be found in steps S1001-S1003 above, and will not be repeated here.

[0218] S2: Based on the module feature information, determine the core device that matches the module feature information.

[0219] Continue to combine Figure 2 As shown, step S2 includes steps S2004-S2005.

[0220] S2004: The database retrieval module retrieves at least one device code that matches the module feature information from the schematic database based on the module feature information.

[0221] Continuing with the example above, the database retrieval module searches the schematic database for five device codes that match the module feature information, such as device B11, device C11, device D11, device B14, and device B15.

[0222] The specific details of step S2004 can be found in step S1004 above, and will not be repeated here.

[0223] S2005: The database retrieval module determines the master device corresponding to at least one device code as a master device list that matches the module feature information.

[0224] Continuing with the example above, the main devices corresponding to the five device codes in the database retrieval module are determined as the main device list A1' that matches the module feature information, and recorded as: device B1, device C1, device D1, device B4, and device B5.

[0225] S2006: The database retrieval module sends the list of main components to the similarity calculation module.

[0226] Following the example above, the database retrieval module sends the main device list A1' to the similarity calculation module.

[0227] The specific details of step S2006 can be found in step S1012 above, and will not be repeated here.

[0228] S2007: The similarity calculation module calculates the similarity score of each main component in the main component list based on the target functional module.

[0229] Continuing with the example above, the similarity calculation module calculates the similarity score of each main device in the main device list based on the target functional module. For example, the similarity score corresponding to device B1 is SCORE1, the similarity score corresponding to device C1 is SCORE2, the similarity score corresponding to device D1 is SCORE3, the similarity score corresponding to device B4 is SCORE4, and the similarity score corresponding to device B5 is SCORE5.

[0230] S2008: The similarity calculation module sorts the main component list based on the similarity score of each main component, and obtains the sorted main component list.

[0231] Continuing with the example above, the similarity calculation module sorts the main device list based on the similarity score of each main device, resulting in the sorted main device list A2': {device D1, device B1, device C1, device B4, device B5}.

[0232] S2009: The similarity calculation module sends the sorted list of main devices to the device scoring and recommendation module.

[0233] Continuing with the example above, the similarity calculation module sends the sorted main device list A2 to the device scoring and recommendation module: {device D1, device B1, device C1, device B4, device B5}.

[0234] S2010: The device scoring and recommendation module inputs the similarity score and the structured constraints corresponding to the main device into the large language model to obtain at least one recommended main device.

[0235] Continuing with the example above, the device scoring and recommendation module inputs the similarity score and the structured constraints corresponding to the main device into the large language model to obtain two recommended main devices: {device D1, device B1}.

[0236] S2011: The device scoring and recommendation module sends at least one recommended master device to the parameter receiving and parsing module.

[0237] Continuing with the example above, the device scoring and recommendation module sends two recommended main devices, {Device D1, Device B1}, to the parameter receiving and parsing module so that the parameter receiving and parsing module can display them to the user.

[0238] S2012: The parameter receiving and parsing module determines the core device from at least one recommended master device.

[0239] Continuing with the example above, the parameter receiving and parsing module receives the main device selected by the user from the recommended main devices: {device D1, device B1} as the core device: device D1.

[0240] S2013: The parameter receiving and parsing module sends the core components to the loading and parsing module.

[0241] Continuing with the example above, the parameter receiving and parsing module sends the core device, device D1, to the loading and parsing module.

[0242] The specific details of steps S2006-S2013 can be found in steps S1013-S1019 above, and will not be repeated here.

[0243] S3: Based on the core device, search the preset schematic database to determine the schematic diagram of the auxiliary device corresponding to the core device.

[0244] Continue to combine Figure 12 As shown, step S3 includes steps S2014-S2015.

[0245] S2014: Load the parsing module based on the core device and query the module feature data table in the schematic database to see if there is a target historical schematic corresponding to the core device.

[0246] The specific details of step S2014 can be found in step S1020 above, and will not be repeated here.

[0247] S2015: If the target historical schematic is not found, the loading parsing module retrieves the standard circuit schematic corresponding to the core device from the reference design table in the schematic database and identifies the standard circuit schematic as the auxiliary device schematic.

[0248] The reference design table stores schematics of general peripheral circuits for core components, provided by the component manufacturers.

[0249] Continuing with the example above, if the target historical schematic is not found, the loading parsing module retrieves the standard circuit schematic P2 corresponding to the core device from the reference design table in the schematic database, and uses the standard circuit schematic P2 to determine the auxiliary device schematic M.

[0250] The specific content of step S2015 can be referred to the specific content of similar step S1021, and will not be repeated here.

[0251] S2016: The loading parsing module sends the auxiliary device schematic diagram to the auxiliary device generation module.

[0252] Following the example above, the loading parsing module sends the auxiliary device schematic M to the auxiliary device generation module.

[0253] S4: Input the schematic diagrams of auxiliary devices, core devices, and user-inputted module interface information into the large language model to obtain a list of auxiliary devices and device connection topology rules.

[0254] Continue to combine Figure 12As shown, step S4 includes step S2017.

[0255] S2017: The auxiliary device generation module inputs the auxiliary device schematic, core device, and user-inputted module interface information into the large language model to obtain the auxiliary device list and device connection topology rules.

[0256] Continuing with the example above, the auxiliary device generation module inputs the auxiliary device schematic, core device, and user-inputted module interface information into the large language model to obtain the auxiliary device list K and device connection topology rules J. Here, it is assumed that the auxiliary device list includes: {device K11, device K21, device K41}.

[0257] S2018: The auxiliary device generation module sends the auxiliary device list and device connection topology rules to the module netlist generation module.

[0258] Continuing with the example above, the auxiliary device generation module sends the auxiliary device list K and device connection topology rule J to the module netlist generation module.

[0259] The specific details of steps S2017-S2018 can be found in steps S1023-S1024 above, and will not be repeated here.

[0260] S5: Based on the list of auxiliary devices and the device connection topology rules, generate the module netlist corresponding to the target functional module.

[0261] Continue to combine Figure 12 As shown, step S5 includes steps S2019-S2021.

[0262] S2019: The module netlist generation module obtains the pin information of core components.

[0263] Following the example above, the module netlist generation module obtains the pin information pin1 of the core device.

[0264] S2020: The module netlist generation module inputs the pin information of the core device, the list of auxiliary devices, the device connection topology rules, and the second preset prompt words into the large language model to generate the module netlist corresponding to the target functional module.

[0265] Following the example above, the module netlist generation module inputs the pin information of the core device, the list of auxiliary devices, the device connection topology rules, and the second preset prompt word into the large language model to generate the module netlist Q1 corresponding to the target functional module.

[0266] S2021: The module netlist generation module sends the module netlist to the hardware circuit module schematic generation module.

[0267] Continuing with the example above, the module netlist generation module sends module netlist Q1 to the hardware circuit module schematic generation module.

[0268] The specific details of steps S2019-S2021 can be found in steps S1025-S1026 above, and will not be repeated here.

[0269] S6: Based on the module netlist, generate the schematic diagram of the target hardware circuit module corresponding to the target functional module.

[0270] Continue to combine Figure 12 As shown, step S6 includes step S2022.

[0271] S2022: The hardware circuit module schematic generation module uses electronic design automation software to process the module netlist and generate the target hardware circuit module schematic corresponding to the target functional module.

[0272] Continuing with the example above, the hardware circuit module schematic generation module uses electronic design automation software to process the module netlist and generate the target hardware circuit module schematic Q2 corresponding to the target functional module.

[0273] In summary, when a matching historical schematic is not available, the reference design serves as the basis for acquiring auxiliary components, enabling the synergy between the schematic database and the large language model. Based on this, a module netlist is generated using the core components as the core, combined with the auxiliary components and their connection rules. The hardware circuit module schematic is then constructed based on the module netlist, thereby achieving automatic circuit generation driven by requirements and effectively improving the efficiency and accuracy of hardware circuit module schematic generation.

[0274] It should be noted that, in the embodiments of this application, the methods for acquiring auxiliary devices and the methods for processing device features can be flexibly combined to form a variety of implementation methods.

[0275] In the first embodiment, virtual device features are introduced, and auxiliary device schematics are obtained by combining them with historical schematics to achieve an auxiliary device determination method based on device feature extension and historical design reuse. In the second embodiment, virtual device features are not introduced; instead, auxiliary device schematics are obtained based on reference designs to achieve an auxiliary device determination method based on standard reference designs. In the third embodiment, virtual device features are introduced, but when no matching historical schematic is obtained, auxiliary device schematics are obtained based on reference designs to achieve an auxiliary device determination method combining device feature extension and reference designs. In the fourth embodiment, virtual device features are not introduced, but when a matching historical schematic exists, auxiliary device schematics are obtained based on the historical schematic to achieve an auxiliary device determination method based on historical design reuse. Further details are omitted here.

[0276] Corresponding to the method described above, the above embodiments utilize a pre-built schematic database. The construction process of the schematic database is explained below.

[0277] Figure 13 This is a schematic diagram of a process for constructing a schematic database provided in an embodiment of this application.

[0278] like Figure 13 As shown, the method for constructing a schematic database includes the following steps: S131: Retrieve historical data corresponding to historical projects.

[0279] The historical data includes historical module feature function definitions, historical schematics, historical device features, historical reference designs, and historical module netlists; the historical module feature function definitions are used to characterize the functional attributes of hardware modules.

[0280] Specifically, the definition of historical module features can include information such as module type, input / output characteristics, electrical parameter requirements, and application scenarios; historical schematics are used to reflect the connection relationships between devices; historical module netlists are used to provide structured electrical connection data; historical device features are used to describe the parameter attributes of devices; and reference designs are used to provide standard circuit implementation schemes.

[0281] For example, taking a "buck power supply module" as an example, its historical data may include: the historical schematic diagram of a power management chip (such as device B1), the corresponding module netlist, the voltage conversion topology (such as Buck topology), the selection parameters of inductors and capacitors, and the reference design provided by the chip manufacturer.

[0282] S132: Construct a module feature data table based on historical module feature function definitions, historical schematic diagrams, and historical module netlists.

[0283] Specifically, the historical module feature function definitions are structured and combined with the electrical connection relationships in the historical schematic diagram and module netlist to extract module-level feature information and form a module feature data table.

[0284] Following the example above, for a step-down power supply module, the following information can be recorded in the module feature data table: input voltage range (e.g., 12V), output voltage (e.g., 5V), output current capability (e.g., 3A), topology type (Buck), interface type, and application scenario (e.g., embedded power supply module).

[0285] S133: Construct a reference design table based on historical reference designs.

[0286] Specifically, the reference design documents provided by the device manufacturers are parsed and structured to extract the circuit topology, device selection and connection relationships, and a reference design data table is constructed.

[0287] For example, for a step-down power supply module, the corresponding reference design may include: a standard Buck circuit design for device B1, which includes the selection parameters of auxiliary devices such as inductor L1, capacitor C1, and resistor R1 and their connection methods with the main device.

[0288] S134: Construct a device feature table based on historical device characteristics.

[0289] Specifically, features of electronic devices involved in historical projects are extracted and structured for storage, forming a device feature data table.

[0290] For example, device characteristics of device B1 may include: input voltage range (4V to 24V), output voltage range (adjustable), maximum output current (3A), package type (QFN), pin definitions (VIN, VOUT, GND, etc.) and manufacturer information.

[0291] S135: Link the module feature data table, historical reference design data table, and device feature data table to establish the correspondence between the three to form a schematic database.

[0292] Specifically, by establishing a mapping relationship between module features and device features, as well as an association relationship between module features and reference designs, a unified association between modules, devices, and reference designs is achieved.

[0293] For example, for a buck power supply module, its module features can be associated with candidate main devices such as device B1 and device B4 (from the device feature table), and at the same time associated with the corresponding Buck reference design (from the reference design table), thus forming a "module features - main device - reference design" relationship, which is used for subsequent device selection and circuit generation.

[0294] It should be noted that in the above embodiments of the schematic database construction method, the example is based on a single module; in practical applications, it may also include the construction process of historical data and corresponding information of multiple modules. This application does not limit this and will not elaborate further here.

[0295] In summary, by integrating multi-dimensional data from historical projects to construct a structured schematic database, a data foundation supporting efficient retrieval and intelligent recommendation is formed. This schematic database can provide reliable data support and knowledge base for subsequent modular design, component selection, and automatic netlist generation.

[0296] Corresponding to the above method, this application also provides an embodiment of a hardware circuit module schematic generation device.

[0297] Figure 14This is a schematic diagram of a hardware circuit module schematic generation device provided in an embodiment of this application.

[0298] like Figure 14 As shown, the hardware circuit module schematic generation device 1400 includes an acquisition module 1401, a determination module 1402, a generation module 1403, and a construction module 1404. The acquisition module 1401 and... Figure 3 The parameter receiving and parsing module 200 corresponds to the parameter determination module 1402 and Figure 3 The database retrieval module 211, virtual device generation module 212, similarity calculation module 213, device scoring and recommendation module 214, and loading and parsing module 215 correspond to these modules. The generation module 1403 is related to... Figure 3 The auxiliary device generation module 216, the module netlist generation module 217, and the hardware circuit module schematic generation module 218 correspond to each other.

[0299] The device includes: an acquisition module 1401, used to acquire module feature information corresponding to a target functional module input by a user; wherein the module feature information is used to characterize the functional requirements and constraints of the target hardware circuit module schematic diagram; a determination module 1402, used to determine the core device matching the module feature information based on the module feature information; the core device is used to characterize the main device of the core function of the target functional module; the determination module 1402 is also used to search a preset schematic diagram database based on the core device to determine the schematic diagram of the auxiliary device corresponding to the core device; the determination module 1402 is also used to input the auxiliary device schematic diagram, the core device and the module interface information input by the user into a large language model to obtain a list of auxiliary devices and device connection topology rules; a generation module, used to generate a module netlist corresponding to the target functional module based on the list of auxiliary devices and device connection topology rules; wherein the module netlist is used to characterize each device and the electrical connection relationship between each device; the generation module is also used to generate the schematic diagram of the target hardware circuit module corresponding to the target functional module based on the module netlist.

[0300] In one possible implementation, the determining module 1402 is further configured to query, based on the core device, whether a target historical schematic corresponding to the core device exists in the module feature data table of the schematic database; if a target historical schematic is found, the target historical circuit schematic is determined as an auxiliary device schematic; if no target historical schematic is found, a standard circuit schematic corresponding to the core device is obtained from the reference design table of the schematic database, and the standard circuit schematic is determined as an auxiliary device schematic; wherein, the reference design table stores general peripheral circuit schematics provided by device manufacturers that are applicable to the core device.

[0301] In another possible implementation, the determining module 1402 is further configured to: retrieve a preset schematic database based on module feature information; determine a list of main components that match the module feature information; calculate a similarity score for each main component in the main component list based on the target functional module; wherein the main component list includes at least one main component identifier and the component features corresponding to each main component; sort the main component list based on the similarity scores of each main component; and determine the core component that matches the module feature information based on the sorted main component list.

[0302] In another possible implementation, the determining module 1402 is further configured to sort the list of main components based on the similarity scores of each main component to obtain a sorted list of main components; input the similarity scores and the structured constraint factors corresponding to the main components into the large language model to obtain at least one recommended main component; wherein, the structured constraint factors are used to characterize the constraints of the target functional module in the electrical design; and determine the core component from the at least one recommended main component.

[0303] In another possible implementation, a determining module is used to retrieve at least one device code that matches the module feature information from the module feature table of the schematic database based on the module feature information; and to determine the main device corresponding to the at least one device code as a list of main devices that match the module feature information.

[0304] In another possible implementation, the determining module 1402 is used to retrieve at least one device code that matches the module feature information from the module feature table of the schematic database based on the module feature information; determine the main device corresponding to the at least one device code as an initial device set; generate virtual device features based on the common features of devices of the same type in the initial device set; perform an extended search in the device feature table of the schematic database using the virtual device features to obtain a supplementary device set; and determine a list of main devices that match the module feature information based on the initial device set and the supplementary device set.

[0305] In another possible implementation, the generation module 1403 is used to select multiple devices of the same type from the initial device set; wherein, devices of the same type are used to characterize devices with the same or similar device features; multiple devices of the same type and their corresponding first preset prompt words are input into the large language model, and virtual device features are output; wherein, the virtual device features are used to characterize the union of features of multiple devices of the same type.

[0306] In another possible implementation, the generation module 1403 is used to obtain the pin information of the core device; input the pin information of the core device, the list of auxiliary devices, the device connection topology rules and the second preset prompt words into the large language model to generate the module netlist corresponding to the target functional module; wherein, the list of auxiliary devices includes at least one auxiliary device identifier and the device features corresponding to each auxiliary device; the device connection topology rules include the connection rules of the core device and the auxiliary devices.

[0307] In another possible implementation, a construction module 1404 is used to acquire historical data corresponding to historical projects; wherein, the historical data includes historical module feature function definitions, historical schematics, historical device features, historical reference designs, and historical module netlists; the historical module feature function definitions are used to characterize the functional attributes of hardware modules; a module feature data table is constructed based on the historical module feature function definitions, historical schematics, and historical module netlists; a reference design table is constructed based on historical reference designs; a device feature table is constructed based on historical device features; the module feature data table, the historical reference design data table, and the device feature data table are associated to establish a correspondence between the three to form a schematic database.

[0308] Figure 15 This is a schematic diagram of a computing device provided in an embodiment of this application.

[0309] like Figure 15 As shown, the computing device 1500 includes a processor 1501 and a memory 1502. Exemplarily, the computing device 1500 may also include a communications interface 1503 and a communications bus 1504.

[0310] The processor 1501, memory 1502, and communication interface 1503 communicate with each other via communication bus 1504. The communication interface 1503 may include a transmitter and receiver for communicating with other devices or communication networks, and may be a wired interface (port), such as a fiber distributed data interface (FDDI) or a gigabit Ethernet interface (GE).

[0311] In some embodiments, the processor 1501 is used to execute program 1505, specifically performing the relevant steps in the above-described hardware circuit module schematic generation method embodiment. Specifically, program 1505 may include program code, which includes computer-executable instructions.

[0312] For example, processor 1501 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement some embodiments of this application. Computing device 1500 may include one or more processors, which may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs. The CPU may be a single-core CPU or a multi-core CPU.

[0313] In some embodiments, memory 1502 is used to store program 1505. Memory 1502 may include high-speed random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device.

[0314] Specifically, program 1505 can be called by processor 1501 to cause computing device 1500 to perform hardware circuit module schematic generation operation.

[0315] Some embodiments of this application provide a computer-readable storage medium storing at least one executable instruction that, when executed on a computing device 1500, causes the computing device 1500 to perform the hardware circuit module schematic generation method described in the above embodiments.

[0316] For example, the computer-readable storage medium can be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device.

[0317] This application provides a chip system for use in a server. The chip system includes one or more interface circuits and one or more processors. The interface circuits and processors are interconnected via lines. The interface circuits receive signals from the server's memory and send signals to the processors, the signals including computer instructions stored in the memory. When the server processor executes the computer instructions, the server performs the various steps of the hardware circuit module schematic generation method shown in the above-described method embodiments.

[0318] The beneficial effects that the readable storage medium provided in some embodiments of this application can achieve can be referred to the beneficial effects in the corresponding inference task execution method provided above, and will not be repeated here.

[0319] It should be noted that, in this application, relational terms such as "first" and "second" 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. Furthermore, 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 the element.

[0320] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0321] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0322] For the purposes of this specification, "computer-readable medium" can mean any means that can contain, store, communicate, propagate, or transmit programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0323] More specific examples of computer-readable media (a non-exhaustive list) include the following: electrical connections having one or more wires (electronic devices), portable computer disks (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM).

[0324] Furthermore, the computer-readable medium can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory. It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof.

[0325] In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc. The above embodiments are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solutions of this application should be included within the scope of protection of this application.

Claims

1. A method for generating a hardware circuit module schematic, characterized in that, include: Obtain the module feature information corresponding to the target functional module input by the user; wherein, the module feature information is used to characterize the functional requirements and constraints of the target sub-circuit schematic diagram; Based on the module feature information, the core components that match the module feature information are determined; the core components are the main components that characterize the core functions of the target functional module. Based on the core device, a preset schematic database is searched to determine the schematic diagram of the auxiliary device corresponding to the core device; The schematic diagrams of the auxiliary devices, the core devices, and the module interface information input by the user are input into the large language model to obtain a list of auxiliary devices and device connection topology rules; Based on the list of auxiliary devices and the device connection topology rules, a module netlist corresponding to the target functional module is generated; wherein, the module netlist is used to characterize each device and the electrical connection relationship between each device; Based on the module netlist, the schematic diagram of the target hardware circuit module corresponding to the target functional module is generated.

2. The hardware circuit module schematic generation method according to claim 1, characterized in that, The step of retrieving a preset schematic database based on the core device to determine the schematic diagram of the auxiliary device corresponding to the main device includes: Based on the core device, query the module feature data table in the schematic database to see if there is a target historical schematic corresponding to the core device; If the target historical schematic diagram is found, the target historical circuit schematic diagram is identified as the schematic diagram of the auxiliary device; If the target historical schematic is not found, the standard circuit schematic corresponding to the core device is obtained from the reference design table in the schematic database, and the standard circuit schematic is identified as the schematic of the auxiliary device; wherein, the reference design table stores general peripheral circuit schematics provided by the device manufacturer that are applicable to the core device.

3. The method for generating hardware circuit module schematics according to claim 1 or 2, characterized in that, The step of determining the core device matching the module feature information based on the module feature information includes: Based on the module feature information, a preset schematic database is retrieved to determine a list of main components that match the module feature information; Based on the target functional module, a similarity score is calculated for each main device in the main device list; wherein, the main device list includes at least one main device identifier and device features corresponding to each main device; The list of main components is sorted based on the similarity scores of each main component, and the core component that matches the feature information of the module is determined based on the sorted list of main components.

4. The method for generating hardware circuit module schematics according to claim 3, characterized in that, The process of sorting the list of main components based on their similarity scores, and determining the core components that match the module's feature information based on the sorted list of main components, includes: The main device list is sorted based on the similarity score of each main device to obtain the sorted main device list; The similarity score and the structured constraint factors corresponding to the main device are input into the large language model to obtain at least one recommended main device; wherein, the structured constraint factors are used to characterize the constraints of the target functional module in electrical design; The core device is determined from at least one of the recommended master devices.

5. The method for generating hardware circuit module schematics according to claim 3 or 4, characterized in that, The step of retrieving a preset schematic database based on the module feature information to determine a list of main components matching the module feature information includes: Based on the module feature information, at least one device code that matches the module feature information is retrieved from the module feature table of the schematic database; At least one of the device codes corresponding to the main device is identified as a list of main devices that match the module feature information.

6. The method for generating hardware circuit module schematics according to claim 3 or 4, characterized in that, The step of retrieving a preset schematic database based on the module feature information to determine a list of main components matching the module feature information includes: Based on the module feature information, at least one device code that matches the module feature information is retrieved from the module feature table of the schematic database; At least one of the master devices corresponding to the device codes is determined as the initial device set; Based on the common characteristics of devices of the same type in the initial device set, virtual device characteristics are generated; The virtual device features are used to perform an extended search in the device feature table of the schematic database to obtain a supplementary device set; Based on the initial device set and the supplementary device set, a list of main devices that match the module feature information is determined.

7. The method for generating hardware circuit module schematics according to claim 6, characterized in that, The step of generating virtual device features based on the common characteristics of devices of the same type in the initial device set includes: Multiple devices of the same type are selected from the initial device set; wherein, the devices of the same type are used to characterize devices with the same or similar device characteristics; The multiple similar devices and their corresponding first preset prompt words are input into a large language model, and the virtual device features are output; wherein, the virtual device features are used to characterize the union of features of multiple similar devices.

8. The method for generating a hardware circuit module schematic according to any one of claims 1-7, characterized in that, The step of generating a module netlist corresponding to the target functional module based on the list of auxiliary devices and the device connection topology rules includes: Obtain the pin information of the core device; The pin information of the core device, the list of auxiliary devices, the device connection topology rules, and the second preset prompt word are input into the large language model to generate the module netlist corresponding to the target functional module; wherein, the list of auxiliary devices includes at least one auxiliary device identifier and the device feature corresponding to each auxiliary device; the device connection topology rules include the connection rules of the core device and the auxiliary devices.

9. The method for generating a hardware circuit module schematic according to any one of claims 1-8, characterized in that, Also includes: Obtain historical data corresponding to historical projects; wherein, the historical data includes historical module feature function definitions, historical schematics, historical device features, historical reference designs, and historical module netlists; the historical module feature function definitions are used to characterize the functional attributes of hardware modules; Based on the historical module feature function definition, the historical principle diagram and the historical module netlist, a module feature data table is constructed. Based on the aforementioned historical reference designs, a reference design table is constructed; Based on the aforementioned historical device characteristics, a device characteristic table is constructed; The module feature data table, the reference design data table, and the device feature data table are associated to establish a correspondence between them, thereby forming the schematic database.

10. A computing device, characterized in that, The computing device includes a memory and a processor; the memory and the processor are coupled; the memory is used to store computer program code, the computer program code including computer instructions, and the processor is used to execute the computer instructions to cause the computing device to apply the hardware circuit module schematic generation method as described in any one of claims 1 to 8.

Images