{ "archive_path": "archive/1791151586.921048", "base_url": "blog.janestreet.com/asic-puzzle-results", "basename": "", "bookmarked_date": "2026-10-04 22:06", "canonical": { "archive_org_path": "https://web.archive.org/web/blog.janestreet.com/asic-puzzle-results", "dom_path": "output.html", "favicon_path": "favicon.ico", "git_path": "git/", "google_favicon_path": "https://www.google.com/s2/favicons?domain=blog.janestreet.com", "headers_path": "headers.json", "htmltotext_path": "htmltotext.txt", "index_path": "index.html", "media_path": "media/", "mercury_path": "mercury/content.html", "pdf_path": "output.pdf", "readability_path": "readability/content.html", "screenshot_path": "screenshot.png", "singlefile_path": "singlefile.html", "warc_path": "warc/", "wget_path": "blog.janestreet.com/asic-puzzle-results/index.html" }, "domain": "blog.janestreet.com", "extension": "", "hash": "1JG6T6RC2NPEBNVBGRDE", "history": { "archive_org": [], "dom": [], "favicon": [ { "cmd": [ "curl", "--silent", "--location", "--compressed", "--max-time", "120", "--output", "favicon.ico", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://www.google.com/s2/favicons?domain=blog.janestreet.com" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-10-04T22:10:53.309151+00:00", "index_texts": null, "output": "favicon.ico", "pwd": "/data/archive/1791151586.921048", "schema": "ArchiveResult", "start_ts": "2026-10-04T22:10:52.763125+00:00", "status": "succeeded" } ], "git": [], "headers": [ { "cmd": [ "curl", "--silent", "--location", "--compressed", "--head", "--max-time", "120", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://blog.janestreet.com/asic-puzzle-results/" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-10-04T22:10:53.886807+00:00", "index_texts": null, "output": "headers.json", "pwd": "/data/archive/1791151586.921048", "schema": "ArchiveResult", "start_ts": "2026-10-04T22:10:53.315165+00:00", "status": "succeeded" } ], "htmltotext": [], "media": [], "mercury": [ { "cmd": [ "/app/node_modules/@postlight/parser/cli.js", "https://blog.janestreet.com/asic-puzzle-results/" ], "cmd_version": "1.0.0", "end_ts": "2026-10-04T22:11:06.980350+00:00", "index_texts": null, "output": "mercury", "pwd": "/data/archive/1791151586.921048", "schema": "ArchiveResult", "start_ts": "2026-10-04T22:11:02.429511+00:00", "status": "succeeded" } ], "pdf": [], "readability": [ { "cmd": [ "/app/node_modules/readability-extractor/readability-extractor", "/tmp/tmpk9je1q4s", "https://blog.janestreet.com/asic-puzzle-results/" ], "cmd_version": "0.0.11", "end_ts": "2026-10-04T22:11:02.422045+00:00", "index_texts": [ "In August, we published a puzzle\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\nto some of our favorite submissions.\n\nThe submissions\n\nWe received about 400 submissions from more than 30 countries, the bulk from the US, India, the UK\nand Australia. Entrants included high school students, researchers, working engineers and retirees.\nMost solvers used KLayout, Yosys and Z3 alongside custom tools (many AI-written) implemented in\nPython, Rust, C++, OCaml, Haskell and even Odin.\n\nThe solution\n\nAs many of you discovered, the chip is a hardware checker for an 11x11 Star Battle puzzle, also\nknown as \u201cTwo Not Touch\u201d. The goal is to place exactly two stars in each row, column, and colored\nregion. 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\ncorresponding square. It then runs several parallel checks on these inputs:\n\n\n \n A 2-bit counter for each row and every column, requiring that each has exactly 2 stars\n \n \n A 121-bit ROM mapping squares to regions, and a 2-bit counter for each region, requiring that each\nhas exactly 2 stars\n \n \n A delay line for tracking nearby squares to ensure that two stars never touch, including\ndiagonally.\n \n \n A counter for the total number of stars, used to produce certain Easter egg outputs\n \n\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\nplaintext, it is obfuscated with a small LFSR driven based off the game board (though that didn\u2019t\nstop some of you from attacking the LFSR!)\n\nOnce success is achieved, the output logic deobfuscates the solution string and emits it!\n\n(* TWO STARS *)\n\n\n\n\n\n\nMost incorrect solutions emit the string \u201cTRY AGAIN\u201d, 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\nLibreLane toolchain.\n\nHow you solved it\n\nBelow, we walk through the steps involved in solving the puzzle, with examples from some of our\nfavorite writeups.\n\n\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 LVS1 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.\nVladislav Shapovalov\u2019s writeup 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\n\n\n(Cropped from Figure 1 of Vladislav Shapovalov's writeup)\n\n\nSimulating 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, 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.\nThe same simulator could then test candidate boards and run the output generator to read the answer.\n\nBut matching that waveform didn\u2019t necessarily mean the simulator was correct. Alejandro Soto\nFranco 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\napparently valid boards with touching stars. Alejandro caught the problem by comparing the Python\nmodel against a separate Icarus Verilog simulation on additional inputs.\n\nWalking through the logic\n\nA common approach, and the one we most expected, was to start at the \u201csuccess\u201d output and work\nbackwards through the netlist to identify the conditions for a valid input. We left a few hints in\nthe floorplan: each \u201cisland\u201d in the layout corresponded to a single module in the original RTL\ndesign.\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. 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\n\n\nSanjay Ravishankar's annotated layout, with the islands of logic labeled by function.\nDiagram from his writeup.\n\n\nDynamic exploration\n\nAnother approach was to simulate the chip with different inputs and watch how intermediate signals\nchanged, without worrying too much about the logic functions themselves.\n\nAaron Shi channeled what he learned in his signals-and-systems class, and \u201ctreated the netlist like a\nsystem and hit it with impulses at various positions\u2026 Then diffed every flop against the all zeros\nbaseline. The flops that change are the response to that one bit,\u201d he writes in his\nwriteup. 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\n\n\nAaron Shi's simulator, with registers colored by the first cycle they went high.\nThis all-ones run trips the row-count and adjacency checks. Image from\nhis writeup.\n\n\nSAT solving\n\nAnother approach we saw was to use SAT solvers to find the correct solution without needing to know\nwhat the circuit does. In some ways, a SAT solver is perfectly suited to a challenge like this; it\ncan take a circuit encoded over a fixed number of clock cycles and compute the input necessary to\nmake a certain condition evaluate to true (in this case, the success output).\nSuch tools are frequently used in hardware verification as well, by using the SAT solver to prove\nwhether 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\u2019t 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, 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\nCracking the output generator\n\nWith a puzzle like this, there will always be unexpected solutions and unorthodox\nthinking, as people found ways to solve the puzzle that we didn\u2019t 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 LFSR2 to\ncompute a \u201cchecksum\u201d 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\u201csuccess\u201d 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 to figure out exactly\nhow the solution was encoded and what seed was needed to get the right outputs.\n\nNeat visualizations\n\nOne of our favorite things about reverse-engineering is just how many unique ways there are to\napproach such a challenge. One of the best ways to see how different people approached the challenge\nis via the visualizations they built!\n\n\n \n Joshua Stapleton built a netlist-layout viewer, that shows\nboth the schematic and the layout side-by-side, showing how the cells connect to each other across\nhierarchical modules\n \n \n Jos\u00e9 Vargas put together a cool visual\nwalkthrough 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 \n \n For anyone who likes solving Star Battle puzzles by hand, Amruth Gulawani made an online\nplayable version\nof the puzzle encoded in the chip, including some of the special easter-egg outputs on\nincorrect solutions.\n \n \n Possibly our favorite visualization: Kjartan van Driel designed a beautiful\ninteractive animated walkthrough of how a\nchip is constructed and how all of the functionality in the puzzle chip fits together\n \n\n\nOther cool things we saw\n\n\n \n Alexander Smallwood decided to have some extra fun with the puzzle by synthesizing the\nextracted netlist onto an\nFPGA,\nand using the switches and LEDs to represent the I/O of the chip!\n \n \n Nikhil Kaniyeri took on the challenge of compiling the netlist into Minecraft command\nblocks to recreate a playable version of the puzzle\nin-game.\n \n \n David Garner converted the entire chip into an analog SPICE\nsimulation\nto verify his final solution in the analog domain.\n \n \n Marcin W\u00f3jcik tried something different: he constructed a Groth16 zero-knowledge\nproof that could demonstrate\nthat he had the solution without revealing it.\n \n\n\n\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2013\n\nThe Easter eggs!\n\nTo add some extra fun we added easter eggs to the puzzle, many of which people were able to find!\nOut of all the submissions, two found all six intended eggs; six people found six of the seven when\nincluding the floating-wire bug at the end.\n\n\n\n\n\n\n\n \n Decoding the two failed attempts in example_inputs.vcd as 7-bit ASCII gives \u201cTHE NIGHT SKY\nAWAITS\u201d\n \n \n The 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 \n \n A row of marks on an otherwise unused layer below the die spells PER ARENAM AD ASTRA in Morse\ncode: \u201cthrough the sand, to the stars\u201d\n \n \n There 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 \n \n About 1,400 isolated squares on met2 form a 57\u00d757 pixel Jane Street logo (you can see it on the\nimage above)\n \n \n If you render the eleven regions, their shapes spell out \u201cJSC\u201d.\n \n \n The TWO NOT TOUCH output path has an unconnected wire in it, which is why some of you saw\nTWO\"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\n\nTakeaways\n\nAI is going to be part of challenges like this, and it is a game changer for building analysis,\nnetlist viewing, and debugging tools. Some entrants described using it for small scripts; others\ngave agents the whole puzzle. When we first came up with the puzzle we also saw that the latest\nmodels could be given a single prompt and, in 30 minutes or less, come up with the final solution.\nAlthough 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\nsupply a winning input, but they still wanted to understand what the chip was counting and how its\nwiring encoded the puzzle\u2019s rules. That curiosity led to some of our favorite writeups: accounts\nthat 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.\nModels that reproduced our sample waveform perfectly still contained mistakes. Comparing separate\nimplementations and constructing inputs that should fail exposed errors that replaying the examples\nhadn\u2019t caught. That\u2019s a useful habit well beyond puzzles, especially when AI makes it easier to\nbuild 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\nwrote up their process in enough detail for the next person to follow along. There were so\nmany great write-ups that we didn\u2019t get to feature all of them, but we really appreciate the\neffort everyone made!\n\nIf you enjoyed taking our chip apart, try designing your own in our protocol-emulator ASIC\ncompetition. 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\u2019ll 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\nHardware at Jane Street\n\nThe hardware team at Jane Street designs FPGAs and ASICs that run some of the fastest trading\nsystems in the world, and the day-to-day work is full of puzzles just like this one: staring at a\nsea of gates, timing reports, or waveforms and slowly teasing out what\u2019s really going on. These\nproblems are hard in a way that\u2019s deeply satisfying to solve, and honestly, it\u2019s a big part of why\nwe like working here.\n\nIf that sounds intriguing, here are some ways of learning more:\n\n\n \n Check out our hardware (FPGA and ASIC)\ninternships and\nfull-time roles.\n \n \n Read about Hardcaml (our open-source OCaml hardware design libraries)\n \n \n On the academic side, read about our visiting\nresearcher\nand graduate\nfellowship\nprograms.\n \n\n\nIf you just want to stay in touch, you can fill out this form." ], "output": "readability", "pwd": "/data/archive/1791151586.921048", "schema": "ArchiveResult", "start_ts": "2026-10-04T22:11:00.335879+00:00", "status": "succeeded" } ], "screenshot": [], "singlefile": [], "title": [ { "cmd": [ "curl", "--silent", "--location", "--compressed", "--max-time", "120", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://blog.janestreet.com/asic-puzzle-results/" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-10-04T22:11:00.330669+00:00", "index_texts": null, "output": "Jane Street Blog - Results from the ASIC puzzle", "pwd": "/data/archive/1791151586.921048", "schema": "ArchiveResult", "start_ts": "2026-10-04T22:11:00.311407+00:00", "status": "succeeded" } ], "wget": [ { "cmd": [ "wget", "--no-verbose", "--adjust-extension", "--convert-links", "--force-directories", "--span-hosts", "--no-parent", "-e", "robots=off", "--reject=js,mjs,woff,woff2,ttf,otf,eot,mp4,m4v,mov,webm,ogv,mkv,avi,flv", "--timeout=120", "--restrict-file-names=windows", "--page-requisites", "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) wget/GNU Wget 1.21.3", "--compression=auto", "--timestamping", "https://blog.janestreet.com/asic-puzzle-results/" ], "cmd_version": "GNU Wget 1.21.3", "end_ts": "2026-10-04T22:11:00.305430+00:00", "index_texts": null, "output": "blog.janestreet.com/asic-puzzle-results/index.html", "pwd": "/data/archive/1791151586.921048", "schema": "ArchiveResult", "start_ts": "2026-10-04T22:10:53.893799+00:00", "status": "succeeded" } ] }, "icons": null, "is_archived": true, "is_static": false, "latest": { "archive_org": null, "dom": null, "favicon": "favicon.ico", "git": null, "media": null, "pdf": null, "screenshot": null, "singlefile": null, "title": "Jane Street Blog - Results from the ASIC puzzle", "warc": null, "wget": "blog.janestreet.com/asic-puzzle-results/index.html" }, "link_dir": "/data/archive/1791151586.921048", "newest_archive_date": "2026-10-04T22:11:02.429511+00:00", "num_failures": 0, "num_outputs": 6, "oldest_archive_date": "2026-10-04T22:10:52.763125+00:00", "path": "/asic-puzzle-results/", "schema": "Link", "scheme": "https", "snapshot_id": "82450b64-45af-4c93-b122-e782e36ae019", "sources": [ "/data/sources/1791151586-import.txt" ], "tags": null, "tags_str": "", "timestamp": "1791151586.921048", "title": "Jane Street Blog - Results from the ASIC puzzle", "updated": "2026-10-04T22:10:52.762674+00:00", "updated_date": "2026-10-04 22:10", "url": "https://blog.janestreet.com/asic-puzzle-results/" }