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

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.