RocketBlog - a discussion about all things related to FPGA verification and debug

The First Honest FPGA Pitch: by Gary Smith

Background
Ok, so maybe I'm exaggerating, but it was certainly the first one I've seen and I've seen a lot. For a little background I was part of the semi-custom, or gate array, community during the 1980s. When FPGAs hit the scene, in the mid 1980s, I took a look at them and easily come up with a formula that divided the gate array market from the FPGA market. It was based on production cost of the die and packaging. There was really not much conflict: FPGAs took up the low gate count end of the market, one that we were happy to relinquish due to low profit. At every node change FPGAs were capable of doing a higher percentage of the design starts, but the volume market was still a gate array, or standard cell ball game.

Towards the late 1980s the FPGA marketing establishment became dissatisfied with their fairly predictable market share and started exaggerating their capabilities. One of the ways they did this was by using what became known as the Paterson Gate. To get a Paterson gate count you took the number of ASIC gates that an FPGA could handle and multiply by four, or six if you were pushing performance. Other exaggerated claims were made and they were made loud enough and often enough to cause confusion in the market place.

In 1989 Stan Baker, of EE Times, put together a panel consisting of the marketing managers of the major FPGA vendors and me. The FPGA guys would give their pitch and then I would point out the exaggerations and sometimes outright lies, to the audience. The panel became popular and Stan shopped it around to most of the conferences. I don't think any of this did anything to move the market share needle, but it was all good fun. Unfortunately I got tagged as being anti-FPGA, which wasn't true.

Moshe takes over as CEO of Xilinx

I've known Moshe for a while now and consider him a good friend. I've always known him to be honest, but even so moving to Xilinx he was bound to be influenced by the Xilinx culture. So I was interested I how he was going to handle his presentation at SNUG. He didn't let me down, and as the title of this note says I heard my first honest FPGA presentation.

The New FPGA Market
Not to take any credit away from Moshe, it was actually not difficult to put and end to the exaggerated marketing claims of the past. The reason is that at 45nm an FPGA had enough gates to do true SoC designs. That has opened up a whole new world to the FPGA designer. Now will that bring and end to the ASIC market as we know it? Of course not and Moshe made a point of saying so. What has happened though is a convergence of enough gates, true globalization of electronic design and the move to ES design and you have the reverse of the perfect storm. Everything has become bright and shiny for the FPGA world. Moshe's move to Xilinx couldn't have come at a better time. His experience in both the ASIC business and the EDA business added to his mature, level headed management style is just what the FPGA world needed to take advantage of this golden opportunity. Xilinx is in for quite a ride.

The FPGA Design/Verification Challenge
This is no free ride for the FPGA designer. All of this capability puts him right into the path of systems design. He will need to take his skill level up another notch and especially with the addition of embedded microprocessors he now needs to design and verify both the hardware and software. His EDA tool needs will increase as will the demand on the EDA vendors to provide out of the box flows. They cannot afford the usual Application Support levels common in today's SoC design. It will be interesting to follow the brave new world of FPGA SoC design.

 

 

 

The founder and Chief Analyst for Gary Smith EDA. Previously, he was the Managing Vice President and Chief Analyst of the Electronic Design Automation Service, Design & Engineering Cluster at Gartner Dataquest.

Dr. Seymour Gates answers: "RocketDrive or evaluation card?"

You remember Dr Seymour Gates, right? He's our resident rocket scientist, an expert on all things FPGA and especially the challenges of debugging and verifying these great devices. This week he fields some questions about the advantages of the GateRocket solution over traditional evaluation card approaches. You can't stump this guy! But go ahead and try - send us your FPGA design questions anytime.

Question:

Why would GateRocket be better than loading the design into an evaluation card? In short there is value in both options, using the GateRocket solution will save time and provide visibility and deterministic debug before spending a lot of unproductive time on the card in the lab looking for issues.

Answer(s)

1. Using GateRocket you get functional hardware and tool flow validation with the control of the simulator exercising the interface or other parts of the design and you don't have to have completed system software or the proper stimulus to test the interface. You can test only the parts you like in the RocketDrive, while on a card you have to have all the parts working to be sure the DDR interface is right. The RocketVision software will help pinpoint issues for you (if any) so you can find and correct them fast. By using the RocketDrive system first, all the functional faults will be wrung out and corrected before loading on the eval card and looking for system or timing issues. The whole class of functional faults will have been captured before you get on the card, making car debug much simpler. Because the RocketDrive allows for simulator control and set up, you can test more corner cases with full visibility before hitting a system level on the eval card, and gain upping the chances the design works right the first time when the card is brought up

2. Using the card can require a pretty complete system up and running to do even the most basic testing. System software, drivers, and the card all have to be functional to test the DDR2 interface. If you use just the card, and it fails, you have to back track through all level of the system and the FPGA design to learn why the failure happened, diagnose the root cause, and correct it in the lab environment with limited visibility.

3. You will have to adapt the FPGA design code to fit the pin out of the eval card to see if the design works assuming your system board for final shipment is different from the evaluation card which it is in most cases.

4.The value of the RocketDrive will be more evident on a advanced design, so for a very simple design using our system may be of less value. But if the design is more complex, IP blocks, multiple clocks, over 30K FFs, then the value of the RocketDrive goes way up and will save considerable time in the development process.

If you have a question for Dr. Seymour Gates, please provide your question by filling out the form on this page.