Reverse-engineering the first FPGA chip, the XC2064 | Hacker News Reader

Reverse-engineering the first FPGA chip, the XC2064

righto.com

128 pointsmatt_d46 comments

A lot of this era of FPGAs was about how to configure the chip- Nobody wanted to use Xilinx's one time programmable serial ROMs.

I used to use some one shots to generate CCLK pulse delayed from an RS-232 start bit. The idea is you would load one bit at time into the FPGA, one bit for each RS-232 byte. Once the FPGA was configured, a UART implemented in FPGA logic would come alive and allow it to communicate with a PC.

Anyway, I used xc2064s in the mid 90s for a project once (they were obsolete then, but I had a tube of them). I modified a point of sale terminal (a little credit-card machine) so that it could be automated. This was for a methadone clinic: they had to check each recipient's social security number every day to verify their medicaid eligibility. So the FPGA would simulate keypresses and read the vacuum fluerescent display back to the PC. (My consulting fee was much cheaper than the medicaid software interface.)

Later I used an XC4010E for a PCI-bus interface for a video capture card. Again, how do you avoid the serial PROM? In this case, I used timed-out PCI configuration accesses to load the serial data. Even if the PCI device does not respond, the address lines of the configuration access make it through to the target, so you just need a fast flip flop to latch DIN and CCLK. Once the FPGA was loaded, the card would appear on the PCI bus (but long after enumeration). This worked until PC BIOS started to turn off the PCI clock on slots with no cards in them to save power.

Both of these were in the pre-Verilog days. To design the FPGA you drew a schematic into (in my case) OrCAD. Xilinx had a meta-design capability in those days (called xblox I think?), where one wire in the schematic was equivalent to entire bus. The actual width was a parameter on a primitive. Yes, I made a PCI interface in schematics, it was not fun.

The thing I find frustrating about FPGAs is how they are stuck in the "ASIC-replacement" mind-set.

In principle, these things could change their programming on the fly, as fast as everything happening in the regular logic, but everybody thinks they have to be programmed at power-up and left that way.

If the programming bit-stream could be fed, separately, to each section of the die, under control of logic on other parts of the die, a system of totally adaptable logic would become possible. Different programming could be installed according to the needs of the moment, replaced with other logic the moment needs change.

It would be a project to figure out out to usefully program such a system, but we are up to it. Our phones adopt completely different usage each time we tap on an app icon, but the performance of apps running on CPUs is strictly limited.

Active partial reconfiguration is a thing and works pretty much as you say - some parts of the chip continue running while others are swapped out, and an example use case is video encoding, just swap in the encoder engine optimised to a given standard, rather than have every standard in the same design requiring a much larger device.

Thank you. Which devices support active partial configuration? I have not encountered any mention of it, before. The "Three Ages of FPGAs" paper in IEEE has "reconfiguration" in the title of a single reference, and no mention in the text.

It's recently been renamed dynamic function exchange (marketing I guess?) but it'd supported in xilinx 7 series and later: https://www.xilinx.com/products/design-tools/vivado/implemen...

Thank you.

The DFX apparatus all looks distressingly proprietary, not to say clumsy. It seems like it will be a long time before this capability leaks out to mainstream use.

After it becomes more accessible, one could hope to compile programmatically generated logic on the fly, and immediately configure some chip area to execute it, perhaps with on-demand / JIT swapping between software and hardware implementation. O Brave New World!

Even for moderately complex designs the synthesis times are way too long for that to be feasible. Unfortunately, a lot of it is inherent to the problems/algorithms involved. So getting rid of the clumsiness of proprietary synthesis tools won't be sufficient, you are going to need another breakthrough.

It is always easy to invent ways for ambitions to be impractical. But, surprise, those are not the things people actually do with new capabilities. Instead they do clever, sensible things that work for them.

Recently @tubetime reverse engineered a Snappy Play video capture device. The mysterious PLAY “HD-1500” at the heart of the device is actually an XC2064.

Follow the thread here:

https://twitter.com/TubeTimeUS/status/1301990455182155776

https://twitter.com/TubeTimeUS/status/1302704667143544833

I'm working with @TubeTimeUS to see if I can reverse-engineer the bitstream.

That’s awesome! Thank you!

1999 Pinnacle Studio MP10 is newer, more sophisticated variation on the same design. Inside: EPF6016QC208, 2.5MB EDO DRAM 25MHz 5 x GLT44016-40j4, 32KB SRAM 66MHz GLT725608-15j3, 256KB VRAM 33MHz Nec uPD42280GU-30, clock chip 14.318MHz 3.579MHz 13.5MHz 27MHz 40.5MHz 8-16MHz 2-40MHz 4-80MHz Chrontel ch9081A-S, saa7127h, saa7112h, audio dac TDA1311AT.

Author here to answer all your questions :-)

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

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!

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?

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.

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

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.