gnucap-devel
[Top][All Lists]
Advanced

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

Re: [Gnucap-devel] Ideas for the GSoC


From: a r
Subject: Re: [Gnucap-devel] Ideas for the GSoC
Date: Tue, 25 Mar 2008 23:50:13 +0000

Hi,

Just a few random thougts.

What gnucap is missing (from the user perspective) is mostly support
of external tools. There is no good schematic editor and gnucap
netlister (you may try gschem or oregano - YMMV), there is only a
simple (although functional) viewer (gwave), there is no co-simulation
capability with other tools tools (octave, icarus). Finally, it would
be nice to have a wrapper (for starting jobs in parallel on multiple
hosts and nontrivial signal postprocessing), no support for binary
output formats, no up-to-date documentation, no website where users
could exchange ideas/models etc (ok, there is this mailing list).
Those are the real missing bits, and if anybody can handle some of
them it would be a big help to the community.

On the other hand, gnucap itself is missing many core features. The
most important one is robustness and stability of the existing code.
There are also plenty of possible usability extensions (probes,
parameters, partitioning, input and output format support). And there
are analyses - I would settle for good support for transient and AC
(stb?) simulations. Perhaps noise. If someone wants to add periodic
analyses - great, but please, do it in a separate code base
(GnucapRF?). However, I can't help the feeling it's better to leave
work on core features to Al.

Cheers,
-r.

On Mon, Mar 24, 2008 at 6:12 AM, Rafael Gonzalez <address@hidden> wrote:
> Hi
>
>  About your suggestion about the plugins for Octave I was thinking more in
>  analysis involving some concepts on signals and systems, like parameters in
>  the time domain response like overshoot and delays or even transfer
>  functions. I like the way that a system can be described in Octave. You can
>  use the  transfer functions, state variables or just give the zeroes and
>  poles of the system. I was thinking this tools can be useful for a
>  simulation.
>
>  Also I've been checking the possibilities to implement Verilog-AMS as an
>  input language, and I think it's good idea. But I also thought that a
>  synthesis tool for digital systems with Verilog or VHDL as input languages
>  may be agood idea too, but it could be very much for a single summer.
>
>  --
>  ISE Rafael González García
>
>  "No existe nada mas desastroso que entrar a una guerra sin la intención de
>  ganarla."
>
>  Douglas McArthur
>  _______________________________________________
>  Gnucap-devel mailing list
>  address@hidden
>  http://lists.gnu.org/mailman/listinfo/gnucap-devel
>




reply via email to

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