SCHEMATIC ENTRY GUIDELINES

1/14/98

1. INTRODUCTION

The following document describes some rules and methodology for schematic entry that will make best use of the postprocessing tools presented here. The goal is errorless schematics. A notation for elements in the schematic is described (net and component naming conventions), to help the post-processing tools in their task.

The author has used OrCAD Capture for Windows (Rev 7.11) as reference tool, but most of this text can be applied to other schematic tools as well.

This text will emphasize the importance of the schematic entry stage in the board design process flow. I’ll try to show you how you can avoid lots of very common mistakes found in prototype boards, just following some methodology during the schematic production. You may save a layout spin, (re-layouts are usually done when rework goes above a threshold). That is time and money saved that can be critical for your product success. I don’t want, though, to diminish the importance to the layout stage, which is critical and becoming even more important in today’s high-speed designs. We will focus, anyhow, in the pervious steps to the layout, presenting simple techniques that will reduce your chance of making "known" mistakes that would show up in your board, and at the same time make easier the interface with the layout design stage.

2. COMPONENT DEFINITION

1. New devices, not found in libraries, should follow following rules. So when creating a new component symbol:

   • Place inputs to the left and define them as inputs to help in the DRC checking of the board

   • Place outputs to the right and define them as outputs to help in the DRC checking of the board

   • Place bi-directional lines to the right and define them as bi-directional to help in the DRC checking of the board

   • Place VCC pins on the top and GND on the bottom.

   • Group functionally related lines with the same prefix i.e.

     • /vme_write

     • vme_data0

     • vme_data1

   So that are easily distinguished.

   • All pin numbers must be visible(including power pins). In the case of resistors, inductors and non-pol capacitors at least pin 1 must be visible, even though is strongly recommended to make both visible to avoid surprises in the number assigned to it.

     • Power pins should be visible for several reasons:

     • To avoid undesired connection by label to the wrong supply net (for instance in +5V and 3.3V mixed level boards). Some library elements have also defined power pins with different names (e.g. VCC and VDD) so they can get unconnected by mistake.

     • To allow connection to power nets through filter elements easily.

     • To allow easy verification of the pin number assigned on the schematic.

   • Pin names must be unique. This will make life easier when working with some netlist formats that make port association by name (as Verilog). This means that net names as NC for all no-connect pins should be replaced by NC1, NC2,etc and the same for VCC and GND pins. This is very important when the netlist is meant to be used for board level simulations, for instance.

   • If a component has several parts per package with common power pins, the component should be defined as a heterogeneous component, where one of the parts would be a block with only the power pins. Don’t define them as power pins, but as passive pins so that the tool doesn’t connect them by name, and you can have unique names for every pin in the part (required for netlist that map by name, i.e. Verilog). There are two other possibilities not recommended (i.e. power pins present in all parts and power pins hidden and connected by label)

2. Every component must have the following mandatory fields (the first two are usually tool dependent and already defined)

   Part Value	e.g. 10k (or PART_VALUE if your tool doesn’t have an equivalent)
   Part Reference	e.g. R100 (or PART_REFERENCE if your tool doesn’t have an equivalent)
   PART_NUMBER	e.g. 001012

   Where PART_NUMBER is a company internal part number used as an index for the company component database, where the rest of the data is stored for a particular part (as manufacturer, manufacturer P/N etc.). Is strongly recommended not to put all attributes relative to a part (let’s say MECHANICAL_MODEL, COST,…) inside the schematic because it is very difficult to keep them in sync with the main database, and it makes cumbersome create new components. The result is schematics with out of date fields. It is a better to link them externally with the main database using the part number as entry key.

3. These 3 attributes above must be visible on the schematic for every single part

4. The PART_NUMBER attribute should be used as Package Type field for layout netlists. This way every part number has a unique package assigned or mapped to it that can be customized and maintained separately, and a reusable library of components (defined by their part numbers) can be created, both for schematic symbols and for layout componentsFor components that can take a range of values, all with the same package, for example resistors from 1ohm to 10M may have p/n 1000 through 1100 in the component database, you can assign a package name as 1000-1100 instead of a different one for each different value. This way a change in value of one component doesn't require a change in the package type when translated to the layout, and allows to have a common package in the library for all the range of components, instead of hundreds of them that need to be maintained separately. Also it saves a lot of time and headaches trying to keep the schematic and the layout database in sync, when after the debug of the board some components change just their value; then the package type won’t need to be changed, because is common for a whole series.

5. The following fields are optional:

   • CFG2_PART_NUMBER, CFG3_PART_NUMBER, ..., CFGn_PART_NUMBER.

   Used to assign different part numbers on different configurations of the board. This properties will be used for a BOM post-processor (BOMP) to generate the BOM for every configuration with no manual intervention

   • STUFFED=(STUFF, <empty>, NO_STUFF)

   if the attribute is not present or its value is empty will be assumed as STUFF. If the component is not to be stuffed, then is a mandatory filed (so that the BOM is properly generated without it). This field will be used for the main configuration. If there are other board configurations they should use the following fields

   • CFG2_STUFFED, CFG3_STUFFED, ..., CFGn_STUFFED

   With the same set of possible values, is equivalent to the previous one, but applied to different configurations

   • REVISION: is useful for instance for assemblies that require some kind of programming (e.g a PLD assembly part number should have this attribute visible).

   If a part is not programmable, the latest rev will be taken from the component database (recommended not to use in non-programmable parts)

   • CFG2_PART_VALUE, CFG3_PART_VALUE, ..., CFGn_PART_VALUE

   They are not required, only may be need to make the schematic more understandable, for boards with different configurations. The CFGi_PART_NUMBER will be the one used to generate the BOM

   If a CFGi_attribute is not defined, its value will be taken from the main configuration.

   If your tool doesn’t show the attribute name along with the value, then is good to add is as a text field in front of it, so that we know what attribute refers to (e.g. add a ‘REV’ text field in front of a 2.1 REVISION attribute)

6. Always use power and ground symbols with the net name visible for all your power/ground connections. This is preferred to a connection by label, because label connection are local (OrCAD), so if no power/ground element is provided at all for an specific schematic sheet, some pages may end up with unconnected nets to power/ground.

7. In two pin components, assign Pin 1 to the positive side (polarized caps, diodes etc.) whenever the component has polarity. This minimizes mistakes when maping the pins n the layout stage.

8. Standard bus (VME, PCI,...) connectors must contain the signal names on them, to minimize the possibility of misplaced signals. For daughter boards is recommended to use the same convention. For connectors, is a good idea too to place the pins in the symbol emulating the disposition on the layout, to avoid miss mapping of the pins to the connector.

9. If you need a hole in a connector to be grounded, prevent a pin number in the connector symbol for it, and also have it connected to the proper net.

10. Everything that should show up in the BOM should be placed in the schematic (this includes sockets, screws, stiffeners, mounting holes etc.) so that the BOM generation can be automated. If you don’t want something to show up in the BOM put a NO_STUFF attribute on it.

3. COMPONENT REFERENCE DESIGNATORS NAMING COVENTIONS

The purpose of these conventions is to be able to pass some information to a post-processing tool, about what type a component is, and sometimes the intention of that component (e.g. in case of a terminator resistor). This can also ease layout design (e.g. it is easier to find all terminators for proper location just making a search by RT* or CT*, there is no need to follow long lists of reference designators)

1. The use the following prefix for reference designators will help a netlist post-processor utility (XDrc) to check for common mistakes

   Reference Designator	Used For
   RP	Resistor Pack
   RT	Terminator Resistor
   POT	Potentiometer
   R	Other Resistors
   CT	Terminator Capacitor
   CD	Decoupling capacitor
   C	Other Capacitors
   L	Inductors and ferrite beads
   DT	Terminator Diode
   D	Other Diodes
   Q	Transistor
   Y	Crystal
   OSC	Oscillator
   H	Header
   TH	Test Header
   JP	Jumper
   J	Connector
   GP	GND Test Point
   VP	VCC Test Point
   TP	Other Test Points
   SKT	Socket
   M	Mechanical element
   RL	Relay
   DOC	Documentation element (e.g. title block or a ECO history block). They must carry a NO_STUFF attribute.
   U	IC or any other component not listed above

2. Rework components that are not present in the layout, must have an X following the initial usual reference designator prefix (i.e. RX100). They should be renamed removing the X when the Schematic is prepared for a re-layout of the board

4. NET NAMING CONVENTIONS

Some schematic capture tools allow putting attributes to nets that are exported with the netlist to the layout house. On the other hand almost nobody uses those attributes during the layout stage, usually because the schematic entry tool is not well interfaced with the layout tool, and they get lost during a netlist generation or a posterior conversion. Usually, only when schematic and layout are done in the same company and with the same family of tools (e.g. cadence Concept/Allegro) this is used, and then it works just fine.

Most companies outsource the layout design to a layout house. Unfortunately, the layout designers usually get a bare netlist (most of the time they don't even have a hard copy of the schematic) and some other information (device package information, placement and routing instructions for critical signals and components) as input.

The goal of defining a syntax for net names is to be able to automate the generation of part of this documentation, by adding net attribute information to the net name (beware of the limitation of some netlist formats to the net-name length)

The proposed general syntax of a net name is the following:

NOTE: You can use an alternative syntax to denote low true, plus side and minus side of a differential pair as follows when using netlist formats that doesn't allow these characters.

'/' -> Replaced by 'N' attribute placed at the end of the attribute list

'+' -> Replaced by 'P' attribute placed at the end of the attribute list

'-' -> Replaced by 'M' attribute placed at the end of the attribute list

So, with the alternative syntax, NetName and Attr definitions get replaced by:

The attribute order in the attribute list is not important, but if you use this alternative notation is recommended to keep these 3 attributes always at the end of the attribute list, to make it easier to read.

Some general rules concerning net naming:

• Every net must have a visible net name. If the net name is not important, it should be labeled as SHxx_n, where 'xx' is the schematic page where it is located and 'n' is a unique number in that page (incremental). This way when checking a netlist, it can be easily located in the schematic

• Net names should be CAPITAL

• Low true signals start with '/' or in the alternative syntax end with '_L'

• Buses should share the same prefix (e.g. /UC_WR, UC_DATA0...)

• Bus lines should be numbered as [msb..lsb] ALWAYS to avoid buses flipped when passing them through hierarchical or off-page ports.

• Local nets shouldn't have the same name than global ones to avoid confusions (the tool usually adds a suffix to distinguish the local one from the global one, but this suffix can be changed by the tool, making netlist comparison tasks more difficult)

• No net should be named by the tool automatically (this eases netlist comparisons)

• Differential lines should use the '+'/'-' suffixes (or in the alternative syntax the '_P'/'_N')

• Regarding the use of the attributes, most of them will be used by XDRC to perform some sort of netlist checking (see 6)

• Clock signals must carry CLK attribute (e.g. use 16M_CLK, don't use CLOCK_16M, CLK_16M)

• Signals used to drive the clock input on any flip-flop, and are not clocks (not periodic), should carry the EDGE attribute (e.g. /WRITE_EDGE)

• Chip select signals must carry the CS attribute (e.g. use /DPRAM_CS, don't use /DPRAMCS)

• Enable signals must carry the ENA attribute (e.g. use LATCH_ENA, don't use LATCH_EN, LATCHENA, LATCH_ENABLE)

• Output Enable signals must carry the OE attribute (e.g. DPRAM_OE_N)

• Controlled impedance nets must carry the attribute ZZn, where n is the impedance value in ohms (e.g. CVBS_ZZ75_IN)

• Nets that require a special thickness in the layout carry the attribute TKn, where n is assumed in mils (e.g. VCC_CON_TK30)

• Data buses must carry the DATA attribute (e.g. UC_DATA0, not UC_DAT0 or DATA0)

• Address buses must carry the ADDR attribute (e.g. VME_ADDR2)

• Multiplexed Address/data buses should carry the ADATA attribute (e.g. 8051_ADATA7)

• Primary input, outputs and bi-directional signals in a board must carry the IN, OUT, IO attributes. That is, signals coming from/to a connector or a header to the board (e.g. RS422_CLK_IN+ and RS422_CLK_IN-)

• Differential lines should carry the same name and end with +/- (see example above) or with the alternative syntax _P/_M

• Is recommended to put the attribute TEST in Test signals (this helps to remove them when they are not longer required)

• LED and DIP switches connection nets should carry the attr. LED and DIP (e.g. /STATUS_LED[7..0], /CONFIG_DIP[7..0])

• Selection lines will carry the attribute SEL (e.g. CLOCK_SEL[1..0])

• Ground nets are named as *GND (e.g. AGND), or the should carry the GND attribute (e.g. A_GND)

• Power pins are named as *VCC or *VDD (only for +5V and +3.3V, e.g. AVCC, LVCC), or they should carry the +nV or -nV attribute (e.g. PIN_+5V, PIN_-12V, A_+5V, VCC_+3.3V)

• Signals coming to/from a module/daughter board, should carry its name as prefix (e.g. RIKER_16M_CLK_OUT), in this case IN/OUT/IO attributes should be also used to indicate if is an output from that module, input to that module or bi-directional. This improves readability making the signals easy to track

• The following attributes are recommended when applicable: FLAG, RD (for read lines), WR (for write lines), INT (for interrupt lines). Examples: MASTER_INT_EDGE, /UC_WR, /UC_RD, IM_OK_FLAG

  They are not used at this point for any checking

• When a signal is a buffered version of another one, must carry the BUFF attribute (from 16M_CLK to 16M_CLK_BUFF). If the signal is a primary IO then is preferred to remove the IO attribute (e.g. RIKER_CLK_OUT -> is buffered to RIKER_CLK)

• Some other useful attributes (optional)

  • OPT (for nets that are driven only if an option resistor is placed inline)

  • DAMPED (for nets after a damping resistor)

  • SRC (for nets before a damping resistor)

• Signals coming from a standard bus should carry its name as prefix (e.g. ISA_ADDR0)

These conventions may seem too cumbersome, but they will help XDRC to figure out what the nets are for, and that will allow it to perform some checking that may catch some mistakes and will generate some reports that will save you time on subsequent steps. Once you are used to the convention it becomes a very natural way to name the nets and provides useful information about them.

5. DOCUMENTATION ELEMENTS

The purpose of this elements is to standardize the documentation sections of the schematic (title block,…) so that the look alike in all schematics for the company and they don't need to be created from scratch for every schematic. For this, is good to have a library with some documentation elements that can be reused.

Some mandatory documentation elements are:

• Prototype Stage Engineering Changes History Block. Should follow the following format and should be present on the last page(s) of the schematic. It's purpose is to document changes done before the board is released, so that that information is not lost

  Date / Change description / By / New Rev

• ECO block should be present on the first page of the schematic and has same fields than the above mentioned history block

• Title block. Sometimes is recommended to use a custom title block instead of the ones provided by the tool. E.g. OrCAD title blocks don't allow changing the rev level or doc. Number fields for all the pages in one step. You have to manually change them page by page (new OrCAD revs allow the use of macros, which overcomes this problem). A way to solve this is to put these two fields as text in the title block component definition and update the modifications to the component to all the schematic

• Configuration tables should be added for documentation purposes on the schematic (only when required)

Some other things to take into account

• Text to identify names of functional blocks should be added to improve readability of the schematic (e.g. DIFFERENTIAL RECEIVER, SERIAL TO PARALLEL CONVERTER…)

• A lot can be written about revision notations, and it is not the scope of this document to cover this. The simplest rule to follow is, different schematics should have different filenames and different revision levels (even if is temporary during the process of updating and schematic e.g. Rev 7-8a, Rev 7-8b, Rev 8). The filename must show the rev level.

• Schematic Rev level and Document Number should be included in every schematic page

• Keep the first page of the schematic just to put documentation on it (title etc.)

6. FOR LAYOUT

All signals with CLK or EDGE attributes should be treated as clocks in the layout. XDRC will report them.

Special thickness nets should contain the attribute TKn on the net name, and (recommended) a note on the schematic. The same with controlled impedance nets (ZZn) and differential nets (+/-). This way they can be easily located for special routing. XDRC will report them too

7. COMPONENT PLACEMENT IN THE SCHEMATIC

Terminators should be placed in the schematic close by the device where it should be placed physically (in the same page and close to the device pin). The possibility of putting them all in the same page with a note to assign it to a device, has the advantage that we don't have the chance duplicate terminators, but XDRC will report the terminators attached to each net, so this will be caught easily. Putting terminators close to the target position on the schematic helps to remember where they should be placed on the board. A note will need to be updated when the reference designators of the board are renamed and the schematic it is back annotated, so they usually end-up being inconsistent or they need to be updated manually)

Decoupling capacitors should be placed in the same page where the device to decouple is located (preferred), or be labeled with text with its reference designator. Again, if reference designator change, text labels may need to be updated manually, so placing decoupling capacitors in the same page is preferred to avoid this.

A Socket associated to a device should be placed in the same page and close the device sharing the same reference designator number (but with the SKT prefix). Placing it in the same page, helps to remember which components will have a socket in the BOM, and minimizes the chance of forgetting about needed sockets.

6. POSTPROCESSING TOOLS

6.1 XDrc description

Before running XDrc over the netlist, a DRC is mandatory on the schematic tool, and should contain no single ERROR (the schematic tool has access to more information than the netlist checker, as pin type for instance). DRC and XDRC reports should be attached to the documentation to present to the design review previous to the layout of the board. XDRC can be configured to allow flexibility over the following rules. The following is the intended list of chekings to perform. Check XDRC documentation for details over current implementation

ERRORS

1. Two pin components R*, C*, L* will be checked for

   • Both pins connected to same net forgiven

   • One pin unconnected forgiven

2. No single node net is allowed

3. Every U device will be checked to have at list two power pins at different potential (to avoid IC's not connected to supply by mistake)

4. Oscillators will be checked for

   • One ground pin at least

   • One supply pin at least

   • One clock net connected to it

WARNNINGS

1. Clock signals (CLK attribute) will be checked for terminators (DT*, RT*, CT* network) and will be included in the report of special routing signals and in the list of signals to check in a Signal Integrity test

2. Edge sensitive nets (EDGE attribute) will be checked for terminators (DT*, RT*, CT* network) and will be included in the report of special routing signals and in the list of signals to check in a Signal Integrity test

3. Address/Data buses will be included in the list of signals to check during the Signal Integrity test

4. Signals with CLK and EDGE attribute will be listed in the special routing section report listing the places to go and terminators associated

5. Differential lines will be reported for routing special requirements

6. Chip select signals (CS attribute) will be checked for pulling resistors to inactive state (if low true will be checked for a pull-up resistor, if high true for a pull-down resistor)

7. Enable signals (ENA attribute) will be checked for pulling resistors to inactive state (if low true will be checked for a pull-up resistor, if high true for a pull-down resistor)

8. Potentiometer and other 3 pin devices detected will be flagged to be included in the list of packages to check, because is very frequent to have a wrong pinout in these packages

9. Ground nets (*GND) will be checked to make sure that they are connected through segmentation resistors (otherwise a warning will be issued)

10. Nets with more than 5 U devices attached will be flagged to check for drive capabilities

11. The same group of U devices will contain all the components of the bus in different pins, one and only one time

12. CD components will be checked to have pin 1 more positive than pin 2 (this can catch backward polarized caps)

13. A report of number of decoupling capacitors and number for VCC/GND pins going to U devices will be generated to evaluate proper decoupling capabilities

14. A list of TK nets will be reported for special thickness nets

15. A list of ZZ nets will be reported for special thickness nets

16. Nets with names as N?????? will be reported so that they can be renamed instead of assigned automatically by OrCAD

17. LED and DIP nets will be checked for pull-ups

18. Crystals will be checked for capacitors to ground

6.2 BOM postprocessor utility description

This tool postprocesses a netlist to extract its BOM and to link it to a database. The database needs to exported in tab delimited format to be used by this tool (this way is independent of your the database manager you are using). Using this utility you don't need to stuff al the fields of the database into the schematic components to get them in the BOM. Insert just the minimum information (Part Value, Reference Designator and Part Number) and use the Part Number as the key to access to the full set of fields on the database. This makes maintenance very easy, because fields that change very frequently (price etc.) need to be changed only on the main database, and yet you can get accurate BOMs with all kind of data on them.

It also allows you to include fields for more than one configuration (customer specific BOM's) on the schematic, so that all BOM's can be extracted automatically with no manual intervention.

The output is a tab-delimited file that can be easily imported in popular database and spreadsheet applications for later use and nice report generation.

6.3 NetCmp description and requirements

It compares two netlists. It is useful when doing ECO´s to make sure that the changes we are getting on the netlist is just what we wanted, so that reliable changes can be done.

6.4 PartCmp description and requirements

Is similar to the previous one but reports the differences in components. Useful also to make safe changes to schematics over boards that are already working.

RETURN HOME