Module 1.1 - General Schematic Quality
Ensuring schematic readability, consistency, and correctness before moving to layout
Ensuring schematic readability, consistency, and correctness before moving to layout
Hierarchical schematic structure means the design is organized into logical functional blocks using sub-sheets or hierarchical sheets. Each sheet represents a distinct function (e.g., Power Supply, MCU Core, Communications Interface) with clearly defined ports connecting them.
This organizational approach mirrors how modern systems are designed - modular, testable, and maintainable.
A flat schematic with hundreds of components on a single sheet is nearly impossible to review, debug, or maintain. Without hierarchy, signal tracing becomes a nightmare, design reuse is impossible, and collaboration between engineers is severely hampered. In production, poorly organized schematics lead to missed review items and manufacturing errors.
Top-level sheet shows: Power_Supply -> MCU_Core -> USB_Interface -> Debug_JTAG -> Sensors
Each sub-sheet has clear port labels like VCC_3V3, USB_DP, USB_DM, SPI_MOSI. The MCU sheet contains only the microcontroller and its immediate support (decoupling, crystal, reset). Peripheral interfaces live on separate sheets.
Single sheet with 300+ components: Everything on one page - STM32, power regulators, USB, CAN, sensors, connectors all mixed together. Net labels jump randomly across the page. Power symbols are scattered. An engineer reviewing this has to zoom to 400% and scroll endlessly to trace any signal.
KiCad: Use Place > Hierarchical Sheet. Right-click sheet symbol > Edit Sheet Properties to set name. Use Hierarchical Labels inside sub-sheets to create ports.
Altium: Project > Add New Schematic to Project. Use Sheet Symbols and Sheet Entries. Design > Create Sheet From Selection to refactor.
OrCAD: Place > Hierarchical Block. Use Hierarchical Ports inside sub-designs. Navigate with hierarchy browser in Capture CIS.
Every schematic sheet must have a properly filled title block containing: project name, sheet title, sheet number (e.g., 3 of 12), revision, date, designer name, and approval signatures. Sheet numbering follows a logical order matching the hierarchy.
Title blocks serve as the formal documentation header for each page, enabling traceability through the product lifecycle.
During manufacturing, assembly houses reference sheet numbers for questions and ECOs (Engineering Change Orders). Missing or incorrect title blocks cause confusion in production, make revision control impossible, and fail audits in regulated industries (medical, automotive, aerospace). A printed schematic without title blocks is essentially an uncontrolled document.
Title Block: Project: "Smart Sensor Hub v2.1" | Sheet: "3 of 8 - Power Management" | Rev: C | Date: 2024-03-15 | Designer: J. Smith | Approved: M. Lee
Each sheet has a unique descriptive title. Revision "C" matches the ECO log showing three design iterations.
Title Block: Project: "Project1" | Sheet: "1 of 1" (but design has 6 sheets) | Rev: (blank) | Date: 2022-01-01 | Designer: (blank)
Generic project name, incorrect sheet count, no revision tracking, stale date from two years ago.
KiCad: File > Page Settings to edit title block. Fields auto-populate with ${REVISION}, ${DATE}. Custom title block templates in .kicad_wks files.
Altium: Design > Document Options > Parameters tab. Use .SchDot template files for company-standard title blocks.
OrCAD: Options > Schematic Page Properties. Use Title Block symbols from library. Automate with TCL scripts for batch updates.
Net naming convention defines a consistent, descriptive naming scheme for all signals in the schematic. Good net names communicate function, direction, voltage level, and active state. They follow a documented standard applied uniformly across all sheets.
Examples of conventions: VCC_3V3, nRESET (active low), SPI1_MOSI, UART2_TX.
Net names propagate to the PCB layout where they become the primary reference during routing. Inconsistent or meaningless names (Net001, N$5) make layout review impossible, complicate debugging with an oscilloscope, and cause errors when multiple engineers work on the same design. During bring-up, clear net names on the PCB silkscreen or assembly drawing save hours of probing.
Consistent naming:
VCC_3V3, VCC_1V8, VCC_5V (power rails) GND, AGND, PGND (ground domains) nRESET, nCS_FLASH, nIRQ (active-low with 'n' prefix) SPI1_MOSI, SPI1_MISO, SPI1_SCK (bus with instance number) USB_DP, USB_DM (differential pair) LED_STATUS_RED (descriptive function)
Inconsistent naming:
3.3V, Vcc, VDD3V3, +3V3 (four different names for same rail!) RESET, reset_n, RST_BAR (three conventions for active-low) Net-(U1-Pad5), N$23 (auto-generated, meaningless) MOSI (which SPI bus? ambiguous) D+ (special characters cause netlist issues)
KiCad: Edit > Global Label or Net Label. Use Inspect > Net Inspector to review all nets. ERC flags single-pin nets.
Altium: Reports > Net Status to list all nets. Use Name parameter in Net Label properties. Project Options > Net Identifier Scope controls naming.
OrCAD: Use Analysis > Cross Reference to find all net occurrences. DRC can flag unnamed nets with custom rules.
Reference designators (refdes) are unique identifiers assigned to every component in the schematic (R1, C15, U3, etc.). They must be unique across the entire design, follow standard prefixes (per IEEE 315 or IPC-2612), and be logically grouped by function or sheet.
The numbering scheme should aid assembly and debugging - components in the same functional block should have sequential numbers.
Duplicate reference designators cause BOM errors - you might order 50 capacitors when you need 100. During assembly, technicians reference components by designator; if R12 appears twice, which one gets which value? During debugging, "check R47" is only useful if R47 is unique and findable on the board.
Power Supply sheet (Sheet 2): U201 (regulator), C201-C210 (decoupling), R201-R204 (feedback divider), D201 (Schottky), L201 (inductor). All grouped in 200-series matching sheet 2.
Random numbering: Power supply has R3, R47, R112, C5, C89 scattered across different sheets. Two instances of C22 exist (one is 100nF, other is 10uF). Component U? still unassigned. Connector labeled "P1" instead of "J1".
KiCad: Tools > Annotate Schematic. Choose "Sort by X/Y position" or "Sort by sheet". Use "Reset existing" carefully.
Altium: Tools > Annotate Schematics. Configure with "Order of Processing" and sheet-based numbering offset.
OrCAD: Tools > Annotate in Capture. Use "Unconditional reference update" for re-annotation. Check with BOM report.
A floating pin is any IC input pin that is not connected to a defined logic level (VCC, GND, or a driven signal). Floating inputs pick up noise and oscillate between logic states, causing excessive current draw, erratic behavior, and potential latch-up that can destroy the IC.
Every input pin must be driven. Every unused output should be documented as intentionally unconnected.
A single floating CMOS input can cause the input buffer to sit in its linear region, drawing 10-100x normal current. This causes overheating, intermittent operation, and field failures. In safety-critical systems, a floating reset pin could cause unexpected device resets. This is one of the most common causes of "works on the bench but fails in production" issues.
STM32 unused pins: Unused GPIO pins configured as inputs with internal pull-downs enabled in firmware, AND external 10k pull-downs added for safety during boot. Unused analog inputs tied to AGND through 1k resistors. BOOT0 pin tied to GND through 10k to ensure boot from flash.
74HC14 Schmitt trigger: Only 4 of 6 inverters used. Remaining 2 inputs left floating (pins 9 and 11 unconnected). These inputs oscillate at ~50MHz, causing EMI failures and 40mA excess current draw. The IC runs hot and eventually fails.
KiCad: ERC will flag unconnected pins. Use "No Connect" flag (Place > No Connect Flag) on intentionally unused pins. Check pin types in symbol editor.
Altium: Compile project for ERC. Use "No ERC" directive on intentionally unconnected pins. Reports > Component Cross Reference shows all pins.
OrCAD: DRC flags unconnected pins. Use "NO CONNECT" marker from Place menu. Check DRC report under "Unconnected Pins" section.
All power and ground symbols throughout the schematic must use the same symbol style and net name for the same electrical net. Different ground domains (digital, analog, power) should use visually distinct symbols. Power symbols should clearly show the voltage level.
This checkpoint ensures that what appears to be the same power rail actually IS the same electrical net everywhere in the design.
If one sheet uses "GND" symbol and another uses "DGND" symbol for what should be the same net, those pins will be unconnected in the PCB layout. This creates a floating ground plane situation that causes massive EMI and non-functional circuits. Similarly, mixing VCC symbol variants can create separate power islands.
Consistent power scheme: Every 3.3V rail uses the same power symbol labeled "VCC_3V3" with an arrow-up style. Ground uses a standard 3-bar symbol labeled "GND" everywhere. Analog ground uses a triangle symbol labeled "AGND" with a single connection point to GND near the ADC.
Mixed symbols: Sheet 1 uses "+3V3" power symbol. Sheet 3 uses "VCC_3V3" label. Sheet 5 uses "3.3V" as a net label (not a power symbol). These are THREE SEPARATE NETS that never connect! The PCB has isolated 3.3V islands and nothing works.
KiCad: Use only power symbols from the "power" library. Check symbol net names in Symbol Properties. Place > Power Port. PWR_FLAG on connector-driven rails.
Altium: Use Power Port objects (not net labels) for power. Properties > Style and Net set correctly. Verify in Net List panel.
OrCAD: Power symbols from CAPSYM library. Check that power pin types are set to "Power" in symbol editor. Cross-reference power nets in netlist.
Off-sheet connectors (also called off-page connectors, net labels, or hierarchical ports) are used to continue signals between schematic sheets. Every off-sheet connector on one sheet must have a matching connector with the identical name on at least one other sheet. Orphaned connectors indicate missing connections.
This is the inter-sheet "wiring" that holds a multi-sheet schematic together electrically.
An unmatched off-sheet connector means a signal goes nowhere - it is effectively an open circuit. If UART_TX is labeled on the MCU sheet but misspelled as UART_Tx on the connector sheet, those signals never connect. The board will be fabricated with broken signal paths that cannot be fixed without a respin.
Sheet 2 (MCU): Off-sheet label "I2C1_SDA" with arrow pointing right (output from this sheet). Sheet 4 (Sensors): Off-sheet label "I2C1_SDA" with arrow pointing left (input to this sheet). Both use identical naming and appear in cross-reference report as connected.
Sheet 2 (MCU): Label "I2C_SDA" (missing instance number). Sheet 4 (Sensors): Label "I2C1_SDA" (with instance number). Net inspector shows these as TWO DIFFERENT NETS with one connection each - both floating. The I2C bus is broken.
KiCad: ERC checks for single-connection nets. Use Inspect > Net Inspector to find nets with only one connection. Hierarchical labels are checked against sheet symbol pins.
Altium: Compile > Messages shows unmatched net labels. Project Options > Net Identifier Scope must be set correctly (Automatic or Global).
OrCAD: DRC checks for single-pin nets. Use cross-reference report (Tools > Cross Reference) to verify all off-page connectors have matches.
Electrical Rules Check (ERC) is the automated verification that checks for common schematic errors: unconnected pins, conflicting pin types (two outputs driving the same net), missing power connections, and other electrical violations. A "clean" ERC means zero errors and all warnings either resolved or documented as intentional.
ERC is your first line of automated defense against schematic errors before committing to a PCB layout.
An ERC with 50 suppressed warnings likely contains 2-3 real errors hidden among the noise. Engineers who ignore ERC routinely ship boards with open connections, shorted outputs, and undriven inputs. Fixing these after fabrication costs $10,000-$50,000 per board respin, plus weeks of schedule delay. ERC takes 30 seconds to run but can save months of debugging.
ERC Report: "0 Errors, 2 Warnings" - Warning 1: Bidirectional I2C SDA connected to bidirectional I2C SDA (expected, documented). Warning 2: Output pin U3-7 connected to output pin U5-3 (documented: U5 is tri-state, directly controlled via OE pin, never active simultaneously).
ERC Report: "3 Errors, 47 Warnings - suppressed" - Engineer says "ERC doesn't work well with this design." Hidden among suppressed items: Pin 12 of MCU (UART_RX) is unconnected, two regulators driving the same net with no OR-ing diodes, 8 input pins floating.
KiCad: Inspect > Electrical Rules Checker. Configure pin type conflict matrix in ERC Settings. Use ERC exclusions sparingly with right-click > Exclude Violation.
Altium: Project > Compile. Check Messages panel. Configure rules in Project Options > Error Reporting. Use specific "No ERC" directives.
OrCAD: Tools > Design Rules Check. Configure in DRC Settings dialog. Review report file (.DRC). Use "No DRC" markers for documented exceptions.
Every passive component must have its value clearly displayed on the schematic (resistance, capacitance, inductance). Active components should show part numbers. Additional critical parameters (voltage rating, tolerance, power rating) should be visible for components where these are design-critical.
The schematic must be self-contained - an engineer should be able to understand the design without opening the BOM.
A resistor symbol without a value is meaningless - is it 100 ohms or 100k ohms? During review, missing values make it impossible to verify calculations (voltage dividers, current limits, filter frequencies). During assembly, if values are only in the BOM and not on the schematic, cross-checking is impossible and errors go undetected.
Voltage divider: R1=10k 1% 0402 and R2=3.3k 1% 0402 shown with values visible. Notes indicate "VOUT = 3.3V * 3.3k/(10k+3.3k) = 0.82V (ADC reference)". Capacitor C15 shows "22uF/16V X5R 0805".
Filter circuit: R23 shows no value (hidden field). C44 shows "C" only. L5 shows "INDUCTOR". Engineer must open properties dialog on each component or cross-reference BOM to understand the circuit. No reviewer can verify the filter cutoff frequency at a glance.
KiCad: Edit > Field Visibility to show/hide value fields. Use bulk edit (Edit > Change Symbol Fields) to display values for all components.
Altium: Right-click component > Properties > Parameters tab > visible checkbox. Use Inspector panel for bulk visibility changes.
OrCAD: Display Properties on components. Use Property Editor (Edit > Properties) for spreadsheet-style bulk editing of visible fields.
Junction dots must appear at every T-junction or crossing where wires are electrically connected. Wires that cross without a junction dot are NOT connected. All wires must be clean, orthogonal (horizontal or vertical), and not overlapping. Wire stubs (short dead-end segments) indicate unfinished connections.
This is the visual grammar of schematics - ambiguity in connections equals ambiguity in the circuit.
A missing junction dot at a T-intersection means the connection does not exist in the netlist - even though it looks connected visually. Conversely, an accidental junction where wires overlap creates unintended shorts. These are among the most insidious schematic bugs because they look correct on screen/paper but are electrically wrong. A single missing junction can mean a power rail is disconnected from half the board.
Clear T-junction: VCC_3V3 power rail runs horizontally. Three vertical wires drop down to IC power pins. Each connection point has a visible junction dot. One wire crosses over a signal wire at 90 degrees WITHOUT a dot - clearly not connected. No ambiguity.
Ambiguous crossing: Two wires cross at a point where a T-junction also exists, but no junction dot. It's impossible to tell if this is a 4-way connection, a T-connection, or just two crossing wires. The engineer "assumed" it was connected. The netlist says otherwise. Board fails.
KiCad: Junctions auto-placed in KiCad 7+. Check Place > Junction for manual placement. Edit > Cleanup Schematic to find off-grid wires. Use View > Grid to verify alignment.
Altium: Auto-junction on T-connections. Use Edit > Toggle Cross-Over to differentiate crossing wires. Reports > Net Status for connectivity verification.
OrCAD: Junction dots auto-placed at T-connections. Verify with DRC. Use Place > Wire to redraw suspicious connections. Check View > Zoom to verify dots are present.
Bus notation groups related signals (like data buses, address buses) into a single thick-line symbol on the schematic, with individual signals branching off via bus entries. The bus name and member naming must follow the tool's specific syntax (e.g., DATA[0..7] in KiCad, DATA[7:0] in Altium) and all bus members must be explicitly connected.
Buses simplify the visual representation of parallel interfaces without reducing electrical connectivity.
Incorrect bus notation can silently drop signals - if the bus is defined as DATA[0..7] but a branch label says DATA[8], it is NOT part of the bus and may become floating. Bus syntax errors can cause the entire bus to fail connectivity checks or, worse, create incorrect connections between mismatched signals.
Memory data bus: Bus drawn as thick line labeled DATA[0..7]. Eight bus entries branch off with labels DATA[0], DATA[1], ... DATA[7] connecting to MCU port pins PA0-PA7 and SRAM D0-D7. All 8 signals verified in netlist.
Mismatched bus: Bus labeled "DATA[0:7]" (colon notation) but tool requires "DATA[0..7]" (dot notation). Tool treats it as a single net named literally "DATA[0:7]" instead of expanding to 8 individual nets. All 8 MCU pins connect to one net (massive short). Or: Bus has 8 members but only 6 branch labels exist - 2 signals are floating.
KiCad: Bus syntax is {SIGNAL1 SIGNAL2 SIGNAL3} for named buses or DATA[0..7] for vector buses. Place > Bus. Use Bus Member tool (Place > Wire to Bus Entry).
Altium: Bus syntax is DATA[7..0]. Use Place > Bus. Net labels on branches must match: DATA0, DATA1... or DATA[0], DATA[1]... depending on configuration.
OrCAD: Use Place > Bus. Bus names like DATA[0:7]. Bus entries connect with Place > Bus Entry. Verify in DRC that all bus members have connections.