Re: Ideas for the GSoC

"a r" <[email protected]>
Newsgroups gmane.comp.gnu.gnucap.devel
Message-ID <[email protected]>
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 <[email protected]> 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
>  [email protected]
>  http://lists.gnu.org/mailman/listinfo/gnucap-devel
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.