Professional preview features

These features are previews. An account sees one only when Nelix has switched it on for that account; everyone else sees the lab exactly as before. Each was tested on the lab's own server on 10 November 2026 with the designs named below. None of them changes your design files.

Before a build#

Check the clock before you build. When you copy a project to another process, or import one from GitHub, the lab runs its one-minute estimate (the process's real cells, slow corner, no wires yet). If the estimate misses your clock, the Overview says by how much and which period would pass the estimate. The clock stays your decision. Measured on the MAC-8 starter: the estimate was within 1 ns of the finished layout on SKY130 and pessimistic by about 6 ns on GF180MCU, so a real build may do better than the notice says.

Lint before you build. The same copy or import also starts a lint run. If lint fails on an error or a risky warning (a latch, a width mismatch, two drivers on one signal), the Overview shows the count and the first finding. Nothing is blocked.

Room on your disk. A chip build is refused before it starts when your storage clearly cannot hold it, with the free space and the estimate in the message. The estimate comes from this project's earlier builds and its synthesized size. Without this, a build can run for a long time and then stop with "no space left".

While a build runs#

Stage and retries on the build's own page. The page of a running chip build shows the same seven phases as the Overview and the step the tools are on. When the lab builds again by itself (a larger die, or a stronger antenna repair), the page says so, and that each attempt has its own time limit. Everything is read from the build's own log.

Reading results#

The layout's date-free fingerprint. A GDS file carries the time it was written, so two identical builds have different SHA-256 values. The chip report now also shows the SHA-256 with the date stamps set to zero. Two builds of the same design with the same settings give the same value (checked on two builds of the UART TX starter).

Trends. Runs & Compare has a Trends button: worst setup and hold slack, cell area, placed cells, wire length and utilization of every chip build that produced a report, and tests passed in every Simulate, with a CSV download. Every value is copied from the build's own stored report.

Timing constraints#

constraints/clock.sdc may also use create_generated_clock, set_case_analysis, set_max_delay, set_min_delay, set_disable_timing, set_timing_derate and group_path, and a whole bus may be written name[*]. The file is still checked before the build: only plain constraints with object queries are accepted.

A generated clock needs a pin with a stable name. Synthesis renames ordinary flip-flops, so give the divider a name the constraint can point at, for example by instantiating the library flip-flop yourself (u_div) and writing [get_pins u_div/Q]. Tested on SKY130 with a divide-by-two clock, a case analysis, a maximum delay and early and late derates: the build's final constraints and timing reports show the generated clock as its own path group. ASAP7 (learning only) still uses the lab's own clock-only constraints.

Verification#

Formal proof with two engines. The V&V page gets "Formal proof, engine portfolio". It uses the same formal/checks.sv as the first formal check. In prove mode it runs k-induction with the Yices solver first, and when induction cannot close it runs property-directed reachability (ABC pdr). PDR can prove a property for all time where induction cannot at any depth; the row says which engine decided. Depths go to 200 steps and the time limit to 15 minutes. A timeout, an engine that runs out of its 1 GB of memory, or an engine error is "not proven", never a pass. On the lab's test design the first formal check says "not decided: no proof in 20 steps" and this one says "proven for all time by abc pdr".

Clock-domain crossings, bit by bit. With this preview the check "Clock and reset domain crossings" looks at every flip-flop bit on its own and recognises four standard structures by their wiring, never by their names: a synchroniser of two or more flip-flops, a reset synchroniser (asynchronous assert, synchronous release), a toggle or pulse synchroniser (synchroniser, one more flip-flop, XOR), and a Gray-coded bus, the last only when the check can list every reachable state and show that one bit changes per clock. A recognised structure is still listed, as "recognised synchroniser", and no longer fails the check. It is stricter in three places: a multi-bit bus synchronised bit by bit without that Gray proof, two separately synchronised signals that meet in the same logic, and a first synchroniser flip-flop that drives anything except the next stage are all reported as unsafe. Handshakes, whole asynchronous FIFOs and gate-level netlists are not recognised and are reported as unsafe rather than guessed. Tested on the lab's own clock-crossing block, which the standard check fails and this one passes with five recognised rows, and on nine deliberately wrong designs, which all still fail.

Coding style and naming rules. "Coding style and naming rules (Verible)" runs Verible's linter with its default rules, its naming rules only, or every rule. By default it only reports; you can choose to fail on any finding. A file Verible cannot parse is counted separately and is never reported as clean.

Tape-out#

Tiny Tapeout wrapper. On the Tapeout page, the row "Top module named tt_um_... with Tiny Tapeout's pins" has a "Make the wrapper" button. The lab reads your top module's port list, maps inputs to ui_in and then the either-way pins, outputs to uo_out and then the either-way pins, and gives you two downloads: the wrapper module and info.yaml. Your files are not changed. A design that needs more than 8 inputs, 8 outputs and 8 either-way pins gets the exact counts instead of a file. The lab reads plain port lists with number widths; parameters or macros in a width, interfaces and old-style port lists are left to you.

Tested: the wrapper around the unchanged UART TX starter built on a 161 × 111.52 µm die on SKY130 and passed. A top module that has exactly Tiny Tapeout's pin list is now recognised by the readiness checks. Unused Tiny Tapeout pins show as "pins not connected" in the electrical rule row; that is expected for a wrapper, and a waiver with that reason is the right answer. Not done by the lab: Tiny Tapeout's own precheck and its build of the wrapped design. Check info.yaml against the one in your Tiny Tapeout template.

IP blocks#

The side bar has an "IP blocks" entry, and New project has an "IP blocks" button. Each block is a complete project: design, cocotb tests, formal checks, a requirements table, constraints and build settings, under the Apache-2.0 licence. The block's page shows its ports, parameters and requirements from its own files, and the lab's measured results for the block as shipped: simulation, lint, formal and one chip build per process, each with the run it came from. A value that was not measured says so. "Use this block" makes a new project from it.

These blocks are tested starting points made with open-source tools on open process kits. They are not silicon-proven IP: check a block inside your own design and with your shuttle.

Activity log#

The side bar has an "Activity log" entry: every run of your own projects, newest first, with the kind of run, its result and how long it took, a summary of the last 30 days, and CSV and JSON downloads. It is the record of what was run, on what, when and with what result. A project in Recently deleted is left out, as it is on the other pages. Sign-ins are not in this list.

Automation (public API)#

A small set of addresses under /api/lab/v1/pub/ lets a script do what the buttons do: list your projects and their runs, start a simulate, synthesize or build, read a run's status and log, and download the chip report as JSON. A run started this way goes through the same checks as the Run buttons, so plan limits, quotas and the disk check apply, and a refusal comes back with the same reason the website shows. The log address returns at most the last 200 lines.

This preview answers a signed-in browser session only. Personal tokens for scripts and CI jobs, a command-line tool and a GitHub Actions example are written and tested on a copy of the sign-in service; they are not switched on yet.

What these previews do not change#

A build's stored result, its reports, the sign-off checks and the Tapeout readiness rules are as before, apart from the Tiny Tapeout pin row named above. The size of a design the lab can build, the number of builds that run at once, and how long a build may take are also unchanged.