{"slug": "results-from-the-asic-puzzle", "title": "Results from the ASIC puzzle", "summary": "Jane Street published the solution to its August ASIC reverse-engineering puzzle, revealing that the chip is a hardware checker for an 11x11 Star Battle (\"Two Not Touch\") puzzle that accepts 121 cycles of inputs and emits the string \"(* TWO STARS *)\" on success. The firm received about 400 submissions from more than 30 countries, with most solvers using KLayout, Yosys and Z3 alongside custom tools written in Python, Rust, C++, OCaml, Haskell and Odin. The chip was designed with the SKY130 open-source standard cell library using the LibreLane toolchain, and its output strings are obfuscated with a small LFSR driven off the game board.", "body_md": "In August, we published a [puzzle](https://blog.janestreet.com/can-you-reverse-engineer-an-asic/)\nthat handed you the final GDS layout of a small chip and asked you to work out what it did. We\nsupplied the physical layout, but not a netlist or internal signal names, and it was up to you to\nreverse-engineer the internals.\n\nThis post reveals what the chip does and explores the different ways you solved it, with shout-outs to some of our favorite submissions.\n\n## The submissions\n\nWe received about 400 submissions from more than 30 countries, the bulk from the US, India, the UK and Australia. Entrants included high school students, researchers, working engineers and retirees. Most solvers used KLayout, Yosys and Z3 alongside custom tools (many AI-written) implemented in Python, Rust, C++, OCaml, Haskell and even Odin.\n\n## The solution\n\nAs many of you discovered, the chip is a hardware checker for an 11x11 Star Battle puzzle, also known as “Two Not Touch”. The goal is to place exactly two stars in each row, column, and colored region. No two stars can touch, even diagonally!\n\nThe chip accepts 121 cycles of inputs, with each input indicating whether to place a star in the corresponding square. It then runs several parallel checks on these inputs:\n\n- \nA 2-bit counter for each row and every column, requiring that each has exactly 2 stars\n- \nA 121-bit ROM mapping squares to regions, and a 2-bit counter for each region, requiring that each has exactly 2 stars\n- \nA delay line for tracking nearby squares to ensure that two stars never touch, including diagonally.\n- \nA counter for the total number of stars, used to produce certain Easter egg outputs\n\nThe puzzle checks are then ANDed together to produce the success signal.\n\nThe output generator stores its strings in ROM. To prevent the solution from showing up as plaintext, it is obfuscated with a small LFSR driven based off the game board (though that didn’t stop some of you from attacking the LFSR!)\n\nOnce success is achieved, the output logic deobfuscates the solution string and emits it!\n\n```\n(* TWO STARS *)\n```\n\nMost incorrect solutions emit the string “TRY AGAIN”, but a few trigger the Easter eggs listed below.\n\nThe puzzle chip was designed using the SKY130 open-source standard cell library, using the LibreLane toolchain.\n\n## How you solved it\n\nBelow, we walk through the steps involved in solving the puzzle, with examples from some of our favorite writeups.\n\n### Extracting the netlist from the layout\n\nThe first step was to extract a gate-level netlist from the GDS layout. To make it a little easier\nto get started, we left the cell names (such as `sky130_fd_sc_hd__nand2_2`) in the GDS files,\nallowing the use of the LVS<sup>[1](#fn:lvs)</sup> passes in tools like Magic and KLayout to extract a raw gate-level\nnetlist.\n\nSome folks, however, took on the extra challenge of writing their own netlist extraction tool.\n[Vladislav Shapovalov’s writeup](https://figurez.s-ul.eu/i6GwNvSU.pdf) shows how he wrote his own\nextraction pipeline in C++ to parse the GDS, extract the shapes of each cell, and combine them with\nthe cell names to generate a full logical netlist. He then did a process of trial-and-error with the\nwarm-up design to debug his pipeline before using it to extract the main puzzle GDS.\n\n### Simulating the netlist\n\nRecovering the netlist gives you a circuit graph, but simulating it also requires knowing how each\ncell behaves. Some solvers generated Verilog and used the SKY130 cell models with an existing simulator.\nOthers such as [Stephen\nEbert](https://drive.google.com/file/d/1lmpogbV_alS9vgaNRp4DcAbzbfTtkt0a/view?usp=drive_link), built\ntheir own evaluators, computing the logic between registers and updating the registers on each clock\nedge.\n\nThe supplied waveform gave them an input sequence to replay and expected outputs to compare against. The same simulator could then test candidate boards and run the output generator to read the answer.\n\nBut matching that waveform didn’t necessarily mean the simulator was correct. [Alejandro Soto\nFranco](https://www.sotofranco.dev/pdfs/asic-reverse-engineering.pdf) describes a Python model that\nreproduced the supplied trace despite getting every tie-high cell wrong. These cells should supply a\nconstant one; the model never evaluated them, leaving their outputs at zero.\n\nThe mistake effectively disabled the adjacency check. A solver using that model could therefore find apparently valid boards with touching stars. Alejandro caught the problem by comparing the Python model against a separate Icarus Verilog simulation on additional inputs.\n\n### Walking through the logic\n\nA common approach, and the one we most expected, was to start at the “success” output and work backwards through the netlist to identify the conditions for a valid input. We left a few hints in the floorplan: each “island” in the layout corresponded to a single module in the original RTL design.\n\nSanjay Ravishankar made great use of this, by drawing bounding boxes over each region and then\ndividing the schematic into these bounding boxes. He includes some [great visualizations of this in\nhis writeup](https://hackmd.io/@sanrav2016/fh9_eHBIQ_upRtm6F9S4wA). After verifying the module\nboundaries by looking at connectivity between them, he simulated each module to figure out what it\ndid, and how it fit into the bigger picture.\n\n### Dynamic exploration\n\nAnother approach was to simulate the chip with different inputs and watch how intermediate signals changed, without worrying too much about the logic functions themselves.\n\nAaron Shi channeled what he learned in his signals-and-systems class, and “treated the netlist like a\nsystem and hit it with impulses at various positions… Then diffed every flop against the all zeros\nbaseline. The flops that change are the response to that one bit,” he writes in [his\nwriteup](https://pakkachan.github.io/asic/). He then observed that the flops corresponded to the\nrows, columns, and regions, noting that each of them had to accumulate to exactly 2 to succeed. From\nthis, he constructed a solution grid that met the required conditions for success.\n\n### SAT solving\n\nAnother approach we saw was to use SAT solvers to find the correct solution without needing to know what the circuit does. In some ways, a SAT solver is perfectly suited to a challenge like this; it can take a circuit encoded over a fixed number of clock cycles and compute the input necessary to make a certain condition evaluate to true (in this case, the success output). Such tools are frequently used in hardware verification as well, by using the SAT solver to prove whether there exists a set of inputs for which a chip will have an undesirable output behavior.\n\nThe downside, however, of using a SAT solver for such a challenge is that it doesn’t reveal much\nabout the inner workings of the chip, just the necessary inputs to reach a desired output state.\nLokesh Aravapalli, however, found the best of both worlds. He started by [using the SAT solver to\nget a valid set of inputs](https://avnlk.github.io/reverse-engineering-an-ASIC.html), but then went\nback and used these inputs to actually analyze and understand the purpose of the circuit itself, and\nconstructed some cool visualizations of the circuit as well!\n\n### Cracking the output generator\n\nWith a puzzle like this, there will always be unexpected solutions and unorthodox thinking, as people found ways to solve the puzzle that we didn’t consider while writing it!\n\nOne thing that some folks tried was directly extracting the solution string from the\noutput module. The chip included some basic obfuscation in the form of an LFSR<sup>[2](#fn:lfsr)</sup> to\ncompute a “checksum” of the board, which was then XORed with the solution string before\nstoring it in the ROM (this made it so that simply editing the circuit to drive the\n“success” input to the output generator would produce a scrambled output). Gabriel\nTaboada, however, was curious how this all worked, and ended up [reverse-engineering the\noutput circuitry](https://gabbytab.github.io/blog/asic-puzzle-2026/) to figure out exactly\nhow the solution was encoded and what seed was needed to get the right outputs.\n\n## Neat visualizations\n\nOne of our favorite things about reverse-engineering is just how many unique ways there are to approach such a challenge. One of the best ways to see how different people approached the challenge is via the visualizations they built!\n\n- \nJoshua Stapleton built a [netlist-layout viewer](https://js-chip-solution.vercel.app/) , that shows\nboth the schematic and the layout side-by-side, showing how the cells connect to each other across\nhierarchical modules\n- \nJosé Vargas put together a cool [visual\nwalkthrough](https://jlvargasme.github.io/posts/reverse-engineering-an-asic.html) of how\na chip is constructed from PMOS and NMOS transistors and how he extracted them from the\nlayout to figure out the logic function of each cell.\n- \nFor anyone who likes solving Star Battle puzzles by hand, Amruth Gulawani made an [online\nplayable version](https://notcleo.github.io/GDS-to-RTL/TwoNotTouch-Interactive-Puzzle/) of the puzzle encoded in the chip, including some of the special easter-egg outputs on\nincorrect solutions.\n- \nPossibly our favorite visualization: Kjartan van Driel designed a beautiful [interactive animated walkthrough](https://kjartanvandriel.github.io/asic/) of how a\nchip is constructed and how all of the functionality in the puzzle chip fits together\n\n## Other cool things we saw\n\n- \nAlexander Smallwood decided to have some extra fun with the puzzle by synthesizing the extracted netlist [onto an\nFPGA](https://raw.githubusercontent.com/alexseekingalpha/jsasicsolved/main/myjanestreetwriteup.pdf) ,\nand using the switches and LEDs to represent the I/O of the chip!\n- \nNikhil Kaniyeri took on the challenge of compiling the netlist into Minecraft command blocks to [recreate a playable version of the puzzle\nin-game](https://drive.google.com/file/d/1ZmbmW6kK7hxcqemHxb7zkxzubLMro7pP/view?usp=sharing) .\n- \nDavid Garner converted the entire chip into an [analog SPICE\nsimulation](https://github.com/davidg351/Jane-Street-Puzzle-August-2026/blob/main/JaneStreetPuzzleWriteup_DavidGarner_FINAL.pdf) to verify his final solution in the analog domain.\n- \nMarcin Wójcik tried something different: he constructed a [Groth16 zero-knowledge\nproof](https://synhex.com/notes/jane-street-puzzle-solution.html) that could demonstrate\nthat he had the solution without revealing it.\n\n**——————————–**\n\n## The Easter eggs!\n\nTo add some extra fun we added easter eggs to the puzzle, many of which people were able to find! Out of all the submissions, two found all six intended eggs; six people found six of the seven when including the floating-wire bug at the end.\n\n- \nDecoding the two failed attempts in `example_inputs.vcd` as 7-bit ASCII gives “THE NIGHT SKY\nAWAITS”\n- \nThe VCD header is dated `Sat Dec 31 23:59:60 2016` , a real leap second, and the`$version` string\nnudges you to look at the file in a waveform viewer.\n- \nA row of marks on an otherwise unused layer below the die spells `PER ARENAM AD ASTRA` in Morse\ncode: “through the sand, to the stars”\n- \nThere are several failure messages. All zeros give `EMPTY SKY` and all ones give`BIG BANG` . A\nboard that passes the counts but has adjacent stars selects the`TWO NOT TOUCH` hint;\nother rejected inputs get`TRY AGAIN` .\n- \nAbout 1,400 isolated squares on met2 form a 57×57 pixel Jane Street logo (you can see it on the image above)\n- \nIf you render the eleven regions, their shapes spell out “JSC”.\n- \nThe `TWO NOT TOUCH` output path has an unconnected wire in it, which is why some of you saw`TWO\"NOT TOUCH` in simulation. This one was originally a bug in our layout. We caught it\nin an LVS pass but left it as an extra easter egg, to see who would catch it! Plenty of\nyou diagnosed it down to the floating`a31oi` input, and a few helpfully reported it to\nus as a bug.\n\n## Takeaways\n\nAI is going to be part of challenges like this, and it is a game changer for building analysis, netlist viewing, and debugging tools. Some entrants described using it for small scripts; others gave agents the whole puzzle. When we first came up with the puzzle we also saw that the latest models could be given a single prompt and, in 30 minutes or less, come up with the final solution. Although this takes away a lot of the fun and learning from working through the puzzle!\n\nSeveral solvers kept investigating after they had already found the answer. A SAT solver could supply a winning input, but they still wanted to understand what the chip was counting and how its wiring encoded the puzzle’s rules. That curiosity led to some of our favorite writeups: accounts that explained how the circuit worked, rather than stopping when it printed the right string.\n\nSome of the best debugging stories came from solvers deliberately trying to break their own tools. Models that reproduced our sample waveform perfectly still contained mistakes. Comparing separate implementations and constructing inputs that should fail exposed errors that replaying the examples hadn’t caught. That’s a useful habit well beyond puzzles, especially when AI makes it easier to build tools faster than you can check them.\n\nThanks to everyone who took the time to pull our chip apart, and especially to those who wrote up their process in enough detail for the next person to follow along. There were so many great write-ups that we didn’t get to feature all of them, but we really appreciate the effort everyone made!\n\nIf you enjoyed taking our chip apart, try designing your own in our [protocol-emulator ASIC\ncompetition](https://blog.janestreet.com/protocol-emulator-asic-competition/). The challenge is to\nbuild an open-source, programmable chip that can handle protocols like UART, SPI and I2C, with\nenough flexibility to support new protocols after fabrication. We’ll pay to fabricate our favorite\ndesigns, and winners will receive chips and dev boards to test them in real silicon. Submissions\nclose on **January 18, 2027**.\n\n# Hardware at Jane Street\n\nThe hardware team at Jane Street designs FPGAs and ASICs that run some of the fastest trading systems in the world, and the day-to-day work is full of puzzles just like this one: staring at a sea of gates, timing reports, or waveforms and slowly teasing out what’s really going on. These problems are hard in a way that’s deeply satisfying to solve, and honestly, it’s a big part of why we like working here.\n\nIf that sounds intriguing, here are some ways of learning more:\n\n- \nCheck out our hardware (FPGA and ASIC) [internships](https://www.janestreet.com/join-jane-street/position/8624440002/) and[full-time](https://www.janestreet.com/join-jane-street/position/8646893002/) roles.\n- \nRead about [Hardcaml](https://hardcaml.org/) (our open-source OCaml hardware design libraries)\n- \nOn the academic side, read about our [visiting\nresearcher](https://www.janestreet.com/join-jane-street/programs-and-events/visiting-researcher/) and[graduate\nfellowship](https://www.janestreet.com/join-jane-street/programs-and-events/graduate-research-fellowship/) programs.\n\nIf you just want to stay in touch, you can fill out [this form](https://bit.ly/4lEqiqb).\n\n1. \nLVS stands for “Layout vs Schematic”, it is usually used at the very end of a chip-design flow to verify that the final layout is logically equivalent to the initial RTL design (e.g., that no wires were dropped or mis-connected during the routing process). However, it can also be used to just extract the netlist from an existing layout file. [↩](#fnref:lvs)\n2. \nLinear Feedback Shift Register, which is a very small circuit that generates a pseudorandom output based on an input bitstream. Often used to compute checksums for data integrity, we used it here to scramble the output string based on a checksum of the solution board. [↩](#fnref:lfsr)", "url": "https://wpnews.pro/news/results-from-the-asic-puzzle", "canonical_source": "https://blog.janestreet.com/asic-puzzle-results/", "published_at": "2026-10-02 00:00:00+00:00", "updated_at": "2026-10-02 13:09:06.526277+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools"], "entities": ["Jane Street", "KLayout", "Yosys", "Z3", "SKY130", "LibreLane", "Vladislav Shapovalov", "Stephen Ebert"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/results-from-the-asic-puzzle", "markdown": "https://wpnews.pro/news/results-from-the-asic-puzzle.md", "text": "https://wpnews.pro/news/results-from-the-asic-puzzle.txt", "jsonld": "https://wpnews.pro/news/results-from-the-asic-puzzle.jsonld"}}