Rules on Editing Schematics

From Qi-Hardware
Jump to: navigation, search

Be noticed that here most of contents came from Werner Almesberger's great feedback[1] on mail thread. And rules that guide to how to edit a good quality of schematics, the editor tool here of schematic we're using KiCad.

For example. : Milkymist One Schematic,
https://github.com/milkymist/board-m1

Contents

[edit] Understandability

Understandability comes from simplicity and systematization.

[edit] Naming Values and Units

Speak of this, one may reference to initial conclusion[2].

[edit] simple components

- one mixed-case letter per value, serving as decimal point,
- where that letter is a unit, no space between number and unit,
- secondary attributes like tolerance (1%), material (X5R), or even ESR 50 mOhm. Don't make this a complex components.

For example, values would change as follows:

resistor: 1 MOhm -> 1M, 4.7 kOhm 1% -> 4k7 1%, 49.9 Ohm -> 49R9, 220 Ohm -> 220R, 20 mOhm -> 0R02
capacitor: 10 uF -> 10u, 3.3 uF -> 3u3, 100 nF -> 100n, 4.7 nF -> 4n7
inductor: 6.8 nH 560 mA -> 6n8 560mA
bead: with a real part number with current rating
varistor: part number with Vdc or Vac
connector, led, switch: with a real part number

[edit] complex, multi-valued units

- use regular SI notation (5.6Vac), except
- no space between value and unit

[edit] Power Symbols

[edit] Directions of Global/Local Labels

[edit] Orientation of Value and Reference

[edit] Style of Junctions

Use the right-side variant of 3a of http://en.wikipedia.org/wiki/File:Schematic_junctions.svg

[edit] Properties of Components/Symbols

[edit] Field Reference

1. set text size as 0.050-0.060"

[edit] Component Name

1. set text size as 0.050-0.060"

[edit] Pin Properties

1. Pin name and Pin number, set 0.050" for them. Meanwhile we should follow whatever the data sheets use, unless the data sheets are obviously wrong or misleading. (I've seen pins named "ON" that turn something off ...) what to do with pin names that aren't valid C identifiers ? (*) Particularly inverted signals often have a lot of presentations that are a pain to use in a program: e.g.,

nRESET, RESET_N, RESET#, /RESET, or RESET with a line on top.

Of these, only nRESET and RESET_N can be directly used in a program.(*) Picking C here as an example for an identifier syntax shared by most programming languages. Names that aren't identifiers could still be transcribed but this easily results in confusion. Possible remedies:

- always use C-friendly names in components,
- define transcription rules and hope for the best,
- a mix of both, e.g., use a C-friendly convention for inverted signals, leave the rest (FOO+, etc.) to transcription.

Note that this doesn't affect alternate pin names. E.g., if we have a pin calles, say, GPIO1/TX/MOSI, then one would normally pick the name corresponding to the respective function or the most generic one, depending on context. So the / aren't part of any identifier.

2. Electrical Type, KiCad has "No connection" (NC) and "Unspecified" (Unspec). NC produces an ERC complaint if anything is connected to it at all. Unspec doesn't care what is connected. When a data sheet says "NC", this can mean "no internal connection" or it can mean "do not connect anything here". Sometimes, a data sheet clarifies that, many don't. So we should use "NC" for anything says "do not connect" or that lacks clarification while we should use "Unspec" only if the data sheet says it's okay to connect something. Why make the distinction ? Because it can sometimes be convenient for the layout to be able to route a signal through an NC pin. But that only works if the pin truly isn't connected to anything on the inside of the package.

3. Graphic Style,

[edit] Better Looking

1. keep connections straight and clear

Werner Almesberger illustrated how best, better and bad editings are:

http://downloads.qi-hardware.com/people/werner/tmp/style-0.pdf

2. remove redundant of useless pins

3. compared to 50-60 mil for most of the other text, make sure the name text had better not to smaller than 50-60 mil.

4. avoid overlaps

5. avoid having positive rails point downward or ground point upward/leftward/rightward.

6. as alignment as possible

7. not crowed

8. given more information on intensive components

[edit] Functional Structure

1. Main part-oriented structure

[edit] Categories of Components/Symbols

http://downloads.qi-hardware.com/people/werner/tmp/kicad-libs-components.pdf

[edit] Project-Specific/Local

we can still have such power symbols, namely in a project-local library. E.g., one circuit may have VIDEO_IN_3V3, AUDIO_3V4, ... while another may have ANALOG_5V. and so on. The common library could simply have 3V3 and such. People can then copy from there and adapt for project-specific needs.

[edit] global common libraries

/milkymist/board-m1/r4/m1.pro    #your project folder
../../../kicad-libs/components/  #your global common components libraries folder, see kicad-libs/components

[edit] local project-specific libraries

/milkymist/board-m1/r4/m1.pro    #your project folder
../board-m1/components           #your local project-specific folder

[edit] Checklists of Symbols

1. is the symbol understandable ?
2. are all pins present ?
3. do they have the correct name ?
4. do they have the correct number ?
5. does the pin type correspond to what the data sheet says ?
6. is text large enough ? (0.050-0.060" for component reference and value(s), 0.050" for pins and other text)
7. more ?

[edit] Checklists of Schematics

1. are the styles of values the same ?
2. are things free from overlaps ?
3. is text readable ? (When adding a symbol from the component library to schematics, a copy is made of the fields. So if the text size is/was later changed in the library, this isn't automatically reflected in the schematics and the two may diverge.)
4. can text be unambiguously associated with components ?
5. are component references on top or the left of values and/or part numbers ?
6. are comments/explanations understandable ?
7. when wires join in a T, is there a junction mark ?
8. are there no junction marks anywhere else ? In particular, do we only have crossings of the types 2b, 3b, and the right side of 3a, but never 1a or 2a ?
9. are connections straight and clear ? Here are some style
  suggestions:
  http://downloads.qi-hardware.com/people/werner/tmp/style-0.pdf
10. do positive rails point up, ground (and negative rails, but we don't have that in M1) down wherever reasonable ?
11. do labels point in the direction of the signal ? (This is all wrong in the original M1 schematics.)
12. to intensity components like bypassing capacitors editing, it would be important that given with the table that says what goes where, the layout will be properly defined, or put respective pin numbering beside bypassing capacitors.
13. more ?

[edit] Links

[edit] References

  1. http://lists.en.qi-hardware.com/pipermail/discussion/2012-April/009658.html
  2. http://lists.openmoko.org/pipermail/gta02-core/2009-July/000184.html
Personal tools
Namespaces
Variants
Actions
Navigation
interactive
Toolbox
Print/export