⏳ This skill is pending AI review.
Scores will appear once the review pipeline completes.
openada
Discover, invoke, and interpret open-source EDA tools through OpenADA's versioned CLI contract. Use for semiconductor or electronics work involving Xschem schematics (.sch), SPICE simulation, GDS/KLayout DRC, Netgen LVS, Verilog/SystemVerilog lint, Yosys ASIC synthesis, OpenSTA timing, PDK discovery, or diagnosing an open EDA environment in Codex, Claude Code, or another terminal-capable agent.
Choose how to use this skill
You do not need every option. Choose the path your AI client supports. The stable page stays the same; versioned files are immutable.
1. Native installer
This listing has no registered native installer command. Use the complete package or source fallback below, depending on what your client supports.
Do not guess an installer command or replace an existing version without reviewing the diff.
2. Complete package recommended
Download the ZIP when available. It includes SKILL.md plus the references, security notes and version metadata.
No complete ProSkills package is published for this listing yet.3. Prompt-only
Copy the prompt above when the agent can read the stable page or when you want to adopt the workflow without installing a skill.
Need only the instruction file?
Download SKILL.md only if your client requires a single file. The complete ZIP is safer for a full installation because it preserves the references and release context.
No path installs or executes anything by itself. Your agent still needs access to the project files. Before updating, compare the installed version and review the diff.
// RATINGS
Not yet listed on ClawHub or SkillsMP
// README
Gelochip
A unified workspace for AI-assisted analog and RF integrated-circuit design.
Gelochip brings together PandaChip Auto Schematic Maker, AnoaChip Auto Layouter, and Gelochip Studio to connect circuit intent, schematic generation, simulation, physical layout, and verification within one project.
The end goal is one website where a designer can develop and review a circuit from specification to verified layout, with a traceable relationship between every design revision and its results. Development starts on localhost, with cloud deployment planned after the integrated workflow has been validated.
Current status: the development branches and both application archives have been consolidated into this repository, and a localhost portal provides access to the three applications. The engines still run independently. Automatic schematic-to-layout transfer, a shared project API, and a unified design interface are planned capabilities.
Project background
Analog and RF IC design connects electrical requirements with physical implementation. A specification must become a circuit topology, device dimensions, bias conditions, and a simulation setup. The circuit then becomes a layout whose placement and routing must satisfy the selected process design kit (PDK). Physical implementation can introduce parasitic effects that require further analysis and design iteration.
These stages produce different artifacts: schematics, SPICE netlists, testbenches, simulation data, layout generators, GDSII files, and verification reports. Keeping those artifacts consistent is a central integration problem. A schematic revision can invalidate an earlier netlist or layout; a change in device models or PDK configuration can alter the meaning of previously generated results.
When each stage lives in a separate application, the designer must manage these relationships manually. Files need to be transferred, input formats reconciled, tool environments configured, and results associated with the correct design revision. The resulting coordination work makes the design process harder to reproduce and review.
Gelochip addresses this problem by bringing existing capabilities into a common platform. PandaChip contributes schematic generation and simulation through xschem and OpenADA. AnoaChip contributes a Glayout-based path toward physical layout and verification. Gelochip Studio contributes design agents and reusable analog/RF building blocks. Consolidating their source is the foundation; the next challenge is to connect their engineering workflows through explicit interfaces and shared project records.
AI supports specification interpretation, candidate generation, and iteration. Engineering acceptance must remain grounded in the circuit's measured behavior and the evidence produced by EDA tools. The platform therefore aims to preserve the connection between a generated design, its inputs, and the checks performed on that exact revision.
This overview follows the conceptual structure requested for a B100-style introduction: background, problem definition, objectives, proposed solution, scope, and acceptance criteria. It is a project overview rather than a formal submission against an institution-specific B100 template.
Problem definition
The project centers on four integration questions:
- How can schematic generation, simulation, layout generation, and verification be coordinated through one website?
- How can the system maintain consistent connectivity, port definitions, device models, voltage assumptions, and PDK selection across engines?
- How can design revisions, execution logs, and artifacts be linked so that each verification result identifies the design it actually checked?
- How can the platform progress from localhost to cloud hosting while preserving existing configurations and design artifacts?
Success requires both a usable interface and a reliable engineering handoff between stages. A common dashboard alone does not establish that a schematic and its generated layout describe the same circuit.
Objectives and intended users
The primary objective is to provide one Gelochip website with one project workspace for the complete analog/RF design workflow.
The platform is intended for Chipathon participants, students, researchers, and developers working with open EDA tools. Its planned benefits are reduced manual file transfer, clearer visibility into design iterations, and easier review of simulation and verification evidence. Improvements in design time, circuit quality, or verification success rate have not yet been measured.
| User need | Intended platform behavior |
|---|---|
| Express circuit requirements | Capture circuit function, performance targets, operating conditions, and design constraints |
| Develop and inspect a circuit | Present the schematic, netlist, device parameters, and simulation results together |
| Continue into physical design | Validate compatible inputs before handing the design to a layout engine |
| Understand a run's outcome | Show execution status, tool logs, artifacts, and engineering check results |
| Revise a design | Track the relationship between input revisions, runs, and resulting artifacts |
| Work locally | Support localhost operation with explicit model, PDK, and EDA runtime configuration |
Proposed platform architecture
The target architecture uses a shared web interface and an orchestration API to coordinate engines with separate runtime environments. This keeps each engine's dependency requirements manageable while giving users a common project experience.
One Gelochip website
|
Project specification and design revision
|
PandaChip: schematic and SPICE netlist
|
Simulation and specification checks
|
AnoaChip / Gelochip: physical layout
|
Layout verification and applicable simulation
|
Reports, artifacts, and design review
|
Revision and another run
The planned orchestration layer must agree on the information exchanged between stages: circuit specifications, connectivity, port names, device parameters, model references, PDK identity, input revision, and artifact locations. It must check that information before launching the next engine and record which inputs produced each result.
The project workspace should also distinguish execution completion from engineering acceptance. For example, producing a GDSII file establishes that a layout artifact was generated. Whether that layout satisfies design rules, matches the intended circuit, and meets performance targets requires the corresponding checks and review.
This architecture describes the development target. The current portal provides navigation and backend availability checks; it does not implement cross-engine orchestration.
Scope and engineering boundaries
The planned scope covers application integration, project and artifact management, schematic-to-layout handoff, and presentation of simulation and verification results for analog/RF designs supported by the selected engines.
PDK and topology support must be established for the actual workflow being used. Availability in one engine does not establish compatibility across the entire pipeline. Likewise, choosing a local or cloud model does not remove the need for suitable EDA binaries, device models, and rule decks.
The first deployment target is localhost. Cloud hosting follows validation of the integrated workflow and its operational requirements. Fabrication readiness requires the applicable signoff process; agent completion, successful simulatio
// HOW IT'S BUILT
KEY FILES