Re: gEDA-user: Ideas for fixing slotting, methodology discussion, NOT implementation details!

[Steven Michalske <smichalske@xxxxxxxxx>]

On Nov 20, 2009, at 8:31 PM, Bill Gatliff wrote:

> Steven Michalske wrote:
>> What do we need to define?
>> I will logically split a symbol and a component now, but we shouldn't
>> make the assumption that the will be split in the final  
>> implementation.
>>
>
> I don't think we'll be happy with things if we don't keep them  
> logically
> split, since they are in fact two conceptually different entities.
> Mixing them is how we ended up with slots, at least from my  
> perspective.

All I meant is that the final implementation should not preclude a  
heavy symbol from using this feature.

That is if I add a footprint attribute, that would propagate, so that  
further down the stream someone couldn't specify another footprint  
that didn't meat your end goals.

An example here would be FPGAs  you might want to use a package that  
had a wide range of gate options, if left to layout or purchasing they  
might choose a footprint that constrained your choice.

>
>> In a symbol:
>> Specify what part of a slot(s) this symbol represents/requires.
>> Specify what parts of a particular slot can be interchanged, e.g. pin
>> swapping
>> Specify what power domains are required for the part.
>> 	- e.g. level shifters and pins to power domains
>> 	- e.g. in a 3.3V and 5V system, which voltage is this symbol on
>> Specify what clock domain a symbol is in
>> 	- e.g.  you can't move some parts across clock domains in VLSI
>>
>
> Ok, now I'm completely lost.  :)
>
I mistakenly called what you are calling a circuit a slot.

Should we decide on calling the electrical part that a symbol provides  
a circuit, or should we call it a sub-circuit.

> A symbol is an abstract entity that expresses a requirement for a
> circuit.  The symbol itself name can't match the circuit name,  
> because I
> can see the likelihood that differently-named symbols might represent
> the same circuit (different ways to draw a NAND gate, for example).   
> So
> maybe the symbol name is arbitrary, but each symbol must have a  
> circuit=
> attribute that identifies the circuit that the symbol represents.

An attribute that specifies what the circuit the symbol requires.

here nand gates are easy.  how do you specify that you need a 50x  
current sense

>  (If
> it doesn't have this attribute, then it must be a graphical element  
> and
> we can ignore it).
>
Sounds good.

> The pin names for symbols live in their own namespace, and in fact  
> need
> not be numeric.  They can't be mapped to a pin number on a component
> package until you know which circuit of which component the symbol
> represents.  That symbol-circuit-component association is roughly
> equivalent to what we're calling a "slot" today--- but I propose we
> deprecate that term altogether.  I also think that symbol pin names
> shouldn't be numeric, so that they can't be confused with package  
> pin names.
>
> Apart from a circuit= attribute and a unique identifier for each  
> symbol
> instance, I can't think of any mandatory attributes that symbols would
> require.  Additional attributes could capture the domain and other
> information you mention.
>
> As for pin swapping, I assume you are referring to two-terminal  
> devices
> like resistors and nonpolarized capacitors.  No ideas on how to deal
> with that.
>
Not just 2 terminal devices, although usually symmetrical parts are  
not an issue with pin swapping

A three input nand gate's inputs are interchangeable, when doing the  
layout, if the pins are known to be interchangeable, the person making  
the layout can swap them to make layout simpler.

Another example,  ports on a micro controller if used for non bused  
communications can often be moved about.
port A pin 2 is signal foo
port A pin 4 is signal bar
The layout would be much simpler if you switch foo and bar, so switch  
them, it is only a small matter of software to cope ;-)
In this example, one of the workflow outputs should be a header file  
that maps signal names to pins and ports in the micro

#define PORT_FOO A
#define PIN_FOO 2
#define PORT_BAR A
#define PIN_BAR 4

To do this would we want to have an attribute that specifies the  
script or input to a script that creates this header?

pin_script="avr_signals_to_PORT_PINS.py %partnumber %refdes"

Where %partnumber and %refdes are substituted by the "implementer"

An "implementer" is the workflow step(s) that take the symbolic  
schematic and creates a realization of the design.

>
>> In a component
>> Specify what slots this component provides.
>>
>
> No.

Again misuse of the term slot. oops :-P
>
> A component merely provides a collection of named circuits.  Those
> circuit names match the circuit= attributes that symbols use, and
> circuit pin names map to symbol pin names once you know which  
> circuit a
> symbol is associated with.  But the symbol and circuit pin names are  
> not
> package pin numbers yet, and the circuit pin names probably  
> shouldn't be
> numeric for that reason.

Agreed, they should be more like a netname.
>
> Finally, for each package that a component is available in, you have  
> to
> provide information that maps the pins of the component's circuit to
> package pins.  I don't yet know what the best way to handle this
> information is, but your idea of components being named with a
> manufacturer's base part number and then the packages identified by
> suffixes seems at the outset to be a pretty good one.
>
We want something that is a guideline here.  This falls apart when you  
move to a family of parts.

I'm thinking of something like a linked list....  family->parts- 
 >packages
Is such that the "implementer" follows the tree to the bottom that  
meets the requirements.

The implementer could even have other metrics as input like a cost  
database.
That has rules for trading off area for cost.
e.g. I can use 0603 parts for my resistors and then bump up to the  
cheaper version of this op-amp, really high level stuff here, not  
really for a hobbyist.

Or in the VLSI case, technology->standard cells->arrangement ?   VLSI  
guys care to comment


I'm tired now, time for bed :-)
Hardkrash


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user