Device acquisition system, device retrieval method, device storage method, terminal and medium

Abstract

This application provides a device acquisition system, a device retrieval method, a device storage method, a terminal, and a medium. The device acquisition system includes a device generation module, a device inspection module, and a device simulation module. The device generation module generates devices based on retrieval instructions. The device inspection module verifies the devices. The device simulation module simulates the devices. The device generation module includes an instruction interaction unit, a device parameter storage unit, and a variable comparison unit. The instruction interaction unit acquires retrieval instructions and generates retrieval variables. The device parameter storage unit stores device data and device variables. The variable comparison unit compares the retrieval variables with each device variable; only when the retrieval variable matches a device variable is the corresponding device generated. Otherwise, device generation fails, thus preventing device data from being used for purposes beyond the original authorization scope and improving the security of device data.

Description

Technical Field

[0001] This application belongs to the field of chip manufacturing technology, and relates to a device acquisition technology, particularly a device acquisition system, device recall method, device storage method, terminal and medium. Background Technology

[0002] A PDK (Process Design Kit) is a collection of files that contains all electrical characteristics, physical design rules, simulation models, and parameterized units for a specific process node, enabling the chip to be manufactured according to the design.

[0003] However, the various device data in existing PDKs are usually stored and distributed in plaintext, which can be directly parsed by tools. The device data in the PDK can be directly read, parsed and applied by the original name of the device. This makes it easy for the device data to be directly misappropriated and used for secondary development by users. This allows users to obtain the core data of the device for their own toolchain development, internal design process customization or other purposes beyond the original authorization without the manufacturer's authorization or permission. This exposes the device to the risk of reverse analysis and theft by third parties, causing the manufacturer to lose its technological development advantage.

[0004] Therefore, how to protect the data security of various devices in the PDK is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] The purpose of this application is to provide a device acquisition system, device retrieval method, device storage method, terminal, and medium to solve the problem that device data is easily misappropriated and used for secondary development in the prior art.

[0006] In a first aspect, this application provides a device acquisition system comprising: a device generation module, a device inspection module, and a device simulation module; the device generation module is used to generate a corresponding device based on a call instruction; the device inspection module is used to verify the generated device; the device simulation module is used to simulate the generated and verified device; wherein, the device generation module includes an instruction interaction unit, a device parameter storage unit, and a variable comparison unit; the instruction interaction unit is used to acquire a call instruction and generate a corresponding call variable based on the call instruction; the device parameter storage unit is used to store data of each device and the corresponding device variable; the variable comparison unit is used to compare whether the call variable matches any of the device variables; if the call variable matches any of the device variables, the corresponding device is generated based on the corresponding device data; otherwise, device generation fails.

[0007] In one embodiment of this application, the device inspection module includes a design rule inspection unit, a layout and schematic comparison unit, and a parasitic parameter extraction unit; the design rule inspection unit is used to inspect the generated device based on preset physical verification rules; the layout and schematic comparison unit is used to inspect the generated device based on preset design circuits; and the parasitic parameter extraction unit is used to obtain the parasitic status of the generated device based on preset device parasitic rules.

[0008] In one embodiment of this application, the device data includes device process parameters, model parameters, set parameters, graphic codes, process levels, and the definitions, names, and data types of various parameters; the device data corresponds one-to-one with the device variables.

[0009] In one embodiment of this application, the calling variable is used to characterize the name of the device to be generated; the device variable is a variable generated based on the name of the device.

[0010] Secondly, this application provides a device recall method, applied to the device acquisition system described above, comprising: acquiring a recall instruction and generating a corresponding recall variable based on the recall instruction; matching the recall variable with pre-stored device variables; if the recall variable matches any of the device variables, generating a corresponding device based on the corresponding device data; otherwise, device generation fails, wherein both the recall variable and the device variable are strings.

[0011] Thirdly, this application provides a device storage method applied to the device acquisition system described above, comprising: acquiring device data corresponding to each device, and generating device variables based on the name of each device; mapping each device variable to each device data one-to-one, and storing them.

[0012] In one embodiment of this application, each of the device variables and each of the device data are stored in the device generation module of the device acquisition system.

[0013] Fourthly, this application provides a terminal, including: a processor and a memory, wherein the memory and the processor are communicatively connected;

[0014] The memory is used to store computer programs, and the processor is used to execute the computer programs stored in the memory so that the terminal performs the device invocation method or device storage method as described above.

[0015] Fifthly, this application provides a computer storage medium storing a computer program, which, when executed by a processor, implements the device recall method or device storage method as described above.

[0016] As described above, this application provides a device acquisition system, a device calling method, a device storage method, a terminal, and a medium. By acquiring calling variables and comparing them with device variables, a device is generated only when the calling variables match the device variables. This prevents the generation of corresponding devices after the device name is modified during secondary development, thereby avoiding the misappropriation of device data and improving the security and confidentiality of device data. Attached Figure Description

[0017] Figure 1 The diagram shown is a schematic representation of a device acquisition system according to an embodiment of this application.

[0018] Figure 2 The diagram shown is a structural schematic of another device acquisition system described in an embodiment of this application.

[0019] Figure 3 The diagram shown is a flowchart illustrating a device calling method according to an embodiment of this application.

[0020] Figure 4 The diagram shown is a schematic flowchart of a device storage method according to an embodiment of this application.

[0021] Figure 5 The diagram shown is a structural schematic of a terminal as described in an embodiment of this application.

[0022] Explanation of reference numerals in the attached figures

[0023] 10: Device generation module; 11: Instruction interaction unit; 12: Device parameter storage unit; 13: Variable comparison unit; 20: Device inspection module; 21: Design rule inspection unit; 22: Layout and schematic comparison unit; 23: Parasitic parameter extraction unit; 30: Device simulation module; 40: Terminal; 41: Processor; 42: Memory; 421: Operating system; 422: Application program; 43: User interface; 44: Network interface; 45: Bus system. Detailed Implementation

[0024] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0025] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0026] A PDK (Process Design Kit) is a crucial toolkit in semiconductor chip design, providing data including all electrical characteristics, physical design rules, simulation models, and parameterized cells for a specific process node. However, existing PDK systems often store device data in plaintext, making it possible to obtain the corresponding device without the manufacturer's authorization or permission, which is detrimental to technology protection.

[0027] To address the technical problems existing in the prior art, the following embodiments of this application provide a device acquisition system, a device calling method, a device storage method, a terminal, and a medium. By acquiring the corresponding calling variable based on the calling instruction, and comparing the calling variable with the device variable corresponding to each device, the corresponding device can only be generated when the calling variable matches the device variable, thereby preventing device data from being used for purposes beyond the original authorized scope, and thus improving the security of device data.

[0028] The technical solutions in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0029] like Figure 1 As shown, this embodiment provides a device acquisition system for providing device data for various devices to facilitate chip design simulation. The device data includes, but is not limited to, device process parameters, model parameters, set parameters, graphical codes, process levels, and the definitions, names, and data types of each parameter. Specifically, the device acquisition system includes a device generation module 10, a device inspection module 20, and a device simulation module 30. The device generation module 10 generates the corresponding device based on a retrieval instruction, the device inspection module 20 verifies the generated device, and the device simulation module 30 simulates the generated and verified device. Based on this, the device acquisition system can generate the corresponding device based on the retrieval instruction and perform verification simulation based on that device, thereby assisting in the smooth execution of the chip design process.

[0030] Furthermore, the device generation module 10 includes an instruction interaction unit 11, a device parameter storage unit 12, and a variable comparison unit 13. The instruction interaction unit 11 acquires a calling instruction and generates corresponding calling variables based on the instruction. The device parameter storage unit 12 stores device data and corresponding device variables. The variable comparison unit compares whether the calling variable matches any device variable. If the calling variable matches any device variable, the corresponding device is generated based on the corresponding device data; otherwise, device generation fails. Therefore, a device can only be generated when the calling variable matches the device variable, thus preventing device data from being directly misappropriated or used for secondary development on the user end, thereby improving the security of device data.

[0031] Specifically, the device data includes device variables. When the device generation module 10 receives a call instruction from the user terminal, it generates a corresponding call variable based on the call instruction, and uses this call variable to determine whether it corresponds to any of the stored devices. For example, the device variables for each stored device are actually variables generated based on the device's name. The call variable represents the name of the device to be generated, and is compared with the names of the stored devices to determine if the device to be generated is a stored device. The corresponding device is generated when the call variable matches the device variable.

[0032] For example, both the device variables and the calling variables are strings. For instance, each device variable is a string corresponding to the name of its respective device, and the calling variable is a string corresponding to the name of the device to be generated.

[0033] It should be noted that secondary development typically requires modifying device names to adhere to a self-defined naming convention, preventing conflicts with the original database or other third-party libraries. Therefore, when a device is regenerated after its name has been modified, the variables generated by the call command based on the modified name will not correspond to the device variables generated based on the original name. This prevents the generation of the corresponding device after the name modification, thus avoiding secondary development on the user side and ensuring the security of device data.

[0034] For example, a specific implementation will be described below.

[0035] For example, the original database contains an NMOS transistor named "nch". When the user needs to generate this NMOS transistor for simulation, it issues a call command. The command interaction unit 11 obtains the string "nch" as a call variable based on the call command, matches it with the device variable string "nch" in the database, and then generates the NMOS transistor based on the device data corresponding to the string "nch".

[0036] After copying the data, it was renamed to mycorp-nch during secondary development. At this point, when the user issues a command to call the transistor, the command retrieves the call variable as the string "mycorp-nch", which does not match the device variable string "nch" in the database, causing the call to fail.

[0037] Based on this, the device can be generated without exceeding the original authorized scope of secondary development, thus improving the security and confidentiality of device data.

[0038] In some optional implementations, the device inspection module 20 includes a design rule inspection unit 21, a layout and schematic comparison unit 22, and a parasitic parameter extraction unit 23. The design rule inspection unit 21 checks the generated devices based on preset physical verification rules to ensure the manufacturability of the devices in actual production. The layout and schematic comparison unit 22 checks the generated devices based on a preset design circuit to ensure consistent connectivity between devices, i.e., correct connection relationships. For example, checking based on the preset design circuit involves comparing the generated layout with the circuit schematic of the design circuit to confirm whether there are errors in the generated devices and their connections, thus confirming the correctness of the generated devices. The parasitic parameter extraction unit 23 obtains the parasitic conditions corresponding to the generated devices based on preset device parasitic rules, thereby providing an accurate parasitic netlist, such as parasitic resistance, parasitic capacitance, and parasitic inductance, to accurately simulate the actual operation of the circuit. Based on this, the device acquisition system can realistically and accurately simulate each device, thereby assisting chip design.

[0039] For example, such as Figure 2As shown, the device generation module 10 is the PCell (parameterized cell) module in the PDK system; the layout and schematic comparison unit 22 is the LVS (Layout Versus Schematic) unit in the PDK system; the rule checking unit is the DRC (Design Rule Check) unit in the PDK system; the parasitic parameter extraction unit 23 is the PEX (Parasitic Extraction) unit in the PDK system; and the device simulation module 30 is the Model (device simulation model) module in the PDK system. Based on this, each device in the circuit can be obtained for simulation of the circuit in the circuit design. Since the device generation module 10 includes an instruction interaction unit 11, a device parameter storage unit 12, and a variable comparison unit 13, it generates call variables by obtaining call instructions to match with the variables of each device. Only when the call variables match the device variables can the corresponding device be generated, thus preventing secondary development by the user and avoiding secondary development beyond the original authorization scope, effectively improving the security and confidentiality of device data.

[0040] On the other hand, this application also provides a device recall method, applied to the device acquisition system as described above, for generating the required device.

[0041] Specifically, such as Figure 3 As shown, the device calling methods include:

[0042] S10: Obtain the call instruction and generate the corresponding call variables based on the call instruction.

[0043] Specifically, the user sends a call command, and the device acquisition system generates a call variable based on the call command. The call variable corresponds to the device required by the user. For example, the call variable is a string generated based on the name of the device required by the user.

[0044] S20: Match the called variable with the pre-stored device variable. If the called variable matches any device variable, generate the corresponding device based on the corresponding device data; otherwise, device generation fails.

[0045] The pre-stored device variables correspond one-to-one with the variables of each stored device. For example, each device variable is a string generated based on the name of each stored device.

[0046] Specifically, the current calling variable is compared with the variables of each device. If a matching device variable exists, it is the device variable corresponding to the device to be generated. The device data corresponding to the matching device variable is obtained, and the corresponding device is generated based on the device data. Otherwise, if no matching device variable exists, the calling variable is incorrect or has been tampered with, and the device generation fails.

[0047] It should be noted that, in order to ensure that no device can be generated after the device name is tampered with, and to improve the security and confidentiality of device data, this application also provides a device storage method, which is applied to the device acquisition system described above, for storing various devices.

[0048] Specifically, such as Figure 4 As shown, the device storage method includes:

[0049] S10': Obtain device data corresponding to each device, and generate device variables based on the name of each device.

[0050] Specifically, the process parameters, model parameters, set parameters, graphical codes, process levels, and the definitions, names, and data types of each parameter of each device are obtained, and this data is stored separately for each device.

[0051] Based on the name of each device, a corresponding string is generated and stored as a device variable for each device.

[0052] S20' maps each device variable to its corresponding device data and stores the data.

[0053] Specifically, the device variables corresponding to the same device, as well as the device's process parameters, model parameters, set parameters, graphic codes, process levels, and the definitions, names, and data types of each parameter, are stored as the device data of that device. This ensures that each device variable corresponds to each parameter of the device, thereby enabling the acquisition of the corresponding device parameters based on the device variables to generate the device.

[0054] Based on the same technical concept, the device calling method and device storage method provided in the embodiments of this application can be implemented on the terminal side or the server side.

[0055] like Figure 5The diagram shown illustrates an optional hardware structure of a terminal according to an embodiment of the present invention. The terminal 40 can be a chip circuit simulation device, a mobile phone, a computer device, a tablet device, a personal digital processing device, a factory back-end processing device, etc. The terminal 40 includes at least one processor 41, a memory 42, at least one network interface 44, and a user interface 43. The various components in the device are coupled together via a bus system 45. It is understood that the bus system 45 is used to realize communication between these components. In addition to a data bus, the bus system 45 also includes a power bus, a control bus, and a status signal bus.

[0056] The user interface 43 may include a monitor, keyboard, mouse, trackball, clicker, button, touchpad, or touch screen.

[0057] It is understood that memory 42 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM) or programmable read-only memory (PROM), used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM) and synchronous static random access memory (SSRAM). The memory characterized in the embodiments of the present invention is intended to include, but is not limited to, these and any other suitable categories of memory.

[0058] In this embodiment of the invention, the memory 42 is used to store various types of data to support the operation of the terminal. Examples of this data include: any executable program for operation on the terminal 40, such as the operating system 421 and application programs 422; the operating system 421 contains various system programs, such as the framework layer, core library layer, driver layer, etc., for implementing various basic services and handling hardware-based tasks. The application program 422 may contain various applications, such as a media player, browser, etc., for implementing various application services. The device calling method or device storage method provided in this embodiment of the invention may be included in the application program 422.

[0059] The methods disclosed in the above embodiments of the present invention can be applied to processor 41, or implemented by processor 41. Processor 41 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 41 or by instructions in the form of software. The processor 41 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 41 can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of the present invention. Processor 41 may be a microprocessor or any conventional processor, etc. The steps of the device calling method or device storage method provided in the embodiments of this application can be directly reflected as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium, which is located in a memory. The processor reads the information in the memory and combines it with its hardware to complete the steps of the aforementioned method.

[0060] In an exemplary embodiment, terminal 40 may be used by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), or complex programmable logic devices (CPLDs) to execute the aforementioned device invocation method or device storage method.

[0061] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when invoked by a processor, implements the device invocation method or device storage method provided by this invention.

[0062] A computer-readable storage medium can be a tangible device capable of holding and storing instructions used by an instruction execution device. Computer-readable storage media can be, for example, (but not limited to) electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, and mechanical encoding devices.

[0063] The computer-readable program represented herein can be downloaded from a computer-readable storage medium to various computing / processing devices, or downloaded via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network, to an external computer or external storage device. A network adapter card or network interface in each computing / processing device receives computer-readable program instructions from the network and forwards these instructions to the computer-readable storage medium in the respective computing / processing device.

[0064] In summary, this application obtains the calling variables and compares them with pre-stored device variables, thereby generating a device when the calling variables match the device variables, and otherwise the device generation fails. This prevents device data from being directly misappropriated or used for secondary development on the user end, thus improving the security and confidentiality of device data.

[0065] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0066] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A device acquisition system, characterized in that, include: Device generation module, device inspection module, and device simulation module; The device generation module is used to generate corresponding devices based on the retrieval instructions; The device inspection module is used to verify the generated device; The device simulation module is used to simulate the generated and verified device. The device generation module includes an instruction interaction unit, a device parameter storage unit, and a variable comparison unit. The instruction interaction unit is used to obtain a call instruction and generate a corresponding call variable based on the call instruction. The device parameter storage unit is used to store data of each device and the corresponding device variable. The variable comparison unit is used to compare whether the call variable matches any of the device variables. If the call variable matches any of the device variables, the corresponding device is generated based on the corresponding device data; otherwise, device generation fails.

2. The device acquisition system according to claim 1, characterized in that, The device inspection module includes a design rule inspection unit, a layout and schematic comparison unit, and a parasitic parameter extraction unit. The design rule checking unit is used to check the generated device based on preset physical verification rules; The layout and schematic comparison unit is used to check the generated devices based on the preset design circuit; The parasitic parameter extraction unit is used to obtain the parasitic status of the generated device based on the preset device parasitic rules.

3. The device acquisition system according to claim 1, characterized in that, The device data includes the device's process parameters, model parameters, set parameters, graphical codes, process levels, and the definitions, names, and data types of various parameters; The device data corresponds one-to-one with the device variables.

4. The device acquisition system according to claim 3, characterized in that, The calling variable is used to represent the name of the device to be generated; the device variable is a variable generated based on the name of the device.

5. The device acquisition system according to claim 1, characterized in that, Both the calling variable and the device variable are strings.

6. A device retrieval method, applied to a device acquisition system as described in any one of claims 1 to 5, characterized in that, include: Obtain the invocation instruction and generate the corresponding invocation variable based on the invocation instruction; The calling variable is matched with the pre-stored device variables. If the calling variable matches any of the device variables, the corresponding device is generated based on the corresponding device data; otherwise, the device generation fails.

7. A device storage method, applied to a device acquisition system as described in any one of claims 1 to 5, characterized in that, include: Obtain the device data corresponding to each device, and generate device variables based on the name of each device; Each of the device variables is mapped one-to-one with each of the device data and then stored.

8. The device storage method according to claim 7, characterized in that, All device variables and device data are stored in the device generation module of the device acquisition system.

9. A terminal, characterized in that, include: A processor and a memory, wherein the memory and the processor are communicatively connected; The memory is used to store computer programs, and the processor is used to execute the computer programs stored in the memory, so that the terminal performs the device recall method as described in claim 6 or the device storage method as described in claim 7.

10. A computer storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the device recall method as described in claim 6 or the device storage method as described in claim 7.

Images