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.
Hosted by: Bill Wong Videography by: Curtis Ellzey and Terry Knight Edited by: Curtis Ellzey
Have a story suggestion? Want to be featured on Engineering TV?
Send us a tip at: EngineeringTV@Penton.com!
(429 Views, 0 Comments)
Altera today announced that its next-generation, 28nm devices will support partial reconfiguration. This means that Altera FPGA users will now be able to update small portions of an FPGA device, rather than having to re-synthesize, re-map and reprogram the entire device every time the application changes.
Xilinx has supported this feature for quite a few years, but has never made it a mainstream, supported feature of their ISE Design Suite development tools. However, in a recent email update to its customers, Xilinx announced with almost no fanfare that, in version 12 of the Xilinx tools, this important capability would finally be given its proper status as a supported feature. Perhaps the marketing department at Xilinx heard rumors coming from the other side of San Jose?
Corporate intrigue aside, this is an important piece of news. Why? Because software application developers first investigating FPGAs are surprised – even shocked – to learn how long the iteration times are for programming and debugging FPGA applications. And the larger the FPGA is, the worse the problem becomes.
For most software developers, being faced with the equivalent of a two, three, or even eight hour iteration time for compile-link-test is completely unacceptable, no matter how much potential increase in performance there may be.
And if, at the end of that long iteration time all the programmer has is a non-working, difficult-to-debug bitmap and a thousand-lines long report filled with hardware-esque warning messages? Then forget it. They might as well go use GPUs and CUDA.
So, why has it taken so long for this seemingly obvious feature to become mainstream? One can only assume that Xilinx and Altera management, their chip architects, and perhaps even their tools developers are hardware engineers first, and software engineers second. Perhaps they can only think of their devices as the poor-man’s ASIC. And their tools as a poor-man’s EDA.
Reliable, vendor-supported partial reconfiguration, including dynamic run-time reconfiguration, has the potential to solve so many problems for software application developers, and to broaden the market for FPGAs.
Consider:
Partial reconfiguration allows developers to iteratively recompile, re-synthesize, re-map and re-test a specific portion of the FPGA in just a few minutes, rather than a few hours. This in itself is a huge benefit. Instead of having to set up elaborate, hardware-oriented simulations to verify correct behavior before hitting that compile button, you can just try it out, again and again, in the same way you would when developing software. Indeed, this method of design was predominant for FPGAs in the 1980s and early 1990s. But as device densities have grown, iterative design-and-test methods have become impractical. That was good for the hardware simulator business, but bad for software developers.
Run-time reconfiguration allows certain parts of the FPGA to remain intact and functioning, for example the I/O processing, while other parts are being updated on-the-fly. Need to change the filtering of a video signal to respond to a change in resolution? Wham, it’s done, and so fast the viewer doesn’t even see a flicker. Want to change the FPGA’s function without causing a system reboot? How about leaving the PCIe endpoint alone and just changing the core algorithm?
Dynamic reconfiguration can increase the effective size of an FPGA. Loading of partial bitmaps at run-time allows the capacity of these devices to grow in the dimension of time. If you don’t need all the hardware capabilities you have programmed into your FPGA all the time, then use dynamic reconfiguration to swap hardware modules in and out as needed. Use reconfiguration to do more, with less.
Partial reconfiguration opens up new FPGA markets. Using partial reconfiguration, the vendors of FPGA-based platforms for specific types of applications – for financial transaction processing and automated trading, for example – could provide a “minimally programmable embedded system” in which most of the FPGA logic is pre-designed, pre-optimized and locked down, while a small portion in the middle is left available for end-user customization. This potentially opens up whole new application domains that were previously not available for FPGAs; applications in which the platform vendor and the end user both have unique domain knowledge, and have their own critical IP to protect.
Again, these capabilities are not really new; the Xilinx partial reconfiguration features have been used successfully, for years, in domains such as software-defined radio. What’s changing is that partial reconfiguration is finally becoming officially supported. With uncertainties about its future and its supportability reduced, software and platform vendors will now begin using these features to enable new programming, debugging and operating features into their own products.
It’s about time.
Altera today announced that its next-generation, 28nm devices will support partial reconfiguration. This means that Altera FPGA users will now be able to update small portions of an FPGA device, rather than having to re-synthesize, re-map and reprogram the entire device every time the application changes.
Xilinx has supported this feature for quite a few years, but has never made it a mainstream, supported feature of their ISE Design Suite development tools. However, in a recent email update to its customers, Xilinx announced with almost no fanfare that, in version 12 of the Xilinx tools, this important capability would finally be given its proper status as a supported feature. Perhaps the marketing department at Xilinx heard rumors coming from the other side of San Jose?
Corporate intrigue aside, this is an important piece of news. Why? Because software application developers first investigating FPGAs are surprised – even shocked – to learn how long the iteration times are for programming and debugging FPGA applications. And the larger the FPGA is, the worse the problem becomes.
For most software developers, being faced with the equivalent of a two, three, or even eight hour iteration time for compile-link-test is completely unacceptable, no matter how much potential increase in performance there may be.
And if, at the end of that long iteration time all the programmer has is a non-working, difficult-to-debug bitmap and a thousand-lines long report filled with hardware-esque warning messages? Then forget it. They might as well go use GPUs and CUDA.
So, why has it taken so long for this seemingly obvious feature to become mainstream? One can only assume that Xilinx and Altera management, their chip architects, and perhaps even their tools developers are hardware engineers first, and software engineers second. Perhaps they can only think of their devices as the poor-man’s ASIC. And their tools as a poor-man’s EDA.
Reliable, vendor-supported partial reconfiguration, including dynamic run-time reconfiguration, has the potential to solve so many problems for software application developers, and to broaden the market for FPGAs.
Consider:
Partial reconfiguration allows developers to iteratively recompile, re-synthesize, re-map and re-test a specific portion of the FPGA in just a few minutes, rather than a few hours. This in itself is a huge benefit. Instead of having to set up elaborate, hardware-oriented simulations to verify correct behavior before hitting that compile button, you can just try it out, again and again, in the same way you would when developing software. Indeed, this method of design was predominant for FPGAs in the 1980s and early 1990s. But as device densities have grown, iterative design-and-test methods have become impractical. That was good for the hardware simulator business, but bad for software developers.
Run-time reconfiguration allows certain parts of the FPGA to remain intact and functioning, for example the I/O processing, while other parts are being updated on-the-fly. Need to change the filtering of a video signal to respond to a change in resolution? Wham, it’s done, and so fast the viewer doesn’t even see a flicker. Want to change the FPGA’s function without causing a system reboot? How about leaving the PCIe endpoint alone and just changing the core algorithm?
Dynamic reconfiguration can increase the effective size of an FPGA. Loading of partial bitmaps at run-time allows the capacity of these devices to grow in the dimension of time. If you don’t need all the hardware capabilities you have programmed into your FPGA all the time, then use dynamic reconfiguration to swap hardware modules in and out as needed. Use reconfiguration to do more, with less.
Partial reconfiguration opens up new FPGA markets. Using partial reconfiguration, the vendors of FPGA-based platforms for specific types of applications – for financial transaction processing and automated trading, for example – could provide a “minimally programmable embedded system” in which most of the FPGA logic is pre-designed, pre-optimized and locked down, while a small portion in the middle is left available for end-user customization. This potentially opens up whole new application domains that were previously not available for FPGAs; applications in which the platform vendor and the end user both have unique domain knowledge, and have their own critical IP to protect.
Again, these capabilities are not really new; the Xilinx partial reconfiguration features have been used successfully, for years, in domains such as software-defined radio. What’s changing is that partial reconfiguration is finally becoming officially supported. With uncertainties about its future and its supportability reduced, software and platform vendors will now begin using these features to enable new programming, debugging and operating features into their own products.
It’s about time.
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.