+A model in spice is really two things: +
+The former, the code, is typically provided as part of the simulator software, +at least for the most common, basic component types. The latter, model +parameters, is specified by the user (normally acquired from the device +vendor or constructed from the datasheet or measurements). + +
+Concrete symbols are compile into abstract components; export_spice will +write a spice instance line for each named component in the abstract model. +Anything more complicated than passives and sources will need to have +a spice model named in the instance line. +
+There are different strategies how this spice model name is generated. + +
+If the symbol has a spice/model attribute, the value of this attribute is +a model name. In sch-rnd reusable spice models are kept in the spice +library, which is very much like the symbol or devmap library: a +directory tree that holds spice models, one model per file, models +identified by file name. Spice export files are self-contained and +do not rely on external model files. This is achieved by sch-rnd +copying the content of these spice model files from the library into +the output file. +
+Furthermore there's a sheet-local library, just like with devmap (and +optionally with symbols), so any spice model used by the sheet is also saved +in the sheet so the sheet is self-contained (and portable) too. +
+Note: the model is copied only once (per unique model name) into the +sheet-local spice lib and to the spice netlist export. +
+If spice/model_card is specifed, that overrides spice/model (so spice/model +is ignored in that case). + + +
+Also called inline spice-card. The whole spice model is specified as a +multiline string in the symbol attribute called spice/model_card. The model +is named with an unique name and copied in the output spice netlist. +
+On the output spice netlist the model is created as many times as specified +in different symbols. +
+If specified, overrides spice/model_card. + + +
+The above two resulted in both self-contained sheets and self-contained +spice netlist exports. That is, if the sheet is shared, a different user +on a different system could export the same spice netlist, without assuming +any spice model library installed. If the exported spice netlist is shared, +it can be ran through a spice implementation without depending on any +external file (model library). The advantage of this is clearly portability, +while the drawback is larger files and files that need update if the model +is changed (fixed) in the spice lib. +
+A non-self-contained method is specifying the following two +attributes for a symbol, without specifying spice/model_card or +spice/model: +
+Once the exported file is ran through a spice implementation, the spice +software will employ its own search method for each .INCLUDE and load +the referenced spice lib file from wherever. +
+This is the weakest method, if spice/model or spice/model_card is specified, +that may modify spice/model_card_uname and will write a model into the +output file. \ No newline at end of file Index: trunk/doc/user/07_io/export_spice/raw.html =================================================================== --- trunk/doc/user/07_io/export_spice/raw.html (revision 7856) +++ trunk/doc/user/07_io/export_spice/raw.html (revision 7857) @@ -46,7 +46,8 @@ (and no X prefixing is performed). The model is searched in the lib with exact file name, with .mod and with .prm appended, all case sensitive. - +
+ See also: model options.
+ See also: model options.
+ See also: model options.
+ See also: model options.