gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnucap-devel] Fwd: Re: [Qucs-devel] Status update / request for feedbac


From: Richard Crozier
Subject: [Gnucap-devel] Fwd: Re: [Qucs-devel] Status update / request for feedback / questions (AMS)
Date: Wed, 28 Aug 2013 09:01:14 +0100
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1


Forwarding this from our list, in case anyone is interested.

Richard


--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


-------- Original Message --------
Subject: Re: [Qucs-devel] Status update / request for feedback / questions (AMS)
Date: Wed, 28 Aug 2013 00:36:04 -0700
From: Kevin Cameron <address@hidden>
To: Richard Crozier <address@hidden>
CC: address@hidden


Just FYI I did an integration of Icarus Verilog with GNUcap and another with Spice3 for mixed signal with Icarus being loaded as a shared library -

http://iverilog.wikia.com/wiki/GIT_Branch_Summary - embedded-vvp (the bulk of the code, C++)

For GNUcap/Spice I just modified the PWL sources to call out to the dynamically loaded code for data points, and for Icarus I added VPI code to locate the (non-blocking) assignments and convert them to PWL data. I added truncation code in the PWL sources to catch the logic thresholds on A->D boundary. Control gets handed to the subordinate simulators between solving and final acceptance (as far as I can remember).

Can probably get it working again if anyone is interested.

Kev.


On 08/27/2013 02:34 AM, Richard Crozier wrote:
On 26/08/2013 19:29, Soeren D. Schulze wrote:
Hi again,


* e_trsolver was temporarily disabled.  What exactly does it do?


e_trsolver is the nascent external interface (external trsolver) I am
creating to the qucs transient solvers. It provides a means to interact
with the solver between each time step, or even completely control the
stepping from another program when qucs is compiled as a library (which
has to be done manually at the moment).

The external interface currently works in two ways, synchonous or
asynchronous. In the asynchonous version it is intended that two time
steps will be provided and the qucs solvers solve between these as they
normally do, choosing their own minor time steps and simply reporting
the values of the solution at the end. In the synchronous version
however it is intended that all step control is performed by the
external program, using the previous solution values reported by qucs. I
have a prototype of this working using the Matlab/Octave solvers, which
determine the local gradient by fitting a 3-point spline to the previous
solution values. This is crude but seems to work ok for testing.

Richard










reply via email to

[Prev in Thread] Current Thread [Next in Thread]