← Back to team overview

kicad-developers team mailing list archive

Re: SWEET pin_merge

 

On 4/13/2011 2:57 PM, Dick Hollenbeck wrote:
> On 04/13/2011 12:00 PM, Chris Giorgi wrote:
>> On Wed, Apr 13, 2011 at 06:56, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
>>>> So you have to think out of the box to really get the large vision here.  I do
>>>> not want EESCHEMA to be the sole source of part generation, or to be honest, not
>>>> even the main source of part generation.
>>> SWEET has succeeded when EESCHEMA can focus on *using* parts, not creating them.
>>>
>>> Because that is the productivity boost that SWEET and the distributed library
>>> management design seek.  You become more productive when the part you need to
>>> use already exists, or one close to it.
>>>
>> Hi Dick,
>>
>> I guess I wasn't very clear about the intended purpose behind my
>> suggestions. 
> 
> Chris,
> 
> I did get what you were saying, and it was my mistake in not addressing head on
> the need you were trying to address.  I skipped right past it, and assumed we
> were all trying to achieve increased productivity, by whatever means.  If we
> don't agree on how to get there, can we at least agree that the need is for
> greater productivity, inclusive of reliability?  This is the big picture goal, no?
> 
> I'm saying that I am unwilling to muck up the SWEET design at this point.  In
> fact, if doing work on SWEET starts to feel like I am swimming upstream, I will
> go play tennis and leave this as a pipe dream for someone else to argue over. 
> Trust me, I have complete control over what work I am willing to do here.
> 
> 
> If you want to submit a patch, or fork the project, you have that option.  Or
> you can hire me to do exactly what you want done.
> 
> 
> Having said that, I think there is much to be decided at layers above SWEET,
> perhaps still within the new EESCHEMA, and for that this project wants *your*
> input because you have good ideas.
> 
> 
> More below.
> 
> 
>> Auto-generation of parts is not the goal, it might be a
>> nice feature to support, but is not central to the functionality I
>> propose. Let me see if I can put my thoughts in terms that are a
>> little clearer.
>>
>> The problems I'm trying to solve are for the user of the parts, not
>> the creators. Currently, I'm doing the following when I need to use a
>> microcontroller in a schematic:
>>   - Create a part for the microcontroller I intend to use, with pin's
>> names being used for the pin-number.
>>   - Create alternate units in the part for each peripheral; the
>> pin-number is the pin's name and the pin-name is the signal. The
>> pin-numbers are unique within a unit, but have multiplicity within the
>> part.
>>   - Lay out the schematic, placing units for the peripherals I need.
>> This is currently frustrating because the unit labels are limited to
>> A,B,C, etc. and have no way of indicating which peripheral they're
>> referring to.
>>   - Create a footprint for each variant of the part, using pin's names
>> rather than number for pads.
>>   - Lay out board, playing with package selection by interchanging footprints.
>>   - Produce output files and send to a board house.
>>   - Test.
>>   - Debug board failure.
>>   - Curse when I realize that I used the same pin for two different
>> functions or used a pin not available in the package and DRC didn't
>> warn me.
>>   - ECO and revise layouts.
>>
>> What I would like to do is:
>> - Create a part for a microcontroller and all it's peripherals.
> 
> 
> Here we have to look to concepts included in verilog, and the notion of
> "schematic modules".  We currently have a very primitive thing we call
> "sheets".  This can be expanded upon significantly to include instantiation of
> schematic portions or schematic modules.
> 
> 
> If you keep this all human readable, then eventually you don't even need
> EESCHEMA, you can simply do the entire schematic with a text editor and a
> schematic compiler.  (I'm not seriously pushing such an idea, except only to
> make a point about how open and free of prior constraints this area above SWEET is.)
> 
> 
> If you want to teach that compiler how to make compile time decisions, that
> could also be done, using tricks of conditional inclusion, branching, etc.
> 
> 
>> - Lay out the schematic, placing the blocks I need. Warn if I try to
>> use a pin that has already been assigned.
>> - Lay out the board, using standard footprints.
>> - Produce output and send to board house.
>> - Test.
>> - Sign off on board.
>>
>> To get there, we would need to represent the part and its variants in
>> a manner that can clearly define what those variations are and allow
>> DRC to identify potential mistakes.
>>
>> Here's a break down of the logic behind the grammar I suggested:
>>
>> **********
>> (part REF
>> -- The part identifier.
>>
>>   (block "NAME"
>> -- This is more or less equivalent to a "UNIT" in current parlance.
>>
>>     (function "NAME" (type "FUNCTIONTYPE"))
>> -- This indicates that this block uses the given function of a given type.
>>
>>     (symbol SYMBOLDEF)
>> -- This is where the symbol for this unit is drawn. SYMBOLDEF would
>> allow inclusion of a pre-existing standard symbol from the library, or
>> an in-place definition for non-standard symbols. We should only need
>> one SPI port symbol in our library, regardless of how many SPI
>> interfaces we have.
>>
>>   )
>>
>>   (configuration "NAME"
>> -- This defines which functions are mapped to which pins and so forth.
>>
>>     (pin "NAME" (function "FUNCTION" (alternate "FUNCTION") (remap
>> "FUNCTION")) (spec SPECDEF)
>> -- Defines a pin with a primary function, and alternate function and a
>> remapped function. Subsequent appearances of a pin act additively, a
>> means of replacement or removal would also be desirable. A
>> specification field would allow annotations that the DRC can use to
>> warn of electrical mismatches.
>>   )
>>
>>   (pinout "NAME"
>> -- This defines a particular pin-out that the part is available in.
>>
>>     (pad "NAME" "PIN")
>> -- Assign a pin to a physical pad.
>>   )
>>
>>   (device "NAME" (configuration "CONFIG") (pinout "PINOUT") (package
>> "PKG") (attribute "NAME" "VALUE"))
>> -- Define an available device with a configuration, pinout and
>> package. Allow attachment of named attributes for things such as
>> memory or clock speed to display for the user and possibly use for
>> DRC.
>>
>> )
>> **********
>>
>> The grammar above is not complete by any means, rather a framework to
>> integrate with the rest of the existing grammar; I haven't reiterated
>> things such as drawing primitives.
> 
> 
> The question becomes, what are *you* willing to code?  If you cannot code it,
> then you have to persuade others to code it, either with words or money.
> 
> I would love for you to refocus your efforts onto the schematic and the notion
> of schematic portions or modules.    Again, you have good ideas.
> 
> The schematic area above SWEET is is a green field area for us.  
> 
> Up there you will not hit the same constraints of "work already done", and
> existing contributors unwilling to throw away labor that normally costs $200/hour.
> 
> So start to work with Wayne, tell us what a schematic module should be, how to
> instantiate it, and make us all happy, including hopefully yourself.

The new schematic file format has not been started yet so everything is on the
table.  Over the next month or so I plan to put together a preliminary file
format document based on the previous discussion on this mailing list.  If you
have any ideas, please feel free to contribute.  You can expect the new
schematic file format to look and feel like the part file format.  A lot good
concepts can be borrowed from it.  The one thing you should expect is that
whatever format we come up with that it must be as human readable and writable
as possible.

Wayne

> 
> 
> Dick
> 
> 
> 
>> Here's what a user would see:
>>
>> In the component chooser, they would select the desired part. They
>> would have the option of specifying the particular device at that
>> point in time, but would most likely not. Once they've chosen the
>> part, they can select which block to place, much as the units are
>> handled now; perhaps a dialog would allow them to select all of the
>> blocks they need in a single operation. They lay out the schematics
>> using the blocks, receiving warnings if a connection to a pin
>> conflicts with an existing one in another block. Once the schematic is
>> laid out, they select a device that supports all of the required
>> peripherals in a package that fits the application. This choice can be
>> changed either from the schematic or from the board layout, as
>> desired. Running DRC would warn about possibly problematic
>> connections, such as a 3 volt MCU connected to a 5 volt logic chip.
>> DRC errors would be corrected, and board layout would ensue.
>>
>> To obtain maximum reuse, perhaps it would be worth considering
>> separating the symbol library from the part library? Capacitors come
>> in many sizes and shapes, but are represented by only a small handful
>> of symbols. There are a few common logic symbols, but a plethora of
>> parts implementing them. I would be perfectly happy to create only one
>> SPI port or modem interface symbol and simply include the appropriate
>> symbols when creating new parts having that functionality. Things that
>> are largely invariant shouldn't be duplicated if it can be avoided.
>> One 100 pin TQFP is essentially the same as any other, the only
>> difference is which pins do what, not where those pins are drawn.
>>
>> As to human readability and writability, I've tried to make the
>> grammar straightforward and intuitive, but would welcome any
>> suggestions or thoughts you may have. For the fragment I generated I
>> went straight off the datasheet for the part. It took me a few minutes
>> to put together, but I'll admit it would take a fair while to define
>> an entire part with 100 pins and several times that number of
>> potential pin functions. This is a place where further fragmentation
>> through inheritance may make a lot of sense.
>>
>>
>> ~~~Chris Giorgi~~~
>>
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 



Follow ups

References