kicad-developers team mailing list archive

[Maciej Sumiński <maciej.suminski@xxxxxxx>]

It still loads the original configuration files (when possible) and
afterwards it checks a few extra locations (relative to the executed
binary path). This gives a chance to package maintainers to provide a
proper spinit file. If it fails to find a custom spinit file, but it
detects a path to codemodel libraries correctly, it will just load them.

Regards,
Orson

On 10/13/2016 04:08 PM, Wayne Stambaugh wrote:
> Does this patch override the users configuration or does it just solve
> the default configuration issue on windows and osx?  If so, that's not a
> good thing.  I'm fine if respects the users config.  I still stand by my
> original investigation that this is a package configuration issue, not a
> broken code issue but if no one is willing to resolve those issues and
> your patch respects the user config, then I'm OK with it.
> 
> On 10/13/2016 9:49 AM, Maciej Sumiński wrote:
>> Finally, I could get back to the issue. If we really focus about the
>> consequences, the real problem is not that spinit is not processed, but
>> the codemodel libraries are not loaded.
>>
>> Looking at the default spinit file:
>> - most of the lines are comments
>> - one causes problems ('set interactive', has to be unset later)
>> - three others have no special meaning in shared library mode (aliases
>> and 'set x11lineararcs')
>> - the only meaningful lines are the ones that load codemodel libraries
>>
>> To fix the problem, there is a patch which:
>> - Allows ngspice to load the default spinit/.spiceinit files (no changes
>> here).
>>
>> - Looks for codemodel files in a few paths relative to eeschema
>> executable. If a valid path is found, then an ngspice variable __CMPATH
>> is set.
>>
>> - After the default initialization, looks for spiceinit (note it is
>> spiceinit not .spiceinit) file in a few paths relative to eeschema
>> executable. If one is found, then it is executed. If we decide to
>> provide our spiceinit file (see the attachment), then thanks to __CMPATH
>> variable we can point to the right codemodel directory.
>>
>> - If no spiceinit was found, but we know the correct path to codemodels,
>> then they are simply loaded.
>>
>> - Unsets a few variables which may cause simulator hangups.
>>
>> Once the patch is committed, codemodels should work out of the box for
>> the common msys2 builds and nightly Windows installers, even without a
>> custom spiceinit. If OSX bundles provide codemodel libraries, then there
>> is a chance it will work for them as well, otherwise we can add another
>> search path.
>>
>> I know it may look like an ugly hack, but sincerely I have no better
>> idea at the moment. I am going to leave it here for comments for a few
>> days, if there are no objections, I will commit the changes.
>>
>> Regards,
>> Orson
>>
>> On 10/06/2016 05:53 PM, Wayne Stambaugh wrote:
>>> I have some additional information that may prove useful:
>>>
>>> 1) Using relative paths in the spinit file does not work on windows.
>>>
>>> 2) Placing a spinit file in the path where the ngspice and libngspice
>>> binaries reside works with no need to set any environment variables.
>>>
>>> Option 2 could be used by the installer.  The installer itself would
>>> have to create the spinit file by substituting the install path for the
>>> path of the .cm files.  I'm not sure if this would work on osx.  Maybe
>>> one of our osx devs could test this.  If it does, than that would
>>> resolve the simulation init issues.
>>>
>>> I've attached a simple circuit that demonstrates the issue.  When the
>>> .cm files are not located, the simulation will run with the following
>>> warnings and cause the output of the op-amp to be an impossibly high 260V:
>>>
>>> Error on line 0 :
>>> a$poly$e.xu1.eos %vd [ xu1.53 xu1.98 ] %vd ( xu1.3 net-_u1-pad1_ )
>>> a$poly$e.xu1.eos
>>> MIF-ERROR - unable to find definition of model a$poly$e.xu1.eos
>>> Warning: Model issue on line 0 :
>>> .model a$poly$e.xu1.eos spice2poly coef = [ 1.7e-3 1 ] ...
>>> Unknown model type spice2poly - ignored
>>> Error on line 0 :
>>> a$poly$e.xu1.eref1 %vd [ vdd 0 0 0 ] %vd ( xu1.98 0 ) a$poly$e.xu1.eref1
>>> MIF-ERROR - unable to find definition of model a$poly$e.xu1.eref1
>>> Warning: Model issue on line 0 :
>>> .model a$poly$e.xu1.eref1 spice2poly coef = [ 0 0.5 0.5 ] ...
>>> Unknown model type spice2poly - ignored
>>> Error on line 0 :
>>> a$poly$e.xu1.eref2 %vd [ net-_u1-pad1_ 0 /out 0 ] %vd ( xu1.97 0 )
>>> a$poly$e.xu1.eref2
>>> MIF-ERROR - unable to find definition of model a$poly$e.xu1.eref2
>>> Warning: Model issue on line 0 :
>>> .model a$poly$e.xu1.eref2 spice2poly coef = [ 0 0.5 0.5 ] ...
>>> Unknown model type spice2poly - ignored
>>> Error on line 0 :
>>> a$poly$e.xu1.eo3 %vd [ xu1.98 xu1.30 ] %vd ( vdd xu1.42 ) a$poly$e.xu1.eo3
>>> MIF-ERROR - unable to find definition of model a$poly$e.xu1.eo3
>>> Warning: Model issue on line 0 :
>>> .model a$poly$e.xu1.eo3 spice2poly coef = [ 0.7175 0.5 ] ...
>>> Unknown model type spice2poly - ignored
>>> Error on line 0 :
>>> a$poly$e.xu1.eo4 %vd [ xu1.30 xu1.98 ] %vd ( xu1.44 0 ) a$poly$e.xu1.eo4
>>> MIF-ERROR - unable to find definition of model a$poly$e.xu1.eo4
>>> Warning: Model issue on line 0 :
>>> .model a$poly$e.xu1.eo4 spice2poly coef = [ 0.7355 0.5 ] ...
>>> Unknown model type spice2poly - ignored
>>> Reducing trtol to 1 for xspice 'A' devices
>>> Doing analysis at TEMP = 27.000000 and TNOM = 27.000000
>>> Warning: vv3: no DC value, transient time 0 value used
>>>
>>> Let me know if you have any other questions or comments.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 10/6/2016 10:56 AM, Nick Østergaard wrote:
>>>> Hi Maciej
>>>>
>>>> In the latest nightlies they are now stored in lib/ngspice/
>>>>
>>>> I guess that should equate to a relative path to the executables to
>>>> ../lib/ngspice/*.cm, given that the exe's are in the bin folder on the
>>>> same level as lib.
>>>>
>>>> So feel free to submit your fix. Also, are there any demos that make
>>>> use of those cm libs such that it can be tested?
>>>>
>>>> Nick
>>>>
>>>> 2016-10-05 23:16 GMT+02:00 Maciej Sumiński <maciej.suminski@xxxxxxx>:
>>>>> Hi Nick,
>>>>>
>>>>> Are the .cm files included in the Windows nightlies installer? If so,
>>>>> could you tell me what is the relative path to the directory storing
>>>>> them? The easiest way to fix the problem is to send a few commands to
>>>>> ngspice before a simulation starts.
>>>>>
>>>>> Regards,
>>>>> Orson
>>>>>
>>>>> On 10/05/2016 10:23 PM, Nick Østergaard wrote:
>>>>>> Is this really needed?  What exactly does the .cm files provide?
>>>>>>
>>>>>> When I run the latest nightly I can run the allen key demo without
>>>>>> problems as far as I can see.  Maybe some other simulation modes do
>>>>>> not work properly?
>>>>>>
>>>>>> 2016-09-30 14:37 GMT+02:00 Wayne Stambaugh <stambaughw@xxxxxxxxx>:
>>>>>>> That would work as a long term solution as well.  I was trying to at
>>>>>>> least prove that it can be done without make changes to the current
>>>>>>> code.   Until a full solution is implemented, users (me) will have an
>>>>>>> interim solution if they want to use the spice simulator.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Wayne
>>>>>>>
>>>>>>> On 9/30/2016 3:40 AM, Maciej Sumiński wrote:
>>>>>>>> We have also discussed on IRC another possibility, which is loading the
>>>>>>>> extensions manually instead of having ngspice process its initialization
>>>>>>>> file (spinit). This way we can adjust the paths during runtime.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Orson
>>>>>>>>
>>>>>>>> On 09/29/2016 08:51 PM, Wayne Stambaugh wrote:
>>>>>>>>> After much cursing and many config attempts, I finally have a working
>>>>>>>>> spice simulation solution on windows.  I'm guessing similar parallels
>>>>>>>>> can be applied to osx as well.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Option A: running from a mingw32 or mingw64 terminal.
>>>>>>>>>
>>>>>>>>> 1) copy the installed spinit file (by default will be in
>>>>>>>>> ${MINGW-PACKAGE-PREFIX}/share/ngspice/scripts) to ~/.spiceinit.
>>>>>>>>> 2) change the msys2 paths (/mingw##) in ~/.spiceinit to absolute windows
>>>>>>>>> paths with / not \ (in my case C:/msys64/mingw##).
>>>>>>>>> 3) Launch kicad.exe from the terminal.
>>>>>>>>>
>>>>>>>>> I realize this is not very elegant and will only work with either the 64
>>>>>>>>> or 32 bit mingw (not both without editing .spiceinit) but it works and
>>>>>>>>> is handy for mingw users.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Option B: configuring windows and run kicad from a shortcut.
>>>>>>>>>
>>>>>>>>> 1) locate the installed spinit file
>>>>>>>>> ($INSTALL_PATH/share/ngspice/scripts) and change the msys2 paths
>>>>>>>>> (/mingw##) to absolute windows paths with / not \ (in my case
>>>>>>>>> C:/msys64/mingw##).
>>>>>>>>> 2) Run kicad, open the config paths dialog, and add an environment
>>>>>>>>> variable SPICE_LIB_DIR with path to the spinit file minus the last
>>>>>>>>> "scripts" path ($INSTALL_PATH/share/ngspice).
>>>>>>>>>
>>>>>>>>> I also tried copying the .spiceinit file from option A to %USERPROFILE%
>>>>>>>>> but that did not work when launching kicad from a shortcut.
>>>>>>>>>
>>>>>>>>> Option B a cleaner solution but still requires some configuration by the
>>>>>>>>> user.  This is going to be an interesting problem to solve for our
>>>>>>>>> package devs.  We need to figure out a way to generate or modify the
>>>>>>>>> spinit file base on where it gets installed by the installer on
>>>>>>>>> platforms where this is relevant.  We will also either have to set an
>>>>>>>>> the SPICE_LIB_DIR environment variable or teach ngspice how to find the
>>>>>>>>> correct spinit file at run time.
>>>>>>>>>
>>>>>>>>> At least now windows users have a way to have the same functional spice
>>>>>>>>> simulation as linux users.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> Wayne
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>

Attachment: signature.asc
Description: OpenPGP digital signature