- Generated by
1.15.0
|
TraceMaker
C++ API of the engine
|
| advice | |
| advice.hpp | The advice file (design doc 17, issue #26): typed hints for the router, written by a person, a script or a language model, and read by the engine like any other input |
| advisor.hpp | The advisor protocol (design doc 17 §5): an advisor is any executable that reads a stuck report (JSON) on stdin and writes an advice file (JSON) on stdout |
| stuck_report.hpp | The stuck report (design doc 17 §3, issue #26 stage 0): what failed and why, as JSON that an advisor (a person, a script or a model) can act on |
| analysis | |
| footprint_check.hpp | Footprint check against datasheet land patterns (issue #5, docs/05-routing.md §43, D115) |
| footprint_ref.hpp | Datasheet land-pattern references and the list of brands whose datasheets are trusted (issue #5, docs/05-routing.md §43, D115) |
| region.hpp | The reference copper of one layer as a queryable region (issue #7, docs/05-routing.md §42): the geometry of the return-path audit |
| return_path.hpp | Reference-return audit of high-speed nets (issue #7, docs/05-routing.md §42, D114) |
| app | |
| defects.hpp | Deterministic defect injection for DRC parity on broken boards (design doc 03 §6, roadmap M2): takes a routed board and adds one kind of defect a given number of times (shorts between nets, dangling tracks and vias, cut connections), so TraceMaker's classification of each defect can be compared with kicad-cli's |
| inspect.hpp | |
| route_job.hpp | One tracemaker route run as a reusable function, shared by the CLI (src/app/main.cpp) and the Python bindings (bindings/), so both take exactly the same code path (design doc 08 §5) |
| tui.hpp | |
| core | |
| events.hpp | Event sink for live visualisation and replay (design doc 02 §7, protocol in docs/13-viewer-protocol.md) |
| hd.hpp | TM_HD marks functions that must compile identically for host and device |
| parse_double.hpp | |
| rng.hpp | Deterministic, counter-based random numbers (design doc 02 §6.2) |
| units.hpp | |
| version.hpp | |
| crules | |
| catalogue.hpp | Component-rule catalogue (design doc 15 §6.1): categories of components with their detectors, roles and layout rules |
| critical.hpp | Critical nets, from what the board's parts are (issue #24, docs/05-routing.md §44, D117) |
| detect.hpp | Category detection and role binding (design doc 15 §3): each footprint is scored against every category's detectors (integer weights, confidence = min(100, sum)); a category instance is the anchor footprint plus the parts, pads and nets that play each role |
| engine.hpp | From detected instances to effective rules and engine inputs (design doc 15 §3.5, §5.5, §7): evaluate -> every catalogue rule of every instance, tagged applied / satisfied-by-board / not-applied(reason) / advisory, with a measured value where TraceMaker can measure it; compile -> placement pseudo-nets (pad pairs), keep-out rule areas for the router and DRC, and a sidecar .kicad_dru with the generated custom rules; report -> the text and JSON the user sees |
| impedance.hpp | Closed-form transmission-line impedance for PCB traces (design doc 15 §5.3) and the IPC-2221 width for current (§5.4) |
| impedance_rules.hpp | Impedance and current rules on a real board (design doc 15 §5.3-5.4, P4): the board stackup gives, per routing layer, the line structure and the dielectric to the nearest reference layer; the closed forms of impedance.hpp turn a rule's target (z0_ohm / zdiff_ohm) into a width and gap |
| names.hpp | Name conventions used to recognise parts and nets (doc 15 §3.1): reference letters, power and ground net names, natural sort of references, component values |
| overrides.hpp | The user override file (design doc 15 §3.5 level 1, §6.3): the user disables rules, forces or forbids a category on a part, or changes a rule parameter |
| topology.hpp | Netlist views of a board for component recognition (doc 15 §3.1 "Topology", §8.0 topology detectors): pads per net, nets per footprint, part kinds from reference letters, and the decoupling-capacitor ties of decision D25 |
| drc | |
| connectivity.hpp | Copper connectivity with KiCad's semantics, shared by the DRC (unconnected/dangling checks) and the router (which pads are already joined) |
| copper.hpp | Copper items with exact shapes, built from the board model, for DRC and routing obstacles |
| drc.hpp | Design-rule checker equivalent to KiCad's for routing-relevant rules (design doc 03 §6) |
| refill.hpp | Zone refill in the engine (doc 05 §36): the fills KiCad 10's zone filler would draw for the board's current copper, so connectivity can be judged as kicad-cli pcb drc --refill-zones judges it |
| rule_engine.hpp | Resolves KiCad constraints for pairs of copper items (design doc 03 §6): net-class clearances, local pad overrides, board minimums and custom .kicad_dru rules with their conditions |
| rule_geometry.hpp | Positional custom-rule predicates |
| geom | |
| clip.hpp | Polygon booleans and offsets on integer nanometres, a thin wrapper over Clipper2 (Angus Johnson, 2022; the Vatti scan-beam clipper, 1992) |
| point.hpp | Integer-nanometre points and KiCad-compatible rotation |
| poly_index.hpp | Bucketed edges of one large closed polygon (a zone fill), so "does this disk touch the polygon?" costs the edges near the disk instead of every edge |
| shape.hpp | Exact integer geometry for clearance checks (design doc 03 §1) |
| gpu | |
| device.hpp | GPU discovery and memory admission control (design doc 07 §4) |
| field.hpp | Cost-to-go fields for the router (design doc 05 §5.2, doc 07 §2): exact shortest-path distances from a set of target lattice points over a window, on an octilinear multi-layer lattice with through-via moves |
| metal_private.hpp | |
| philox_fill.hpp | Fills an array with draws 0..n-1 of the RNG stream (seed, stage, item) |
| index | |
| uniform_grid.hpp | Uniform spatial hash grid over a bounding box (design doc 03 §2): O(1) insert, box queries return each id at most once per query via a generation stamp |
| io | |
| kicad | |
| srj | |
| learn | |
| knowledge_base.hpp | Persistent knowledge base (design doc 06 §4, failure-memory tier T3): what was learned on earlier runs |
| model | |
| board.hpp | The board model (design doc 02 §3): every object TraceMaker reads from a .kicad_pcb, in absolute integer-nanometre coordinates, with a link back to its s-expression node for lossless writing |
| netlist.hpp | Schematic connectivity as exported by KiCad (kicad-cli sch export netlist –format kicadsexpr) |
| rules.hpp | Design rules as KiCad defines them (design doc 08 §3–4): board minimums and net classes from the .kicad_pro project file, plus custom rules from the .kicad_dru file |
| stackup.hpp | The board's physical stackup as KiCad stores it in (setup (stackup ...)) (design doc 15 §5.3): read-only, used to turn impedance rules into widths and gaps |
| passes | |
| stitch.hpp | Stitching vias (doc 05 §39.3): after routing, vias of a plane's net are added where fills of that net lie over each other on two or more layers (plane stitching), and next to the vias of signals that need a reference plane (return-path stitching) |
| style.hpp | Style metric (doc 05 §39.2): how tidy a set of tracks is, per connection and per board |
| widen.hpp | Power track widening (doc 05 §39.1): after routing, new tracks that are narrower than they should be are made wider where the exact check allows it |
| place | |
| anneal.hpp | (E) Detailed placement by simulated annealing (design doc 04 §3 E; Kirkpatrick, Gelatt, Vecchi, Science 1983; move set after TimberWolf, Sechen & Sangiovanni-Vincentelli, IEEE JSSC 1985) |
| anneal_state.hpp | Internal: the incremental annealing state shared by simulated annealing, parallel tempering, large- neighbourhood search and exact windows (anneal.cpp, tempering.cpp, lns.cpp) |
| congestion.hpp | Routability estimate for placement (design doc 04 §3 B R(x), E β·RUDY overflow, G) |
| global.hpp | Global placement (design doc 04 §3 A–C) |
| legality.hpp | Placement legality (design doc 04 §3 D/E): exact integer tests of courtyards, through-hole obstacles, the board outline, keepouts and pad-to-edge clearance, plus a bucket index of placed parts and a conservative occupancy raster used as a fast path by the legaliser |
| legalize.hpp | (D) Legalisation (design doc 04 §3 D): Tetris-style greedy, largest parts first, each part moved to the nearest legal position (minimum Euclidean displacement over a lattice searched in rings) from its target |
| lower_bound.hpp | Exact lower bound on weighted HPWL (design doc 04 §1 level L4) |
| placer.hpp | The placement pipeline (design doc 04 §3): full runs A (quadratic B2B) → B (SimPL spreading) → C (rotations) → D (legalisation) → E (annealing); refine starts from the current placement and runs D (only for illegal parts) → E |
| problem.hpp | Placement problem extracted from a board (design doc 04 §2): parts with courtyards, holes and pins per rotation, weighted nets, the board outline, keepouts and spacing rules |
| routable.hpp | Router-in-the-loop placement (design doc 04 §3 G) and ECO placement (doc 04 §4) |
| wirelength.hpp | Wirelength and airwire metrics: weighted half-perimeter wirelength (HPWL) and crossings between the minimum-spanning-tree airwires of different signal nets (doc 04 §3 E) |
| route | |
| bundle.hpp | Bundle (river) escapes (design doc 05 §50) |
| bus.hpp | Buses (design doc 05 §38): groups of nets that belong together (a data bus, an address bus, a parallel display interface) |
| diff_pair.hpp | Differential pairs (design doc 05 §9 phase 3, §15): the geometry rule a pair is routed at, and a measurement of how a routed pair came out (coupled share, gap, intra-pair skew) |
| escape.hpp | Escape (fanout) planning, version 1 (roadmap M9; design doc 05 §3) |
| escape_flow.hpp | Escape planning, version 2 (roadmap M9; design doc 05 §3 and §14): min-cost-flow channel assignment for deep ball-grid arrays, layer by layer |
| global_router.hpp | Global routing on a coarse 3-D tile graph (design doc 05 §4 and §19, roadmap M6; CPU, the only path: §19 shows why there is no GPU version) |
| heat_grid.hpp | Coarse accumulation grid behind the viewer's heatmap overlays (design doc 09 §3 "Heatmap overlays", protocol doc 13 heatmap) |
| layer_limits.hpp | Which copper layers may carry new tracks, and what a track costs on each (doc 05 §29): the user's --no-tracks-on and --layer-cost lists turned into the numbers RouterOptions holds |
| legalize.hpp | Gridless legalisation of routed copper (doc 05 §41.3, D104) |
| obstacles.hpp | Obstacle model for routing: every copper item, hole, board edge and keepout, with exact legality tests that use the DRC's rule engine, so the router and the DRC can never disagree about what is legal |
| ref_map.hpp | Where a track is over a void of its reference plane (issue #24, docs/05-routing.md §44, D117) |
| router.hpp | TraceMaker's detailed router, version 1 (roadmap M4; design doc 05 §2, §5) |
| server | |
| messages.hpp | Builders for viewer protocol v1 messages (docs/13-viewer-protocol.md) |
| replay_log.hpp | Replay log (design doc 09 §2, decision D45): the viewer protocol's JSON messages, one per line, each with a leading "t" (seconds since the recording started) |
| viewer_server.hpp | HTTP + WebSocket server for the live viewer (design doc 09, protocol in docs/13-viewer-protocol.md) |
| session | |
| session.hpp | A board session an agent can drive (design doc 19, milestone M18) |
| transport.hpp | The two ways to talk to a Session (design doc 19 §6) |
| sexpr | |
| sexpr.hpp | Lossless s-expression documents for KiCad files (design doc 08 §3) |
1.15.0