EEE Simulator is a planned browser-based, Applied Physics-driven, hierarchical, multi-fidelity electronics and computer simulation platform designed to connect reviewed physical principles to mathematical models, engineering equations, numerical algorithms, reusable component models, realistic circuit simulations, integrated devices, educational processors, and complete computer systems. Each technical link remains unverified until it satisfies the repository's source and evidence gates.
The platform is intentionally not a promise to simulate every transistor in a modern CPU, GPU, or RAM device at full electrical and thermal fidelity in one browser tab. It combines detailed circuit simulation where scale permits with switch-level, event-driven, RTL, architecture, and ISA-level models where higher abstraction is necessary. This is an adopted repository scope decision whose planning origin is recorded by the legacy source-brief citation; that citation is not technical proof. [Source PDF, pp. 1-4, 12-16, 43-44]
The normative development chain is:
Physical Principles -> Mathematical Models -> Engineering Equations -> Numerical Algorithms
-> Primitive Models -> Composite Models -> Library Devices -> Circuits and Boards
-> Complete Systems -> Experimental Validation
Applied Physics informs every fidelity tier. R4 does not introduce physics for the first time; it applies real-world non-ideal, electrothermal, environmental, manufacturing, parasitic, uncertainty, aging, interconnection, source, instrument, and failure behavior to the foundations established earlier.
The first production target is the Realistic Electronics MVP: a visual schematic editor with voltage/current measurement, transient waveforms, non-ideal component behavior, heating, tolerance, leakage, failure indication, basic logic, reusable subcircuits, a WebAssembly simulation engine, and Worker-based execution. Released basic components also receive recognizable physical representations, and ICs use reusable, independently customizable package definitions with explicit pin mappings. CPU, GPU, and full-computer capabilities follow only after this gate succeeds. [Source basis: PDF, pp. 22-23, 26-27, 30-37; the representation and package contracts are repository decisions.]
The long-term learning path is:
Component -> Circuit -> Logic -> CPU block -> Small CPU -> Small computer -> Architecture platform
This staged path is an adopted repository delivery decision originally suggested by the unverified source brief. Its technical assumptions and gate results require independent evidence. [Source PDF, pp. 39-41]
- Next.js/React and TypeScript for the web product.
- Canvas 2D as the default editor renderer, WebGL2 for scale and visualization, SVG for standards-friendly export, and WebGPU only for benchmark-proven workloads.
- A Rust simulation core compiled to WebAssembly, with simulation and waveform work off the main UI thread.
- Small and interactive work runs locally first; large SPICE, RTL compilation, Monte Carlo, thermal, architecture, and GPU jobs run in isolated server workers. [Source PDF, pp. 22-26]
- A deterministic, timestamped scheduler coordinates analog, digital, thermal, RTL, and external engines. [Source PDF, pp. 27-28, 40]
- Apache-2.0 for the open-source core. GPL or mixed-license engines remain behind executable or process boundaries pending distribution review.
These decisions are recorded in the complete ADR-0001 through ADR-0020 decision index.
Start with docs/START_HERE.md. The most important contracts are:
- Product requirements
- Normative source and evidence policy
- Physical representation and IC package requirements
- Physical appearance and reusable package contract
- Device/package binding and pin-map contract
- Reusable package registry
- System architecture
- Applied Physics and real-world fidelity
- Hierarchical model and library architecture
- Data-driven library and storage architecture
- Component registry
- Scientific model registry
- Variant pin-profile guide
- Normative variant pin-profile registry
- Normative variant semantic-profile registry
- Normalized parameter-definition catalog
- Component model contract
- Master roadmap
- Atomic task index
- Atomic task contract
- Stable test catalog
- Requirements traceability
- Release gates
The baseline catalog tracks 162 canonical component families, 502 built-in variants/presets, 502 exact PinProfiles, 502 semantic profiles, 801 normalized planning parameter definitions, 38 reusable package templates, and nine planned scientific seed models. These are separate inventories and do not claim executable completion or every manufacturer SKU. Vendor parts are ingested through generic-device inheritance, bounded parameter overrides, exact package/pin bindings, provenance, license, and validation evidence. Scientific-model counts include only records actually enumerated in the model registry; the project makes no speculative claim of thousands of completed models.
This repository currently contains the documentation foundation only. It does not yet contain application code, runtime configuration, migrations, or deployment assets.
The frozen planning baseline enumerates 63 requirements, 20 accepted ADRs, 37 platform epics, 477 platform tasks, 2,636 component/package tasks, 66 golden validation tasks, and 129 stable requirement/golden tests. The resulting 3,179 atomic task cards are future work specifications, not implementation or passing evidence. PLAT-QA-001 is the sole initial Ready task; every other card remains Planned, Deferred, or otherwise gate-controlled until its exact dependencies and evidence qualify it.
Read CONTRIBUTING.md before taking work. Future contributors and AI agents must select one Ready atomic task and keep its tests, catalog coverage, and requirements traceability synchronized. See AGENTS.md for the exact workflow.
Please report vulnerabilities according to SECURITY.md. Community participation is governed by CODE_OF_CONDUCT.md.
The principal planning brief is Web-based Electronics and Computer Simulation Platform, 44 pages. Page references use [Source PDF, p. N], [Source PDF, pp. N-M], or [Source basis: PDF, ...] only to preserve source-brief and scope lineage. The PDF is not a confirmed technical source and cannot by itself establish equations, standards, accuracy, licensing, security, implementation truth, or release evidence. See the normative Source and Evidence Policy. Applicable official/primary sources, physical evidence, and current project results are required before technical work becomes Ready or an artifact becomes Validated or Released.
The repository's open-source core is licensed under Apache License 2.0. See LICENSE and NOTICE.md. Third-party models, datasets, symbols, tools, and engines retain their own terms and require provenance and compatibility review.