FreeCalypso > hg > ueda-linux
diff ueda/doc/prelayout.txt @ 0:cd92449fdb51
initial import of ueda and ifctf-part-lib from ifctfvax CVS
author | Space Falcon <falcon@ivan.Harhan.ORG> |
---|---|
date | Mon, 20 Jul 2015 00:24:37 +0000 |
parents | |
children |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/ueda/doc/prelayout.txt Mon Jul 20 00:24:37 2015 +0000 @@ -0,0 +1,110 @@ +Pre-layout in uEDA + +If one implements the common division of labor in which the conceptual/schematic +hardware design and the PCB layout are done by different people, in what form +is the design passed from the original designer to the PCB layout contractor? + +The common input to the PCB layout step is the netlist. However, the netlist is +actually not enough. The netlist specifies all interconnections among +components in the design, but what about the components themselves? In what +form is the list of components passed from design to layout? The answer depends +on exactly how the division of labor is implemented. + +In some organisations the designer may specify standard components by value or +device nomenclature and let the PCB layout person pick the footprints. Or the +designer may specify the footprints verbally ("this resistor is an 0805, this +tantalum cap is size C, this logic IC is SMT, that one is a DIP..."), but still +leave it to the layout person to actually draw the footprints in the PCB layout +package of his/her choice. + +However, if the hardware design is being done by a non-profit organisation like +the International Free Computing Task Force (the application scenario for which +uEDA is designed), it is often the case that the conceptual/schematic hardware +designer is a volunteer whereas the PCB layout labor has to be hired for money. +In this scenario it is advantageous to save cost by having the designer do as +much pre-layout work as possible, including the scripted generation of all PCB +land patterns, leaving only the actual layout (the placement of the supplied +footprints on the PCB and trace routing) to the costly hired labor. + +An additional consideration is that in order to keep our designs strictly free +and open source from start to finish, we don't want the layout to be done in +some proprietary package and we insist instead that it be done with the free +and open source PCB program (http://pcb.sourceforge.net/). Or more precisely, +we insist on the PCB layout file format. + +These two considerations combine to suggest that we generate the PCB footprints +for all components in the design in the PCB format and hand them to whoever we +hire to do the layout. This is what is called pre-layout in uEDA. + +Whereas PCB layout is inherently a graphical/visual task and thus seriously +incompatible with the world view of the uEDA author, the footprint generation +for PCB happens to be very compatible with the UNIX culture-based text-based +scripted flow embraced by uEDA. The PCB project's original footprint library +is actually M4 code that generates footprints algorithmically on the fly! + +The pre-layout function of uEDA requires the use of the IFCTF part library. +Among other things it contains a version of the M4 footprint library from PCB +ported from GNU M4 to the original UNIX M4. The IFCTF part library is +maintained in the IFCTF CVS repository and may be checked out with: + +$ cvs -d :pserver:anoncvs@ifctfvax.Harhan.ORG:/fs1/IFCTF-cvs co ifctf-part-lib + +uEDA expects it to be installed in /usr/local/eda/ifctf-part-lib + +The pre-layout function of uEDA works as follows: + +1. Each component needs to have a footprint= attribute defined in the MCL. + It works exactly like the footprint= attribute in gEDA with the gsch2pcb + flow. + +2. To generate the PCB footprints for your design, run the following pipeline: + +ueda-getfps | ueda-runm4 > elements.pcb + +ueda-getfps(1) reads the MCL and emits a set of M4 macro calls to generate all +of the footprints, and ueda-runm4(1) runs m4(1) on the IFCTF part library. +The output of the pipeline is a concatenated set of footprints for the board +with the name field (refdes) filled in correctly in each. If the -h option is +given to ueda-getfps, the concatenated set of footprints will be preceded by a +blank PCB template (the same one provided by PCB itself when starting a new +layout) and the resulting elements.pcb will be a valid layout PCB that can be +loaded into PCB to start the layout job. + +Alternatively, ueda-cutelements(1) may be used to cut the concatenated output +from ueda-getfps | ueda-runm4 into one file per element. It should be run in +an empty directory and the files thus produced are named after the component +reference designators. + +The uEDA footprint generation mechanism is designed so that the generation of +all footprints at once concatenated into a single PCB file is native whereas +producing single elements is secondary because the way PCB's M4 library is +designed makes this approach much more efficient, especially when using the +original UNIX M4 rather than GNU M4. + +File elements + +In addition to the M4-based original PCB footprint library which has been +incorporated into the IFCTF part library, there are other popular footprint +libraries which are simple collections of pregenerated elements, one per file. +They are called file element libraries, and there is a very popular and very +useful one maintained by John Luciani. + +uEDA supports file element libraries in addition to the main M4-based IFCTF +part library, but the process always goes through M4. + +ueda-getfps(1) normally generates a make_footprint() M4 macro call for every +component. This macro looks for the requested footprint in the M4 library and +if none is found, invokes the ueda-instfileelem(1) utility to try to find it in +the file element libraries and instantiate it from there. +See the ueda-instfileelem(1) man page for how to locate the file element +libraries. + +Some file element libraries (particularly John Luciani's) use footprint names +which would confuse M4. To get around this problem, the footprint= attribute +in the MCL may be specified as follows: + + footprint=file:Long-weird_footprint-name + +This syntax tells ueda-getfps(1) to generate a make_footprint_file() M4 macro +call instead of make_footprint(). The former invokes ueda-instfileelem(1) +immediately without trying to look in the M4 library first.