Inspiration
Redstone makes it possible to build computers inside Minecraft, but even a small circuit can take a surprising amount of manual work. Placing blocks, orienting repeaters, and tracing broken connections can take longer than designing the logic itself. We wanted to make hardware design more approachable: what if you could write a circuit, generate it in Minecraft, and then walk through it?
Gate-or Gates grew from that idea. We saw an opportunity to combine digital logic with a world students already enjoy exploring. Our long-term vision is a tool that could complement Minecraft Education, helping students connect hardware code to something they can see, interact with, and understand.
What it does
Gate-or Gates compiles SystemVerilog hardware descriptions into Minecraft redstone circuits. It synthesizes the logic, maps it to reusable components, places those components, routes their connections, and exports a Minecraft function that constructs the design.
The pipeline supports more than individual gates:
- Combinational circuits, including multiplexers, adders, decoders, and ALUs.
- Sequential circuits, including flip-flops, registers, and registered datapaths that retain values between clock events.
- Finite-state machines, where stored state determines how a system responds to its inputs.
- Larger composed designs, combining logic, storage, control, and reusable seven-segment displays.
This lets us build upward from simple primitives toward complete digital systems. Our stopwatch design, for example, combines a state machine, counters, registers, control inputs, and four display components.
The hardware input bridge makes those circuits physically interactive. Point at an in-game input lever or stand on it, then assign it to a switch or button on the DE10-Lite. You choose which physical control drives which circuit input. The mapping is configurable, so the same board can control different generated circuits without hardcoding every connection.
The bridge carries those inputs through an Arduino Uno and a Python connection to Minecraft. Physical switches provide steady input states, while buttons can deliver pulses.
Together, these pieces create a workflow where you can describe a machine in HDL, generate its implementation in Minecraft, map its controls to your FPGA board, and investigate how it behaves. Minecraft becomes a space for exploring digital systems, from a single Boolean operation to logic that remembers, sequences, and responds.
How we built it
We built Gate-or Gates as two connected systems: a compiler that turns hardware code into a Minecraft circuit, and an input bridge that lets physical FPGA controls interact with that circuit.
The compilation pipeline looks like this:
SystemVerilog → Yosys/ABC → JSON netlist → Python component mapping → OR-Tools placement → redstone routing → Minecraft build function
We defined the physical building blocks. We started by building redstone implementations of basic logic gates and registers. Each component has a Python definition recording its blocks, dimensions, orientations, and input/output terminals. That library connects abstract logic to physical Minecraft structures. When the compiler encounters an AND gate, it knows which blocks implement it, how much space it occupies, and where its wires must connect. We later added larger reusable components, including a seven-segment decoder and lamp display.
Yosys translates hardware code into connected logic. The user supplies SystemVerilog describing a circuit. Yosys reads the design, resolves its module hierarchy, and synthesizes it into logic cells and connections. ABC optimizes the combinational logic and maps it into supported gate types. The result is a JSON netlist: a description of the components and which signal connects to each terminal. A structural design, such as a four-input mux built from smaller muxes, can therefore enter the same pipeline as a circuit described with behavioral HDL. At this stage, we know what must connect, but nothing has a Minecraft position yet.
Python maps the netlist onto our component library. Our exporter reads the JSON and matches supported cells to their redstone implementations. It tracks individual signal bits, circuit inputs and outputs, and connections that branch to multiple destinations. Registers also carry clock and reset information. Keeping that information allows the physical layout to connect registers sharing an HDL clock to a shared clock source and route intentional feedback through storage elements. This produces a circuit graph whose components now have real dimensions and terminal locations.
Google OR-Tools chooses where the components go. We pass that graph and its physical constraints to OR-Tools' CP-SAT solver. The solver chooses component coordinates while enforcing spacing, preventing overlap, and reducing estimated connection distances. The output is a placement: every component has a location, and every terminal has a coordinate. OR-Tools handles this positioning; our own router builds the wires between those coordinates.
Our router turns connections into redstone paths. We began with flat paths and basic A* routing, then developed weighted A* search across multiple height layers. The router finds paths around components and existing wires, using bridges when signals need to cross. It also accounts for Minecraft's electrical constraints. Wires need supporting blocks and clearance, long paths need repeaters to restore signal strength, and separate signals must remain isolated. Branching routes let one output feed several inputs. When an early route blocks a later connection, rip-up and reroute rebuilds the wiring with the blocked connection given higher priority. Additional checks reject paths that reconnect around repeaters and create unintended feedback.
The exporter builds the circuit in Minecraft. Once placement and routing succeed, the exporter writes a .mcfunction containing block-placement commands. It places supports before redstone components and can position the build relative to the player. For designs with displays, four-bit output buses connect to copies of our existing seven-segment component. Its decoder turns each binary value into the corresponding lamp pattern.
The physical input system follows a second path:
DE10-Lite switches/buttons → FPGA GPIO → Arduino Uno → USB serial → Python bridge → Minecraft commands
The Arduino reads the FPGA's input signals, debounces buttons, and sends switch states and button-press counts to the computer. The Python bridge receives those updates and uses RCON to control the corresponding Minecraft inputs. Players establish those connections themselves: point at an in-game input lever or stand on it, then assign a DE10-Lite switch or button. Saved bindings tell the bridge which physical control drives which virtual input.
Together, the two systems connect the HDL description, the generated redstone circuit, and the physical control board. We validate the stages with logic tests, sequential simulations, and routing geometry checks, while treating Minecraft timing as a further part of testing the completed build.
Challenges we ran into
Our early routing used flat paths and basic A* search. That worked for small circuits, but more complicated designs quickly needed wire crossings. Two unrelated redstone signals cannot simply intersect on the same layer without connecting, so we introduced bridges. Those bridges needed room for ramps, supporting blocks, repeaters, and clearance above existing components.
Then we discovered that a bridge could accidentally become a memory element. When a path turned back toward itself, nearby dust could reconnect around a repeater and form a feedback loop. An input could remain powered after it should have turned off. Preventing block collisions was insufficient—we had to check electrical separation and reject unintended reconnections along the entire route.
Placement and routing also competed with each other. Packing gates tightly reduced estimated wire distance, but sometimes left no usable path between their terminals. Spreading everything out made routing easier while producing enormous builds. We introduced OR-Tools placement using our components' actual dimensions, then checked each proposed layout with the redstone router.
Muxes and ALUs exposed another weakness: shared signals. A selector or data bit might feed many gates, and routing each connection independently wasted space or blocked later connections. We added branching routes, reserved space for shared controls, and developed rip-up and reroute so a failed wiring pass could be rebuilt with difficult connections prioritized. We also optimized the synthesized circuit before routing it. Throughout those changes, we kept asking: did solving the larger circuit make the smaller ones worse? We added regression checks to preserve successful compact layouts.
Sequential logic introduced clock, reset, and feedback constraints. Registers that share an HDL clock need a shared physical clock connection; independent redstone oscillators would drift apart. Intentional feedback through a register also had to remain distinct from accidental feedback around a repeater. Even with every connection routed, propagation delay and clock skew can affect behavior, so large sequential builds still require in-game timing validation.
Eventually, Minecraft itself became part of the scaling problem. Our largest export contains 575,483 block-placement commands. Command-execution limits could stop a build before all its redstone appeared, while large structures put pressure on memory and world loading. We had to distinguish an incomplete build from an incorrect circuit.
Our most interesting challenge, however, was that one of our team members lost their voice due to sickness and had to communicate through hand gestures and text.
Accomplishments that we're proud of
We built a pipeline that turns HDL into Minecraft circuits, from basic gates to registered logic and state machines. Our final generated build included four displays, 1,081 routed connections, and almost 600,000 block placements. We also added configurable FPGA input controls and passed 73 regression tests.
What we learned
We learned how digital logic, pathfinding, and constraint solving come together to turn hardware code into a physical circuit. A short HDL description can produce hundreds of gates, and connecting those gates can be harder than placing them. We also learned that the shortest route is not always electrically safe, and that clock distribution becomes a major challenge as sequential circuits grow.
Working across an FPGA, an Arduino, Python, and Minecraft taught us how to connect systems with very different timing and communication requirements.
What's next for Gate-or Gates
We want faster routing, more compact builds, and better clock distribution so larger circuits become easier to generate and use. We also want a simpler interface for loading HDL, generating circuits, and assigning physical controls.
We think this would be a really cool feature for Minecraft Education. Students could write a circuit, generate it, and walk through its gates and registers while controlling its inputs with real hardware. Interactive lessons could build from basic Boolean logic to arithmetic, memory, and state machines, making abstract hardware concepts something students can explore together.
Log in or sign up for Devpost to join the conversation.