[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gEDA-dev: SoC Hopeful
>
>
> Bob Sherbert wrote:
>
>>Hi all,
>> Congratulations on getting into summer of code. I'm applicant
>>looking for some additional information on one of the posted
>>projects. I apologize in advance if I'm posting to the wrong list for
>>this; a polite redirection would be appreciated in such a case.
>> My questions pertain to the project "Parts manager". I understand
>>the symbol/footprint chooser idea as well as the concept of a database
>>backend for data sheets and additional information, these seem simple
>>enough. I am confused, however, by the lines: "In addition, this tool
>>should be able to support multiple backend flows ... the parts manager
>>should be able to also indicate how the symbol should be netlisted for
>>spice, gnucap, or other backends." From what I understand each type
>>of backend has slightly different information requirements for a
>>netlist file, and that it is perfectly possible to generate a
>>schematic which may not meet all of the requirements for a given
>>backend. Does the quote indicate that the parts manager would be
>>responsible for ensuring that all the required data for a given
>>backend is present when the component is initially placed in the
>>schematic? For example: If a user selects a spice backend and then
>>places a resistor, the parts manager should prompt the user for the
>>footprint, a refdes(or auto generate one), and a value (with
>>appropriate units). Is my understanding of this (mostly) correct, and
>>are there any major categories of information that I have overlooked
>>that such a program would require?
>>
>>Thanks for your time,
>>Bob Sherbert
>>Drexel University
>>Undergraduate Computer Engineering Major
>>------------------------------------------------------------------------
Steve Meier wrote:
> Wow, do we need a uniform way for each backend to define what info
> should be embeded within a "part"? Seems on the first thought to be a
> good idea. Would gsymcheck be a good starting point?
>
> Steve Meier
Hi Bob,
This is indeed the right list for such questions. Let me describe my
thoughts on the issue and we'll see what others think.
------------------
Current situation
------------------
We have a large collection of schematic symbols that are basically tied
to a particular part in a particular package (or at least pinout). To
try and be more concrete, lets use an op-amp as an example.
Lets further assume that our part comes in both an 8-pin SOIC as well as
a 5-pin SOT-25.
In the 8-pin package, the pin out is
1 - NC
2 - IN-
3 - IN+
4 - VSS
5 - NC
6 - OUT
7 - VDD
8 - NC
and in the 5-pin package the pin out is
1 - IN+
2 - IN-
3 - OUT
4 - VSS
5 - VDD
In the current setup, you have to create 2 different symbols for
schematics because the pin number in the symbol needs to match the pin
number in the footprint. And from the user point of view, you have to
make sure that your seelcted footprint is compatible with the symbol as
drawn.
As you might guess, you can quickly end up with a very large number of
essentially identical symbols in your gschem symbol library since you
almost have to have 1 symbol per part number (where the part number
includes the package code).
----------------
Other approaches
----------------
Some commercial tools (PCAD comes to mind) use the following approach.
You draw a symbol and give the pins a "symbol pin number". Next you
create a footprint and number those pins according to some standard
(whatever standard defines that package type). Now you create a
component by a tool that maps symbol pins into footprint pins. In our
example, we would have 2 components.
In the first, there information stored would be:
symbol name = opamp-1
footprint name = SO8
component name = AMP1234-A <--- some vendor part number including
package code
symbol pin | pin name | footprint pin
1 | VDD | 7
2 | VSS | 4
3 | IN+ | 3
4 | IN- | 2
5 | OUT | 6
- | NC1 | 1
- | NC2 | 5
- | NC3 | 8
and in the second the table looks like:
symbol name = opamp-1
footprint name = SOT25
component name = AMP1234-B <--- some vendor part number including
package code
symbol pin | pin name | footprint pin
1 | VDD | 5
2 | VSS | 4
3 | IN+ | 1
4 | IN- | 2
5 | OUT | 3
This lets us create a standard set of footprints, a standard set of
symbols and then a large database of components that marry the two.
This works nicely and it would be especially convenient if this
information could be filled out perhaps in a big ascii database. I'm
thinking it would be simple to define large numbers of opamps for
example in a very short time.
Ok, this covers the initial part. Now we really get more down to your
question about backend flows.
Suppose you'd like your schematics to also provide gnucap or a spice
netlist for simulation. Further suppose that you have a macromodel
available for this particular amplifier and that it assumes the
following port order:
OUT IN+ IN- VDD VSS
In the netlist you'd see a call like:
* node 1 = output
* node 2 = op-amp in+
* node 3 = op-amp in-
* node 4 = op-amp VDD
* node 5 = op-amp VSS
Xamp1 1 2 3 4 5 my_amp_model
What the netlister needed to know was the following
- what prefix to use? In this case "X" since it is a subcircuit. Were
this a resistor (a gnucap and spice primitive), the answer would be "R".
- what order do the nodes come out. This gives another table just like
the symbol pin # -> footprint pin # mapping like we had for board design.
- what model is called (if any) for the element? In this case
"my_amp_model".
- what parameters should be netlisted (if any) for the element? In this
case, none. In the case of a resistor it would be the resistance and
then if given, the other optional gnucap or spice parameters.
Alright, now suppose you want to use YACS (Yet Another Circuit
Simulator). It may have a different netlist format or different
requirements on how to order the nodes or required refdes or whatever.
For example in spectre a resistor call looks like:
myrefdes ( node1 node2 ) resistor r=10k
so you don't have to prefix it with "R" and the model call is always
"resistor".
---------------
other thoughts
---------------
In tools like cadence's custom IC tools, when you create a cell, you
also have the ability to define certain parameters which can be queried
and modified by a user. In the gschem world this would be like allowing
each component to define a set of attributes that it expects to have
filled in when ever the component is instantiated. For example a
resistor would expect that you fill in "value" (set to the resistance
value) and something like an op-amp may not expect any attributes to be
filled in.
I've not talked about slotting, but you could envision the component
defining the slots as well. Say you have 3 slots, you'd just define a
symbol to use for each slot (maybe you have 2 op-amp symbols and one
vdd/vss symbol for a dual op-amp or maybe you have a truely
heterogeneous part like an amplifier and a LDO in a package) and define
the symbol pin -> footprint pin mapping for each slot.
So ideally this parts manager work would have the frame work for storing
the information talked about here and gschem would be able to read
component information to know, for example that if you instantiate a
resistor you have to pick a value and if you instantiate a dual-opamp
you get a combo-box letting you pick slot 1 or slot 2.
Hope this gives some ideas.
-Dan
_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev