Platform Architecture

OpenForge EDA is a cloud-native electronic design automation platform built on open-source foundations, specifically optimized for post-quantum cryptographic hardware development. This document describes the platform's layered architecture, from the user-facing orchestration interfaces down through the verification engine pods and data storage layer.

Architecture Overview #

The platform is organized into four horizontal layers. User requests enter through the Orchestration Layer, are scheduled by the Job Scheduler, dispatched to specialized Verification Engine Pods, and results are persisted in the Data & Results Layer.

Orchestration Layer #

The Orchestration Layer provides four interfaces for interacting with OpenForge. All four interfaces communicate with the same backend API and job scheduler, ensuring consistent behavior regardless of access method.

Web UI (React + TypeScript)

The Web UI is a single-page application built with React, TypeScript, and Tailwind CSS. It integrates the Monaco Editor (the same editor powering VS Code) for in-browser RTL editing with SystemVerilog syntax highlighting and openforge.yaml schema validation. The waveform viewer renders VCD/FST traces using WebGL for high-performance display of large simulation runs.

REST API (FastAPI)

The REST API is the backbone of OpenForge. Built with FastAPI (Python), it provides full CRUD operations for projects, job submission and monitoring, result retrieval, webhook registration for CI/CD event notifications, and OpenAPI/Swagger documentation auto-generated from type annotations. Internal service communication between pods uses gRPC for performance-critical paths.

CLI Tool (Python)

The openforge CLI is a Python package distributed via pip. It wraps the REST API for terminal-based workflows and adds local-only capabilities like running verification directly on the host machine without the server infrastructure. The CLI supports both local and remote execution modes. See the CLI Reference for the full command catalog.

CI/CD Hooks

OpenForge provides native integration with GitHub Actions, GitLab CI, Jenkins, and Azure DevOps. CI/CD hooks trigger verification runs on push, pull request, or scheduled events. Results are reported back as check statuses, PR comments, and SARIF security findings. See the CI/CD Integration Guide for setup details.

Job Scheduler & Workflow Engine #

The Job Scheduler receives verification requests from the Orchestration Layer and dispatches them to the appropriate Verification Engine Pods. OpenForge supports three scheduling backends depending on deployment scale:

Workflow Execution Model

A full verification run executes as a directed acyclic graph (DAG) of tasks. The scheduler respects dependencies — formal verification can start only after synthesis completes, but simulation and linting run in parallel from the start. The crypto security checks run in parallel with each other but depend on simulation completing first (to collect power traces for the side-channel simulator).

# Simplified workflow DAG for a full verification run

    ┌───────────┐
    │   Lint    │───────────────────────────────────────┐
    └─────┬─────┘                                       │
          │ (parallel)                                   │
    ┌─────▼─────┐     ┌──────────────┐                  │
    │Simulation │────▶│ Power Traces │──┐               │
    └─────┬─────┘     └──────────────┘  │               │
          │                              │               │
          │  ┌──────────────┐     ┌─────▼──────┐       │
          │  │ CT Verifier  │     │ SCA Sim    │       │
          │  └──────────────┘     └────────────┘       │
          │  ┌──────────────┐     ┌────────────┐       │
          │  │ NTT Validate │     │ FIPS Check │       │
          │  └──────────────┘     └────────────┘       │
          │  ┌──────────────┐                           │
          │  │Entropy Check │                           │
          │  └──────────────┘                           │
          │                                              │
    ┌─────▼─────┐     ┌────────────┐                    │
    │ Synthesis │────▶│ Timing/STA │                    │
    └───────────┘     └──────┬─────┘                    │
                              │                          │
                       ┌──────▼──────┐                   │
                       │ Aggregate   │◀──────────────────┘
                       │  Results    │
                       └─────────────┘

Task Isolation

Each verification task runs in its own container with isolated filesystem, memory, and CPU allocation. This ensures that a runaway formal verification engine cannot starve simulation jobs, and provides multi-tenant isolation when multiple users share a cluster. The container images are pre-built with all required tools and pinned to specific versions for reproducibility.

Simulation Pod #

The Simulation Pod handles functional verification through simulation. It integrates five open-source tools, with Dyber extensions to Verilator for power trace instrumentation and taint tracking.

The primary simulation flow uses Verilator for speed — it compiles RTL to optimized C++ that runs 10-100x faster than event-driven simulators. OpenForge adds a --power-trace flag that instruments the compiled model to record Hamming weight and Hamming distance per signal per clock cycle, generating the power traces used by the Side-Channel Simulator. The --taint-track flag propagates secret annotations through the dataflow graph at compile time to detect constant-time violations statically.

Formal Verification Pod #

The Formal Pod provides exhaustive property checking — proving that assertions hold for all possible inputs, not just the ones tested in simulation.

OpenForge ships the Cryptographic Property Library — a collection of pre-written SVA (SystemVerilog Assertion) templates for common cryptographic verification patterns. These include constant-time execution properties, key handling properties (zeroization, isolation, write control), FSM integrity properties (valid states, valid transitions, sticky error states), and NTT/polynomial arithmetic correctness properties. The openforge-auto-assert Yosys pass automatically inserts appropriate assertions based on design analysis — detecting key registers, FSM state machines, and NTT butterfly patterns.

Analysis Pod #

The Analysis Pod handles physical implementation analysis: timing closure, power estimation, area estimation, and code quality linting.

The timing analysis flow synthesizes the design with Yosys targeting the specified PDK (SkyWater SKY130 or GlobalFoundries 22FDX), runs placement and routing through OpenROAD, then performs static timing analysis with OpenSTA. Power estimation uses switching activity data (SAIF files) generated by the Verilator simulation stage to provide realistic dynamic power numbers rather than worst-case estimates.

Supported PDKs

Cryptographic Security Pod #

The Cryptographic Security Pod is Dyber's proprietary contribution to OpenForge and the primary differentiator from commercial EDA tools. It contains eight specialized analysis engines that address security verification needs that no existing EDA vendor provides.

These engines run in parallel during the crypto verification stage. Each produces its own report, and results are aggregated into a unified crypto security dashboard. The engines connect to the open-source tools where needed — the Constant-Time Verifier generates SVA assertions and runs them through SymbiYosys, the Side-Channel Simulator consumes power traces from the instrumented Verilator simulation, and the FIPS Checker synthesizes the design with Yosys to verify structural properties.

For detailed usage of each engine, see the Crypto Verification Guide.

Data & Results Layer #

The Data & Results Layer persists all project metadata, verification results, waveforms, and metrics across four storage systems optimized for different data types.

Incremental Verification

OpenForge caches intermediate results in Redis and MinIO. When a design file changes, only the affected verification tasks re-run. The cache key includes a hash of the source files, tool versions, and configuration. This typically reduces re-verification time by 60-80% for incremental changes.

Technology Stack #

Deployment Models #

OpenForge supports three deployment models depending on your security requirements, team size, and infrastructure.

Docker Compose (Local / Small Team)

All services run on a single machine via Docker Compose. Suitable for individual developers or teams of 1-5 engineers. Requires 8GB+ RAM and 50GB+ disk. This is the default deployment described in the Installation Guide.

Kubernetes (Cloud / Medium-Large Team)

Full Kubernetes deployment with Helm charts. Auto-scaling worker pods based on Celery queue depth via HPA custom metrics. Suitable for teams of 5-50+ engineers with shared verification infrastructure. Supports multi-tenant isolation with Kubernetes namespaces and RBAC.

Air-Gapped (Defense / Government)

Offline deployment for classified environments. All container images and PDKs are bundled for transfer via physical media. No external network access required. Supports ITAR/EAR compliance for export-controlled cryptographic hardware designs. This model uses the Celery + Redis backend since Kubernetes is often unavailable in air-gapped environments.

Scaling & Performance #

OpenForge is designed to scale horizontally. The primary bottleneck is verification compute — formal provers and large simulations are CPU-bound. The platform addresses this through parallelization at multiple levels:

For typical post-quantum cryptographic accelerator projects (5-20K lines of RTL), a full verification run including simulation, formal, and all crypto security checks completes in 5-15 minutes on a 4-core Docker Compose deployment, or 1-3 minutes on a Kubernetes cluster with 8+ worker pods.