Excellent write up and reverse engineering. Amazing to see this level of detail for an iconic chip

Thank you so much for all writing you've done! Your work is incredible!

Would it be safe to say that modern FPGA, although larger, are not more complex, in terms of the bit stream that programs them?

In other words, that a modern chip's bit stream is not more complex, only longer?

Some FPGAs such as the Xilinx 7 series support bitstream encryption, so that's a new layer of complexity.

Modern FPGAs also have much more in each CLB, and have multiple types of CLBs, so the bit stream is more complex in that way. See e.g. https://www.xilinx.com/support/documentation/user_guides/ug3...

I don't know a whole lot about modern FPGA bitstreams, so I'd be interested in anyone has more details. Is the bitstream still essentially a pile of raw bits controlling things, or is there more structure inside?

I would like to also add if your curious about more modern FPGA bit-streams there are these two projects which reverse-engineered bit streams for open source synthesis.

https://github.com/SymbiFlow/prjxray https://github.com/SymbiFlow/icestorm

The bitstream is probably decrypted as it enters the chip. After that at best you might have some simple xoring at each CLB to make someone probing with needles life harder.

Also making sure each data line is not on the top or bottom layer to make non-destructive access harder. At which point you going to need careful application of acid or focused ion beam ablation.

The encryption has been broken. You can read about it here https://news.ycombinator.com/item?id=22915831

I was not saying anything about that, but if you look at that paper or video you can see the bitstream is passed through an AES decryption stage before programing the logic fabric. This break found a way to read the data after that AES stage.

However, I was just explaining how encryption generally works for these things. Weather or not breaks exist for some chips.

Not an expert but, in modern FPGAs, the CLBs are more complex, there are dedicated resources like multipliers and block RAMs scattered around, and routing resources are much more complex because of the vastly increased size.

You might enjoy this document[0].

[0]: https://www.doc.ic.ac.uk/~wl/papers/survey/kuon08.pdf

Any plans for the Spartan6 family? :-)

Unfortunately, the Spartan6 is way beyond my capabilities. Among other things, it uses 45 nm technology, while the wavelength of light goes down to 400 nm, so my microscope won't show the features.

I can imagine you would have a lot fun with an electron microscope.

Time for a GoFundMe, maybe.

Amazing article as always! Thanks!

Is the intent to go all the way and get it supported on yosys and nextpnr?

People are encouraging me in that direction, but I don't give any guarantees :-)

Likely to do with the symbolic value it would have, it being the first fpga.

As current generation Xilinx hardware is already partially supported, it would seem to imply everything in between and in the future is doable.

This is a big question but - where would you recommend one to start to feel the “magic” of hacking on a fpga for problem solving?

Not the author, but I recently started down the FPGA rabbit hole myself.

I started with HDLBits [0], which has a bunch of problems that you solve by writing verilog that is then run in a simulator. It starts with simple gates and such, and then builds up from there.

I also purchased a dev board from NANDLand [1] and have been going through the tutorials written for their board. A lot of code is provided for you in the tutorials, but I've been reimplementing it all from scratch as part of the learning process. The later tutorials cover things like UART send/receive and simple VGA.

I'm not affiliated with either site, but have found both to be helpful. Good luck!

[0] https://hdlbits.01xz.net/wiki/Main_Page

[1] https://www.nandland.com/

Not the author, but my advice would be to grab a cheap devboard and try doing something, anything.

My approach was to implement very simple interfaces without using libraries.

Simulators are nice and all, but you won't feel the magic with these.

There's many cheap options[0] these days, but I'd suggest something based on iCE40[1], as they are cheap and have the most mature support in the open stack thanks to icestorm[2].

Excellent, dirt-cheap options include icestick, tinyfpga bx and blackice mx. These are all <$70.

[0]: https://joelw.id.au/FPGA/CheapFPGADevelopmentBoards

[1]: https://en.wikipedia.org/wiki/ICE_(FPGA)#iCE40_(40_nm)

[2]: http://www.clifford.at/icestorm/

Honestly, I haven't done a whole lot with FPGAs so others can probably give you a better answer. One thing I did which was fun was generate VGA video signals with an FPGA. This was much easier than I expected and it's rewarding to get immediate visual feedback.

That sounds like fun. I’ve been wanting to get a more intuitive understanding for video signals and poking that instead of OpenGL.

Great article! You compared XC2064 to the CPUs of its time. How many transistors were in XC2064?

I don't have any questions, I just wanted to say your blog is awesome! Thank you for it.