[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: Solving the light/heavy symbol problem

   This post kind of blew out a bit - TLDR version - I have a database
   idea that may be helpful in the pin swapping under discussion. The
   database would provide a device representation that captures
   *everything*. The database would help inform the pin swapping decision
   process rather than provide any gEDA plugin automation. It would be a
   standalone tool (at this stage).
   long version...
   I have some thoughts on this - as my original reason for starting a
   database for managing symbols and components was trying to come up with
   some sane method of capturing all possible configurations of an ARM
   chip while only displaying those that are currently in use in the
   I am not convinced that the schematic is the correct place to capture
   the full detail of all possible functional variations of a symbol,
   otherwise the component symbol becomes bloated or split into many many
   subcomponents either of which is likely to be unreadable or obfuscated.
   I want a schematic that describes succinctly what the design is
   intended to do.
   I *do* however need to have some representation somewhere that captures
   what a device is capable of so that I can implement the design as
   easily as possible - the idea is to not have to manually create a new
   component symbol by hand for each design variation.
   Pin/function swapping to enable better routing I think *has* to be a
   fairly user involved process - although I suppose in theory it may be
   somewhat possible to tie into an autorouter of some description...
   <off topic> - but would it be possible to have a second class of rats
   nest that is one link per function? - ie 1 point to point line to
   indicate a data bus path etc - or just colored rats-nest where common
   function nets are color coded</off topic>
   I think DJs description of pin swapping makes sense - it seems like a
   more complete version of slotting. In the design I have been working on
   recently, I used a slotted resistor package. The process for changing
   which device was used was actually very easy with the 'import schematic
   option'. I had the schematic and layout open side by side - hover the
   mouse over the footprint to determine the net - then swap the slot in
   the schematic and hit import schematic - then 'O' in PCB to refresh the
   rats nest.
   This was quite pleased at the efficiency, and pushing the design flow
   from schematic to layout makes sense to me. I could be handy to be able
   to pull some schematic information from the PCB, however how you
   indicate the change to the net from pcb is beyond me. (I don't think
   laying copper would be correct - what if you had an accidental short
   More on the capturing of functional component information - my current
   plan is to create an entirely self sufficient database of component
   information. This would redefine the concept of a device to encompass
   all possible variations of the device. (noting that not all of them are
   required for a device description to be useful)
   * A logical device is made up of a number of logical pins (one pin may
   exist across a number of device packages/footprints)
   * A logical pin can be tied to a number of functions (eg UART-TX,
   * A function can be grouped in a functional class (eg UART)
   * A physical-device is defined by joining a device, footprint and
   * The pinout mapping allows a logical pin to be defined once and
   remapped across multiple packages - ie DIP, SOIC, QFN
   * Functional class awareness allows a package with multiples of the
   same function to be swapped with a degree of automation, including
   grouping pins that together form a functional group (ie a data or
   address bus, a serial port etc)
   * Pins and functions are somewhat separated - so it's easy to handle
   the situation where UART1_TX can be on pin 15, or pin 47.
   * This allows for the possibility of remapping a generic UART function
   between UART_1 and UART_2, along with the option of configuring UART_1
   to use pins 15 and 16, or pins 47 and 48.
   This concept does not in any way replace DJs description of pin
   swapping - this is more about the capture of information than the
   mechanics of an implementation at this stage.
   I think I have the bulk of the database schema worked out, with a few
   minor details about some of the linkages to finalize - the harder part
   is providing a workable interface to the information.
   Particularly an efficient way to capture and describe the information
   in the first place, and then methods of manipulation and output.
   My initial thoughts are to have some of the information captured from a
   spreadsheet - this is most likely the easiest way to enter the data
   that is read from a datasheet - this can then be pulled into the
   database (similar to tragesym I suppose).
   The next issue is then view and manipulating the data - again my first
   pass would be to have some form of symbol view the can generate an
   overview of the symbol that can be drilled down into to get the detail
   - or else another more text heavy view that would be closer to a
   rehashing of the tables of pinouts included in most datasheets.
   Outputs could be in the form of a symbol - ie you chose a component,
   and select the functions that you will need (ie I need UART, and I2C
   but not SPI, ADC, but not comparator etc) - from this a gschem symbol
   is created with the labels on the symbol matching the chosen functions
   and omitting the functions not desired.
   Alternatively the output could be a set of schematics, with a high
   level symbol describing functions, which when you navigate down the
   symbol provides a detailed schematic symbol of the pinout of that
   function. Part of the idea being that you can easily create a high
   level functional schematic that doesn't define the pinout - the tool
   would hopefully provide the pin mapping options which gives you the
   ability to swap functions between different areas of the component.
   I admit I can't yet picture exactly how all of this hangs together -
   but I do have a handle on the database and information requirements,
   and I know I can generate symbols (possibly leveraging tragesym I
   Input would likely be in a format very similar to tragesym.
   Manipulation and viewing of the information is an unknown at this
   I have only described the core information relationships of the
   database - obviously there would be additions tied to this such as
   simulation information or parameters, datasheet-links being a few
   obvious ones. Also storing symbol graphical parameters/info if for
   example you want to generate a symbol other than tragesym style output
   (this is non-trivial as it is necessary to keep track of pins etc
   within the symbolic representation).
   Well, I ended up posting a LOT more than I had intended..
   Also I have the core schema in a sort of database description view at

   On Thu, May 26, 2011 at 9:27 AM, DJ Delorie <[2]dj@xxxxxxxxxxx> wrote:

   > Otherwise my head starts to twirl in confusion over how to support
   > it or maintain the tool that does it.

     True.  Please re-read my pin mapping doc, and see if your swirling
     head can come up with a solution ;-)
     Maybe the solution for FPGAs and the like, is to use something other
     than schematics - something more appropriate to such a dynamic

   geda-user mailing list


   1. http://nixotic.com/partsdb.png
   2. mailto:dj@xxxxxxxxxxx
   3. http://www.delorie.com/pcb/pin-mapping.html
   4. mailto:geda-user@xxxxxxxxxxxxxx
   5. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

geda-user mailing list