[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
schematic.
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
somewhere?)
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)
Eg,
* 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,
SPI-MOSI)
* A function can be grouped in a functional class (eg UART)
* A physical-device is defined by joining a device, footprint and
pinout
* 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
think).
Input would likely be in a format very similar to tragesym.
Manipulation and viewing of the information is an unknown at this
stage.
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
[1]nixotic.com/partsdb.png
Geoff
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 ;-)
[3]http://www.delorie.com/pcb/pin-mapping.html
Maybe the solution for FPGAs and the like, is to use something other
than schematics - something more appropriate to such a dynamic
component.
_______________________________________________
geda-user mailing list
[4]geda-user@xxxxxxxxxxxxxx
[5]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
References
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
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user