Re: [Qucs-devel] [Ngspice-devel] Ngspice for Qucs

[Kevin C. <dk...@gr...>]

Hi Guilherme,

If you are going to the length of incorporating analog you might as well do mixed-signal. It's also better to look at it as many kernels doing different kinds of simulation - a friend of mine swears by IRsim, which is a halfway house on the analog/digital spectrum - but it's PWL values on wires that glue stuff together.

Yes, OA isn't very open, but it isn't patented (possibly copyrighted), and you can do your own version if you didn't sign the Si2 agreement to download it. One could probably do a compatible open-source implementation as long as you call it something else and write your own docs.

Architecturally I'd go for designing a language and simulator that can do all the current stuff by translating to a superset language/database and providing plug-in engines (rather than translating back-ends, you have translating front-ends). OA isn't a bad starting point for that.

Way too much of the discussion about simulation is about syntax and translation, when semantics and the data model are a lot more important.

Kev.

On 12/07/2014 08:10 AM, Guilherme Brondani Torri wrote:
> Hi Kevin,
>
> Are you talking about a mixed-signal simulation? I always thought that 
> having the analog and the digital kernels communicating to each other 
> was the way to go.
>
> I appreciate the idea of having a implementation independent 
> representation for schematic and/or netlist storage (call it database 
> in  binary or plain text formats). It could be used as an intermediate 
> format to convert to and from (all flavors of spice, other netlists out 
> there) as well as the native format which the simulator uses directly. 
> It seems that everyone rolls out their A -> B converter to resolve their 
> issue and move on.
>
> OpenAccess is not really *open* right?
>
> Perhaps it is time for an open-source all-to-all converter that handle 
> the major schematic and netlist formats. Something like Pandoc 
> (http://johnmacfarlane.net/pandoc/) does for markup languages.
>
> There should be a tool to convert across schematic capture programs 
> (Qucs, gEDA, Kicad) and there should be a toll for netlist formats 
> (ngspice, qucsator, gnucap, xyce). After all it is often frustrating if 
> you have your work tied to a particular toolset.
>
> Guilherme
>
> On 12/7/14, 10:15 AM, Kevin Cameron wrote:
>> 2c:
>>
>> It's better to make the digital stuff a plug-in to the analog simulators than trying add analog chunks to a digital simulator - analog simulators understand wires better, they can do potential /and/ flow rather than just potential /or/ flow.
>>
>> Structurally there's little difference between analog and digital - wires are wires - if you have support for user defined types (VHDL) you can map analog (Spice) nets to some VHDL equivalent to represent voltages (with [discrete] derivatives).  Currents are associated with drivers/contributions rather than nets, so you can map them into VHDL too. Analog simulators actually operate in discrete steps, the piece that is different is they apply rules to the drivers/contributions of nets - e.g Kirchoff's Current Law - before making the steps, and that might require doing some hard math.
>>
>> IMO netlisting to intermediate files is a bad idea, if you have the source just fix it to work directly of whatever database you are using - using intermediate files just eats up time and resources and loses information, it's a hangover from when machines were too small to run two things at the same time (Verilog & VHDL are ~ 30 years old and SPICE is older). E.g. I got stuck trying to netlist VHDL out of OpenAccess a while back and I was thinking it would be a lot more efficient if the simulator just worked directly of OA.
>>
>> Kev.
>>
>> On 12/04/2014 01:05 AM, Richard Crozier wrote:
>>> Hi All,
>>>
>>> Some time ago we had the idea to have optional backends for Qucs
>>> simulation. No-one had time to do it, and there isn't complete support
>>> for all Qucs components and sims in other simulators (and vice versa).
>>>
>>> However, I still think it's a good idea in principle, ideally we could
>>> support qucsator, ngspice, gnucap, xyce etc. or make it easy to set up a
>>> custom backend. I can imagine a system where you specify a translation
>>> program location (qucs schematic to your systems's netlist format), the
>>> simulation program and arguments, e.g. ngspice, or gnucap, and the
>>> output translation program, which converts the output data to a format
>>> the qucs gui can understand. Each simulator project could then maintain
>>> their own sets of these programs if they chose to.
>>>
>>> Just some thoughts.
>>>
>>> Richard
>>>
>>> On 01/12/14 18:06, Paolo Nenzi wrote:
>>>> Hello Vadim,
>>>>
>>>> Thanks for announcing you work on our list. I have browsed the web pages you referenced in your mail.
>>>> May be in the end we can have the long sought GUI for ngspice.
>>>>
>>>> Keep us informed and do not hesitate to ask if you need some help.
>>>>
>>>> Ciao,
>>>> Paolo
>>>>
>>>>
>>>>> On 30 Nov 2014, at 15:01, Vadim Kusnetsov <ra...@gm...> wrote:
>>>>>
>>>>> Dear ngspice developers!
>>>>>
>>>>> I am from Qucs circuit simulator development team. Recently I have
>>>>> started implementation of ngspice and Qucs intergation feature. You will
>>>>> be able to simulate Qucs circuit with ngspice. At current state basic
>>>>> simulations (AC. TRAN) for RCL-circuit are supported. Qucs builds spice
>>>>> netlist from schematic, executes ngspice, and  converts simulation
>>>>> results from ngspice dataset to Qucs dataset. In other words, Ngspice
>>>>> can simulate Qucs schematic instead of intrinsic Qucs simulation kernel.
>>>>>
>>>>> You can read discussion thread at github[1], see proposal [2] and source
>>>>> code [3]. You can find screenshots inside discussion thread [1].
>>>>>
>>>>> I hope my results will be interesting for you. I would like to discuss
>>>>> my future tasks with you.
>>>>>
>>>>> [1] https://github.com/Qucs/qucs/issues/77
>>>>> [2]
>>>>> https://github.com/Qucs/qucs/wiki/QEP%3A-Qucs-schematic-simulation-with-ngspice
>>>>> [3] https://github.com/ra3xdh/qucs/tree/spice4qucs
>>>>>
>>>>> ----
>>>>>
>>>>> Regards,
>>>>>
>>>>> Vadim Kuznetsov
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Ngspice-devel mailing list
>>>>> Ngs...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/ngspice-devel