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 >