[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.

reply via email to

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