Re: gEDA: gaf - Spice question

[Magnus Danielson <cfmd-at-NOSPAMswipnet_dot_se>]

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