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

FPGA Survey Highlights Debug Crisis

The popular web site and newsletter FPGA Journal conducted a survey of its readership in the spring of 2010 to determine the biggest issues in verifying and debugging complex FPGAs today. Over 300 FPGA designers and managers responded to the survey, citing the bottlenecks they face as they try to bring up today's most advanced FPGAs.

The survey produced some eye opening results, particularly among the segment of the survey population doing complex FPGA design. On average, the number of iterations required to bring up a working FPGA is more than 100, a situation unheard of in previous eras of FPGA use, and one that is threatening the biggest FPGAs to being with – faster time to market and/or rapid prototyping.

The survey revealed that the number one issue causing lengthy debug times is tracking down errors in RTL code. This can be a result of designer error, or, increasingly, because of issues related to other design tools such as synthesis and place and route, or IP cores. Regardless of the source, these types of errors are tougher and tougher to find using traditional FPGA debug and verification techniques.

In fact, the survey results show that debugging a complex FPGA can now represent to 92 days of the overall development cycle!

If you are having issues with FPGA debug and verification, you are not alone. Of course, we believe GateRocket can help address this growing crisis with our solutions for giving designer increased visibility into their FPGA design through our unique Device Native approach.

To see for yourself what other designers are experiencing, go here to sign up for a 7-page summary of the survey results

Xilinx 7 Series: A game changer for FPGAs?

Last month Xilinx took the wraps off its next generation FPGA family, the 7 Series.  There were many exciting advancements included in the roadmap laid out by the company as it moves its state of the art devices to 28nm (on TSMC and Samsung processes). For us at GateRocket, we are impressed with the huge leap in capacity that the move to 28nm will enable – in some cases doubling the amount of logic gates for designers to work with. Virtex7, for example, offers 2 million logic cells. With that kind of capacity, it is inevitable that the verification and debug challenges for FPGA designers will require an advanced and efficient approach. More on that in a bit.

First a recap of the 7 Series.

Interestingly, the Xilinx FPGA family now consists of three components, instead of the traditional Virtex/Spartan product lines. The new triumvirate consists of Virtex at the high end, and newly named Kintex as the mid range option, and Atrix as the lower cost alternative. It’s good to see Xilinx continue to expand the number of options and overall flexibility for its product line, tailoring the products for specific needs like cost, performance, power, etc.

Family naming conventions aside, the technology under the hood of the new architecture and devices is impressive. First of all, Xilinx continues its Targeted Design Platform strategy with the 7 Series, which helps designers optimize FPGA for special applications like wireless or broadband or DSP. The new family looks to offer a smooth transition path from previous generations Xilinx devices, too.

Most importantly in terms of breaking into new markets, Xilinx appears to have cracked the code on delivering truly low power solutions for programmable devices. The new family reduces power by up to 50% over previous generations, positioning it very well for demanding consumer and mobile markets that require low power consumption characteristics. In fact Xilinx CEO Moshe Gavrielov says that with the low power capabilities of the 28-nm family, the market opportunity for FPGAs could be twice as large as what is if for the current 45/40nm generation. With the combination of low power, high capacity, and targeted design strategy, Xilinx thinks it can break into markets like LTE basebands, automotive infotainment and more advanced medical applications, for example.

As FPGAs continue their march along the Moore’s Law curve, the needs for specialized and powerful design tools becomes clearer and clearer. The 7 Series is a great advancement and we are excited to be part of how it will transform FPGAs as we know it.  For those of you who may not be familiar with our solution, because we use the FPGA to test the FPGA and leverage the vendor tools to place the design into the RocketDrive, we are able to leverage all of Xilinx R&D when we deliver new RocketDrives based on the new family of devices. 

In essence, we can offer a solution as soon as the devices are available and we start to see customer demand for them. With our recently-announced support of the Virtex-6 family already seeing much interest in the market, we are excited to move along the technology curve with the FPGA suppliers and let our mutual customers leverage the great potential these devices now offer.

See you at DAC 2010

The Design Automation Conference is always a great event to catch up with people in the industry - customer, partners, press, other EDA suppliers. We're expecting next week's 47th edition of the annual chip design confab, to be held in Anaheim, to be no different, albeit perhaps less crowded than the glory days of years gone past.

For GateRocket, it's an opportunity to show the world the latest solutions we have to address the most pressing FPGA design verification debug challenges. Front and center of our exhibit will be our Release 5.0 of our RocketVision debug solution, featuring the highly efficient SoftPatch feature. SoftPatch eliminates the majority of long loops through synthesis and place and route by enabling interactive exchange of RTL and device-level design representations within the user's software simulator without rebuilding the FPGA.

Our RocketDrive verification tool comes in new flavors now, with support for Xilinx' Virtex-6 devices being offered now (to go along with Virtex-4 and Virtex-5, and Altera's Stratix II and IV families). In fact, we've introduced a tiered pricing model for RocketDrive, which leverages our unique Device Native approach to speeding up verification performance.

We're honored that we are once again on Gary Smith's "What to see @DAC" list, which he will present on Monday morning at 9:00AM in Booth #694.

Come see us in Booth #1319. We'll give you a copy of the recent FPGA Journal survey that shows where the growing pain points are in the FPGA design process.

We'll also be telling our story in the DAC Exhibitor Forum. That's located in Booth #1562 and we'll be on stage on Wednesday at 3:55PM.

Finally, if you want to hear and chime in on a debate about the future of FPGA tools, we recommend going by the panel entitled "Is the FPGA tool opportunity an oasis or mirage." This will be held in Booth #694 at 2:30 on Tuesday and will be moderated by FPGA Journal editor Kevin Morris.

Hope to see many of you at DAC 2010, and if you come by our booth, we'll make sure you take a rocket home from Anaheim!

Not your father's FPGAs

The current generation of modern FPGAs have reached unprecedented levels of performance, size and complexity. Devices like those in the Xilinx Virtex®-6 family, for example, are built on the most advanced manufacturing processes (45nm and 40nm) and allow true system-on-chip integration featuring embedded processing cores that enable the most bandwidth-demanding applications.

In addition to the performance advantages, devices in the Virtx-6 family consume 50 percent less power and deliver 20 percent lower cost than the previous generations. The latest family is built with a mix of programmability, integrated blocks for digital signal processing (DSP), memory, and connectivity support - including PCI Express(R) 2.0 compliant interface blocks and high-speed transceivers supporting line rates beyond 11Gbps to satisfy the insatiable demand for higher bandwidth and performance. These advances enable system architects to integrate Virtex-6 FPGAs into their designs to enable 'green' central offices and data centers, which is particularly relevant for the telecommunications industry as it deploys new technologies to support the demand for internet video and rich media content.

Clearly, these are not your father's FPGA's anymore.

With the great benefits and capabilities of today's most sophisticated FPGAs come a new wave of design challenges. At GateRocket we are focused exclusively on the debug and verification issues associated with these mammoth devices.

That's why we are pleased to offer a new version of our verification solution that incorporates FPGAs from the Xilinx Virtex-6 family. Using GateRocket's RocketDrive system, designers can now literally integrate the Virtex-6 FPGA into their HDL simulator to provide a "hardware in the loop" process based on GateRocket's proprietary Device Native® methodology. This has proven to cut verification and debug time half versus traditional FPGA design approaches. By combining the actual FPGA hardware and RTL simulation models in the same verification run, this solution reduces verification time significantly.

Advanced debugging with RocketVision® for Virtex-6 devices
In addition to the performance boost the RocketDrive system provides, the GateRocket solution also allows designers using Virtex-6 devices to move effortlessly between RTL and the specific FPGA being targeted, combining actual FPGA hardware and RTL simulation models together in a single verification run, without changes in the design flow or methodology. This technique, called soft patch, provides engineers with the ability to make a change to one or more RTL blocks and re-run them along with the hardware implementations of the other blocks, thereby avoiding the need to rebuild the device for each fix and enabling multiple design-change-debug iterations in a single day. The net result is a time savings of up to 50% or more over traditional verification and debug approaches.

Multiple configurations optimized for different user needs
The new Virtex-6 RocketDrives use the largest LX and SX devices for advanced logic and DSP applications respectively. GateRocket also offers a cost effective mid-range device configuration targeted at users who do not require the largest FPGA device in the family. By using devices optimized for specific needs, GateRocket can pass along the cost savings for an even greater return on investment. Each RocketDrive configuration offers the same enhanced verification performance and debug efficiency, and maintains complete compatibility with popular EDA logic simulators from Cadence, Mentor and Synopsys.

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.

Survey Says: FPGA designers at or near a debug crisis

 

A lot of you have told us you're in pain. Enough that we began to ask ourselves whether there are bigger debug problems brewing in FPGA design. To answer the question we turned to our friends at The FPGA Journal. They helped us put together a survey to ask FPGA designers what causes them pain in the FPGA design process. FPGA designers - that's you - responded en mass and for the first time we have a picture of the biggest problem facing FPGA designers.  

Designers are in Crisis

Nearly one quarter of FPGA designers today are in crisis mode when it comes to the amount of time spent (wasted) debugging designs. Current design practices, specifically the process for identifying and fixing bugs in FPGAs by looping from the lab, where a bug is identified, back through simulation, synthesis and place and route, adds between 92 and 148 days to the typical FPGA design process. These times are growing fast as design and chip complexity increases threatening one of the primary advantages of FPGA technology - rapid time to market.  

Fix Bugs Up Front

By contrast, if FPGA design bugs can be identified and fixed up front in the design process, the survey respondents told us it takes an average of 55% less time to find and fix a bug.  The problem is that many of the bugs only manifest themselves in the programmed FPGA.  Therefore, in order to expose the bug and correct it up-front in the design process, the FPGA device must be integrated into the simulation environment in a way that combines software-like flexibility with the implementation accuracy of the FPGA – like is only done with a RocketDrive and RocketVision.   

Long Synthesis-Place-Rout Cycles are the Problem

Users identified long synthesis-place-route cycles as the key productivity issue.  Using a hardware-in-the-loop solution that links simulation with the FPGA and enables debug without rebuilding the device with each debug iteration addresses the problem.  This is a significant improvement to the present methodology (looping through simulation-synthesis-P&R and debugging in the lab). Imagine cutting design time in half by eliminating unnecessary cycles of synthesis and place-and-route, which survey respondents identified as the most acute time consumers. 

Cut Time-to-Market by 60 days

The good news is this: Time to market can be reduced by more than 60 days for large, complex FPGAs by making a simple change in the design process! The GateRocket RocketDrive enables this paradigm shift in the FPGA design process. This solution further reduces the time it takes to find and fix real hardware bugs in simulation because it accelerates simulation at the same time and further enables the flexibility to run rapid test and verification cycles in the design running in the target hardware with the simulator.FPGA Journal editor Kevin Morris describes it as "the best of both worlds...the visibility, control, flexibility, and iteration time of the (software) simulator combined with the raw speed of native FPGA hardware."

If you would like to learn more, please contact us.

Guest Blog: Max Maxfield on FPGAs becoming SoCs

When I graduated college and commenced my career in 1980, my first job was as a member of a team designing CPUs for mainframe computers. At that time, only a limited number of digital implementation technologies were available to us: we could either use a bucketful of simple off-the-shelf "Jelly-Bean" integrated circuits each containing a handful of primitive logic gates, or we could create our own custom ASIC device (we were working at the 5 micron technology node in those days, and each ASIC contained only around 2,000 logic gates and registers).

We also had simple programmable logic devices (SPLDs), which we used for a variety of tasks such as implementing rudimentary state machines, acting as look-up tables, or gathering a bunch of "glue logic" functions together. These devices were invaluable when it came to fixing late-stage design errors without being obliged to re-spin the board.

I remember when the FPGAs first appeared on the market in the mid-1980s. The thing I remember the most was how unimpressed we all were. As far as we could see, although these components provided a little more capacity and flexibility than our existing SPLDs, they lacked the deterministic timing of their predecessors. And since we performed our board-level timing analysis using a pencil and paper, this was something of an issue.

So, my first impression was that FPGAs were of interest when it came to implementing glue logic and simple state machines ... but not much more. Over time, of course, FPGAs grew in terms of capacity and performance and became much more interesting. They also started to boast a variety of configurable input/output (I/O) capabilities, which made them of interest for interfacing between other components that supported different I/O standards.

Today, high-end FPGAs may feature hundreds of thousands of look-up tables, thousands of DSP functions, many hundreds of standard I/Os, large numbers of transceiver blocks providing gigabits-per-second of high-speed serial interface capability ... special communications and interface functions to the outside world (CAN, I2C, SATA, DDR2 and DRR3 memory interfaces, etc.) and the list goes on.

The term System-on-Chip (SoC) was originally associated with ASIC technologies. An SoC was an ASIC that included one or more microprocessor and/or microcontroller and/or DSP cores coupled with on-chip busses, on-chip memory, peripheral functions, communications functions, external interface functions, and the "secret sauce" functions that differentiated this device from the competition. The point is that we can do all of this with a high-end FPGA. For a vast range of applications, FPGAs are today's SoCs!

But with this trend comes a need for more robust design and verification tools. The ability to debug an FPGA design in a timely manner determines time-to-market (and time-to-profit) success; however, debugging one of today's multi-million gate FPGA designs is a non-trivial task. How can you ensure that the third-party RTL IP you are using for your software simulation is functionally identical to the gate-level IP you are loading into the FPGA? And how can you be sure that the optimizations being performed by the synthesis engine aren't introducing errors?

Of course it's no secret that I'm a big fan of GateRocket's RocketDrive, which was uniquely developed to solve debugging problems with the traditional FPGA design process. The RocketDrive bridges the gap between the RTL/abstract-level software simulation domain and the physical FPGA. As each new block is verified at the RTL (or behavioral) level in the context of your full-chip design, its synthesized/gate-level equivalent can be moved over into the physical FPGA in the RocketDrive.

As soon as a problem manifests itself, the verification run can be repeated with the RTL version of the suspect block resident in the simulation world running in parallel with the gate-level version realized in the physical FPGA. By means of a special software application, the signals from the peripheries of these blocks (along with any designated signals internal to the blocks) can be compared "on-the-fly."

Using this technology - combining conventional simulation with physical hardware and an appropriate debugging environment - it is possible to very quickly detect, isolate, identify, and resolve bugs, irrespective of where they originated in the FPGA design flow.

As I say, I'm a big fan ...I strongly recommend that you give a RocketDrive a whirl yourself, and then let me know what you think!

Clive (Max) Maxfield is the president of TechBites, which provides a unique mix of technical content, editorial content, and social networking. Max is the author and co author of a number of books, including Bebop to the Boolean Boogie (An Unconventional Guide to Electronics), The Design Warrior's Guide to FPGAs, and How Computers do Math, featuring the pedagogical and phantasmagorical virtual DIY Calculator. In addition to being a hero, trendsetter, and leader of fashion, Max is widely regarded as being an expert in all aspects of computing and electronics (at least by his mother). Max was once referred to as "an industry notable" and a "semiconductor design expert" by someone famous who wasn't prompted, coerced, or remunerated in any way.