|
|
|
| Newsletter List | |
|
|
|
|
|
Intusoft's latest 8.x.11 Build 3090 for the ICAP/4 and Test Designer products is mature and feature-rich. In this release numerous improvements have been implemented that further the software's ease of use, notably in the more advance applications. Two popular new features are: (1) the ability to export waveforms in a tab-delimited file that can easily be used in other programs such as Microsoft excel, and (2) a Pspice-to-IsSpice4 model converter. Further, Build 3090 is compatible with Windows Vista and 64-bit Windows operating systems. A detailed features list for Build 3090 can be found at: http://www.intusoft.com/featurechanges.htm. |
|
||||||||||||||
ICAP/4Windows and higher offerings have always been attractive due to valuable features like interactive parameter modification, and advance multi-run analysis like Monte Carlo, Sensitivity, Optimize, EVA, WCS, RSS, GFT, nested parametric sweeping and fault simulation. Build 3090 adds to only these packages the new Pspice-to-IsSpice4 Converter, and an improved automated part-database management system (Library Manager). If you are an existing ICAP/4Rx or Consumer user and frequently add or modify parts from different sources, then you'll want to upgrade to a ICAP/4Windows or higher offering. You can upgrade at anytime by only paying the price difference. Please read the rest of the newsletter to decide if it is time for you to upgrade to a higher offering and the latest Build 3090. You won’t be disappointed. |
|||||||||||||||
|
|
|
Many SPICE models are available in Pspice format. The majority of the analog syntax for both IsSpice4 and Pspice is exactly the same, but there are a few small differences that would make the Pspice model inoperable in IsSpice4 until it was translated to proper syntax. A manual conversion could be done, but this would take time and is error prone. Intusoft has created a Pspice-to-IsSpice4 Converter that instantly changes the analog Pspice netlist into a format used by IsSpice4. Simply open the Pspice netlist file in IsEd, or paste it in a blank IsEd window. From the edit menu select "Convert Pspice to IsSpice" or press the <Ctrl>+I hotkey. Another window will come to view with the netlist converted to IsSpice4 syntax. Note that the converter works on analog parts only. No Pspice digital parts will be translated.
Everything in the selected file will be converted at once. You can also have a file with multiple models. To be compatible with SPICE model library files (.LIB) and simulation netlist files (.CIR), the first line of the file is always ignored and treated as a comment line. If you want a quick one-line conversions then remember that the first line will not be evaluated for conversion.
|
|
If you have a SPICE part in IsSpice4 compatible format then you can easily import the part and add it to the part browser. Highlight the individual part you want to import and copy it to your clipboard. In SpiceNet's File menu select "Import Spice Model" and press the "From clipboard" button. If the model name on the .subckt line does NOT already exist in the part database, the New Model dialog will come to view. The unique model name will be shown in the bottom right field under "Enter the new model name." By default the "From_Import.lib" file will be selected, but you can specify your own library file. Note that all user added parts are placed in the <ICAPSdir>\pr\mylib folder to keep user parts separate from Intusoft parts. If the part already exists in the part database, Library Manager is immediately brought to view with a character by character diff of an existing part and imported part. If you don’t want the existing part in the part database replaced with your imported model, then exit Library Manager without saving changes, and re-import the part again with a slightly different name on the .subckt line. Every fourth asterisk in a row has been automatically replaced with a space. This prevents the problem of imported parts with comment boxes made up of asterisks from being split into pieces. If a line starts with an asterisk and has 5 asterisks in a row, we know that the beginning or end of the part has been reached. Even if you only have one part in a library, you need a top and bottom row of asterisks part delimiter.
If you bring up the hierarchical Graphical Parts Browser you will find the recently imported part under PartType then SubType. You will want to move your part so it is under one of the existing categories. Use the Edit Fields buttons at the top left corner of the Library Manager dialog to change the text shown in the part browser. If the text is the same as an existing category then it will be placed in that category. Further, instead of using a generic box symbol, a more appropriate existing symbol can be used. First select a similar existing part in the part browser and look at the symbol name shown at the end of the SymLib: line, located at the bottom of the part browser. Then in the Library Manager click the "symbol" button and type the existing symbol name. Changing the *SRC= or *SYM= line will flag Library Manager to ask if want to perform an "update part database" when you try to close the dialog. This is necessary so your changes will ultimately be found in the part browser. If Library Manager launches Makedb, it will automatically close the part browser and re-open it with the new updated part database after it is done compiling. If the vendor who provided this part revises it, you can then re-import the part. Your modified *SRC= and *SYM= lines will not be changed. You will see a character by character diff and know exactly what was changed between revisions. |
|||||||||||||||||||
| Prepare a schematic circuit configuration with only the circuitry that you want to include in the subcircuit. This means you must create a special configuration with the test circuitry and stimulus sources removed. You can use wires, test points or continuation symbols on the nodes that are unconnected. Unconnected nodes are shown as red diamonds. All unconnected parts must have their pins resolved with node numbers or names shown. If you want to pass parameters into your subcircuit then you need to copy your passed parameters to the parameters dialog for the configuration that you plan to export. These passed parameters will be added to the .subckt line for you. Select Make Subdrawing from the Subdrawings drop-down menu. The Subdrawing will be given a name that is the same name as the current configuration. You may change it in the Subdrawing Name: field if you want your part to have a different name. Click on the node from the list of nodes in the dialog that you want to expose from inside of the subcircuit (external connection that will be on the .SUBCKT line). Click the Add button to add the selected node to the list of subcircuit pins. Repeat this operation for each node you want to expose. You may arrange the node order using the Move Up/Move Down buttons. You can also assign the pins to be hidden. You will then be able to make connections to the hidden pins by using a continuation symbol with the same name as the hidden pin. The hidden pin name is assigned inside of the Parts Properties dialog. If you use the symbol wizard to create your own symbol then remember to save your symbol before you click on the Finish Subdrawing button at the bottom left of the symbol editor. Also don’t add the symbol to an existing symbol that Intusoft provides or it will be overwritten when you update the software. We have created a special folder to contain user-generated symbols: (C:\spice8\sn\mysym). If you save your symbol to ..\sn\mysym\mysym.sym then you won’t have to do anything. If you save the symbol to a different symbol file then modify the c:\spice8\sn\sym.@@@ file to include the path to your new symbol file.
From the SpiceNet file drop-down menu select Export. Choose "subckt" in the drop-down list and press OK. By default, the From_Icaps.lib file will be selected, but you can specify your own library file. After makedb is done, Library Manager will come up ready for you to modify the *SRC= and *SYM= lines. If you revise your schematic then re-export your SubCkt. The subdrawing step is only needed to decide which nodes in your circuit to expose on the symbol. Your modified *SRC= and *SYM= lines will not be changed by re-exporting your SubCkt. |
|||||||||||||||||||
The advance analysis that use tolerance/sweep/optimize tab have been made easier to setup, and we have moved the active/disabled state from the part level to individual parameters for each part.
The sweep output file has been made more organized. Outer and Inner loop device parameter values are listed in association with any user-prescribed measurements, including the plot name associated with each value. For Extreme Value Analysis, Device tolerances are railed to their maximum or minimum value, based on the sign of an initial sensitivity analysis, such that the result at any measured device or node specified by the user is maximized. A successive simulation is then run with the device's tolerance engaged in a maximum positive or negative direction. This former EVA routine is now called EVA_HI. A new EVA_LO routine similarly performs the above tasks, but device tolerances are railed to their extreme value based on the sensitivity analysis's minimizing the measured result of specified devices or nodes. In Worst Case Analysis by Sensitivity, a reference simulation is first run on the design and a plot of the data is stored to save the simulation results, notably at nodes or devices specified by the user (i.e., Vout, iR2, etc.). Then a new simulation is run for each device containing tolerance parameters, perturbing the parameter by a small fraction. The difference between these two sets of measurements is saved. The absolute value of operations performed on the difference measurements are summed (for the WCS_HI analysis) or subtracted (for the new WCS_LO analysis), and saved in the IsSpice4 output file for viewing, and in a format that can be read back into the "Results" dialog accessed from SpiceNet's "Simulation Control" dialog. |
|||||||||||||||||||
|
Introduction Through the decades the design automation industry has touted accurate simulation of electronic products from concept to production readiness. SPICE simulation for analog and mixed-signal circuitry has been no exception, including its unique ability to mold designs for production compliance. Analyses like Monte Carlo and worst-case simulation mimic variations in real-world component tolerances on a design, so it can be tweaked for acceptable performance. Such variation is valuable because it cannot otherwise be performed with a lab prototype board or production unit. But establishing good design margins is not the only factor that helps ensure a product's performance merit. What happens when a part goes sour in the field, such as a short, open or stuck-at value, or if a power supply faults? What effect could this have on a product's end use? The product designer should be privy to end-use risk (i.e., security monitor, backup power system, automobile ABS), but the cause and effect of failed parts is something that's best scrutinized early in the design process, not in the field. Historically, digital simulators have provided fault diagnosis to analyze the outcome of component failures, viewing the effects that faulty devices inflict on critical design signals. Today, such automated capability is also available for analog-based design (and with mixed digital) by way of Intusoft's automated fault simulation. Traditionally without this capability, a designer had to employ any number of tricks to painstakingly insert circuit faults. A super-high resistance value (i.e., 1G ohm) could be inserted as an open condition, or a wire might be inserted in place of a component to impose a short. A certain value might be temporarily assigned to a transistor's temperature coefficient to force "stuck at" condition, or an "open" from base to emitter. Manually inducing thorough fault coverage in this fashion could take days-to-weeks to setup and simulate, including the need to track an immense amount of alteration to the design database. Automated fault coverage on the other hand spares the designer from this lengthy and impractical task. In short it provides a convenient means of first assigning pass/fail limits to components' electrical properties (i.e., max power, RMS voltage, transistor collector current, rise time, propagation delay, etc.). Signal variation limits are similarly prescribed for desired lines. Then, shorts, opens and "stuck at" values are assigned to passive and active devices, as well as faulty levels for device temperature and power supply sources. After enabling any number of these conditions, fault simulation is run. Resulting electrical measurements are automatically recorded for desired components and signals lines, including readouts that chart numerical data and pass/fail results. Fault Simulation Setup and Implementation You prepare a fault simulation (in time or frequency domain) by assigning fault conditions to any device (Figure 7). A type of fault can be prescribed in a "failure mode" dialog box for a part (or optionally all "like parts"), as well as power sources and device temperature. Next, Figure 8 illustrates a one-fault setup for a UC1524 advanced regulating PWM controller circuit. Using the mouse, L1 is enabled as "shorted" amongst a vast collection of other possible faults that were assigned throughout the design. The engineer also selects which electrical properties of the design to monitor during a fault run. Several signals and devices were selected in Figure 9 for monitoring their "initial value" post a fault simulation. A variety of other selectable measurements are provided in the list. The fault run (time domain) was prescribed over a 1-millisecond period. Figure 10 illustrates the resulting measured "initial value" readings, including pass/fail. However, min/max est limits have not yet been assigned.
Figure 11 displays multiple faults enabled for simulation. Note that three new faults were added (R7 stuck at 1K ohms, R3 short and source V1 stuck at 4.9v). Post simulation results are shown in Figure 12.
The top five fault selections in Figure 12's list are enabled (corresponding labels put in bold text on the schematic). After simulation, these faults can be randomly selected from the "Variation" menu as shown, to quickly view corresponding changes in the measured readouts on the left. Figure 13 provides a breakout of the "initial value" devices and signals on the left, showing the measured data (right) that the four enabled faults produced for the selected signal V(18). All of these features provide a fast "what-if" analysis of how faults affect critical devices and signal lines. Also shown are thumbnail simulation waveforms that display in real time during fault runs, with V(18) in the low left corner. Establishing Design Test Limits Establishing electrical test limits for devices and signal lines can be achieved in a number of ways. One method of course is to assign them per the designer's discretion. Other ways make use of acceptance criteria from product specifications and component datasheet ratings (i.e., device maximum power). For limits on signal lines, a designer can also run a Monte Carlo statistical analysis, which randomly varies component parameters through their tolerance range, then examines variation on signal lines. Once the circuitry is tweaked enough where variations are acceptable, the range can be used to establish pass/fail signal limits for fault simulation. Such limits are prescribed within the "Set Limits" dialog box for convenience. For example, the (left dialog) in Figure 14 provides a number of ways to open the min/max test limits to accept all measured readings under the present fault at hand (i.e., Q1 open). Sigma limits could have been selected if a previous Monte Carlo run was administered. The "Expand to Pass" option was chosen. Corresponding colored histograms to the right reflect the new "passed" measurements (green). This is useful for quickly studying test limit compliance with successively selected faults, that is, seeing how other faults' measured results comply with the relaxed test limits. For example, when the "R7 stuck" fault was next selected (Figure 15), some of the histograms changed color (failed) despite the new "expand to pass" test limits from Q1 open. Corresponding measured data is also shown. Conclusion Knowing how a design will operate under faulty conditions can be examined early in a product’s design-simulation phase. Historically SPICE tools have provided powerful ways of varying component tolerances and temperature to study signal variation for manufacturing compliance. This method and other means can also be used to establish pass/fail criteria for acceptable operation under fault conditions. In the end, design safeguards can be incorporated early in the design cycle to help eliminate possible damage from faults encountered in production and in the field.
|
