Subscribe by Email

Your email:

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

Current Articles | RSS Feed RSS Feed

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

Share on Twitter Twitter | Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon | Submit to Reddit reddit 
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.

Comments

Currently, there are no comments. Be the first to post one!
Post Comment
Name
 *
Email
 *
Website (optional)
Comment
 *

Allowed tags: <a> link, <b> bold, <i> italics