How were custom chips designed in the days prior to the arrival of FPGAs as hardware emulation devices? [closed]

Question

One of the applications of FPGAs is to model a computer system/chip/functionality on it prior to mass manufacturing the copies of finalized design. How was this done before FPGAs were used for this kind of work?

Answer 1

We still release final RTL (* see below) based on simulation alone (simulators by Cadence, Mentor). All functional tests are covered in RTL simulation, some are promoted to gate level simulations. Simulations that run for days on dedicated servers were and are no exception. For most sub-system simulations it is not uncommon to run them over-night, and baby-sit them over weekends.

In this simulation-only flow, FPGA fabrics are still used for pre-silicon software development, so that S/W or F/W can be developed before silicon is ready and in many cases even well before tape-in.

Vector simulations and independent Formal Equivalence Verification are still necessary to prove logic equivalence: when FPGA output and RTL simulation differ it is not always clear which one is compiled correctly, or which one is coded as expected.

Without doubt FPGA simulations provide much more coverage in much shorter time. Randomized simulations (looking for error handling, exceptions, bit-errors etc...) are finally practical thanks to FPGAs.

To "Tape-out" means to send the ASIC GDSII files and other design specs to a foundry to begin the manufacturing process. Historically, before FTP and high-speed internet, the GDSII was stored on a magnetic tape and the tape was sent to the foundary.

To "Tape-in" is our cult-jargon for the final release of the RTL and other design information so that the back-end team can start final synthesis and layout / place & route. For algorithm team and RTL coders & verification teams this target "Tape-in" date is the mark on the calendar around which all work, overtime and vacations are planned. It is also the date by which all critical verification and most other verification is to be completed.

The tape-in can be a company internal affair, involving a hand-off between different departments, or a hand-off to an external (sub-) contractor.

Although the design is pretty much final and released at this point, verification still continues after tape-in, and any issues found are triaged. The course of action depends on how far the back-end team is: (1) the issue is fixed and the RTL is revised (a.k.a "re-spinning the RTL"), (2) the design is patched by the backend using spare space, spare logic cells and spare flip-flops intentionally placed and distributed for this purpose, or (3) the issue is deferred as a known bug, carried through documentation, and the designer is shamed for the rest of their short career (so it feels...).

Then there are the issues we don't know about yet. The use of FPGAs has helped narrow this gap, because not only can we run many more tests and re-spin the RTL quickly for the FPGA, we can also run the firmware on a SoC core or a home-brew soft core processor with working hardware busses and interfaces.

Before verification with FPGA the complexity of the hardware was limited, the verification coverage was lower, and you'd need more re-spins of the ASIC to get to acceptable working silicon.

Obviously, the more complex the SoC architecture (DDR, CPU, Logic, peripherals) the larger the gap will be between the FPGA RTL and the ASIC RTL, and dedicated FPGA teams will amend the RTL to map it to the target emulation device.

Any patches have to be verified, and for that we use gate level simulations (very slow) and netlist audits (very tedious manual work). Although the RTL matches the netlist, any further FPGA verification of the design is based on RTL and not the netlist, and it's called "post layout" verification.

Caveat: the meaning of jargon might vary slightly between companies and regions, but it is generally well aligned.

(*) As for the meaning of "RTL": You describe your logic circuits using a hardware design language (HDL) like Verilog or VHDL. RTL (Register Transfer Level) is a specific narrow way of describing your circuit as steps of combinatorial calculations/functions (and/or, look up table etc..) and storage functions (flip-flops, memory). You use an HDL to accomplish that description. An HDL can describe it in other supplemental ways too, such as at a behavioural level and at gate level.

To "run" your code means to simulate the description and confirm that the circuit it implies will do what you expect. As the code base becomes large, it requires more CPU cycles on your laptop or server to simulate what happens, even for simple events. This is why mapping the RTL for an ASIC first to an FPGA for verification is a natural and attractive choice for ever larger designs.

Answer 2

Simulations were done. Designers used SPICE as well as various, often proprietary logic simulators.

You shouldn't think that every chip works perfectly the first time it is manufactured. These design tools are not perfect, and neither is an FPGA emulation. Debugging first silicon is a rite of passage for VLSI designers.

Answer 3

TTL lash-ups, functional simulators, logic simulators, and large budgets for minicomputers to run these things were the norm before FPGA acceleration and prototyping were a thing.

---

The introduction of FPGAs in the mid-late 1980s didn't change things much at first. Early FPGA accelerators (e.g., Quickturn and its competitors) were quite expensive. For ASIC prototyping, the first-gen FPGAs were still too slow, hard to use, not dense enough.

(more here: https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7086413)

Meanwhile, workstations and servers got a lot faster and less expensive, so it made more sense to spend the R&D money on ever-faster machines for simulation.

By then HDLs like VHDL and Verilog (as well as proprietary in-house solutions) were well-established as the design method of choice. As a result, MSI/SSI prototyping fell out of favor, with its use limited to blocks that needed to run at-speed such as mixed-signal I/O or SERDES controllers (and even then, small test chips were and are used for this to validate the designs as these blocks are very process-dependent.)

In time FPGAs got denser, faster, and easier to route; their tools got better (especially third-party synthesis tools like Synplify); their I/Os became more flexible, plentiful and useful, and multi-FPGA partitioning techniques became more manageable for prototyping large designs because of the improved I/Os. This made them not only more useful for acceleration, but more cost-effective for prototyping too.

Nevertheless, there is the conundrum of ASIC vs. FPGA implementation: do you model the ASIC logic gate-for-gate, or do you re-synthesize specifically for FPGA? The answer came in improved synthesis and validation strategies that provided better confidence in the FPGA model, even though its low-level implementation is very different from ASIC standard-cell. So an FPGA-optimized version could be used for prototyping, providing improved speed and density compared to a gate-level model, while maintaining confidence that the ASIC-targeted synthesis will behave the same way.