---------------------------------------------------------------------- Documentation for Black Belt Systems full Autorouter for Board Master. ---------------------------------------------------------------------- AutoRouter designed by Pete Patterson and Ben Williams. AutoRouter implemented by Pete Patterson. Copyright 1990 Black Belt Systems ALL RIGHTS RESERVED. ---------------------------------------------------------------------- --- General description --- The autorouter operates by processing three different types of text files. These include physical ".style" definition files, pin name and orientation files called ".part" files, and ".net" files which contain references to the part files and designate specific signal connection information. We'll talk about the three file types in a "bottom up" manner; that is, from the lowest level (style) to the highest (net). ---------------------------------------------------------------------- --- .style files --- Style files contain physical information. One example style file is called "DIP14.style", and contains information relating to the physical placement of the pins of a 14 pin DIP. No information about signal names is contained in this file; only pin numbers and the actual placement information reside here. The contents of the DIP14.style file looks like this: *14 pin dip .1/.3 spaced pad@[ 0, 0]:1 pad@[ 0, 2]:2 pad@[ 0, 4]:3 pad@[ 0, 6]:4 pad@[ 0, 8]:5 pad@[ 0,10]:6 pad@[ 0,12]:7 pad@[ 6,12]:8 pad@[ 6,10]:9 pad@[ 6, 8]:10 pad@[ 6, 6]:11 pad@[ 6, 4]:12 pad@[ 6, 2]:13 pad@[ 6, 0]:14 The line that begins with an asterisk is a "comment" line. it can contain anything, and in this case simply indicates what the style file is for and what the spacing of the pins is. You can have comment lines anywhere, and there may be as many as you like. All of the other lines are of the form "pad@[x,y]:n". The part "pad@" literally means "place a pad at". The [x,y] is a grid position on a .050 size grid which begins at the upper left. if you draw a grid on paper, and number the cells accross and down, you'll see that the pads defined here fall exactly where you'd expect them to for a standard dual in line IC package. There are other things you can specify in a style file, see the reference section at the end of this document for specific details on how to: * specify specific hole sizes (default is "A" size) * place metal foil areas, like under a regulator case * create special silkscreen text for a particular style. ---------------------------------------------------------------------- --- .part files --- Part files contain information that relate particular pin names with physical pins as defined in a particular style file. We'll look at the .part file for the 7400 integrated circuit. Here is the file: * 7400 style:DIP14 swapg:ABCD swapi:12 1:A0 2:A1 3:A2 4:B0 5:B1 6:B2 7:GND 8:C1 9:C2 10:C0 11:D1 12:D2 13:D0 14:VCC The first thing you see is a comment line (it's optional, but suggested). The comment simply identifies the file to you, since in a text editor (for instance) you may not remember the actual part being edited and this serves to remind you. You may have multiple comment lines if you wish. Next is a line that specifies the physical style. This is required - it provides the physical definitions used later in the part definition. Note that the style file is the same one we used as an example previously - you should be familiar with its contents. The next line is optional. It contains the keyword "swapg", followed by the letters ABCD. This tells the router that, if it feels it will help the final output PCB to be "more routable" or provide shorter traces, the router may swap sets of pins that begin with these letters. We'll go into this a little more once we've looked at the individual pin definitions. This next line is also optional: "swapi". This keyword informs the router that on the same gate, pins with these numbers may be swapped. It's only reasonable to specify this on a chip like the 7400, where the two inputs to a particular gate mean the same thing - they have exactly identical functions. Some further discussion ahead once we talk about the pin definitions. Once the style has been chosen, and the swap options (if any) specified, the actual pins of the part are defined. This is done with a line of the form "number:name". The "number" portion is a number from the ".style" file; it is the actual pin number. You don't need to worry about where it is physically, because the style file has taken care of that. The "name" portion is the name you will be using in your schematic drawing, and in the main netlist itself. In most 14 pin DIP 74xx series parts, pin seven is the ground connection. If you look at the part definition, you'll see that the 7th pin looks like this: 7:GND This means that the system has now generalized the GND connection for you. All you need to specify later, in the netlist, is "GND". The router will know that this belongs on pin 7 because of the part definition, and it will know where pin 7 physically is because of the definition in the DIP14.style file, called for in the part file. All parts, regardless of physical configuration or type, use this simple set of relationships. You use the pin name (defined in the part) along with the name of that part in your design (defined in the netlist, to be discussed further on) and you don't have to worry about the physical portions of the design. --- About Swapping Gates --- The 7400 contains 4 identical NAND gates. Each gate has two inputs and one output; You can use any gate in the package anywhere any other gate can be used because they do not interact with, or depend on, each other, and they are identical in the logical and electrical senses. In such a case, you as a PCB designer would tend to assign the gate you want in a particular circuit based upon the actual board layout, rather than some arbitrary sequence. This would allow you more latitude in routing the traces on the PCB to that area of the board. The mechanism to accomplish this within the router is the "swapg" keyword. As long as some simple naming conventions are followed, the router can use the swapg keywords data (here, it's ABCD) and the names of the pins to see if it is allowed to swap entire gates. If the swapg keyword is not present, then gate swapping will never occur. Looking at the pin names, you'll see that for each gate, the pin name begins with the letter A, B, C or D. Each pin on an individual gate further has a terminating number - in this case, 1, 2 or 3. 3 is the output pin, 1 and 2 are the inputs. It is clear that if the original design specifies A1, A2, and A3 somewhere in the design, then if the router swaps gate A with gate B and uses B1, B2 and B3 instead, the circuit will function exactly the same, electrically. If for specific reasons you desire that the gates used are exactly what you specify in the main netlist, then place an asterisk before the swapg keyword and it will be treated as a comment. --- About Swapping Inputs --- The router also contains a mechanism for swapping inputs to a circuit. Again using the 7400 as an example, note that this is a type of logic gate where the two inputs for each individual gate function exactly the same. It follows that if you choose input A1 for signal XXX and input A2 for signal YYY, the circuit would perform exactly the same electrically if signal XXX were connected to A2 and signal YYY were connected to A1. If you use the "swapi" keyword, you are telling the router that if it finds it worthwhile, it is allowed to swap these inputs. The swapi keyword affects only inputs with the same alphabetic prefix. For the 7400 part, the swapi keyword specifies that pins with the suffixes 1 and 2 may be swapped; A1 with A2, and B1 with B2, and C1 with C2, and D1 with D2. C1 may not be swapped with B2, since the prefix letter is different. If for specific reasons you desire that the inputs used are exactly what you specified in the main netlist, then place an asterisk before the swapi keyword and it will be treated as a comment. --- Pin naming conventions for compatibility with swapping --- For the swapper to function correctly, pins should be named with a single letter followed by a number from 1-9999. A1, C27, and Z800 are all legal pin names and will be understood by the swapper. Pin names that do not follow this convention (such and GND or VCC) are ignored by the swapper - gates that contain pin names that do not follow these conventions will not swap completely, such definitions should be avoided. Pin names such as 1A, C0, and CLOCK are not valid names for the swapper and will not swap correctly. Note that they are valid pin names, it's just that the swapper logic cannot understand them and so will not operate upon them. ---------------------------------------------------------------------- --- .net files --- Net files are at the top level of the routers data structures. Each net file is specific to a particular design - a SCSI adaptor, a power supply, a CPU card and so on. In a net file, the only physical information that is present involves size of the PCB and the positioning of each part in this particular design. All other information is based upon pin names as defined in the part files, and part IDs, defined in the net file. We'll go over the contents of a sample net file now to familiarize you with whats needed, and why. Here is the beginning of the net file called "scsicard.net": * mpu design boardsize[110,90] place@[ 5, 1]:W id:EDGE part:ZORRO place@[25,85]:W id:SCSI part:SCSIHDR place@[42,60]:W id:MPU part:NCR53C80 place@[40,55]:N id:INVERT part:7406 place@[60,35]:S id:COMPARE part:74688 place@[75,39]:S id:DECODE part:74139 The first line is a comment. Again, you can have any text in a comment, and as many comment lines as you desire. The asterisk indicates this is a comment line to the router. --- Board Size --- The next line specifies the desired final board size. The size is in the form X,Y where X is the number of .050 grid locations horizontally, and Y is the number of .050 grid locations vertically. For the scsicard the line reads "boardsize[110,90]". 110 times .050 is 5.5 inches; 90 times .050 is 4.5 inches. So this board is a little wider than it is high. You can change this at any time - if it looks like the router can easily route all the required connections for your design in a smaller board, and the board size you initially specified is not a physical requirement (such as it would be if it were to be inserted in a card cage like the Amiga 2000's) then you reduce these values, remembering that each count is equal to .050 inches. --- Parts Placement and Identification--- The next group of lines are all "place" statements. These perform several functions: 1 - actually choose the part to be used 2 - designate a "logical" name for the part in this design 3 - specify the location and orientation of the part. Here is one of the "place" lines from this design: place@[40,55]:N id:INVERT part:7406 The first portion, "place@[40,55]:N" chooses where pin ONE of the part will be placed on the board. The numbers 40,55 are in X,Y order, and specify horizontal,vertical postioning. The values are increments of .050 inches each; so this pin one of this part is located at 2.00, 2.75 inches as measured from the top left of the board. The next portion, "id:INVERT" is a "logical" name that is used within this design. It can be any text name, and must not be duplicated by any other part. If you have two of these in a design, you might name them INVERT1 and INVERT2. The logical name is used to identify the individual component in the succeeding portions of the netlist. The last information in the place@ statement is the "part:7406" segment. This actually specifies the .part file that is to be used for this item in the netlist. Once all the parts have been defined and placed the main portion of the netlist, the actual connections to be made, is defined. --- links --- To connect two pins, we use a LINK statement. A LINK statement simply names two (or more) pins on one or more parts. Here is an example LINK statement: LINK MPU.VCC & INVERT.VCC After the keyword LINK, the parts logical ID is specified, then a period, then the name of the pin you wish to connect. This represents a "net" in the classic PCB meaning of the word, albeit a simple one. It is perfectly reasonable to specify more than one connection in a single link statement; in fact, there is no limit to the number of connections for a single statement. You can span multiple lines in the .net file for one link statement if you need to. Here is the first LINK statement in the scsicard.net file: LINK DECODE.VCC & COMPARE.VCC & COMPARE.P7 & INVERT.VCC & MPU.VCC1 & MPU.VCC2 & MPU.VCC3 This causes the router to connect all of the parts and pins named together in one "net". In this case, we're connecting all of the power pins on all of the parts used in the design. Just above this line is a statement that reads: "priority 3". This tells the router that this net is important - the higher the priority, the sooner (and shorter) the nets in question are routed in the design. Once a priority statement is placed in a netlist, that priority remains in effect until the next priority statement. The defaulr priority is zero. All of the remaining lines in the netlist are either priority statements or LINK statements. This is typical of any design. --- summary --- To recap, there are three file types. The lowest level is a ".style" file, which contains the physical location and numbers of the pins for a particular case style. These style files are not directly associcated with a particular part, and are usually used in many more than one part. For instance, the DIP14 definition is used to define the 7400, 7402, 7486, and many more. The middle level file is the ".part" file, which defines for a specific part such as a 7400 or 7474, the names of it's pins, and (optionally) if these pins and/or gates may be swapped with each other. It also indirectly defines the physical characteristics of the part by naming the appropriate ".style" file that contains this information. The top level file is the ".net" file, or netlist, which specifies the board size, places and names the parts required for the specific design, and specifies which signals are to be linked to which other signals. --- Reference Section --- --- Minimum System Requirements --- Hardware - you must have: an Amiga 500, 1000, 2000, 2500.20/30, or 3000.16/25 with 2 megabytes of memory at a minimum. The router will run (with some difficulty) in a floppy based machine; we strongly suggest the use of a hard disk system for serious use of the router and the PCB CAD system in general. Software - You must have: OS 1.3 or later; ARexx, installed with the libraries supplied with the ARexx package; Board Master, version v1r14 or later; and (of course) the router itself. --- Installation --- The router command, the routepre command, the part & style files must all reside in one directory on diskette or HD partition. Once the files have been copied, an assignment must be made. Here is an example installation for a hard drive named dh0: It assumes you have a directory where you are keeping your arexx scripts already created, and already assigned to REXX: as specified in the ARexx manual. 1) type this at any cli/shell prompt: makedir dh0:rl 2) put the floppy that has the router software in df0: 3) type this at any cli/shell prompt: copy df0:rl to dh0:rl all quiet 4) type this line at any cli/shell prompt: assign RouteLib: dh0:rl 5) type this line at any cli/shell prompt: copy df0:rexx to rexx: all quiet This proceedure will install everything you need on your HD to begin using the autorouter. This next sequence will allow you to run the autorouter from the floppy it is supplied on, or a copy of it (preferably a copy!). This sequence assumes the use of drive df0:, if you wish to use df1: or df2:, just replace the occurance of df0: with the other drive name. If you have enough ram, you can copy the entire floppy to ram: and make the assignments there as well. 1) place the router floppy in drive df0: 2) type this at any cli/shell prompt: assign rexx: df0:rexx 3) type this at any cli/shell prompt: assign RouteLib: df0:rl --- Operation --- To invoke the router, Board Master must be running. Use cntrl-FKEY to place the following in a macro key: rexx:exd.rexx If you have copied the "BM_Defaults.mcr" file from the root of the Board Master distribution disk to wherever you are running Board Master from, then F1 should already contain this, as Board Master now loads this specially named macro file on startup automatically. Lets assume you placed this in FKEY F1 by pressing ctrl-F1. Now, to invoke the autorouter, press ALT-F1. You should get a file requester, listing the various netlists that are available. Pick one of the samples provided by clicking on it, then select [route!] and off it goes. Once you have gotten this far you are ready to begin defining your own netlists. Here is what rexx:exd.rexx ARexx macro actually contains, with some extra comments which aren't in the actual macro file. These explain just what the macro is doing on a line-by-line basis. /* exd.rexx - invoke Board Master router macro */ options results; /* allow return data from Board Master */ 'sniff'; /* get address of internal private data structures */ esp = result; /* copy from 'result' variable to permanent variable */ 'REQUEST FILE RouteLib:,,.net,NetList'; /* pick netlist from list */ filename = result; /* copy from 'result' to permanent variable */ options; /* turn off return data condition */ if filename = "FR_CANCELLED" then do /* did user cancel operation? */ exit 0 /* exit macro, all done */ end /* and terminate conditional */ options results; /* allow return data from Board Master */ 'REQUEST BOX,Select Trace Placement,Routing Strategy,Mode A,Mode B'; temp = result; /* get router mode selection */ options; /* turn off results */ if temp = 'R' then do /* if B then tell Board Master, A is default */ 'ALTMODE'; /* send to Board Master */ end /* end conditional */ address command 'RouteLib:netpre 'filename /* preprocess netlist */ address command 'RouteLib:Route 'esp filename; /* now route */ exit 0 /* terminate macro, routing is complete */ If you wish to terminate the route proceedure before it is complete, the ARexx command "RHALT" will do this. If you have placed the file "BM_Default.mcr" in the root directory where Board Master is, then F10 should already contain this command. If so, pressing ALT-F10 will terminate the route operation. --- Special Files --- The router and preprocessor commands produce, or may produce, several files in addition to the netlist file and the part and style files. Here is a list of the files and their purposes. 1) netlist.PRE - this is produced by the netlist preprocessor; you don't need to worry about it, as it's generally going to be quite a small file. 2) netlist.STATS - This is a file that contains statistical information about the routing process. It always includes the routing time, the number of vias, and the number of nets. If the route does not complete all of the traces, more data is included here for each connection that it could not make. --- Future Enhancements --- Black Belt Systems will be providing a placement tool that allows you to create a PCB interactively using typical mouse operations. Once you have created your board shape, you'll choose the parts from a file requester and place them using the mouse. Once you're satisfied with the placement of the parts, the placement tool will create the netlist output file for the router; you won't have to deal with the physical placement in the net file unless you want to. Finally, a Schematic drawing system is planned that will generate the entire netlist for you automatically. Unlike the router and the placement tool, this will NOT be a free upgrade to the Board Master package. It is expected to retail for $99.95, and we hope to have it ready late this year in December. Once you have both the PCB system and the Schematic generator, you will be done spending money. Upgrades are free (as always) and we will maintain both products, and of course continue to improve and enhance them. We hope you see the release of the autorouter the way we do - as evidence of Black Belt Systems committment to support of our customers and our products. ========================================================================= Reference Section ========================================================================= --- ".style" files --- Keyword/Format |Definition ------------------------------------------------------------------ * text |comment line - you may place any number |of these, anywhere in the file as you |prefer. They are not processed by the |router at all after the "*" is detected. ------------------------------------------------------------------ pad@[X,Y]:N:s |place a pad at X,Y and specify it as |pin number "N". X and Y are .050 inch |grid spacing increments. The ":s" at |the end of the definition is an optional |hole size specification. The default, if |this is not present, is size "A". You |may specify the letters A-G as hole sizes. ------------------------------------------------------------------ drill@[X,Y]:s |place a drill hole center at X,Y and |(optionally) specify it to be of hole |size ":s", where s may be A-G. A is the |default. ------------------------------------------------------------------ text@[X,Y]:O:TEXT |Silkscreen "TEXT" to be placed at X,Y |in orientation "O". "O" may be H or V. |"H" is the default, meaning horizontal. ------------------------------------------------------------------ foil@[X,Y]:L:N |This is a CONNECTABLE foil area that is |.050 square. It is placed at X,Y, on layer |"L". "L" may be T, U, L, or B, for top, |upper, lower, or bottom. "N" refers to a |"pin number" that may be references in |the part definition. ------------------------------------------------------------------ fill@[X1,Y1,X2,Y2]:L |This is a NON-connectable foil area that |inclusively fills the rectangular region |defined by X1 Y1 and X2 Y2. It is placed |on layer "L", which may be either H or V. ------------------------------------------------------------------ --- ".part" files --- Keyword/Format |Definition ------------------------------------------------------------------ * text |comment line - you may place any number |of these, anywhere in the file as you |prefer. They are not processed by the |router at all after the "*" is detected. ------------------------------------------------------------------ style:PARTNAME |this line includes the partname in a |string that builds it into a complete |filename of the form: | RouteLib:parts/PARTNAME.part |Do not include the ".part" suffix or |any part of the prefix. This will |allow the best compatibility as we |expand the routers ability to handle |filesystem structures. ------------------------------------------------------------------ swapg:AB... |This OPTIONAL line tells the router |that it may swap any gates that begin |with the single alphabetic characters |contained in the list after the keyword. |The letters A-Z are valid here. A letter |should only appear once. ------------------------------------------------------------------ swapi:12... |This OPTIONAL line tells the router |that it may swap any of the numbered pins |on a gate with the same single letter |prefix. For instance, swapi:123 would |allow A1 to be swapped with A3 or A2, but |not with B2 because the prefix is |different. ------------------------------------------------------------------ N:NAME |"N" is a number that corresponds with a |number defined in the style that was |specified earlier in the .part file. |"NAME" is a name for the pin. It may be |any alphanumeric sequence as long as it |begins with a letter; in addition, if |you wish to be able to use the swap |capability, then the pin names need to |be labled using a single letter to |identify the particular gate, and a number |that identifies the signal within that |gate. See the 7402.part file for a simple |example. ------------------------------------------------------------------ --- ".net" files --- Keyword/Format |Definition ------------------------------------------------------------------ * text |comment line - you may place any number |of these, anywhere in the file as you |prefer. They are not processed by the |router at all after the "*" is detected. ------------------------------------------------------------------ boardsize[X,Y] |This must be the first line in the file |(except for comment lines) as it defines |the board area where the router is to |create the output PCB. X and Y are in |.050 grid blocks; therefore, a board |must be rectangular. ------------------------------------------------------------------ avoid@[X1,Y1,X2,Y2]:L |The avoid keyword allows you to specify |rectangular areas of a layer (or all |layers) where you do not wish the router |to run traces. This is useful if you have |a large cutout that will be made in the |PCB, or if there will be something metal |resting against the surface of the PCB. |the X,Y values are in .050 grid segments, |and L may be T, U, L, B for Top, Upper, |Lower or Bottom. In addition, for the |avoid statement only, it may be "A" which |causes ALL layers to be avoided by |the router. ------------------------------------------------------------------ place@[X,Y]:D id:NA part:FN |For each part in the PCB design, there |must be one of these lines. There are |three parts to the place@ line. The first |is "place@[X,Y]:D" which tells the router |where to put pin ONE of the part, and what |direction "D" (N,S,E,W) to orient the |part. "N", or north, is the default. North |is the same as "up" on the screen; pin one |would be at the top left in this case. |The second section "id:NA" is where you |specify a logical name for this part. The |name must be unique in this design, and it |should not use any of the reserved words |used by the router. You might use: | id:CPU |in a design, for instance. The last |portion of the place@ line is the |"part:FN" segment. This actually names |the part that is to be included in the |design. It must be the same as the parts |filename without the ".part" suffix. |One example would be: | part:7402 ------------------------------------------------------------------ LINK ID.PIN & ID.PIN |The LINK statement is where connections |between various pins are specified. |You specify the connections as two parts, |the first ("ID") as the name you used |in the ID: portion of the place command, |and the second as a PIN name that is |defined in the actual part file. You may |specify as many ID.PIN names as you like |to be connected together in one link |statement, and they may span multiple |lines. To do so, begin the next line with | & ID.PIN & ID.PIN.... etc |There are several examples of multiple |line link statements in the SCSIcard.net |file. ------------------------------------------------------------------ priority N |This specifies the priority of all LINK |statements that follow it until another |"priority" statement is encountered. The |default priority is zero. The router reads |ALL the links in before attempting any |routes, and then routes them in an |internally determined order. If you wish |certain routes (like power and ground) to |receive the optimal paths, then set the |priority up higher for them, them set it |back for the rest of them. See the file |SCSIcard.net for a good example of this. |The statement is optional. ------------------------------------------------------------------ --- Things to remember --- You need ARexx. You need 2 MB or more of memory, depending on the size of the netlist. You must have version 1.3 of the operating system. The router should run under v2.0 of AmigaDOS, but since they are still changing it at this time, we cannot promise anything. When 2.0 is really released (this fall, 1990), we'll be certain that all works as it should. Remember to make the "REXX:" and "RouteLib:" assignments; if REXX: is already assigned, make sure that the macro file "exd.rexx" has been copied into the REXX: assignment from the routers :rexx directory. ------------------------------------------------------------------