5 ms·

As a veteran from the chip industry, I should warn you that all these suggestions about FPGAs for prototyping are not really done that much in the ASIC industry

As a veteran from the chip industry, I should warn you that all these suggestions about FPGAs for prototyping are not really done that much in the ASIC industry. The skills to do front end work are similar but an ASIC design flow generally doesn't use an FPGA to prototype. They are considered slow to work with and not cost effective. IP cores in ASICs come in a range of formats. "Soft IP" means the IP is not physically synthesised for you. "Hard IP" means it has been. The implications are massive for all the back end work. Once the IP is Hard, I am restricted in how the IP is tested, clocked, resetted and powered. For front end work, IP cores can be represented by cycle accurate models. These are just for simulation. During synthesis you use a gate level model.

pslam 9y ago
As a veteran from the chip industry, I can tell you my experience is completely the opposite. Nobody in their right mind would produce an ASIC without going through simulation as a form of validation. For anything non-trivial, that means FPGA.
- phkahler 9y ago
  I find the above pair of comments really interesting. I'm guessing there are parallels with differences of opinion and approach in other areas of engineering. There are always reasons for the differences, and those are usually rooted in more than just opinion or dogma. In this case, I'd guess its got a lot to do with cost vs relevance of the simulation. If you're Intel or AMD making a processor, I bet FPGA versions of things are not terribly relevant because it doesn't capture a whole host of physical effects at the bleeding edge. OTOH for simpler designs on older processes, one might get a lot of less formal verification by demonstrating functionality on an FPGA. But this is speculation on my part.
  - gluggymug 9y ago
    "If you're Intel or AMD making a processor, I bet FPGA versions of things are not terribly relevant because it doesn't capture a whole host of physical effects at the bleeding edge." Exactly. When you verify a design via an FPGA you are only essentially testing the RTL level for correctness. Once you synthesise for FPGA rather than the ASIC process, you diverge. In ASIC synthesis I have a lot more ability to meet timing constraints. So given that FPGA validation only proves the RTL is working, ASIC projects don't focus on FPGA. We know we have to get back annotated gate level simulation test suite passing. This is a major milestone for any SoC project. So planning backwards from that point, we focus on building simulation testbenches that can work on both gate level and RTL. I am not saying FPGAs are useless but they are not a major part of SoC work for a reason. Gate level simulation is a crucial part of the SoC design flow. All back end work is.
  - dreamcompiler 9y ago
    Let me try to summarize part of this: When you're building an ASIC, you have to care about the design at the transistor level because you're going for maximum density, maximum speed, high volume, and economies of scale. When you're building an FPGA, you are only allowed to care about the gates, which is one abstraction level higher than transistors. In an FPGA, you cannot control individual transistors. (FPGAs build "gates" from transistors in a fundamentally different way than ASICs do, because the gates have to be reprogrammable.) And that's okay because FPGA designs aren't about the highest possible speed, highest density, highest volumes or lowest volume cost.
- gluggymug 9y ago
  I don't agree. If it's non trivial, I don't have the more advanced verification tools such as UVM if I prototype via FPGA. The ability to perform constrained randomised verification is only workable via UVM or something like it. For large designs that is arguably the best verification methodology. Without visibility through the design to observe and record the possible corner cases of transactions, you can't be assured of functional coverage. While FPGAs can run a lot more transactions, the ability to observe coverage of them is limited. I have worked on multiple SoCs for Qualcomm, Canon and Freescale. FPGAs don't play a role in any SoC verification that I've worked on.
  - gibrown 9y ago
    This was my experience working on SoCs at Broadcom also where we didn't really use FPGAs at all. But at another employer that did not work on consumer designs, I did use a lot of large FPGAs in final shipped products, and in those cases we did some of our heavy testing and iterating on the real FPGA(s). For example I built a version of the FPGA with pseudo-random data generation to test an interface with another FPGA. When I found a case that failed I could then reproduce it in simulation much more quickly. That employer also built some ASIC designs and I remember some discussions about using FPGA prototyping for the ASICs to speed up verification or get a first prototype board built faster that would later get redesigned with the final ASIC. I don't know if they ever went down that route but it would not surprise me if they did. These were $20k PCB boards once fully assembled, and integration of the overall system was often a bigger stumbling block than any single digital design. There are a lot of different hardware design niches so I'm sure there are many other cases. All my information is also about 10 years out of date.
  - spear 9y ago
    That's a false dichotomy -- you can do FPGA verification in addition to simulation-based verification. And yes, there are ASIC teams that have successfully done that.
    - gluggymug 9y ago
      At the SoC level, I don't think so. The reasons are numerous. I already gave a few. I will give another. Once you have to integrate hard IP from other parties, you cannot synthesise it to FPGA. Which means you won't be able to run any FPGA verification with that IP in the design. You can get a behavioural model that works in simulation only. In fact it is usually a requirement for Hard IP to be delivered with a cycle accurate model for simulation. I'll give another reason. If you are verifying on FPGA you will be running a lot faster than simulation. The Design Under Test requires test stimulus at the speed of the FPGA. That mans you have to generate that stimulus at speed and then check all the outputs of the design against expected behaviour at speed. This means you have to create additional HW to form the testbench around the design. This is a lot of additional work to gain speed of verification. This work is not reusable once the design is synthesised for ASIC. I can go on and on about this stuff. Maybe there are reasons for a particular product but I am talking about general ASIC SoC work. I got nothing against FPGAs. I am working on FPGAs right now. But real ASIC work uses simulation first and foremost. It is a dominant part of the design flow and FPGA validation just isn't. On a "Ask HN", you would be leading a newbie the wrong way to point to FPGAs. It is not done a lot.
scott_wilson46 9y ago
I've had a different experience to this. I've worked on ASIC's for over ten years and have had experience with nearly all aspects of the design flow (from RTL all the way to GDS2 at one point or another). I've taped out probably 20+ chips (although I've been concentrating on FPGA's for the last three years). Every chip that I've taped out has had extensive FPGA prototyping done on the design. This is in a variety of different areas too (Bluetooth, GPU's, CPU's, video pipelines, etc). You can just get a hell of a lot more cycles through an FPGA prototyping system than you can an RTL sim and when you are spending a lot of money on the ASIC masks, etc you want to have a chance to soak test it first.
- zerohp 9y ago
  My experience agrees with yours. Many big-budget teams use a hardware emulator like the Palladium XP or the similar Synopsis device. Both built from FPGAs. Hardware emulators are expensive, but a single mask respin at 7, 10, or 16nm is even more expensive.
  - gluggymug 9y ago
    There is a distinction between hardware emulators and FPGAs. Though hardware emulators such as Palladiums may use FPGAs inside them they don't work the same way in terms of validation. The two tools are very different to use. See myth 7 here: http://www.electronicdesign.com/eda/11-myths-about-hardware-emulation http://www.electronicdesign.com/eda/11-myths-about-hardware-...

pslam 9y ago

As a veteran from the chip industry, I can tell you my experience is completely the opposite. Nobody in their right mind would produce an ASIC without going through simulation as a form of validation. For anything non-trivial, that means FPGA.

phkahler 9y ago
I find the above pair of comments really interesting. I'm guessing there are parallels with differences of opinion and approach in other areas of engineering. There are always reasons for the differences, and those are usually rooted in more than just opinion or dogma. In this case, I'd guess its got a lot to do with cost vs relevance of the simulation. If you're Intel or AMD making a processor, I bet FPGA versions of things are not terribly relevant because it doesn't capture a whole host of physical effects at the bleeding edge. OTOH for simpler designs on older processes, one might get a lot of less formal verification by demonstrating functionality on an FPGA. But this is speculation on my part.
- gluggymug 9y ago
  "If you're Intel or AMD making a processor, I bet FPGA versions of things are not terribly relevant because it doesn't capture a whole host of physical effects at the bleeding edge." Exactly. When you verify a design via an FPGA you are only essentially testing the RTL level for correctness. Once you synthesise for FPGA rather than the ASIC process, you diverge. In ASIC synthesis I have a lot more ability to meet timing constraints. So given that FPGA validation only proves the RTL is working, ASIC projects don't focus on FPGA. We know we have to get back annotated gate level simulation test suite passing. This is a major milestone for any SoC project. So planning backwards from that point, we focus on building simulation testbenches that can work on both gate level and RTL. I am not saying FPGAs are useless but they are not a major part of SoC work for a reason. Gate level simulation is a crucial part of the SoC design flow. All back end work is.
- dreamcompiler 9y ago
  Let me try to summarize part of this: When you're building an ASIC, you have to care about the design at the transistor level because you're going for maximum density, maximum speed, high volume, and economies of scale. When you're building an FPGA, you are only allowed to care about the gates, which is one abstraction level higher than transistors. In an FPGA, you cannot control individual transistors. (FPGAs build "gates" from transistors in a fundamentally different way than ASICs do, because the gates have to be reprogrammable.) And that's okay because FPGA designs aren't about the highest possible speed, highest density, highest volumes or lowest volume cost.
gluggymug 9y ago
I don't agree. If it's non trivial, I don't have the more advanced verification tools such as UVM if I prototype via FPGA. The ability to perform constrained randomised verification is only workable via UVM or something like it. For large designs that is arguably the best verification methodology. Without visibility through the design to observe and record the possible corner cases of transactions, you can't be assured of functional coverage. While FPGAs can run a lot more transactions, the ability to observe coverage of them is limited. I have worked on multiple SoCs for Qualcomm, Canon and Freescale. FPGAs don't play a role in any SoC verification that I've worked on.
- gibrown 9y ago
  This was my experience working on SoCs at Broadcom also where we didn't really use FPGAs at all. But at another employer that did not work on consumer designs, I did use a lot of large FPGAs in final shipped products, and in those cases we did some of our heavy testing and iterating on the real FPGA(s). For example I built a version of the FPGA with pseudo-random data generation to test an interface with another FPGA. When I found a case that failed I could then reproduce it in simulation much more quickly. That employer also built some ASIC designs and I remember some discussions about using FPGA prototyping for the ASICs to speed up verification or get a first prototype board built faster that would later get redesigned with the final ASIC. I don't know if they ever went down that route but it would not surprise me if they did. These were $20k PCB boards once fully assembled, and integration of the overall system was often a bigger stumbling block than any single digital design. There are a lot of different hardware design niches so I'm sure there are many other cases. All my information is also about 10 years out of date.
- spear 9y ago
  That's a false dichotomy -- you can do FPGA verification in addition to simulation-based verification. And yes, there are ASIC teams that have successfully done that.
  - gluggymug 9y ago
    At the SoC level, I don't think so. The reasons are numerous. I already gave a few. I will give another. Once you have to integrate hard IP from other parties, you cannot synthesise it to FPGA. Which means you won't be able to run any FPGA verification with that IP in the design. You can get a behavioural model that works in simulation only. In fact it is usually a requirement for Hard IP to be delivered with a cycle accurate model for simulation. I'll give another reason. If you are verifying on FPGA you will be running a lot faster than simulation. The Design Under Test requires test stimulus at the speed of the FPGA. That mans you have to generate that stimulus at speed and then check all the outputs of the design against expected behaviour at speed. This means you have to create additional HW to form the testbench around the design. This is a lot of additional work to gain speed of verification. This work is not reusable once the design is synthesised for ASIC. I can go on and on about this stuff. Maybe there are reasons for a particular product but I am talking about general ASIC SoC work. I got nothing against FPGAs. I am working on FPGAs right now. But real ASIC work uses simulation first and foremost. It is a dominant part of the design flow and FPGA validation just isn't. On a "Ask HN", you would be leading a newbie the wrong way to point to FPGAs. It is not done a lot.

scott_wilson46 9y ago

I've had a different experience to this. I've worked on ASIC's for over ten years and have had experience with nearly all aspects of the design flow (from RTL all the way to GDS2 at one point or another). I've taped out probably 20+ chips (although I've been concentrating on FPGA's for the last three years). Every chip that I've taped out has had extensive FPGA prototyping done on the design. This is in a variety of different areas too (Bluetooth, GPU's, CPU's, video pipelines, etc). You can just get a hell of a lot more cycles through an FPGA prototyping system than you can an RTL sim and when you are spending a lot of money on the ASIC masks, etc you want to have a chance to soak test it first.

zerohp 9y ago
My experience agrees with yours. Many big-budget teams use a hardware emulator like the Palladium XP or the similar Synopsis device. Both built from FPGAs. Hardware emulators are expensive, but a single mask respin at 7, 10, or 16nm is even more expensive.
- gluggymug 9y ago
  There is a distinction between hardware emulators and FPGAs. Though hardware emulators such as Palladiums may use FPGAs inside them they don't work the same way in terms of validation. The two tools are very different to use. See myth 7 here: http://www.electronicdesign.com/eda/11-myths-about-hardware-emulation http://www.electronicdesign.com/eda/11-myths-about-hardware-...