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

Lost in Translation: FPGAs, Synthesis and Finding out why things don't always work as intended

With today's modern FPGAs, designers are using sophisticated design methodologies that were once only used in the ASIC world. This includes the use of high level languages, RTL based design, and synthesis tools.

Synthesis is a critical step in translating high level descriptions of the design into a gate-level netlist that be used to implement the design using place-and-route tools. High level design methods and Synthesis tools are great time savers, and engineers also appreciate their optimization capabilities to find the best options for meeting power, timing and size requirements.

But sometimes things can get lost in translation.

In the process of transforming an RTL level design into a gate-level description, synthesis tools automatically make choices based on their internal optimization algorithms. Now, these optimization features are great for dealing with large complex designs. But engineers can be misled by the choices synthesis tools make as a result. The design may simulate fine. You may not see any warnings during synthesis, or more often you see huindreds of warnings - too many to sort through. But in the end, the design just doesn't work for some reason - a reason that you could spend days and weeks trying to uncover.

See, the synthesis engine makes assumptions about how to apply optimizations in response to different styles and inferred intent presented in your RTL. Without warning, RTL semantics may translate into structure that just doesn't work and you're left guessing what to change.

It can takes hours to re-run synthesis just to find out what to change, and hours again to change the synthesis parameters looking for the reason the tool did not map and optimize your design faithfully. That's if you know it broke your design... and if you don't, you have to add hours of place and route time mapping the broken design to the FPGA just to discover that something is wrong when you get to the lab.

There is a solution to this problem. Our RocketDrive® debug and verification solution bridges the gap between RTL and FPGA implementation by putting your FPGA into your simulator and giving you the tools you need to move back and forth between RTL and FPGA without guessing, re-synthesizing and re-routing. Finding issues caused by synthesis optimizations becomes simple with RocketDrive and doesn't require long loops through synthesis and routing each time you want to examine and debug different parts of the design.

So don't worry about your synthesis tool giving you fits and starts because something gets lost in translation. Let GateRocket be your FPGA ‘interpreter'. We can help you spell success in any language.

Events are a great way to learn about FPGA debug and verification

February and March are always busy months on the trade show calendar and 2010 is no different. The trade shows in our industry are usually a good way for designers to meet with suppliers and their partners face to face, hear about the latest trends, and learn some new things about design, tools, IP and the other aspects of making your jobs easier and better. In surveys, people usually rank peer-to-peer networking and word-of-mouth suggestion very highly on the list of how they get information to do their jobs, and that's why trade shows are still a good medium to bring together people with a common professional interest.

GateRocket will be participating in two events in February and March, one live and one virtual.

The first event is DVCon which has emerged as a preeminent show for engineers and management involved in the verification of ICs and systems. That's obviously right up our alley with our focus on improving how designers verify and debug complex FPGAs. DVCon is held Februrary 22-24 at the Doubletree Hotel in San Jose, near the airport. There are a lot of good sessions, tutorials, and panels planned and they all center on verification related issues. For GateRocket, we'll be using the show to take the wraps of some new technology in our latest release of our RocketVision and RocketDrive solutions. Can't reveal all the details yet but you can be assured we'll be delivering new ways to make verification and debug of FPGAs even more efficient. So if you can make it out to the event, be sure to stop by our booth #802.

The other event we'll be doing soon is called The FPGA Virtual Summit. As the name implies, it's not a live tradeshow like DVCon. It's an extended webinar, to be held March 18, that will consist of a series of presentations and discussions on various FPGA design topics. It's a neat format because you don't even have to leave the comfort of your own desk to take in the information - just log into the web site at the appointed time. It's interactive, too, so you can ask questions of the presenters. Granted, it's not quite the same as talking to someone live, but you can't beat the convenience. GateRocket will be participating in the FPGA Verification session in the afternoon and we'll be sending our more information shortly.

We hope you can join us at DVCon and The FPGA Virtual Summit in the coming weeks. We love hearing first hand from FPGA designers and both these events are ideal ways to do just that.

Beware the IP mismatch in FPGA debug

Incorporating 3rd party IP in a complex ASIC design is a fairly standard practice these days. There's a lot of great functionality available, it saves time compared to designing from scratch, and by and large the IP is of good quality if you get it from a reputable supplier.

Should work the same for FPGAs right? Sounds simple enough - plug in the IP you need and verify it with the context of your entire design. You've got enough simulation horsepower and you can synthesize right to your FPGA target.

But there's a ‘dirty little secret' about IP for FPGAs that you should consider. For FPGA design, IP vendors often give you their cores as both RTL (for simulation) and FPGA netlist models for the device. So the IP models you use for RTL simulation differ in significant ways from the corresponding models the place-and-route software uses. Often, the high-level simulation model contains behavioral constructs to make the software simulations run faster. Synthesis tools cannot handle these constructs, however. Moreover, subtle differences often exist between the behavioral- and gate-level representations that manifest themselves only when you deploy the FPGA design in its target system.

This difference is one that can drive you bonkers, not to mention make your boss a little testy. So how do you deal with this? Even if you try adding some debugging logic around the IP block, it may not solve the problem, leaving you to resort to rounds and rounds of gate-level simulation - a tedious and time consuming chore to say the least. The long-chain test patterns are just too, well, long! Re-running synthesis and place-and-route in hopes of shaking out the bug is equally as time consuming and nerve wracking.

Wouldn't it be great if you could move directly between the RTL representation and the actual FPGA target chip to pinpoint the problem, without having to keep churning through synthesis and place-and-route runs? That's where GateRocket comes in. Our RocketDrive system bridges the gap between RTL and FPGA by putting your design into your FPGA directly. We give you the tools you need to move back and forth between RTL and FPGA without guessing, re-synthesizing and re-routing.

So don't let headaches from IP libraries get you down. The solution is just a call or a click away.

FPGA Debug, you can't fix what you can't see

The legendary baseball pitcher Walter "Big Train" Johnson once said, "You can't hit what you can't see," referring to his blinding fast fastball that helped put him in the Hall of Fame. We're pretty sure the Big Train never had to deal with designing big complex FPGAs, but his words of wisdom apply. Here's why:

Designers struggle with traditional FPGA verification methods, particularly as they move from RTL through the typical synthesis-to-P&R process. Not being able to observe the entire design is a main culprit in what can be a seemingly never-ending design loop. Everything looks great after you run an initial RTL simulation, but lo and behold - after you synthesize to your FPGA target and load the results, there are errors you didn't see in the first go-round. Where did they come from?

You re-check your RTL and simulation. Both are correct. You add some debugging logic around what you think may be the problem. Wait for synthesis and routing to complete. #$@%@%!!! Still doesn't work!

But you can't see any problem with your RTL or simulation, no matter how hard you look, and you can't get it to work how many tweaks you try. The result is big delays and big frustration.

Turns out, synthesis has thrown you a curveball. See, your simulation runs ignore the synthesis pragmas - those directives that give synthesis tools the flexibility to fit your design into silicon. Your RTL simulation doesn't match your netlist and your FPGA design is overwriting registers that you didn't care about in your RTL.

But in your view of the world, you can't see that from just your usual methodology: every step in your process seems to produce the result you expect - except for the finished FPGA. Simulation was fine. Synthesis and routing complete with no errors. The netlist loads without issues. But the design doesn't work.

That's where GateRocket gives you a fighting chance, an opportunity to "see the un-seeable." Our RocketDrive bridges the gap between RTL and the FPGA by putting the FPGA into your simulator and giving you the tools you need to move back and forth between RTL and the FPGA without guessing, re-synthesizing and re-routing. Finding RTL code that does not implement the way it simulates becomes simple with RocketDrive and doesn't require long loops through synthesis and place & route each time you want to examine and debug different parts of the design.

So if you want to play in the big leagues of FPGAs, you better arm yourself with the right equipment. Even the Big Train could understand that.

With FPGAs, bigger is better if you have the right design tools

This week Xilinx announced the first shipments and availability of its Virtex(R)-6 LX760 device. The FPGA market leader is touting the device as the industry's largest FPGA available and says it's for designers "who need raw logic density and industry-leading I/O performance." It's impressive all right, with 1,200 I/O pins and 25,920 Kbits of Block RAM embedded memory. It's been optimized on a UMC 40-nm process which Xilinx claims helps give it 15% higher performance and 50% lower system power consumption compared to competitive 40nm FPGA offerings.

All this is great and shows that the FPGA continue to give ASIC designers a very competitive option for high-performance applications. But with this continued march forward in complexity, the verification and debug challenges will also continue to mount.

We at GateRocket are all too familiar with designers' pain when it comes to verifying and debugging complex FPGAs. Particularly with first time FPGA users (who may have migrated over from more established ASIC methodologies and flows) who struggle with debug issues related to RTL quality and unfamiliar IP. And, seemingly endless synthesis-to-place-and-route loops slow design cycles down as well.

None of this is a result of the FPGA device itself - it's simply a factor of the significantly increased complexity that these devices enable. Therefore, adopters of these mega-FPGAs are looking for more efficient approaches to verification and debug. Particularly with debugging, the complexity of FPGAs makes debugging in the lab with firmware and logic analyzer almost impossible. Enter GateRocket.

With GateRocket designers can combine conventional simulation with physical hardware and an appropriate debugging environment to detect, isolate, identify, and resolve bugs, no matter where they originated in the design flow. Our RocketDrive lets designers plug the FPGA right into the native software simulation environment - we call in ‘device native simulation.'

FPGA suppliers like Xilinx are continuing to bring out larger, more complex chips that are quickly landing in applications that would have been exclusively the domain of ASICs a few years ago. We say ‘bring it on' - even though they do present more ASIC-like challenges, with tools like GateRocket at their disposal, we're sure designers will be up to the task.

Debugging FPGA designs may be harder than you expect

EDN published technical article by GateRocket's founder Chris Schalick about FPGA debug. 

Please read the article here.

Of course, the purpose of these articles is to discuss technical challenges and general approach to the solution without being commercially motivated.  Chris has done that in his article and you can read about the challenges by reading his paper on EDN.  

If you are looking for a solution, here is the rest of the story:

So, what's the solution to the FPGA debug challenge?

After battling his way through similar problems, Chris came to the conclusion that a different approach was required. Designers needed an environment where software and hardware representations could co-exist: where each functional block could reside in the software domain, or in the hardware realm, or in both.

Suppose you could move the gate-level representations of any known-good blocks (i.e. some trusted IP cores) into the same type of FPGA you are targeting for your real-world design? Suppose that you could now verify these blocks in conjunction with the rest of the design running in your software simulator of choice? Right-from the start, your verification time would speed up.

After each block is verified at the RTL (or behavioral) level, its synthesized equivalent can be moved over into the physical FPGA. If issues arise, the RTL verification can be compared with the version 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) could also be compared on-the-fly.

This flexible solution is available now from GateRocket, in the form of the RocketDrive. The RocketDrive houses your target FPGA in removable caddy that plugs into a standard 5¼" drive bay in a standard workstation (figure below). RocketDrives come in a variety of models, each targeted toward a different family of FPGAs from Altera or Xilinx. In each case, the RocketDrive contains the largest member of the family with which you are working.

 Each RocketDrive contains the largest member of the FPGA family with which you are working.

With the RocketDrive, designers start with software simulation. Then using an interface, the designer can place all proven blocks into the drive, while keeping blocks under development in the simulator. This accelerates simulation right away. As new blocks are finished they can be moved into hardware, for “device native” verification and acceleration.

Unlike a simulator, all of the parameters associated with the design's I/O pins are verified in a physical FPGA, and unlike a development board, your design does not need to be modified in any way in order to use this technology.  GateRocket’s software suite provides advanced debug and visualization for a workhorse solution that drops into your design environment without any disruption to your flow. Both hardware and software complement industry-leading simulators from Cadence, Mentor and Synopsys.   In fact, the debug and visualization features are enabled and controlled from within the user's software simulator, which means there is no methodology change.

Now designers can test behavior in a physical chip, running just as it would in-system, while accessing all the capabilities and flexibility of their software simulator. It allows engineers to quickly detect, identify, and correct differences between the RTL and the physical chip.  Results have been repeatedly validated by our customers, who accelerate verification by a factor of up to 10X or more, while reducing the in-silicon debugging process by a 30X. 

FPGA debugging harder than you think?  It’s time to get creative about how we use our chips!  

Xilinx ARMs itself for battle

Xilinx announced today that it has entered into a strategic development relationship with ARM.  This is great news for users of Xilinx devices and the FPGA design community since it brings the most powerful embedded processor to the most prolific programmable platform. 

Do you remember the push for what LSI Logic was calling Structured ASICs?  Back several years ago LSI was pushing platform based silicon with key IP components and embedded processors all connected together with a programmable fabric.  Sound familiar? It should because that is what today's FPGAs have become.  Well, several years into the Structured ASIC business, LSI Logic abruptly pulled out.  Another interesting tidbit is that much of the Xilinx leadership has lineage from LSI Logic.  

Although delivery dates were not mentioned, some time in the future you will be able to build all of your system components into a single FPGA device leveraging the ARM processor technology.  

The challenge that is unanswered is that the FPGA of today is nearly impossible to verify because of long simulation times and debug tools are well suited for small FPGAs only.  That is where GateRocket comes in. The only way to verify and debug these complicated chips is by using the chip itself in a new verification environment.  FPGA tools need to change with the exponential increase in silicon complexity.  We think we have the magic bullet here.  Check out the site and contact us for more info.

In the meantime it is exciting to see how Xilinx is ARMing itself for the FPGA battels.  

The FPGA Blitz as described by David Maliniak

In a football game, when the defense brings many players to tackle the quarterback of the opposing team we call that a blitz. The market trend away from ASIC chips to FPGAs is is a clear blitz, the statistics reported by Gartner of the 30-1 margin prove that point.  

David Maliniak of Electronic Design just published an article titled Tool up for the FPGA Blitz where he describes FPGA design moving to an ASIC like tool flow and the difference in the FPGA process that warrants different tools.  

At GateRocket we view the issues the same way as David does. David describes the need for hardware based verification on page two of his article and he outlines GateRocket in that flow.  

Please take a read of David's article and consider GateRocket when you review your FPGA verification and debug strategy.

 

GateRocket CEO DAC Video Interview

GateRocket had a great Design Automation trade show.  See our earlier post on the topic.  During the conference, Graham Bell of EDA Cafe interviewed the GateRocket CEO.  View the interview bu clicking on the picture.  

During the interview Dave talked about the two announcements at DAC:

1. Shipping of our Stratix IV RocketDrive
   
2. The release of version 4.0 of our software. 
   

The RocketDrive release was expected and the customers who received them benefited by being able to debug their design code on early silicon before their system boards were available in the lab and with an environment where it is much easier to find bugs.

During his discussion of the version 4.0 software he reveled RocketVision's unique ability to pinpoint the root cause of errors and enables the user to run code in or out of the FPGA without rebuilding the chip.  A boon for productivity while debugging the FPGA. 

Dave also discussed being listed on Gary Smith's "Must See" list, the ability to run up to 8 simultaneous RocketDrives at once for system validation and being the "Only Game In Town" when it comes to FPGA verification and debug. 

Graham asked about the key trends we see.  Listen to Dave's view on the topic of FPGA design starts and the innovation and fast pace of the FPGA technology offered by the device vendors. 

 

 

Great DAC for GateRocket

GateRocket is having a great DAC conference.  We are getting attention from many representatives from large companies accross the US.  We have not seen many international attendees but that is expected given the economic climate.  

Engineers who are interested in FPGA verification and debug were excited about our ability to move blocks in and out of the chip without rebuilding the FPGA.  We also saw many who were interested in this capability for ASIC prototyping.  We were the buzz at the show and thank you Gary Smith for adding us to your DAC "Must See" list.  

The weather in San Francisco has been cold and foggy, but GateRocket has been HOT!  Be sure to check out our webinar titled "What you missed at DAC" to see what you've missed.