[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Ideas for fixing slotting, methodology discussion, NOT implementation details!
Hi Steven and all,
Steven Michalske wrote:
> 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
>
>
This appears to be a "gschem --> [gnetlist, (x)gsch2pcb] --> pcb -->
gschem" workflow discussion.
FWIW, for me slotting seems to work.
Thus I vote for keeping the "slot=", "numslots=" and "slotdef*=" attributes.
<rant>
What seems not to be working properly is the swapping of the pins of
slots and the back-annotation from pcb to gschem.
What could be useful is thinking up an attribute for defining swappable
slots.
Take the 7400 package as an example:
known attributes:
numslots=4
slotdef1=1,2,3
slotdef2=3,4,5
slotdef3=9,10,8
slotdef4=12,13,11
new (proposed) attribute stuff:
slotswapdef1=1,2,3,4
We should allow for multiple instances of interchangeable slots.
pinswap_slotdef1=1,2
pinswap_slotdef2=3,4
pinswap_slotdef3=9,10
pinswap_slotdef4=12,13
These define which pins are swappable within each slot.
Or any other attribute naming convention one can think of.
Now take the 7410 as an example:
numslots=3
slotdef1=1,2,13,12
slotdef2=3,4,5,6
slotdef3=9,10,11,8
and new stuff:
pinswap_slotdef1=1,2,13
pinswap_slotdef2=3,4,5
pinswap_slotdef3=9,10,11
or with (obfuscating) all permutations
pinswap_slotdef1=1,2,13;1,13,2;2,1,13;2,13,1;13,1,2;13,2,1
pinswap_slotdef2=3,4,5;3,5,4;4,3,5;4,5,3;5,3,4;5,4,3
pinswap_slotdef3=9,10,11;9,11,10;10,9,11;10,11,9;11,9,10;11,10,9
If all permutations of an IO bank of a FPGA needs to be written out this
will become a disaster, and prone to err.
Adding these attributes to all existing symbols who needs them, is still
the easy part, it's the implementation and coding in gschem/gnetlist/pcb
that is the hard part !
If one wants to swap pins of a slot in pcb, this would require setting
yet another set of attributes in that element, including the pin swap
pattern chosen (see the obfuscated 7410 attributes), and the
back-annotate feature will have to test if this attribute is set or cleared.
Currently pcb accepts attributes, but doesn't process them in any
intelligible way.
Then there is a need for a [GTK, lesstif] GUI dialog for the users to
choose swap patterns etc.
And then all this information has to be passed into the gschem structs,
requiring gschem to read from a temp file or communicate by means of IPC
messages (dbus ?).
</rant>
Not an easy task to undertake.
Hope this helps a little bit :)
Kind regards,
Bert Timmerman.
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user