Automated Power Discrete and Modular Model Generation for System-Level Simulators
Product SPICE models address inaccuracies in system-level simulators by simulating semiconductor dies with granular inputs, ensuring accurate system-level simulations and reducing design risks.
Patent Information
- Application Number
- JP2024548734
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2022-11-23
- Filing Date
- 2023-09-01
- Publication Date
- 2026-01-06
AI Technical Summary
Existing system-level simulators face inaccuracies due to laboratory-derived datasheet data that includes errors from laboratory equipment and parasitic characteristics, leading to over-design, under-design, or marginal design, and increased development time and expense.
Utilize product SPICE models derived through modeling that account for electrical and thermal characteristics of semiconductor dies, allowing for granular input and output simulations without laboratory equipment interference, and generate product system model files for system-level simulators.
Provides accurate simulations by accounting for designer-specific boundary conditions and parasitic characteristics, reducing prototype failures and design inefficiencies, and enhancing design precision.
Smart Images

Figure 2026500053000001_ABST
Abstract
Description
[Technical Field]
[0001] Aspects of this document relate generally to simulating electronic systems. More specific implementations include systems and methods for simulating systems that include semiconductor dies. [Background technology]
[0002] Semiconductor dies are incorporated into larger electronic systems, such as motherboards or circuit boards, either directly attached or via a packaging system attached to the semiconductor die, which are designed to provide and receive specific electronic signals from the semiconductor die during operation. Summary of the Invention
[0003] An implementation of a method for generating a product system model for use in a system-level simulation may include receiving a selection of a product type from a user using a first interface generated by a computing device, selecting a product SPICE model associated with the product type from a database of product SPICE models using a processor, and receiving a selection of process conditions from the user using a second interface generated by the computing device. The method may also include receiving one or more system characteristics and one or more operational characteristics from the user using a third interface generated by the computing device, receiving one or more circuit characteristics from the user using a fourth interface generated by the computing device, and generating a SPICE model output using the product SPICE model, the process conditions, the one or more system characteristics, the one or more operational characteristics, and the one or more circuit characteristics using a processor and a SPICE model simulation module. The method may also include formatting the SPICE model output into a product system model file using a processor and a formatting module, the product system model file comprising one of a structured text file, a plain text file, or a delimited text file.
[0004] Implementations of the method for generating a product system file for use in a system-level simulation may include one, all, or any of the following:
[0005] The product system model file can be configured to be used to perform a system-level simulation of a system that includes a product type.
[0006] Receiving a selection of a product type from the user may further include receiving a selection of one of a product die type, a product technology type, a product voltage level, a device type, and any combination thereof.
[0007] Receiving a selection of process conditions from a user may further include receiving a selection of one of nominal conditions, worst case conduction losses / best case switching losses, or best case conduction losses / worst case switching losses.
[0008] The one or more system characteristics may include one of a number of devices and one or more temperatures.
[0009] The one or more operating characteristics may further include one of at least one DC current characteristic, at least one switching characteristic, at least one gate threshold voltage, or any combination thereof.
[0010] The one or more circuit characteristics further include one of a gate resistance, a gate inductance, a gate loop inductance, a source inductance, a loop inductance, a diode voltage, and any combination thereof.
[0011] The fourth interface may further include a circuit diagram.
[0012] The product system model file may be a structured text file configured for use by a piecewise linear electrical circuit simulation system.
[0013] The product type may include a discrete power semiconductor die.
[0014] An implementation of a system for generating a system model for use in a system-level simulation may include one or more hardware processors, configured with machine-readable instructions to receive a selection of a product type from a user using a first interface generated by a computing device, select a product SPICE model associated with the product type from a database of product SPICE models, and receive a selection of process conditions from the user using a second interface generated by the computing device. The system may further include receiving one or more system characteristics and one or more operational characteristics from the user using a third interface generated by the computing device, receiving one or more circuit characteristics from the user using a fourth interface generated by the computing device, and generating a SPICE model output using the product SPICE model, the process conditions, the one or more system characteristics, the one or more operational characteristics, and the one or more circuit characteristics using a SPICE model simulation module. The system may further use a formatting module to format the SPICE model output into a product system model file, the product system model file comprising one of a structured text file, a plain text file, or a delimited text file.
[0015] An implementation of a system for generating a system model for use in a system-level simulation may include one, all, or any of the following:
[0016] The product system model file can be configured to be used to perform a system-level simulation of a system that includes a product type.
[0017] The selection of the product type may further include selecting one of a product die type, a product technology type, a product voltage level, a device type, and any combination thereof.
[0018] The selection of process conditions may further include selecting nominal conditions, worst case conduction losses / best case switching losses, or best case conduction losses / worst case switching losses.
[0019] The one or more system characteristics include one of a number of devices and one or more temperatures.
[0020] The one or more operating characteristics may further include one of at least one DC current characteristic, at least one switching characteristic, at least one gate threshold voltage, or any combination thereof.
[0021] The one or more circuit characteristics further include one of a gate resistance, a gate inductance, a gate loop inductance, a source inductance, a loop inductance, a diode voltage, and any combination thereof.
[0022] The fourth interface may further include a circuit diagram.
[0023] The product system model file may be a structured text file configured for use by a piecewise linear electrical circuit simulation system.
[0024] The product type may include a discrete power semiconductor die.
[0025] These and other aspects, features, and advantages will be apparent to those skilled in the art from the detailed description and drawings, and from the claims. [Brief explanation of the drawings]
[0026] Implementations are described below in conjunction with the accompanying drawings, in which like numbers refer to like elements, and in which: [Figure 1] FIG. 2 is a diagram of a first interface generated by a computing device. [Figure 2]FIG. 10 is a diagram of a second interface generated by a computing device. [Figure 3] FIG. 10 is a diagram of a third interface generated by a computing device. [Figure 4] FIG. 10 is a diagram of a fourth interface generated by a computing device. [Figure 5] FIG. 1 is a diagram of a first portion of a system model file containing a structured text file. [Figure 6] FIG. 6 is a diagram of a second portion of the system model file of FIG. 5. [Figure 7] FIG. 1 is a diagram of a first portion of a system model file in a file viewer containing a structured text file. [Figure 8] FIG. 8 is a diagram of a second portion of the system model file of FIG. 7. [Figure 9] 5 shows one implementation of the circuit diagram included in the corresponding part of FIG. 4. [Figure 10] 3D graph of system-level simulation data from a system simulator using a system model file. [Figure 11] 10 is a graph of system-level simulation data showing Eoff switching losses versus diode current (ID) at different temperatures and voltages obtained using the system model file. [Figure 12] 10 is a graph of system-level simulation data for Eoff switching losses at different diode currents (ID) obtained using the system model file. [Figure 13] 10 is a graph of system-level simulation data for Eoff switching losses at different diode currents (ID) at different temperatures obtained using the system model file. [Figure 14] 10 is a graph of system-level simulation data for Eon switching losses at different diode currents (ID) obtained using the system model file. [Figure 15] 10 is a graph of system-level simulation data for Eon switching losses at different diode currents (ID) and temperatures obtained using the system model file. [Figure 16] 10 is a graph of system level simulation data for Vdson switching losses at different diode currents and temperatures. [Figure 17] 10 is a graph of system level simulation data for Vsd (voltage source drain) at different diode currents and temperatures. [Figure 18] FIG. 1 is a block diagram of an implementation of a system for generating a system model for use in a system-level simulation. [Figure 19] 1 is a flowchart of one implementation of a method for generating a system model for use in a system-level simulation. DETAILED DESCRIPTION OF THE INVENTION
[0027] The present disclosure, its aspects, and implementations are not limited to the specific components, assembly procedures, or method elements disclosed herein. Many additional components, assembly procedures, and / or method elements known in the art consistent with the intended systems and methods for generating product system models for use in system-level simulators will become apparent for use in particular implementations of the present disclosure. Thus, for example, while specific implementations are disclosed, such implementations and implemented components may include any shape, size, style, type, model, version, measurement, concentration, material, quantity, method element, step, etc. known in the art for such systems and methods for generating product system models for use in system-level simulators and implementing components and methods consistent with the intended operation and method.
[0028] Implementations of various systems and methods herein utilize product SPICE models built using performed simulations that integrate a semiconductor die with a corresponding package (semiconductor package). These product SPICE models correspond to specific products sold by semiconductor product manufacturers that circuit designers want to incorporate into specific system designs. The system being designed may be a circuit board or motherboard that uses the semiconductor product as a component, or it may be the semiconductor product for which the entire circuit board or motherboard was designed. Semiconductor products are typically sold with datasheets that contain electrical performance, electrical characteristics, and package configuration information (such as pinouts) that circuit designers need to know to properly incorporate the semiconductor product into a board design.
[0029] Circuit designers utilize system-level simulators to simulate semiconductor products as part of determining the electrical performance / characteristics of the entire system. For power semiconductor systems, system-level simulators allow circuit designers to simulate the power characteristics of the system / device under design. For power converter devices, system-level simulators allow simulation of various power converter topologies. System-level simulators take as input a product system file for a specific semiconductor product, which contains models for conduction losses, switching energy losses, and thermal impedance data. These model data are typically derived from data on the semiconductor product's datasheet, which is obtained by physically testing the as-assembled semiconductor product in laboratory equipment. A challenge with datasheet data obtained in this manner is that the loss-related data depends on the parasitic characteristics of the laboratory measurement equipment and the laboratory test circuit(s). Furthermore, laboratory-collected data is often not dense enough to ensure accurate interpolation / extrapolation of the semiconductor product. In fact, the amount of available data creates situations where significant extrapolation with insufficient data points is required by the system-level simulator. Furthermore, the limitations of the laboratory testing process affect / bias the simulation results and cannot be corrected / estimated because the only data available contains errors from all laboratory equipment. The foregoing creates a situation where over-design, under-design, or marginal design can occur simply because the circuit designer is working with inaccurate information regarding the actual performance of the semiconductor product when actually incorporated into a real system. This can result in prototype and field failures and can significantly increase the time and expense associated with developing a circuit / board design.
[0030] Another aspect of the problem that arises during laboratory measurements is that the potential unknowns created by the particular laboratory equipment or equipment used to obtain the datasheet data are one of an infinite number of possible boundary conditions that are statistically unlikely to match the particular boundary conditions of the circuit designer who designed the semiconductor product. Parasitic characteristics of the laboratory equipment (and other factors associated with temporary testing of the component) add additional variability, which reduces the likelihood that the laboratory test results will accurately reflect the actual real-world performance of the component as intended by the designer.
[0031] The product SPICE models of the semiconductor products disclosed herein are derived through modeling performed using one or both of the modeling processes disclosed in U.S. Pat. No. 1,1481,532, issued to Victory et al. on October 25, 2022, entitled "Systems and Methods for Designing a Discrete Device Product" (the '522 patent), and U.S. Pat. No. 1,1481,533, issued to Victory et al. on October 25, 2022, entitled "Systems and Methods for Designing a Module Semiconductor Product" (the '533 patent), the disclosures of each of which are incorporated herein by reference in their entireties. Accordingly, the term "product SPICE model" as used herein means the same as the corresponding "product SPICE model" used in the '532 patent and the '533 patent, respectively. These product SPICE models are the result of meaningful simulations that take into account the electrical and thermal characteristics of one or more semiconductor dies and the corresponding packages to which the one or more semiconductor dies are coupled and which are used to provide electrical and thermal connections to the circuit or motherboard to which the semiconductor product is coupled. Therefore, unlike datasheet data provided using a typical laboratory testing process, these product SPICE models, as models, do not include any of the losses / errors introduced by laboratory equipment or test circuits. Furthermore, as mathematically based models, product SPICE models have the ability to be "tested" using a much more granular / numerous amount of inputs fed into the product SPICE model, with the corresponding ability to output correspondingly more granular / numerous outputs. Furthermore, by using the product SPICE model for testing, the circuit designer can apply the designer's boundary conditions to the product and obtain system data that matches the designer's boundary conditions (without having to deal with additional unknown boundary conditions introduced through laboratory test equipment).Finally, implementations of the systems and methods disclosed herein allow designers to take into account various parasitic characteristics associated with their system's own circuitry that are not simply measurable / adjustable using typical laboratory test equipment.
[0032] Implementations of various systems and methods disclosed herein utilize product SPICE models, such as those disclosed in the '532 and '533 patents, to create product system model files that can be used by various system-level simulators used by circuit designers during circuit design. These product system model files can take the form of structured text files, plain text files, or delimited text files in various implementations. In some implementations, the product system model files can be structured text files in an xml format structured for use with the Piecewise Linear Electrical Circuit Simulation (PLECS) system-level simulator (PLECS model) commercially available from Plexim (Zurich, Switzerland). In other implementations, the product system model files can be structured text files, plain text files, or delimited text files that can be used in another system-level simulator type, such as one commercially available under the trademark PSIM by Powersim, Inc. (Rockville, MD), or any other system-level simulator.
[0033] 18 , a block diagram of an implementation of a system 100 for generating a system model for use in a system-level simulation is shown. In some implementations, the system 100 may include one or more computing platforms 102. The computing platform(s) 102 may be configured to communicate with one or more remote platforms 104 according to a client / server architecture, a peer-to-peer architecture, and / or other architectures. The remote platform(s) 104 may be configured to communicate via the computing platform(s) 102 and / or with other remote platforms according to a client / server architecture, a peer-to-peer architecture, and / or other architectures. A user may access the system 100 via the remote platform(s) 104. Examples of remote platforms 104 that may be used by a user include, as inanimate examples, a desktop computer, a server computer, a laptop computer, a smartphone, a tablet, or any other portable electronic device.
[0034] The computing platform(s) 102 may be configured with machine-readable instructions 106. The machine-readable instructions 106 may include one or more instruction modules. The instruction modules may include computer program modules. The instruction modules may include one or more of an interface generation module 108, a SPICE model simulation module 110, and a formatting module 112. The interface generation module 108 operates to generate the various computing interfaces shown in FIGS. 1-4, which are described in more detail below. The SPICE model simulation module 110 runs a series of simulations using a product SPICE model selected by a user that is stored in a database 114 containing a set of product SPICE models such as those disclosed in the '532 and '533 patents. The results of these simulations are then processed by the formatting module 112 to form a product system model file. In various implementations, the product system model file may be stored in the database 114 for retrieval by a user or others who wish to access the file.
[0035] In some implementations, the computing platform(s) 102, the remote platform(s) 104, and / or the external resources 118 may be operably linked via one or more electronic communication links. For example, such electronic communication links may be established, at least in part, via a network, such as the Internet and / or other networks. This is not intended to be limiting, and it will be understood that the scope of the present disclosure includes implementations in which the computing platform(s) 102, the remote platform(s) 104, and / or the external resources 130 may be operably linked via some other communication medium.
[0036] A given remote platform 104 may include one or more processors configured to execute computer program modules that may be configured to enable a professional or user associated with the given remote platform 104 to interface with the system 100 and / or external resources 118 and / or provide other functionality attributed to the remote platform(s) 104 herein. By way of non-limiting example, a given remote platform 104 and / or a given computing platform 102 may include one or more of a server, a desktop computer, a laptop computer, a handheld computer, a tablet computing platform, a netbook, a smartphone, a game console, and / or other computing platforms.
[0037] External resources 118 may include information sources external to system 100, external entities participating in system 100, and / or other resources. In some implementations, some or all of the functionality attributed to external resources 130 herein may be provided by resources included in system 100. As shown in FIG. 18 , computing platform(s) 102 may include electronic storage / database 114, one or more processors 116, and / or other components. Computing platform(s) 102 may include communication lines or ports that enable the exchange of information with networks and / or other computing platforms. The illustration of computing platform(s) 102 in FIG. 18 is not intended to be limiting. Computing platform(s) 102 may include multiple hardware, software, and / or firmware components that work together to provide the functionality attributed to computing platform(s) 102 herein. For example, the computing platform(s) 102 may be implemented by a cloud of computing platforms operating together as the computing platform(s) 102 .
[0038] The processor(s) 116 may be configured to provide information processing capabilities in the computing platform(s) 102. Thus, the processor(s) 116 may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other mechanisms for electronically processing information. Although the processor(s) 116 are shown in FIG. 18 as a single entity, this is for illustrative purposes only. In some implementations, the processor(s) 116 may include multiple processing units. These processing units may be physically located within the same device, or the processor(s) 116 may represent the processing functions of multiple devices acting in concert. The processor(s) 116 may be configured to execute modules 108, 110, and / or 112 and / or other modules. Processor(s) 116 may be configured to execute modules 108, 110, and / or 112 and / or other modules by software, hardware, firmware, any combination of software, hardware, and / or firmware, and / or other mechanisms for configuring processing power on processor(s) 116. As used herein, the term "module" may refer to any component or set of components that perform the functions attributed to a module. This may include one or more physical processors in execution of processor-readable instructions, processor-readable instructions, circuitry, hardware, storage media, or any other component.
[0039] 18 as being implemented within a single processing unit, it should be appreciated that in implementations in which the processor(s) 116 include multiple processing units, one or more of the modules 108, 110, and / or 112 may be implemented remotely from the other modules. The description of functionality provided by different modules 108, 110, and / or 112 described below is for illustrative purposes and is not intended to be limiting, as any of the modules 108, 110, and / or 112 may provide more or less functionality than described. For example, one or more of the modules 108, 110, and / or 112 may be eliminated, and some or all of its functionality may be provided by other of the modules 108, 110, and / or 112. As another example, the processor(s) 116 may be configured to execute one or more additional modules that may perform some or all of the functionality attributed to one of the modules 108, 110, and / or 112.
[0040] Referring to FIG. 1 , an implementation of a first interface 120 generated using the interface generation module 108 is shown. As shown, the first interface 120 allows a user to identify / select a particular product type (and associated information such as, by way of non-limiting example, product die type, product technology type, product voltage level, device type, or any combination thereof) for which a product system model file should be generated by the system. As shown, the first interface 120 includes several drop-down menus 122, 124, 126, 128 that assist the system in determining the product SPICE model(s) for which the user desires to generate a product system model file. Drop-down menu 122 allows a user to select whether the product is a discrete product or a modular product. Drop-down menu 124 allows a user to select which semiconductor process technology is associated with the desired product (in this case, silicon carbide M2 process technology, although any particular type / naming convention for semiconductor process technology may be adopted in various implementations). Drop-down menu 126 allows the user to select what voltage the product is designed to operate at, and drop-down menu 128 allows the user to select from a list of specific device(s) that meet the requirements of the first three drop-down menus. Once a specific device type (part number) is selected and the submit / save button in interface 120 is pressed, in various system implementations, the system retrieves the specific product SPICE model from database 114 and provides it to SPICE model simulation module 110.
[0041] Referring to FIG. 2 , another implementation of a second interface 130 is shown. This interface 130 allows a user to select specific process condition(s) to be used by the SPICE simulation module 110 in conjunction with the product SPICE model when running a simulation. Here, process conditions refer to the state of the manufacturing process used to create the semiconductor die(s) included in the selected device / product. As shown, the interface 130 includes a drop-down menu 132 that allows a user to select between three options: nominal process conditions (the average of the process conditions for a particular fab), worst conduction loss / best switching loss process conditions, or best conduction loss / worst switching loss process conditions. The trade-off between conduction loss and switching loss occurs because, in power semiconductor devices, increasing capacitance decreases RdsON and vice versa. Because both of these device characteristics are a direct result of the particular manufacturing process achieved by a given power semiconductor die, corner models may be used in various system and method implementations to illustrate the effects of observed worst-case and best-case processing conditions resulting from a given manufacturing facility producing a particular semiconductor die. The above are merely examples of a particular type of corner model focused on switching and conduction losses; in other implementations, corner models for any other device performance characteristics may also be used and included in drop-down menu 132 for use in the simulation. In various implementations, instead of corner models, Monte Carlo models may be used to simulate / represent the full range of semiconductor process variations for a given semiconductor die, improving the accuracy of the simulation across the full range of possible process conditions. In such implementations, the selected product SPICE model was also generated using a similar Monte Carlo method using the model generation principles disclosed in the '532 and '533 patents.In various system implementations, when the send / save button of interface 130 is selected, a specific product SPICE model corresponding to the selected process conditions (e.g., nominal) is retrieved from database 114 and provided to SPICE model simulation module 110.
[0042] Referring to FIG. 3 , an implementation of a third interface 134 is shown, designed to allow a user to input one or more system characteristics and one or more operational characteristics to be modeled by the SPICE model simulation module 110 using the product SPICE module. As shown in FIG. 3 , a system characteristic, such as the number of parallel devices within a particular selected product / device, can be entered by the user in a text box 136. The user can then input several operational characteristics for the simulation, such as, by way of non-limiting example, temperature, current, load voltage, voltage supply gate, or any other desired device / product operational parameters. In the embodiment shown in FIG. 3 , the user can input several direct current (DC) characteristics and several switching characteristics, along with temperature. As shown in FIG. 3 , user-defined ranges of values can be entered in the text boxes, such as those shown for load voltage and temperature under the switching characteristics. By being able to enter ranges of values for the simulation at a desired level of granularity, the user can create a dense space to enable accurate interpolation and minimize extrapolation by a system-level simulator utilizing the generated product system model file. In various system and method implementations, the entered system and operating characteristics are then provided to the SPICE model simulation model 110 when the user presses the send / save button in the third interface 134.
[0043] Referring to FIG. 4 , an implementation of a fourth interface 140 is shown that is used by a user to input specific circuit characteristics. These circuit characteristics may include various circuit parasitic characteristic values and other circuit values associated with a circuit diagram 142 included on the interface. The circuit diagram 142 is a schematic diagram of a circuit used to create switching loss data using a product SPICE model selected by the user. By being able to select circuit parasitic characteristics, the user can ensure that the switching loss values in the resulting product system model file are accurate as desired for the designer's end system application. An example circuit schematic 146 with components associated with values in the data table 144 of FIG. 4 is shown in FIG. 9 . In various implementations, specific parasitic characteristics of interest, such as those shown in FIG. 9 and data table 144, may be included, while in other implementations, any of the parasitic characteristics shown in FIG. 4 may be included / substituted for other parasitic characteristics.
[0044] As a non-limiting example, the R and R parasitic characteristics can have a typical range between 0 and approximately 20 ohms and represent gate resistance, which modulates the speed of the device turn-on / off process, affecting switching loss(es). The gate inductance (LG) can have a value between approximately 1 and approximately 50 nanohenries and acts as a parasitic characteristic that affects the V waveform, causing an overshoot at the plateau voltage during turn-on (the inductance acts as a current source), aiding turn-on speed and correspondingly reducing turn-on loss(es). Another parasitic characteristic can include the gate loop inductance (Lgateloop), which can have a value between approximately 1 and 50 nanohenries. The gate loop inductance may not significantly affect losses during turn-off, but acts to increase Tdoff (turn-off delay). In extreme cases, this inductance can cause a slow V waveform and high loss(es). Additionally, inductance within the gate can cause oscillation with the gate of another device(s), resulting in additional corresponding ringing losses. The source inductance (LS) may have a value between about 1 and about 20 nanohenries and may cause losses by lowering Eon due to the voltage drop caused by the inductance during positive di / dt and increasing Eoff due to voltage overshoot for negative di / dt. This inductance may also slow down the di / dt of the drain current, which affects the loss(es) in the circuit. Another parasitic characteristic that may be included / accounted for is loop inductance, which may have a range of values between about 10 and about 200 nanohenries. Any of a wide variety of other commonly occurring and / or circuit-specific parasitic characteristics may be included in the fourth interface 140 to allow the user to input a value(s) and / or a range of values for use during the simulation process. In various system and method implementations, values of the various circuit characteristics are provided to the SPICE model simulation module 110 when the user presses the send button on the fourth interface 140.In various system and method implementations, this also represents the point in the method when the SPICE model simulation model 110 uses all provided inputs and product SPICE models to generate the SPICE model output, which is then formatted by the formatting module 112 into the desired file format.
[0045] 5 and 6, diagrams of first and second portions of a system model file containing a structured text file formatted in the PLECS format are shown. In this implementation, the structured text file is in the form of xml. FIG. 5 shows related data of Eon versus Rg across a set of y-axis dimension values, which can be plotted into a curve to allow a designer to observe system behavior across product package dimensions. FIG. 6 shows a set of voltage values for each of a set of different temperature values. This ability to simulate voltage responses for each of a set of different temperature values can be invaluable for designed circuits that need to understand the heat dissipation needs for a given product across different temperature levels. FIGS. 7 and 8 show the output of a plain text file or comma-separated text file being viewed using a spreadsheet program commercially available under the name EXCEL® by Microsoft Corporation of Redmond, Washington. However, in some implementations, via a script as described, the formatting module 112 can directly output the file in .xlsx format or any other desired structured file format. Figure 7 shows the temperature dependent Eoff, Eon, and Err at each of four possible operating temperatures, as well as a set of diode voltages (ID). Figure 8 shows the DC characteristics of a MOSFET at a set of IDs and a set of temperatures, showing the effect of temperature on RDSon. These modeled data points in a product system model file implementation are then used by a system-level simulator to allow a circuit designer to evaluate whether a device will work in a given circuit design and / or how to best integrate it thermally and / or electrically.
[0046] Figure 10 shows various on-state currents (i on), showing the output of a system-level simulator showing a surface where energy E is graphed against Vblock. All data in this output is derived from a PLECS-formatted product system model file and is the result of either direct data value plotting or interpolation / extrapolation by the system-level simulator. Figures 11-17 are similar two-dimensional outputs from a system-level simulator using a PLECS-formatted product system model file. Figure 11 shows a graph of Eoff versus diode current, ID, for a set of different temperatures at different diode voltages. Figure 12 is a graph of Eoff versus gate resistance (RG) for a set of diode current, ID. Figure 13 is a graph of Eon versus diode current (ID) over a range of temperatures at different diode voltages (VD). Figure 14 is a graph of Eon versus gate resistance, RG, for a set of diode current values, ID. Figure 15 is a graph of Err versus diode current, ID, for a set of temperature values and diode voltage, VD. Figure 16 is a graph of Vdson for a set of diode current, ID, for four different temperatures. Figure 17 is a graph of Vsd versus diode current, ID, for four different temperatures. These graphs demonstrate the significant degree of data granularity available to a system-level simulator for these calculations from a product system model file generated using an implementation of the systems and methods disclosed herein. This type of data granularity is generally not available using laboratory techniques, nor is it available with the same degree of accuracy. Furthermore, the ability to input and adjust parasitic values can help circuit designers understand the sensitivity of their products to parasitic characteristics. In various products, the impact of some parasitic characteristics can be better or worse depending on the type of parasitic characteristic. To help observe the impact of parasitic characteristics, modeling can also be performed to sacrifice some performance parameters. For example, some Eoff can be sacrificed in order to gain a better Eon to understand the impact of the parasitic characteristics.
[0047] The SPICE model simulation module 110 operates using system and operating characteristics in various ways to generate each of the desired performance characteristics contained in the product system model file. For example, using a defined current value, the module 110 sweeps the current at a given VGS value and measures the resulting IV to obtain the conduction loss of the MOSFET diode. In various module implementations, a double-pulse simulation can be used to obtain energy loss using the product SPICE model. In various system implementations, conduction loss / energy is calculated using an IV sweep with the product SPICE model. The SPICE model simulation module 110 can work with the product SPICE model so that simulations can be performed under ideal conditions without interference from the parasitic characteristics of laboratory equipment.
[0048] The ability to input circuit parasitics and characteristics into the SPICE model simulation module 110 further enables the establishment of boundary conditions for each simulation, where the parasitic characteristics are boundary conditions. However, in the case of IV sweeps used to test switching characteristics, the parasitic characteristic input may not be used. Because the product SPICE model implementation used with the SPICE model simulation module 110 may also include a thermal model, the SPICE model simulation module 110 may include a thermal impedance network, such as a Cauer or Foster network, in the product system model file. This may be done in various implementations by the SPICE model simulation module 110 extracting the thermal model and adding it to the product system model file. However, in various system and method implementations, additional thermal characteristics may be added to enable modeling using corner thermal models and Cauer or Foster networks that are used by the module to perform additional thermal modeling for inclusion in the product system model file. These corner thermal models may include typical operating cases or worst-case cases (high temperature, low temperature, or both). In such implementations, in addition to the circuit diagram, different representations of the specific thermal network that may be used may be selectable by the user. The product system model file generated by the SPICE model simulation module 110 is a component-level model valid for use in system-level simulation, but is not actually a SPICE model itself, but rather a table model containing the performance data necessary for a system-level simulator to use it for its simulation operations.
[0049] In various system implementations, the SPICE model output of the SPICE model simulation module 110 requires additional formatting to be organized into a desired format for the product system model file. Various implementations of the formatting module 112 may utilize scripts and other programs to automatically perform the data rearrangement. In various implementations, the scripts may be Python language scripts. Following the desired formatting and formation of the product system model file by the formatting module 112, the resulting product system model file may be made available for immediate download to a user via a user interface and / or stored in the database 114 for later download / access by the user or another user who desires to use the file. In various implementations, the product system model file may be made available by a semiconductor device manufacturer along with a data sheet for each specific product being manufactured.
[0050] Various system implementations disclosed herein may utilize various implementations of a method for generating a product system model for use in a system-level simulation. Referring to FIG. 19 , a flow diagram of a method implementation is shown. As shown, method 148 may include receiving a selection of a product type from a user using a first interface generated by a computing device (step 150) and selecting, using a processor, a product SPICE model associated with the product type from a database of product SPICE models (step 152). The database may be any database disclosed herein, and the computing device may be any computing device implementation disclosed herein. The method also includes receiving a selection of process conditions from the user using a second interface generated by the computing device (step 154) and receiving one or more system characteristics and one or more operating characteristics from the user using a third interface generated by the computing device (step 156). The process conditions, one or more system characteristics, and one or more operating characteristics may be any of those disclosed herein. The method also includes receiving one or more circuit characteristics from a user using a fourth interface generated by the computing device (step 158), which may be any of the circuit characteristics, including parasitic characteristics, disclosed herein. The method also includes generating a SPICE model output using the product SPICE module, process conditions, one or more system characteristics, one or more operational characteristics, and one or more circuit characteristics (step 160), using the processor and a SPICE simulation module. The SPICE simulation module may be any of those disclosed herein, and the method of simulation performed may be any of those disclosed herein.The method also includes formatting, using a processor and a formatting module, the SPICE model output into a product system model file, which may be a structured text file, a plain text file, or a delimited text file such as any of those disclosed herein. A wide variety of method implementations may be constructed using the principles disclosed herein.
[0051] The various semiconductor devices in which implementations of the disclosed systems and methods may be employed may be any of a wide variety of device types, including, by way of non-limiting example, metal oxide semiconductor field effect transistors (MOSFETs), insulated gate bipolar transistors (IGBITs), diodes, power semiconductor devices, silicon controlled rectifiers, transistors, or any other semiconductor device type. Additionally, the various product types may include a single die, two dies, or multiple dies contained in a module. Those skilled in the art will readily understand how to adapt the principles disclosed herein to various semiconductor die or device types.
[0052] Where the above description refers to particular implementations and implementation components, sub-components, methods, and sub-methods of systems and methods for generating product system models for use in system-level simulators, it will be readily apparent that certain modifications may be made without departing from the spirit thereof and that these implementations, implementation components, sub-components, methods, and sub-methods may be applied to systems and methods for generating product system models for use in other system-level simulators.
Claims
1. 1. A method for generating a product system model for use in a system-level simulation, comprising: receiving a product type selection from a user using a first interface (120) generated by the computing device; selecting, using a processor (116), a product SPICE model associated with the product type from a database of product SPICE models; receiving a selection of process conditions from the user using a second interface (130) generated by the computing device; receiving one or more system characteristics and one or more operational characteristics from the user using a third interface (134) generated by the computing device; receiving one or more circuit characteristics from the user using a fourth interface (140) generated by the computing device; generating a SPICE model output using the product SPICE model, the process conditions, the one or more system characteristics, the one or more operational characteristics, and the one or more circuit characteristics using the processor (116) and a SPICE model simulation module (110); and formatting the SPICE model output into a product system model file using the processor (116) and a formatting module (112), wherein the product system model file comprises one of a structured text file, a plain text file, or a delimited text file.
2. The method of claim 1 , wherein the product system model file is configured to be used to perform a system-level simulation of a system that includes the product type.
3. 10. The method of claim 1, wherein receiving the selection of the product type from the user further comprises receiving a selection of one of a product die type, a product technology type, a product voltage level, a device type, and any combination thereof.
4. 2. The method of claim 1, wherein receiving the selection of the process conditions from the user further comprises receiving a selection of one of nominal conditions, worst case conduction losses / best case switching losses, or best case conduction losses / worst case switching losses.
5. The method of claim 1 , wherein the one or more system characteristics include one of a number of devices and one or more temperatures.
6. 10. The method of claim 1, wherein the one or more operating characteristics further comprise one of at least one DC characteristic, at least one switching characteristic, at least one gate threshold voltage, or any combination thereof.
7. The method of claim 1 , wherein the one or more circuit characteristics further comprise one of a gate resistance, a gate inductance, a gate loop inductance, a source inductance, a loop inductance, a diode voltage, and any combination thereof.
8. The method of claim 1 , wherein the fourth interface (140) further comprises a circuit diagram (142).
9. The method of claim 1 , wherein the product system model file is a structured text file configured for use by a piecewise linear electrical circuit simulation system.
10. The method of claim 1 , wherein the product type comprises a discrete power semiconductor die.
11. 1. A system for generating a system model for use in a system-level simulation, the system comprising: A system comprising one or more hardware processors (116), the hardware processors (116) receiving a product type selection from a user using a first interface (120) generated by the computing device; selecting a product SPICE model associated with the product type from a database (114) of product SPICE models; receiving a selection of process conditions from the user using a second interface (130) generated by the computing device; receiving one or more system characteristics and one or more operational characteristics from the user using a third interface (134) generated by the computing device; receiving one or more circuit characteristics from the user using a fourth interface (140) generated by the computing device; generating a SPICE model output using the product SPICE model, the process conditions, the one or more system characteristics, the one or more operational characteristics, and the one or more circuit characteristics using a SPICE model simulation module; 1. A system configured with machine-readable instructions (106) to format, using a formatting module (112), the SPICE model output into a product system model file, the product system model file comprising one of a structured text file, a plain text file, or a delimited text file.
12. The system of claim 11 , wherein the product system model file is configured to be used to perform a system-level simulation of a system that includes the product type.
13. 12. The system of claim 11, wherein the selection of the product type further comprises selecting one of a product die type, a product technology type, a product voltage level, a device type, and any combination thereof.
14. The system of claim 11 , wherein the selection of the process conditions further comprises selecting nominal conditions, worst case conduction losses / best case switching losses, or best case conduction losses / worst case switching losses.
15. The system of claim 11 , wherein the one or more system characteristics include one of a number of devices and one or more temperatures.
16. 12. The system of claim 11, wherein the one or more operating characteristics further comprise one of at least one DC characteristic, at least one switching characteristic, at least one gate threshold voltage, or any combination thereof.
17. 12. The system of claim 11, wherein the one or more circuit characteristics further comprise one of a gate resistance, a gate inductance, a gate loop inductance, a source inductance, a loop inductance, a diode voltage, and any combination thereof.
18. The system of claim 11 , wherein the fourth interface (140) further comprises a circuit diagram (142).
19. The system of claim 11 , wherein the product system model file is a structured text file configured for use by a piecewise linear electrical circuit simulation system.
20. The system of claim 11 , wherein the product type comprises a discrete power semiconductor die.