[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] New ideas
From: |
al davis |
Subject: |
Re: [Gnucap-devel] New ideas |
Date: |
Mon, 15 May 2006 16:37:33 -0400 |
User-agent: |
KMail/1.9.1 |
On Monday 15 May 2006 05:50, Gopala Krishna wrote:
> I have got a few ideas which might involve reworks.
> 1. gnucap may start supporting xml i.e the netlists , model
> files etc. may be in xml format.
> I mean we should develop XML format for netlists. This
> way we can develop browser plugins for viewing or even
> executing gnucap netlist on fly.
There is work in progress to change to Verilog format netlists.
It will probably be in the 0.36 stable release, and the first
development snapshot after the 0.35 stable release.
Eventually, the full Verilog-AMS language should be suported,
with the Verilog-A subset first. Gnucap is a true mixed-mode
simulator. The capabilities are limited by the Spice
description language.
I don't see XML netlists in the future, because the industry is
moving toward Verilog and VHDL. Regardless of technical merit,
XML would not be accepted.
Now, considering technical merit, XML describes only a style.
It might as well be C-style with curly braces, or whatever.
That choice is strictly cosmetic, and trivial. After choosing
a style, it is still necessary to define how content is
organized. Teams of industry experts have come up with the
Verilog and VHDL standards, which are well documented. A new
format would be a lot of work, and probably not as good as the
established ones. If we (the gnucap team) believe additional
features might be desirable, I can suggest them, and a
development snapshot of gnucap can demonstrate them.
> 2. We can split gnucap code to server-client architecture
> (socket based) This can really encourage extremely rich
> clients both GUI and text(python based) with excellent
> circuit query and data plotting facilities. Also this can
> help us to optimize the server code for high efficiency and
> at same time provide rich client interface.
> Python programmers can easily work on client side and at the
> same time c++ coders can work on major functionality of
> simulator.
Actually, the plan is to do a 3-part split. One part is the
user interface, which ideally would be written in an
interpreted language. The second part is the core engine and
database. The third part is plugins with new algorithms and
models, which are linked as shared-object modules, and accessed
through a dispatcher object, which has no speed penalty.
> My intention is to make gnucap very popular circuit
> simulator. To do this we got to innovate. I don't say my idea
> is only way. But any way why dont we try to add unique
> features to this robust software ? I am ready to work on
> gnucap .
> Please be free to give your opinions about my ideas.