Comments on: An ASIC Guy Visits An FPGA World - Part II http://theasicguy.com/2009/06/22/an-asic-guy-visits-an-fpga-world-part-ii/ sharing insights into the people side of ASIC design Sat, 11 Feb 2012 20:49:24 +0000 http://wordpress.org/?v=2.3.2 By: Dave Simmons http://theasicguy.com/2009/06/22/an-asic-guy-visits-an-fpga-world-part-ii/#comment-1005 Dave Simmons Thu, 09 Jul 2009 05:48:23 +0000 http://theasicguy.com/2009/06/22/an-asic-guy-visits-an-fpga-world-part-ii/#comment-1005 As an ASIC snob, I have always had sort of the same attitude toward FPGA designers that Bill Widlar (the inventor of the 741 op amp) had toward digital designers generally. Anybody who uses wiring delays to solve timing problems probably isn't really housebroken, either. The fact that you only get one chance to get it right with an ASIC really enforces some engineering discipline and makes for better engineers, IMO. However, maybe if I hadn't been so arrogant about it, I'd actually have been able to stay employed, instead of ending up involuntarily retired. For years on end, ASICs and FPGAs were leapfrogging each other in design starts, but in the past few years, FPGAs would appear to have taken the high ground permanently. As a result, while the demand for ASIC designers has faded away, the demand for FPGA designers is still there - even if clock tree synthesis is completely beyond them. Oh well... As an ASIC snob, I have always had sort of the same attitude toward FPGA designers that Bill Widlar (the inventor of the 741 op amp) had toward digital designers generally. Anybody who uses wiring delays to solve timing problems probably isn’t really housebroken, either. The fact that you only get one chance to get it right with an ASIC really enforces some engineering discipline and makes for better engineers, IMO.

However, maybe if I hadn’t been so arrogant about it, I’d actually have been able to stay employed, instead of ending up involuntarily retired. For years on end, ASICs and FPGAs were leapfrogging each other in design starts, but in the past few years, FPGAs would appear to have taken the high ground permanently. As a result, while the demand for ASIC designers has faded away, the demand for FPGA designers is still there - even if clock tree synthesis is completely beyond them.

Oh well…

]]> By: Rajesh C http://theasicguy.com/2009/06/22/an-asic-guy-visits-an-fpga-world-part-ii/#comment-980 Rajesh C Mon, 29 Jun 2009 19:40:17 +0000 http://theasicguy.com/2009/06/22/an-asic-guy-visits-an-fpga-world-part-ii/#comment-980 I have noticed FPGA designers cutting corner on verification. But here is the fact. Running simulation on FPGA same level as in ASIC would be overkill. But there is got to be adequate simulation, else as someone pointed out, design team get thrashed in lab. I think fresh FPGA designers get swayed by FPGA vendor marketing, that everything is cozy and tool will take care of everything. ASIC experience can provide a lot of education here. I have noticed FPGA designers cutting corner on verification. But here is the fact. Running simulation on FPGA same level as in ASIC would be overkill. But there is got to be adequate simulation, else as someone pointed out, design team get thrashed in lab.

I think fresh FPGA designers get swayed by FPGA vendor marketing, that everything is cozy and tool will take care of everything. ASIC experience can provide a lot of education here.

]]> By: Dave Orecchio http://theasicguy.com/2009/06/22/an-asic-guy-visits-an-fpga-world-part-ii/#comment-969 Dave Orecchio Wed, 24 Jun 2009 19:39:08 +0000 http://theasicguy.com/2009/06/22/an-asic-guy-visits-an-fpga-world-part-ii/#comment-969 Hi Harry, I have enjoyed both FPGA posts and suggest another one that looks at the distribution of design starts by chip size and family. When you do that you will see that the low end (small and simple) designs follow the traditional "old school" FPGA design process of "no simulation and quick to the lab" approach. Anyone who is doing a large design (consider 40,000 luts or larger) is going to simulate otherwise they will find themselves thrashing in the lab. I recently spoke to one company that fired their development team because they were thrashing in the lab and could not get the product to work and in the process I discovered that they attempted to design and debug the large FPGA without simulation! The replacement team started to simulated the design like it should have been from the beginning. The recent Gartner design-start report showed the movement to FPGAs from ASICs and that FPGAs projects outnumber ASIC projects by a 30 to 1 margin. The many who are moving from ASICs to FPGAs are using traditional ASIC style verification techniques for their FPGA design and verification. In the end, projects where the design is small can get away without simulating but anything of reasonable size or complexity simulation is unavoidable and it is foolish to go into the lab with a design without simulating first. Hi Harry,

I have enjoyed both FPGA posts and suggest another one that looks at the distribution of design starts by chip size and family. When you do that you will see that the low end (small and simple) designs follow the traditional “old school” FPGA design process of “no simulation and quick to the lab” approach.

Anyone who is doing a large design (consider 40,000 luts or larger) is going to simulate otherwise they will find themselves thrashing in the lab. I recently spoke to one company that fired their development team because they were thrashing in the lab and could not get the product to work and in the process I discovered that they attempted to design and debug the large FPGA without simulation! The replacement team started to simulated the design like it should have been from the beginning.

The recent Gartner design-start report showed the movement to FPGAs from ASICs and that FPGAs projects outnumber ASIC projects by a 30 to 1 margin. The many who are moving from ASICs to FPGAs are using traditional ASIC style verification techniques for their FPGA design and verification.

In the end, projects where the design is small can get away without simulating but anything of reasonable size or complexity simulation is unavoidable and it is foolish to go into the lab with a design without simulating first.

]]> By: Narayan Bhagavatula http://theasicguy.com/2009/06/22/an-asic-guy-visits-an-fpga-world-part-ii/#comment-967 Narayan Bhagavatula Tue, 23 Jun 2009 17:07:37 +0000 http://theasicguy.com/2009/06/22/an-asic-guy-visits-an-fpga-world-part-ii/#comment-967 I have done complex verifications of large FPGAs and SOC ASICs and large FPGA do need ASIC like verification flow with OVM, VMM etc. Because debugging in lab on board is quite expensive. The bug is buried deep inside board issues, rtl coding , synthesis and also chipscope type tools do not have visibility of a self checking rtl test bench. Flushing out with RTL test bench is always productive , especially with functional and code coverage. Board respins are costly in terms of market windows. Typically lab fpga verification is best utilized for long transactions (e.g 1 million packets, video streams). Get all your rtl bugs out first with directed tests and constrained random tests in simulation environment. I have done complex verifications of large FPGAs and SOC ASICs and large FPGA do need ASIC like verification flow with OVM, VMM etc. Because debugging in lab on board is quite expensive. The bug is buried deep inside board issues, rtl coding , synthesis and also chipscope type tools do not have visibility of a self checking rtl test bench. Flushing out with RTL test bench is always productive , especially with functional and code coverage. Board respins are costly in terms of market windows. Typically lab fpga verification is best utilized for long transactions (e.g 1 million packets, video streams). Get all your rtl bugs out first with directed tests and constrained random tests in simulation environment.

]]> By: Vinodh C. http://theasicguy.com/2009/06/22/an-asic-guy-visits-an-fpga-world-part-ii/#comment-965 Vinodh C. Mon, 22 Jun 2009 22:06:54 +0000 http://theasicguy.com/2009/06/22/an-asic-guy-visits-an-fpga-world-part-ii/#comment-965 @Harry, Your observation #8 is a little disturbing. I have had several instances where the FPGA vendor provided tools mapped logic to LUTs incorrectly, replaced buffers with invertors, etc. Every one of those instances wouldn't have been caught without Equivalence Checking tools. @Harry,

Your observation #8 is a little disturbing. I have had several instances where the FPGA vendor provided tools mapped logic to LUTs incorrectly, replaced buffers with invertors, etc. Every one of those instances wouldn’t have been caught without Equivalence Checking tools.

]]> By: Sean Murphy http://theasicguy.com/2009/06/22/an-asic-guy-visits-an-fpga-world-part-ii/#comment-963 Sean Murphy Mon, 22 Jun 2009 19:48:57 +0000 http://theasicguy.com/2009/06/22/an-asic-guy-visits-an-fpga-world-part-ii/#comment-963 Harry, you should approach the FPGA Summit folks with your panel idea, I think they are still planning their program for this year. See http://www.fpgasummit.com/ the Program Chairperson is Dr. Lance Leventhal Phone: 858.756.3327 / Email: lance@fpgasummit.com Harry, you should approach the FPGA Summit folks with your panel idea, I think they are still planning their program for this year. See http://www.fpgasummit.com/ the Program Chairperson is Dr. Lance Leventhal
Phone: 858.756.3327 / Email: lance@fpgasummit.com

]]> By: Shyamprakash Aandoor http://theasicguy.com/2009/06/22/an-asic-guy-visits-an-fpga-world-part-ii/#comment-962 Shyamprakash Aandoor Mon, 22 Jun 2009 19:24:20 +0000 http://theasicguy.com/2009/06/22/an-asic-guy-visits-an-fpga-world-part-ii/#comment-962 Hi Harry, There is an important aspect of FPGA design that you missed in your investigation. Unlike ASIC tapeout, you don't have to be paranoid about potential bugs that may exist in your design. If you happen to ship a product with a bug, you can always send new bitfile with fix, just like Microsoft sends you Windows patch. In fact this psychological relief will help faster turn around in product development. Yes, this bug fix will cost your organization, but far far less when compared to such a situation in an ASIC product. Shyam Hi Harry,

There is an important aspect of FPGA design that you missed in your investigation. Unlike ASIC tapeout, you don’t have to be paranoid about potential bugs that may exist in your design. If you happen to ship a product with a bug, you can always send new bitfile with fix, just like Microsoft sends you Windows patch.

In fact this psychological relief will help faster turn around in product development. Yes, this bug fix will cost your organization, but far far less when compared to such a situation in an ASIC product.

Shyam

]]>