Build openly: reproducible designs, review and real hardware

Share enough to repeat the result

A screenshot shows a result; a reproducible package explains how it was obtained. Record the design revision, tool versions, commands, constraints, process/library revisions, tests and reports. SiliconCompiler can record tool versions and input/output hashes. Those records help identify a run, but do not prove the circuit is correct.

Source: SiliconCompiler: schema and build records ↗

README: purpose, supported inputs, expected outputs and steps to reproduce.
Design source and constraints: the inputs that actually produced the result.
Tests and expected results: include a known failing case when fixing a bug.
Reports and provenance: versions, hashes, limitations and what changed.

Separate design, software and process rights

Publishing files does not by itself grant permission to modify or redistribute them. CERN’s Open Hardware Repository recommends suitable licences for the hardware, gateware, firmware, software and documentation. CERN OHL v2 has permissive, weakly reciprocal and strongly reciprocal variants; these have different sharing obligations.

Source: CERN Open Hardware Repository: licensing guidance ↗

OpenROAD’s licence does not grant access to every PDK. Its documentation states that proprietary process kits and platform files cannot be redistributed because of NDA restrictions. Keep the tool licence, your design licence and process-data permissions as separate entries.

Source: OpenROAD: tool scope and PDK support ↗

A small dependency register
Item	Record before sharing
Your circuit / RTL	Author, source revision, chosen licence and scope.
Tools and libraries	Version, licence, notices and any required attribution.
PDK or cell data	Source, access terms and redistribution permission.
Documentation / images	Creator and permitted reuse of each item.

Open-source licences can allow commercial use; read the actual licence and dependency terms. A public repository is not a promise that fabrication is free or that every included file has the same reuse rights.

Make a fork useful to someone else

A fork is a separate line of work based on a shared design. Make a small change, explain why, and compare it with its parent version. A review should inspect both the change and its evidence. OpenROAD’s contributor guide illustrates project-specific requirements; every project can have its own rules.

Source: OpenROAD: developer and contribution guide ↗

Reviewer 1 checks the specification and expected results before reading the implementation.
Reviewer 2 reproduces the test and inspects the changed connections or RTL.
The author records what passed, what failed and what remains outside the model.

Use AI as a helper with a separate check

AI can help draft RTL, explain a report or suggest test inputs. Treat the result as a proposal. VerilogEval evaluates generated hardware descriptions using functional tests against reference behaviour, which is a useful reminder that fluent code still needs an independent check.

Source: NVIDIA Research: VerilogEval ↗

Write the intended behaviour first. Ask for a test that would expose a wrong implementation, then inspect the expected results yourself. For our half adder, A = B = 1 catches the OR-for-XOR mistake. For a clocked design, include reset, disabled cycles and boundary transitions. Never promote an AI explanation into a signoff result without the actual checks.

A chip is manufactured, packaged and tested

Silicon fabrication builds precisely aligned patterned layers on a wafer in controlled facilities. Teaching inference: an ordinary desktop filament or resin 3D printer does not provide the semiconductor materials, processing or transistor-scale precision needed for a silicon IC. A printed enclosure can hold electronics; it is a different deliverable. Research into printed electronics is also a separate field.

Source: ASML: how microchips are made ↗

A fabricated die still needs an appropriate package, electrical connections and testing. Intel’s assembly-and-test explanation shows these as manufacturing work after wafer processing; exact steps vary by device. Plan how inputs will be driven, outputs measured and failures diagnosed before ordering hardware.

Source: Intel: assembly and test ↗

Begin with a simulation milestone you can reproduce. A later hardware milestone might use an existing FPGA, which configures already manufactured programmable hardware, or a qualified chip fabrication programme. Compare access, fabrication, packaging, board and test costs separately. An exported layout is an intermediate result.

Publish a claim that matches your evidence

Sources and further reading

Reviewed 10 October 2026. Company examples describe the named product categories, not a complete ranking. Exercises and worked examples are original Quantum Sharma teaching material.