FreeCalypso > hg > ueda-linux

comparison ueda/doc/overview.txt @ 0:cd92449fdb51

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
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
comparison
equal deleted inserted replaced
-1:000000000000 0:cd92449fdb51
1 Welcome to uEDA, an EDA suite for UNIX!
2 (for board level design)
3
4 The uEDA project has been inspired by gEDA (http://geda.seul.org/) and intends
5 to do for the UNIX culture what gEDA has done for the GNU/Linux culture.
6
7 First a disclaimer is in order. Different people write Free Software based on
8 different motivations. Like most Free Software written by Michael Sokolov,
9 uEDA is based on the "scratching a personal itch" development model. In other
10 words, I have written the software to satisfy my own internal need, and I
11 don't really care if you like it or not. Please keep this observation in mind
12 as you discover that it lacks some feature you need or want, or that its flow
13 is not to your liking. I have written it to satisfy *my* needs. I could have
14 written it for myself and never released it, but I believe in sharing and
15 letting others have what I have (though whether they like it or not is not my
16 concern). So there you have it.
17
18 uEDA has been written by a hard-core UNIX programmer (as in real UNIX in 4
19 capitals running on Big Iron, not the cheap modern crap), and is designed to
20 allow one to design hardware using not only a UNIX host environment, but also
21 the intellectual creation flow model associated with the UNIX culture, one that
22 revolves around the concepts of source code files, generated files and
23 Makefiles. I won't explain these concepts here; if they are foreign to you,
24 uEDA is not for you.
25
26 Note my choice of words: "the intellectual creation flow model" of the UNIX
27 culture, rather than "the UNIX programming model". I fully acknowledge that
28 hardware engineering is very different from SW eng, and uEDA does not try to
29 "make hardware like software". However, the UNIX culture's intellectual
30 creation flow model has already been extended many times to various intellectual
31 products other than software. Consider for example an author writing a book in
32 troff. The troff source files take the place of C source code, PostScript or
33 other typesetter files for the print house take the place of the executable
34 binary, and a Makefile is used to drive the flow. The author edits the book
35 source files with vi and regenerates the generated files on each iteration by
36 running 'make'. It isn't software, but the intellectual creation flow is
37 virtually identical. uEDA applies the same model to hardware design.
38
39 So what is the source code for hardware, and what is the final product that
40 should be generated by 'make all'? Well, the ultimate final product is the
41 physical board which you can hold in your hand, but the most "final" product
42 that can be made on a computer would be a set of gerber files for PCB
43 fabrication, a bill of materials (BOM) for the purchasing or other procurement
44 of parts, and a set of assembly instructions to be handed to the assembly line
45 workers who populate the parts on the board. The starting source code would
46 be the schematic design.
47
48 The ultimate UNIX-model EDA suite would thus be one that can generate all final
49 manufacturing files from the schematic source code with a single 'make' command.
50 uEDA is almost there, except for the layout step.
51
52 The problem is that even with the best EDA technology PCB layout still involves
53 considerable human effort, and is thus not something that can be done by a batch
54 program that works from stdin to stdout. Therefore, the PCB layout file is
55 subject to human editing and is not just an intermediate file between schematics
56 and gerbers like a .o file in the software compilation flow.
57
58 The uEDA solution is to view the job of designing a board as two separate
59 intellectual creation jobs, each with its own UNIX-model Makefile-driven flow.
60 These two jobs are the design and the layout. uEDA addresses the design. The
61 uEDA suite does not really get involved in the layout, but is designed with the
62 assumption that the layout will be done with the free & open source PCB program
63 (http://pcb.sourceforge.net/). The two are connected by the "pre-layout" step
64 described in prelayout.txt.
65
66 (Note that such separation of the design and layout jobs is additionally
67 supported by the fact that in many engineering companies these jobs are done
68 by different people.)
69
70 In the design phase addressed by uEDA, the source code is the set of schematic
71 sources and the Master Component List (MCL), a human-edited text file documented
72 in mcldoc.txt. The products that can be generated from these sources with a
73 Makefile are:
74
75 * Printable schematics (PostScript or PDF) for documentation;
76 * A set of "pre-layout materials" for handing to the PCB layout person;
77 * Bill of Materials (BOM) in different formats for part procurement, for
78 assembly and for quick reference.
79
80 In the layout phase the .pcb that is both read and written by the PCB GUI is the
81 source code, and pcb can be invoked from the command line without the GUI to
82 generate gerbers, PostScript prints of the layout and other product files from
83 it; those generations can be codified in a Makefile, once again creating the
84 traditional UNIX flow.
85
86 Design source code structure
87
88 The source code for a board design in uEDA consists of 3 major parts:
89
90 * Information about all components on the board;
91 * Electrical interconnect information: how these components are interconnected
92 with nets;
93 * Graphical information used to construct PostScript prints of the schematic
94 sheets.
95
96 The core philosophy of uEDA is that these 3 kinds of information should be kept
97 as orthogonal as possible. Component information is stored in the Master
98 Component List (MCL) documented in mcldoc.txt, whereas the interconnect and
99 graphical schematic information is stored in the schematic sheets (.usch files)
100 documented in uschemlang.txt. Although the electrical interconnect and
101 graphical information are stored together, the uschem language is designed to
102 provide a high degree of orthogonality between the two. Schematic sheets can
103 be either graphical or non-graphical.
104
105 Further reading:
106
107 bom_model.txt Describes the uEDA approach to BOM handling
108 drc.txt Describes the means for helping ensure a match between the
109 actual electrical interconnect and the graphical representation
110 graphsyms.txt Information about graphical symbols used on schematic sheets
111 mcldoc.txt Master Component List document
112 netlisting.txt Describes uEDA's handling of netlist information
113 prelayout.txt Describes what I mean by "pre-layout"
114 psfeatures.txt Describes the features available in the PostScript prints of
115 schematic sheets made with uschem-print(1)
116 uschemlang.txt uschem language document
117 *.1 Man pages for all uEDA utilities