What you can do in Tapeo

Tapeo is a browser workspace for digital hardware projects. It combines editable project files, optional AI assistance, simulations, and shared engineering tools managed by Tapeo.

The copper and signal-green interface follows the path from a hardware idea to manufactured geometry. The animated chip, the “prompt to silicon” console, and the five-stage 3D journey on account pages are illustrative product motifs; they are not project simulations or physical-analysis results. The FPGA Lab and Marketplace shown there are coming soon and not available yet.

1. Describe

   Explain the hardware you want in Architect chat. Add behavior, interfaces, constraints, and any technology preference you know.

2. Choose

   Review the requirements and architecture choices. Accept one to create the project.

3. Follow

   The first-run workflow generates project files and starts the available stages. Follow status, files, tool logs, and blockers in Workflow.

4. Improve

   Inspect the design in other tabs, edit files, ask AI Engineer for help, update goals, and rerun stages after changes.

Tool availability depends on the configured runners, the selected technology platform, and the design files and process data available for that project. A step can finish, fail, be skipped, remain blocked, or be unavailable.

• Describe. Tell the Architect what you want to build. You can attach a sketch, block diagram, or datasheet (image or PDF), or add your own Verilog/SystemVerilog/VHDL files to start from. Answers appear as they are written; Stop ends one early. Full screen gives the conversation the whole window.
• Answer a few questions. When details are missing, the Architect asks short questions with answers to click. “Not sure — you choose” lets it pick a sensible default, which it lists as an assumption.
• Choose. You get a design brief (what you asked for, what it assumed, how you will know it works, what is not included) and 2–3 options compared on area, speed, power, and complexity, with one recommended.
• Review the plan. Review build plan shows every stage the first run will attempt for your process and whether it will run, needs an input, or will be skipped. Change something asks for a change; the brief and plan update. Nothing is built until you press Build this.
• Build. The project is created and the first workflow run starts. If you added your own files, they are kept unchanged and protected; the AI only adds what is missing, such as a testbench and constraints. The conversation stays in your browser until you build or start a new one.
• AI Engineer can review project files and tool output, propose code or plan changes, explain failures, and help repair files. Its answers appear as they are written; Stop ends one early. Proposed edits can be reviewed before they are applied; first-run automation can apply bounded repairs that the user has authorized.
• AI-generated code and plans are starting points. The evidence comes from the tools that actually run, not from the AI's description.

When an architecture is accepted, the initial workflow attempts the configured design stages in order. It records what each stage consumed and produced, and passes usable artifacts forward.

AI Engineer can use actual error output to propose repairs and retry supported stages, with a bounded number of attempts. It continues independent available work when a stage cannot run. Workflow runs are saved and executed by the server-side worker, so closing or refreshing the browser does not stop an active run. This does not guarantee every project completes every stage.

Workflow states communicate whether a step has run, is running, failed, is blocked by prerequisites, was skipped, has no generated file, or is not integrated. “Not integrated” means the app does not currently run that part as an automated stage.

Workflow builds the design; Evaluation tells you whether its goals are met. To change something after a run:

1. Find the file. Select a stage on the Workflow map. Inputs used and Outputs list each file with who last changed it: You, AI, or Tool. Click a file name to open it in Code.
2. Edit it. Your edit is saved automatically and protects the file: automatic AI repairs will only suggest changes to it, never apply them. Use the lock button in a stage panel, or Protect from AI in Code, to change this.
3. Rerun. Workflow shows a banner such as “You changed constraints/top.sdc after Pre-route timing ran” with Run from Pre-route timing. You can also use Run this stage (one stage) or Run from here → (that stage and every later one) in any stage panel. Goals measured by the rerun stages get new results automatically, so Evaluation stays up to date; your goal list is never changed. Tick “Let the AI Engineer repair failures” if you want automatic repairs of unprotected files.
4. Review what the AI changed. The run report lists files the AI Engineer changed, with View change and Revert, and suggested changes to protected files, with Review and Apply.
5. Go back if needed. Project history (Workflow header, or the history icon above the file tree) lists checkpoints by You, AI Engineer, or Tool, shows what each changed, and restores a file to its earlier or later content. Your edits get their own checkpoint when a workflow run starts.
6. Check your goals. Evaluation already shows the results from your rerun. A result is marked stale only when one of its inputs changed and no rerun stage measured it; rerun that stage, or use Verify in Evaluation.

Evaluation goals describe behavior or measurable limits the design should meet. A goal has a name/metric key, target, comparison, unit, and optional verification plan.

• Numeric target: compare a measured number against a limit using at most, at least, exactly, or an inclusive range.
• Behavior goal: describe expected behavior in text. AI Engineer can translate it into a testbench check; it passes only when the supported run produces matching evidence.
• Goals can be added, edited, removed, planned, and run again. “Prepare / update plan” chooses a compatible adapter, project inputs, and a measurement. “Run saved plans” executes the saved steps; preparing a plan does not itself run the check.
• AI can derive behavior goals from requirements and project behavior. It may only keep a tool goal when a compatible run reports the exact expected metric; it must not invent performance targets or measurements.
• Reports distinguish pass, failure, missing inputs, tool errors, stale evidence, and checks that need review. A result is stale when one of its own input files changed after it was measured. Scenario coverage appears only when the testbench emits named coverage records; it is not automatic code coverage.
• Each measured result names its tool and links to the Workflow stage that produced it (Measured in Workflow → stage), where you can inspect and rerun that stage.

Available adapters include the configured simulation, synthesis, timing, physical design, and signoff tools. A goal is not automatically testable just because its metric sounds useful: the tool must be able to measure it and the required files/resources must exist.

The Logic view can show a rendered view of an exported GDS layout when the project has one and the layout renderer is available. This is a visual aid for inspecting geometry, not an interactive chip editor or a manufacturing approval.

The physical design summary reports values when they can be extracted from saved tool runs: placement/routing state, die and core dimensions, utilization, placed instances, estimated or measured wire length, vias, and DRC results. Some fields may say “not reported” because a particular flow does not emit that measurement. The UI should not fill those gaps with guesses.

The layout viewer supports 2D inspection and an illustrative 3D layer stack. Fullscreen, fit and zoom controls, box zoom, layer visibility, cell/net selection, and saved-run comparison help inspect the exported geometry. Dense 3D layouts also have a progressive placement overview: large placed instances and sampled logic regions can be selected to focus the scene and reveal local GDS detail. These regions are inferred from physical placement, not RTL module hierarchy; counts may be incomplete when the layout cell sample is capped. Small flat layouts continue to open in full detail. The 3D layer spacing is exaggerated and is not a to-scale cross-section.

For explicitly instantiated hard macros, the selected process pack may declare verified power-grid via stacks from the macro LEF supply-pin layers to a named platform PDN grid. Tapeo inserts those connections before OpenROAD generates the grid; it does not infer metal layers or reuse another process setup.

When a saved simulation waveform and DEF routes are available, the 3D view can replay a selected signal against a selected routed net. It shows the VCD value and time, and labels the signal-to-net match as exact, inferred from a bus range, manually selected, or unmatched. Its moving marker illustrates timeline position on the route; it does not model propagation or delay, and the VCD and route are not a timing-aware co-simulation. A manual pairing is not proof of electrical connectivity.

Use 2D for precise geometry inspection and 3D to understand layer order and routed connectivity. Neither view replaces DRC/LVS, timing or power analysis, process-qualified signoff, or foundry approval. Cell/net selection does not provide a guaranteed trace back to RTL hierarchy.

Most hardware does not run programs. The Software tab tells you which kind of design you have. Fixed-function logic, accelerators, sensors, neuromorphic arrays, and other non-processor hardware are exercised by simulation in Workflow and Evaluation, so they get no Assembly or C tab. If a design does contain a processor, set its execution model to Programmable CPU / MCU under Advanced settings.

1. Set up this CPU (Software tab). The AI Engineer writes tb/firmware_tb.sv for your CPU and finds its RISC-V instruction set (for example RV32I, RV32IM, RV32E) and memory map. A built-in instruction test then runs every base instruction (plus M-extension instructions when present) and enables assembly. Two C self-tests enable C. If the CPU computes something wrong, setup names the instruction, for example sra … expected ffffffff, got 00000001.
2. Assembly tab. Build and run a program and read its output. Programs can run even before the instruction test passes, so you can debug the CPU; the tab warns you.
3. C programs tab. Available when the status is Assembly + C ready.

• Changing the RTL or the CPU settings shows Needs recheck. Recheck this CPU repeats the checks. Changing compiler flags does not require a recheck.
• CPUs with a custom instruction set use the custom-ISA assembler with your isa.json; C is not available for them.
• “Ready” means the current RTL passed these built-in checks in simulation, for the listed extensions only. It is not a complete ISA audit, operating-system compatibility, formal equivalence, or safety certification.

Project files live in a virtual project tree and are stored with their project. Generated flows and results use project-relative folders such as rtl/, tb/, analysis/, generated/, and signoff/. Exact paths depend on the project and flow.

Files generated by a tool or AI are kept visible as project artifacts. Review generated constraints, flow scripts, mapped netlists, and reports before relying on them for a design decision.

Integrated runners currently cover Icarus Verilog for simulation, Yosys for synthesis/mapping, OpenSTA for timing, OpenROAD for physical design, and signoff-related integrations such as KLayout, Magic, and Netgen. RISC-V toolchain support is available for relevant software workflows. Integrated tools are enabled for every user; Tapeo manages shared runner images and starts isolated jobs automatically. A runner can still be unavailable when the server is not configured or its image is missing.

Technology platforms represented in the app include SkyWater 130 HD/HS, GF180 MCU, IHP SG13G2, educational Nangate45, and ASAP7 manual/multi-library setup. A platform record or bundled runner resource does not mean every check is supported for that process.

Yosys uses one selected Liberty file to map generic logic into standard cells. OpenSTA can analyze multiple compatible Liberty corners when the project timing Tcl loads the selected libraries, defines and evaluates a timing scene for each corner, and reports measurements tagged with each scene name. Workflow shows how many compatible corner files were inputs separately from which corners produced measurements. Uploading or selecting several libraries alone does not run multi-corner analysis.

Physical design and signoff also depend on process-specific data such as LEF/GDS libraries, technology files, DRC rule decks, extraction rules, and LVS setup. These files must correspond to the same process and release. Bundled exploratory decks may cover only part of the rules. KLayout DRC has a 30-minute default timeout and can be configured up to 60 minutes; a timeout or missing report remains unknown rather than zero. When no reference netlist is attached, workflow can freshly synthesize one from the saved RTL and matching Liberty before LVS. Gate-level Verilog references use the matching standard-cell SPICE/CDL library. Referenced hard macros declared by the selected process pack are compared as pin-compatible blackboxes at the layout boundary to avoid expanding large memories; this does not validate macro internals. Magic duplicate-cell and electrically-shorted-port warnings are surfaced for review; they do not by themselves establish a clean extraction.

Tapeo currently provides email and password accounts, sign-in, account creation, and password reset. Projects are associated with the signed-in account. Design tools are shared and enabled for all users; the header's Design tools panel reports server-managed runner status, and users do not add tools or start runners themselves. Email verification and password-reset delivery require the deployment's email settings.

Select your name in the header to open the Account page: your details, plan, and how many projects and files you have. To delete your account, use Delete account there and confirm with your password. It immediately and permanently removes your projects and everything in them (files, history, simulations, tool runs, layouts, Engineer chats), your Architect attachments, usage history, feedback, waitlist sign-ups, and sign-in details, and signs you out. Download anything you want to keep first.

Docs, the plans page, and the example projects are public. Creating and changing your own projects requires an account. The Privacy Policy explains what is collected and how to get a copy of your data or delete your account; the Terms cover using the service.

New accounts start a free 14-day trial. No card is needed. The header shows a small meter with the days and builds you have left; select it for the full picture.

Trial builds try one automatic AI repair per failing stage, and do not repair and rerun after goal verification. If a stage still fails, you can fix the file yourself or ask the Engineer, then rerun just that stage.

Found a problem or have an idea? Use Feedback in the workspace header; the page you are on is attached so we can find it. Paid plans are not available yet. The plans page describes the planned Pro plan and lets you join its waitlist. Your projects stay yours when a trial ends: you can still open, edit, and download them.

Examples are finished designs that went through the whole workflow. Anyone can open them, without signing in, in the same workspace you use for your own projects.

These features are on the roadmap. They are not available yet; nothing described here can be used today.

FPGA Lab: one design, your choice of destination

The Marketplace

• A simulation pass means the executed testbench reported success for the tested cases; it does not prove all possible behavior correct.
• Timing, area, power, temperature, and physical metrics are only available when the corresponding tool flow produces a measurement with suitable inputs. RTL simulation does not measure silicon power, temperature, or physical timing.
• A DRC result is only as broad as the exact deck and settings used. A reported zero is not a complete foundry DRC pass if the deck is partial.
• Layout extraction and LVS require process-specific inputs and a valid reference netlist. Missing prerequisites remain blockers.
• An engineering handoff archive is useful for review and continued engineering work, but it is not automatically a foundry-qualified tapeout package.

RTL / HDL

The code that describes the digital hardware, usually Verilog or SystemVerilog.

Testbench

A simulation program that drives inputs into the design and checks its outputs.

Synthesis

Converts RTL into a gate-level logic representation.

Liberty file

A standard-cell library description used for cell mapping and timing characteristics.

SDC

Timing constraints such as clocks and input/output delays.

PDK

A process design kit: technology files and rules needed to design for a particular manufacturing process.

GDS

A geometric layout database commonly used to represent physical chip shapes.

DRC

Design-rule checking: tests layout geometry against a rule deck.

LVS

Layout-versus-schematic: compares a netlist extracted from layout with a reference netlist.

SPEF / parasitics

Estimated resistance and capacitance of routed wires, used for more realistic timing analysis.