Re: gEDA: gaf - Spice question

[Stephen <stephen-at-NOSPAMelantec_dot_com>]

Many commercial packages use a generic HDL netlist format
and generate the appropriate required format netlist from this.

Stephen.

> From owner-geda-dev-outgoing@seul.org Wed Mar 20 15:49:07 2002
> From: Magnus Danielson <cfmd@swipnet.se>
> To: geda-dev@seul.org, wk@ire.pw.edu.pl
> Delivered-To: geda-dev-outgoing@seul.org
> Delivered-To: geda-dev@seul.org
> Date: Thu, 21 Mar 2002 00:51:35 +0100 (CET)
> Subject: Re: gEDA: gaf - Spice question
> Mime-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe geda-dev
> 
> From: Wojciech Kazubski <wk@ire.pw.edu.pl>
> Subject: Re: gEDA: gaf - Spice question
> Date: Wed, 20 Mar 2002 15:01:22 +0100
> 
> > Hi All!
> 
> Hi Wojciech,
> 
> > I am thinking about the new spice backends for gnetlist. The current backend 
> > is (hardly!) usable for IC designers. Some times ago a improvement was 
> > proposed, but it was not implemented due to compatibility reasons.
> > If this is the major problem, the current spice backend could be left 
> > unchanged and new spice backend (or two) should be written.
> 
> Now, just to be the devil's adovcate for a little moment...
> 
> Just *how* broken is the current backend for your purposes?
> Would code-sharing be infinitly difficult or is it just "we need to
> add this bunch of fixes, but it will break stuff for others"?
> If code-sharing is possible as such, maybe a parametrisation of mode
> migth be in place?
> 
> I am not saying that doing a separate backend (from fresh or reusing
> some code) is a bad thing, I just like to hear the arguments spelled
> out.
> 
> > I have almost finished a backend for IC designers which can use all modelling 
> > capabilities of spice3f5 but it needs some new attributes (as "area" and 
> > "model").
> 
> Cool.
> 
> > The backend for circuit designers should be quite different. The active 
> > devices should be modelled as _subcircuits_ instead of (or as an alternative 
> > to) the device model. Thus modelling of devices such as opamps, transistors 
> > with case parasitics, dual gate mosfets... will be possible.
> > The main problem is with linking the proper model to the gnetlis output. The 
> > device manufacturers deliver their models in variety of formats (sometimes 
> > internally incoherent) so it is difficult to extract them.
> 
> Indeed.
> 
> > Is it legal to to extract a model from, say Philips or Siemens, homepage, 
> > then modify it and add to a geda library?
> 
> Well... there is a few methods available:
> 
> 1) One builds a gEDA library. This can be somewhat difficult if you
>    want to avoid legal issues. Most manufactures have basically a "do
>    not redistribute" clause in there somewhere. This ties our hands
>    somewhat.
> 
> 2) Download from manufacture site at install (in Debian I've even seen
>    downloads of TrueType fonts from Microsoft's site!).
> 
> As for the method of to adapting models, you can do either of these:
> 
> 1) Update the model by hand - messy and makes updates even messier
> 
> 2) Provide a mapping and device a tool to massage the model
> 
> 3) Provide a mapping and make a wrapper model
> 
> 4) Provide a mapping and generate the right code
> 
> The benefits in providing a mapping separately is that you overcome
> the problem of what we can control in naming convetions etc. and the
> issue of many external models.
> 
> You must also recall that at least for some modeling languagues there
> migth be parameterized differences between different variants of a
> device using the same model.
> 
> I have for a very long time argued that we should device gEDA with a
> generic mapping mechanism that can be shared by many different
> languages (VHDL, Verilog, SPICE, IBIS etc.) and needs.
> 
> I have also argued that there migth be not only multiple models but in
> different languagues, but there migth be multiple models within the
> same languague, for a multitude of reasons (manufacture, degree of
> simulation detail, versions of model etc.).
> 
> These are naturally just a few aspects of a larger view, but touching
> on the subject at hand.
> 
> Cheers,
> Magnus
>