feature article
Subscribe Now

GateRocket Blasts Off

FPGAs Verifying FPGAs

The system is both elegant and enigmatic.

When visitors see the RocketDrive sitting on your lab bench (particularly if it is plugged into the handsome show-floor-worthy box currently making the rounds at trade shows), your “cool factor” will definitely creep up a notch or two. When you use it to help you knock bugs out of your next FPGA design, you’ll most likely be pleased with your purchase. GateRocket’s RocketDrive is a useful tool for FPGA designers.

You have to be careful, though, not to think about it too hard.

You see, if you’ve been doing FPGA design for awhile, you probably have first-hand experience with the history of FPGA de-bugging and “verification” methodologies.  If you’ve been reading here for awhile, you also probably know why “verification” is in quotes.  In our world, verification is a process for vetting your design before it goes over the wall to manufacturing and tooling.  The very idea of verification is to make sure that everything is great and straight before crossing the one-way barrier from the domain of flexible, iterative design to the world of irreversible investment in expensive masks and physical inventory.  In “measure twice, cut once,” verification is the second “measure” – giving us peace of mind that all is well before we commit our concept to materials.

The whole point of FPGA design is that it doesn’t work that way.  FPGAs give us Mulligans for Life. We can change our hardware design anytime from the initial concept phase all the way through to working systems in the field.  Unlike ASIC and even board design, there is (theoretically) never a point where a well-used FPGA must have its bitstream set in stone.  

It would be nice, however, to know that our design works correctly before we ship it to customers – particularly in safety-critical applications, but also in employment-critical situations like the one that could occur when your boss figures out that your design error is the one that has the support switchboards lighting up like New York City at dusk.  So, regardless of our sloppy use of the term “verification,” we need the ability to make sure our design (or our design revision) works as expected before it leaves our sphere of influence.

In the early days of FPGA, we simply spun the design using our development board.  We made a change to our schematic, hit the place-and-route button (then fixed a couple of stupid mistakes, rebooted our laptop, hit the place-and-route button again), zipped up the bitstream and pushed it down to the development board (then sat looking confused for awhile, plugged in the development board, pushed the bitstream again, cursed, rebooted our laptop, pushed the bitstream again…), and found out that our design did not work in hardware.  15 minutes later, we actually connected the output signal to the output buffer, re-ran the process above (sans cursing) and found out that our design showed signs of life, but still did not work in hardware.  23 iterations of this process later – at the end of the second day — things seemed pretty good with our FPGA design, and we were ready to move on to the next step in our project.

FPGAs got bigger and more complicated, however, and we moved on to HDL-based design.  Now, we had to add synthesis to our process, and place-and-route times scooted upward despite the steady march of increased computing power.  Design iterations went from minutes to hours.  Our two-day debug scenario crept toward two weeks.  It began to be less obvious what was wrong when we powered up our development board and got stone-cold darkness.  We needed visibility. We needed insight.  We needed (sigh) to simulate.

EDA vendors were happy to oblige.  Millions of our design budget dollars were directed toward the ModelSims and Aldecs of the world, and thousands of simulation licenses landed on our laptops. EDA marketing rhetoric spread like wildfire.  If we failed to abandon our old “burn-and-pray” method of catching FPGA bugs in hardware and refused to embrace the new age of software-based simulation splendor, we were labeled “logic-design luddites” and forced to drink our break-room coffee from the “old-timer’s” drip machine instead of the new robotic barista that whipped out double-skinny mochaccinos for all the hip engineers.   Debugging in actual FPGA hardware was lame.  Simulation was suave and sophisticated.  We tasted the Kool-Aid. We added more sugar. We tasted it again.  HDL simulation for FPGAs was sweet.

FPGAs trundled on, however, growing bigger and bigger.  Designs became so complicated that HDL simulation actually became more true necessity than PowerPoint panache.  Drop 100K LUTs worth of unproven logic into a development board and hit the reset button.  The chances that anything good will happen are near zero.  The chances that you can then guess what’s wrong – even smaller.  The visibility of HDL simulation was our best hope for getting the design right before we kicked off the overnight run of synthesis, place-and-route, timing optimization, more synthesis, more place-and-route, and finally blasting a candidate bitstream down to our board for the next real-hardware iteration.

We began to rely more on simulation, and our methods became more sophisticated.  For complex designs, we needed a robust testbench to put our designs through their paces. Our de-bugging methods started to bear a strong resemblance to ASIC verification processes.  We’d alter our HDL code, load it into the simulation environment, and run off for coffee (the good kind) while our computing clusters cranked through bazillions of simulated clock-cycles looking for flaws.  More iteration now went from HDL editor to simulator and back instead of looping through synthesis, place and route, and prototype programming.  Our transition from hardware de-bug to software-based virtuality was virtually complete.  

Until something else went wrong.

Today, the high-end FPGAs are so large that software simulation is becoming unwieldy.  Running a reasonable vector set through a repeatable testbench takes a long time even with significant computing power.  We’re back in the trap of long-loop iteration again…

GateRocket comes in with a back-to-the-future solution:  “Why don’t we accelerate our HDL simulation of large FPGA designs with FPGA-based hardware accelerators?”

Wait just a second here.  We’re using an FPGA to accelerate the software simulation of – itself?

Strange as it sounds, the solution makes a lot of sense.  We are not just falling back to the days of burn-and-pray.  The difference here is that the FPGA hardware (yes, RocketDrive does walk, quack, and smell a lot like a development board) is essentially under the control of your software simulation environment.  The testbench that you use for HDL simulation seamlessly passes to the FPGA in your RocketDrive, and you get the best of both worlds – hardware execution speed with software visibility, control, and iteration times.  GateRocket says the RocketDrive “plugs into a standard disk drive slot in your PC and is available in several configurations, each containing the largest FPGA in its respective device family from Xilinx or Altera.”

Despite our skepticism, RocketDrive is not just an overpriced development board.  The tight integration with your HDL simulation environment has significant utility if you depend on a structured, organized methodology for FPGA design verification.  You could probably accomplish something similar with a bunch of custom coding, an FPGA development board, and the services of embedded-hardware logic analyzers like Xilinx’s ChipScope or Altera’s SignalTap.  Of course, then you’d be developing GateRocket’s product again from scratch.  Really, what’s the point of that?  Just buy it.

Leave a Reply

featured blogs
Oct 27, 2020
As we continue this blog series, we'€™re going to keep looking at System Design and Verification Online Training courses. In Part 1 , we went over Verilog language and application, Xcelium simulator,... [[ Click on the title to access the full blog on the Cadence Community...
Oct 27, 2020
Back in January 2020, we rolled out a new experience for component data for our discrete wire products. This update has been very well received. In that blog post, we promised some version 2 updates that would better organize the new data. With this post, we’re happy to...
Oct 26, 2020
Do you have a gadget or gizmo that uses sensors in an ingenious or frivolous way? If so, claim your 15 minutes of fame at the virtual Sensors Innovation Fall Week event....
Oct 23, 2020
[From the last episode: We noted that some inventions, like in-memory compute, aren'€™t intuitive, being driven instead by the math.] We have one more addition to add to our in-memory compute system. Remember that, when we use a regular memory, what goes in is an address '...

featured video

Demo: Low-Power Machine Learning Inference with DesignWare ARC EM9D Processor IP

Sponsored by Synopsys

Applications that require sensing on a continuous basis are always on and often battery operated. In this video, the low-power ARC EM9D Processors run a handwriting character recognition neural network graph to infer the letter that is written.

Click here for more information about DesignWare ARC EM9D / EM11D Processors

featured paper

An engineer’s guide to autonomous and collaborative industrial robots

Sponsored by Texas Instruments

As robots are becoming more commonplace in factories, it is important that they become more intelligent, autonomous, safer and efficient. All of this is enabled with precise motor control, advanced sensing technologies and processing at the edge, all with robust real-time communication. In our e-book, an engineer’s guide to industrial robots, we take an in-depth look at the key technologies used in various robotic applications.

Click here to download the e-book

Featured Chalk Talk

ROHM BD71847AMWV PMIC for the NXP i.MM 8M Mini

Sponsored by Mouser Electronics and ROHM Semiconductor

Designing-in a power supply for today’s remarkable applications processors can be a hurdle for many embedded design teams. Creating a solutions that’s small, efficient, and inexpensive demands considerable engineering time and expertise. In this episode of Chalk Talk, Amelia Dalton chats with Kristopher Bahar of ROHM about some new power management ICs that are small, efficient, and inexpensive.

Click here for more information about ROHM Semiconductor BD71847AMWV Programmable Power Management IC