Re: [Kicad-developers] Kicad-Spice simulation tutorial

[Astroelectrónica]

Hi Matan.

Kicad is normally used to generate schematic, PCB and BOM. It is also used
to generate manufacturing files as Gebers.

Usually the external power supplies and signal generators do not belong to
the PCB or BOM. It is for this reason that I add these elements in the
simulation project but not in kicad design.

It's easier to work this way because if you want to change the power or
signal values do not need to create a netlist file every time you want to
launch a simulation.

You can see an example in the following articles of my personal blog:

http://astroelectronica.wordpress.com/2013/07/14/an1297-simulacion-transitoria-del-mcp6241-en-kicad-y-orcad/

http://astroelectronica.wordpress.com/2013/05/17/diodos-zener-con-kicad-y-orcad/

http://astroelectronica.wordpress.com/2013/05/08/amplificadores-operacionales-aritmeticos-con-kicad-y-orcad/

Cheers!


2013/10/7 Matan Gal-Katziri 

> Thanks for the advice, Miguel!
> I didn't know you can use external files to reference to spice
> simulations. That's good to know.
> Not sure I understand what you mean "include power supplies and generator
> in the simulation project".
> you mean in another sub-circuit? I will go through your blog and look
> at more of your examples.
>
> KiCad design flow is quite different from what I'm used to.
> At work we usually have three steps:
> 1. Hand calculations - Done the same.
> 2. Schematic design and simulation - just learning how to do that, not as
> easy as with commercial tools..
> 3. Layout extraction (For SI/High freq analog) - I know the commercial
> tools very well (ADS/EM solvers) but those are expansive. Are there any
> free software?
>
> Anyway, thanks again!
> Matan
>
>
>
> On Mon, Oct 7, 2013 at 3:04 PM, Astroelectrónica <
> astroelectron...@gmail.com> wrote:
>
>> Hi Matan .
>>
>> You did a good job . The document is very illustrative.
>>
>> I've done some testing with LTspice and TINA simulating circuits designed
>> in kicad . All simulators are very similar.
>>
>> No need to paste the simulation model in the schematic . Sometimes the
>> model can be very large and it is necessary to work with very large sheet
>> sizes . Simulation models can be saved in library files and add them to
>> the project simulation using pspice instructions .
>>
>> Similarly, the power supplies and signal generators can be included in
>> the simulation project , avoiding the inclusion in the list of materials.
>>
>> I think this method is better because it allows launching several
>> simulations without the need to generate a ". Cir " every time.
>>
>> Please see my personal blog where you can see examples of pspice
>> simulations performed with kicad project .
>>
>> http://astroelectronica.wordpress.com
>>
>> A common point of simulators is that most are designed only for analog
>> simulations . Manufacturers offer IBIS files from digital devices. These
>> files can be translated to IBIS pspice with IBIS2Spice of Intusoft tool .
>>
>> http://www.intusoft.com/utilities.htm
>>
>> I am working to implement digital simulations kicad projects. I also
>> think it is important to work with signal integrity simulations, signal
>> reflections, transmission lines, etc ...
>>
>> Cheers!
>>
>>
>> 2013/10/6 Matan Gal-Katziri 
>>
>>> Hi Guys,
>>> I had a little time this weekend to arrange my thoughts and write a
>>> coherent documentation of what I did. Conclusions:
>>> 1. I think it covers procedures that might look obvious to advanced
>>> users.
>>> 2. This is my preferred working method and not an absolute truth. Others
>>> might not like it.
>>> 3. If KiCad could create sub-circuits out of hierarchies where
>>> local hierarchical labels are the pins it could be great for integration
>>> purposes, don't know if it's on your roadmap though.
>>>
>>> Anyway, I attach a preliminary PDF of what I did. If you still find the
>>> content helpful I can convert it to your file format, review and upload to
>>> the repository..
>>>
>>> Best regards,
>>> Matan Gal-Katziri
>>>
>>>
>>> On Thu, Oct 3, 2013 at 2:21 PM, Matan Gal-Katziri wrote:
>>>
 Nacho,
 I feel the same way about qucs. Maybe their choice to work with a
 private netlist format also contribute to bugs and import issues...
 After a short study (my time is very limited..) I chose to work with
 LTspice. It's free, well maintained and has a GUI. don't know about netlist
 size limitations though.

 Anyway, I feel that the easiest thing would be if Kicad could create
 spice subcircuits from hierarchies, where the hierarchy labels (local, not
 global) will be the subcircuit pins. I succeeded to do something similar to
 that manually and I bet automating the procedure shouldn't be difficult.

 Also, adding a .model/.subckt field to components can save a lot of
 work when exporting spice netlists.

 Once you have a subcircuit in hand - use whatever simulator you want.
 Almost all of them can handle spice subcircuits and the purpo

Re: [Kicad-developers] [PATCH] Github support for mingw-w64

[Dick Hollenbeck]

On 10/07/2013 05:21 AM, Brian Sidebotham wrote:
> 
> On 7 October 2013 05:32, Dick Hollenbeck  > wrote:
> 
> Hi Brian,
> 
> You have a total comprehension of what is going on, and your solution has 
> left the linux
> build working.  So I would say thank you for an excellent job.  I would 
> hope windows users
> would say the same.
> 
> Comments below.
> 
> 
> Excellent, glad that's the case - I don't mean to waste your time asking you 
> to look at
> everything. It's good to get the feedback before the commit at the moment 
> though. Thanks
> for taking the time to review the changes.
>  
> 
> 
> Remove this if() block:
> 
> > +if( MINGW )
> > +set( GITHUB_ADDITIONAL_LIBS ws2_32 )
> > +endif()
> > +
> >  # No, you don't get github without boost and openssl
> >  target_link_libraries( github_plugin
> >  ${Boost_LIBRARIES}
> >  ${OPENSSL_LIBRARIES}
> > +${wxWidgets_LIBRARIES}
> 
> remove this:
> > +${GITHUB_ADDITIONAL_LIBS}
> >  )


Maybe also move wxWidgets_LIBRARIES down into the lower optional appendage also.

> 
> and replace it with this trailing additive statement:
> 
> if( MINGW )
> target_link_libraries( github_plugin
> ws2_32
> )
> endif()
> 
> >
> >  add_dependencies( github_plugin boost )
> 
> 
> Perfect, that looks more obvious regarding what's going on. Thanks.
> 
> As an aside, I noticed that some targets such as libpcbcommon and libpolygon 
> have a
> header-only dependency on boost. CMake won't know about that dependency. 
> Although CMake
> doesn't encounter the problem at the moment I think with many parallel build 
> processes it
> may be possible that one of those targets gets built before boost has been 
> installed.
> Should I add the add_dependencies( target boost ) command for those targets? 
> I think it
> appears best to do it.

We did have those parallel build problems, they went away moons ago when I 
added the lines
you talk about near line 403 of the main topmost CMakeLists.txt file.

I thought it best to aggregate them in one place because it serves as a 
reminder to those
adding new libraries.



> 
> Best Regards,
> 
> Brian.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Github plugin.

[Dick Hollenbeck]

On 10/07/2013 04:56 AM, Brian Sidebotham wrote:
> On 7 October 2013 05:56, Dick Hollenbeck  > wrote:
> 
> On 10/06/2013 06:05 PM, Brian Sidebotham wrote:
> > > On Windows, building without the msys environment means perl is 
> an absolute no-go
> > area for
> > > me;
> >
> > Android cell phone found this this morning, while I was laying in 
> bed.  I guess
> it wanted
> > to be relevant, helpful, and to cmake a difference:
> >
> >
> > https://github.com/LuaDist/openssl
> >
> >
> >
> > Hi Dick,
> >
> > Thanks for this link. KiCad-Winbuilder just puts the 1.0.0d release of 
> the luadist
> openssl
> > project in it's environment and points the OPENSSL_ROOT_DIR variable to 
> the install.
> This
> > works well - so there's no need for me to create a separate project. 
> The Luadist openssl
> > binary release is compiled to rely only on msvcrt, so there are no 
> C-Runtime library
> > conflicts.
> >
> > We could easily use this project through ExternalProject_Add to if we 
> preferred that
> approach.
> >
> > Best Regards,
> >
> > Brian.
> >
> 
> The audience most likely to be dissappointed with the current setup is a 
> KiCad Windows
> builder person that is not using KiCad-Winbuilder.  I am not in that 
> audience, so I am not
> the best spokesperson for their pain.
> 
> The only pain I'd have to suffer is if you were thinking of bringing in 
> all the source for
> that lua openssl project into KiCad and adding it to our tree.  I'd 
> prefer not to do that.
> 
> There are quite a number of alternatives all of which would use 
> ExternalProject_Add().
> 
> Someday in the next year or so we could rely on the new CMake 2.8.11 
> support of https://
> downloads.  That would get you the most recent zip file from github, but 
> it would not pin
> the version number.  Each download would be today's version.
> 
> Alternatively, you could strip out all the CMake scripts into a patch and 
> apply that patch
> into a pristine (older?) openssl download using ExternaProject_Add().  
> Having that patch
> in our tree (dir: /patches) would not bother me at all.
> 
> 
> Hi Dick,
> 
> This alternative would be my favourite choice. 


Mine too.  I provides the best record of what changes are being made, and it 
provides the
summary of the upstream argument.  Then if the upstream argument is won, the 
patch goes
away.  This how the openemebedded system works, debian, etc.

This path might be helpful for the OSX folks too or for someone on linux also, 
although
linux is unlikely.



>I think we can just extract the CMake
> scripts, tidy them a bit because they use the old style CMake install 
> commands, and also
> remove the Luadist specific stuff and we should be able to easily patch them 
> on top of a
> vanilla OpenSSL source.
> 
> The OpenSSL source is very stable, I think the only changes they make are to 
> close buffer
> overflow and other security risks, so the source code file set remains 
> predominately
> unchanged between releases.
> 
> I'm more than willing to do this and it would be more in keeping with our 
> CMake build system.
> 
> Then, we could submit it to openssl folks and ask them (no doubt "again") 
> to offer a
> sensible build system for poor Windows builders.  You would think the lua 
> guy that did all
> that work did that, but who knows.  Piling on seems appropriate in any 
> case.
> 
> The only thing I've been afraid of is to push Windows builders into using 
> patch.exe.  You
> scared me away from that.  So we went with "bzr patch", but that only 
> works in a bzr
> working tree.  So I've had to check in anything needing to be patched 
> into a scratch repo,
> just to establish a working tree.
> 
> LOL, why is patch.exe not included as part of Windows?
> 
> Thank goodness we have you Brian to sort this all out.
> 
> 
> I agree, Windows is lacking a lot.
> 
> It's a shame bzr patch requires a working tree. That is a pain. The original 
> problems with
> patch.exe were coming from the Windows User Access Control layer which 
> prevents access to
> any executable called patch.exe! However, it can be circumvented by having a 
> manifest file
> alongside the executable which reassures Windows. So just something to trip 
> the normal
> user up with no enhancement what-so-ever!
> 
> Thank goodness for projects like CMake, mingw-w64 and the like!! That's the 
> only way any
> of these builds are possible.
> 
> Plus of course, thanks to you and everyone else for building everything so 
> solid on top of
> CMake so that just a bit of tweaking is needed to get things building on 
> Windows!
> 
> Best Regards,
> 
> Brian.
> 
> 
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-deve

Re: [Kicad-developers] Interesting DLL Hell with SSL

[Brian Sidebotham]

On 4 October 2013 08:55, Maciej Sumiński  wrote:

> Hi Brian,
>
> In fact it looks very strange.. I am just wondering - wouldn't it be
> easier to link OpenSSL as a static library? It may require a rebuild in the
> KiCad-Winbuilder, but then you will not have to care about stuff that users
> keep in Windows directory.
>
> Regards,
> Orson
>
>
Hi Orson,

While static linking would be a band-aid, it seems a bit poor to have to
resort to static linking, especially as the project is moving more towards
shared objects for everything.

Static linking will give us multiple copies of the same code which isn't
great (especially if the code requires large amounts of const data like
look-up tables the like), but also shared objects give us good code
separation.

I think we could in the future move to patching the OpenSSL vanilla source
and build it as part of the KiCad build (As has now been mentioned in
another thread). At that point we're in control of the library name. We
could call it libeay32-kicad.dll for example and we'll remove ourselves
from DLL hell. I'd prefer to head down this route in the future. It's right
that if we compile something, we get to name it.

Best Regards,

Brian.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Github support for mingw-w64

[Brian Sidebotham]

On 7 October 2013 05:32, Dick Hollenbeck  wrote:

> Hi Brian,
>
> You have a total comprehension of what is going on, and your solution has
> left the linux
> build working.  So I would say thank you for an excellent job.  I would
> hope windows users
> would say the same.
>
> Comments below.
>
>
Excellent, glad that's the case - I don't mean to waste your time asking
you to look at everything. It's good to get the feedback before the commit
at the moment though. Thanks for taking the time to review the changes.


>
> Remove this if() block:
>
> > +if( MINGW )
> > +set( GITHUB_ADDITIONAL_LIBS ws2_32 )
> > +endif()
> > +
> >  # No, you don't get github without boost and openssl
> >  target_link_libraries( github_plugin
> >  ${Boost_LIBRARIES}
> >  ${OPENSSL_LIBRARIES}
> > +${wxWidgets_LIBRARIES}
>
> remove this:
> > +${GITHUB_ADDITIONAL_LIBS}
> >  )
>
> and replace it with this trailing additive statement:
>
> if( MINGW )
> target_link_libraries( github_plugin
> ws2_32
> )
> endif()
>
> >
> >  add_dependencies( github_plugin boost )
>

Perfect, that looks more obvious regarding what's going on. Thanks.

As an aside, I noticed that some targets such as libpcbcommon and
libpolygon have a header-only dependency on boost. CMake won't know about
that dependency. Although CMake doesn't encounter the problem at the moment
I think with many parallel build processes it may be possible that one of
those targets gets built before boost has been installed. Should I add the
add_dependencies( target boost ) command for those targets? I think it
appears best to do it.

Best Regards,

Brian.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Github plugin.

[Brian Sidebotham]

On 7 October 2013 05:56, Dick Hollenbeck  wrote:

> On 10/06/2013 06:05 PM, Brian Sidebotham wrote:
> > > On Windows, building without the msys environment means perl is an
> absolute no-go
> > area for
> > > me;
> >
> > Android cell phone found this this morning, while I was laying in
> bed.  I guess it wanted
> > to be relevant, helpful, and to cmake a difference:
> >
> >
> > https://github.com/LuaDist/openssl
> >
> >
> >
> > Hi Dick,
> >
> > Thanks for this link. KiCad-Winbuilder just puts the 1.0.0d release of
> the luadist openssl
> > project in it's environment and points the OPENSSL_ROOT_DIR variable to
> the install. This
> > works well - so there's no need for me to create a separate project. The
> Luadist openssl
> > binary release is compiled to rely only on msvcrt, so there are no
> C-Runtime library
> > conflicts.
> >
> > We could easily use this project through ExternalProject_Add to if we
> preferred that approach.
> >
> > Best Regards,
> >
> > Brian.
> >
>
> The audience most likely to be dissappointed with the current setup is a
> KiCad Windows
> builder person that is not using KiCad-Winbuilder.  I am not in that
> audience, so I am not
> the best spokesperson for their pain.
>
> The only pain I'd have to suffer is if you were thinking of bringing in
> all the source for
> that lua openssl project into KiCad and adding it to our tree.  I'd prefer
> not to do that.
>
> There are quite a number of alternatives all of which would use
> ExternalProject_Add().
>
> Someday in the next year or so we could rely on the new CMake 2.8.11
> support of https://
> downloads.  That would get you the most recent zip file from github, but
> it would not pin
> the version number.  Each download would be today's version.
>
> Alternatively, you could strip out all the CMake scripts into a patch and
> apply that patch
> into a pristine (older?) openssl download using ExternaProject_Add().
>  Having that patch
> in our tree (dir: /patches) would not bother me at all.
>
>
Hi Dick,

This alternative would be my favourite choice. I think we can just extract
the CMake scripts, tidy them a bit because they use the old style CMake
install commands, and also remove the Luadist specific stuff and we should
be able to easily patch them on top of a vanilla OpenSSL source.

The OpenSSL source is very stable, I think the only changes they make are
to close buffer overflow and other security risks, so the source code file
set remains predominately unchanged between releases.

I'm more than willing to do this and it would be more in keeping with our
CMake build system.

Then, we could submit it to openssl folks and ask them (no doubt "again")
> to offer a
> sensible build system for poor Windows builders.  You would think the lua
> guy that did all
> that work did that, but who knows.  Piling on seems appropriate in any
> case.
>
> The only thing I've been afraid of is to push Windows builders into using
> patch.exe.  You
> scared me away from that.  So we went with "bzr patch", but that only
> works in a bzr
> working tree.  So I've had to check in anything needing to be patched into
> a scratch repo,
> just to establish a working tree.
>
> LOL, why is patch.exe not included as part of Windows?
>
> Thank goodness we have you Brian to sort this all out.
>

I agree, Windows is lacking a lot.

It's a shame bzr patch requires a working tree. That is a pain. The
original problems with patch.exe were coming from the Windows User Access
Control layer which prevents access to any executable called patch.exe!
However, it can be circumvented by having a manifest file alongside the
executable which reassures Windows. So just something to trip the normal
user up with no enhancement what-so-ever!

Thank goodness for projects like CMake, mingw-w64 and the like!! That's the
only way any of these builds are possible.

Plus of course, thanks to you and everyone else for building everything so
solid on top of CMake so that just a bit of tweaking is needed to get
things building on Windows!

Best Regards,

Brian.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Fwd: Re: Kicad-Spice simulation tutorial

[Brian Sidebotham]

On 6 October 2013 18:39, Dick Hollenbeck  wrote:

> -- Forwarded message --
> From: "Matan Gal-Katziri" 
> Date: Oct 5, 2013 11:44 PM
> Subject: Re: Kicad-Spice simulation tutorial
> To: "Nacho Domínguez" 
> Cc: "Miguel Angel Ajo Pelayo" , "Fabrizio Tappero" <
> fabrizio.tapp...@gmail.com>, "Dick Hollenbeck" , "Miguel
> Angel" 
>
> Hi Guys,
> I had a little time this weekend to arrange my thoughts and write a
> coherent documentation of what I did. Conclusions:
> 1. I think it covers procedures that might look obvious to advanced users.
> 2. This is my preferred working method and not an absolute truth. Others
> might not like it.
> 3. If KiCad could create sub-circuits out of hierarchies where
> local hierarchical labels are the pins it could be great for integration
> purposes, don't know if it's on your roadmap though.
>
> Anyway, I attach a preliminary PDF of what I did. If you still find the
> content helpful I can convert it to your file format, review and upload to
> the repository..
>
> Best regards,
> Matan Gal-Katziri
>
>
Hi Dick,

I was interested in reading Matan's PDF to see how he was using SPICE
simulation with KiCad. Could you attach the pdf he refers too, either just
pop me a private email, or send direct to the list if you think others will
be interested in it.

SPICE is another thing that's been on my list for a long time, but
something I've never got round to with KiCad.

Best Regards,

Brian.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp