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

Low visibility ahead: Shedding more light on FPGA place-and-route

Using an advanced design methodology to develop modern FPGAs is a requirement for today's leading-edge programmable devices. RTL-based design, synthesis and place-and-route are all standard tools in the designer's toolbox. But as FPGAs become more complex, visibility from RTL through simulation, synthesis and place and route isn't as clear as the old blow-and-go idea of the programmable logic device. The temptation to solve problems by iterating through the RTL-to-programming cycle runs into the reality that these steps each take hours or days to complete and the productivity gained by re-programmability can quickly disappear.

Let's take place-and-route, for example. By the time they reach this step, designers often think they are close to the goal line and just an automated run of a tool away from working silicon. And why not: The RTL simulation worked perfectly. Synthesis did its job and produced a working gate level netlist. On to place-and-route using a tool the device vendor likely provided.

What may not be as straightforward is the fact that, like FPGA synthesis, place-and-route is essentially a translation and optimization function. The tools take a structural representation of a design from synthesis and map it into the physical architecture of the part. This helps optimize the fitting to provide maximum performance from the inherently course grain architecture of FPGA devices.

In order to perform this optimization, place-and-route tools make choices - sometimes at the designer's request and sometimes on their own. The results can introduce new mysteries into the design process and cause undue delays trying to find where and why a decision was made.

Consider a function every FPGA and real logic gate must do: power up and initialize. The place-and-route tool provided by the FPGA vendor decides that one of the design's registers must have a defined state at power-up so it makes an arbitrary - and unfortunate - choice that causes the FPGA to behave completely differently in place-and-route than the simulation. The choice wasn't wrong, but the real-world initialization of a gate that's only important after place-and-route wasn't something specifically considered in the designer's RTL or simulation. The designer is left trying to figure out why the simulation of the RTL works and the FPGA doesn't.

The traditional FPGA flow doesn't provide the necessary visibility into the silicon, which makes understanding choices that the place-and-route tool made nearly impossible. The typical approach is to set probes in the logic analyzer and try to narrow in on the problem. This is a tedious process, as resetting the probes each times takes hours. Even if the designer thinks the problem has been discovered, testing the theory means another cycle through synthesis and place and route.

Quickly, debug has become the major bottleneck and time consumer in the development process.

With GateRocket, we turn a spotlight on these types of debug issues, enabling designers to streamline the way they can manage the nuances and intricacies of an advanced FPGA design flow. Our solution allows designers to move effortlessly between RTL and the actual FPGA being targeted. The FPGA is actually in the simulator, through our RocketDrive solution, which lets designers jump back and forth between RTL and the FPGA to quickly pinpoint the problem, add the appropriate directive, and be done.

With this approach, there's no guesswork and finding differences between RTL and the FPGA implementation created by place-and-route becomes simple. It also eliminates long loops through synthesis and routing each time the designer wants to examine and debug different parts of the design.

Complex FPGA design is not as straightforward as you might think, so why not give yourself every advantage possible to make life easier?