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?

  • 7
    \$\begingroup\$ GALs, PALs etc.. \$\endgroup\$
    – Andy aka
    Sep 12, 2021 at 15:24
  • 7
    \$\begingroup\$ We built a board about 600 mm square full of TTL to prove the design and get prototypes working for our first custom ASIC \$\endgroup\$
    – Neil_UK
    Sep 12, 2021 at 16:22
  • 6
    \$\begingroup\$ With great efforts :) and a lot of bugs, unrelated to fpga though. Same happens today with fpga and all the available tools \$\endgroup\$
    – user76844
    Sep 12, 2021 at 17:59
  • 2
    \$\begingroup\$ Models, as in prototypes, were often boards of TTL. The chips themselves were either full custom, or later some form of ASIC (such as the Ferranti ULA, which was mask programmed like ROMs of that era). \$\endgroup\$
    – user16324
    Sep 12, 2021 at 18:50
  • 4
    \$\begingroup\$ Maybe you should read "The Soul of a New Machine" by Tracy Kidder, published in 1981. It relates the development of the Data General Eclipse MV/8000, and what the hardware and firmware designers went through. \$\endgroup\$
    – SteveSh
    Sep 12, 2021 at 23:55

3 Answers 3


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.

  • 4
    \$\begingroup\$ Apple famously used Cray supercomputers to design Macs. It was the ONLY direct sales of a Cray machine (all other Cray machines were sold by Cray winning tenders). Apple was a System Verilog shop (and I think still is judging by job ads) \$\endgroup\$
    – slebetman
    Sep 13, 2021 at 17:14
  • \$\begingroup\$ @P2000 I want to ask a question about the impact of AI on professionals in semiconductor industry. Will this question be off topic? \$\endgroup\$
    – lousycoder
    Sep 17, 2021 at 5:57
  • 1
    \$\begingroup\$ @lousycoder sounds like the intent is to grab an audience here with a "linkedIn" type question, and so it would likely be ruled off topic (similar questions have been closed in the past). If you haven't tried it yet, I'd propose an online survey around that topic, and you ask your linkedin contacts to pass it on. \$\endgroup\$
    – P2000
    Sep 17, 2021 at 6:39
  • \$\begingroup\$ @P2000 No, the intent is not that. Stack exchange communities have always been a technical and serious niche audience who share their insights, like in this question. It is rare to find so many people sharing their substantial know how. Can you name a community where this question won't be off topic? \$\endgroup\$
    – lousycoder
    Sep 17, 2021 at 10:41
  • \$\begingroup\$ @lousycoder LinkedIn \$\endgroup\$
    – P2000
    Sep 17, 2021 at 14:02

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.

  • 1
    \$\begingroup\$ While true, great savings can be achieved by keeping any patches/fixes restricted to the metal layers. That, in itself, takes quite a bit of planning and forethought. \$\endgroup\$ Sep 13, 2021 at 18:59
  • 1
    \$\begingroup\$ This is it in a nutshell - lots and lots of simulations, the more the better. The more sophisticated simulations drove corner cases and pathological conditions (scenarios that weren't expected, but could possibly occur). \$\endgroup\$
    – SteveSh
    Sep 13, 2021 at 21:04
  • \$\begingroup\$ PLAs, ROMs and other regular structures could save your bacon by avoiding a base-layer tapeout. They're also editable using FIB techniques to speed up validating fixes. \$\endgroup\$ Sep 14, 2021 at 17:40

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.


Not the answer you're looking for? Browse other questions tagged or ask your own question.