From online payments and electronic banking transactions to organizing company documents and mission-critical supply chain management systems, cloud computing now plays an ever-present role in both consumer and enterprise applications. In general, cloud computing's "pay-as-you-go" elasticity – requiring little upfront investment – tends to be its main value proposition to IT departments, although security and service disruptions are potential risks that come to mind.
But what does cloud computing mean for the FPGA design engineer? How can seemingly unlimited server resources help engineers in our daily work? This article examines the benefits and potential pitfalls of cloud computing in FPGA design from a practical, day-to-day viewpoint.
A typical workflow for an FPGA designer working on a design looks like this:
- Design Entry
- Place-and-Route (P&R)
- Timing analysis, design rule checks
- Testing in hardware
Note that I am purposely omitting steps such as software development and debugging, system integration of separately-implemented blocks, etc. in order to reserve rich fodder for future discussions.
Out of the steps above, Synthesis and P&R are steps that I consider to be the most...
- Iterative: After each synthesis and P&R build, results are analyzed, design changes are made, and run again.
- Compute resource-intensive (in terms of CPU cores and memory): Depending on the design, the FPGA software tools can compile faster or slower with multiple cores and more memory, but in general, having more RAM seems more important than having more cores.
- Time-consuming: A heavily-utilized design with aggressive constraints can easily take a few hours or even a day to route successfully.
Talking with other designers, the above observations seem true whether or not their FPGA designs are used for ASIC prototyping efforts or are shipped with the final product.
From an IT resource point of view, the immediate benefits of cloud computing are clear. If FPGA software tools are available on a cloud-like infrastructure along with a sufficiently large pool of tool licenses, I (or any designer for that matter) can fire off synthesis and P&R tasks in parallel almost at will. There will be few concerns about insufficient servers or licenses to run those builds, or if the builds are hogging company servers and preventing colleagues from running their tasks. Typically, things start to get hairy during integration time or near deadlines. During peak periods when everyone is trying to tape-out or close timing, the ability of a cloud to handle the peaks and troughs of compute resource demand makes much sense. Correspondingly, with a cloud-like resource to call upon, a CAD/IT department will probably have less trouble forecasting server requirements and planning budgets for upcoming quarters. Concerns about IT over-investment and under-investment are alleviated.
However, getting more compilation resources and reaping IT benefits is arguably just the tip of the iceberg. How can cloud computing really help an FPGA engineer complete a design in less time than before?
"So what if I can run a hundred different synthesis and place-and-route builds at the same time? There has to be smart way to quickly analyze the results of those hundred iterations, so I can compare their differences and get an idea of what steps to take next. Is this going to require changes to my RTL? Can a constraint change potentially eliminate timing errors?"
These are questions that can be addressed by carefully tweaking and re-running the design. The question is, can running more builds in the same amount of time result in better answers?
From a workflow and design methodology perspective, it makes sense that, given the ability to run multiple builds at the same time, suddenly a lot more data could be obtained for comparison and analysis. This data, mostly in the form of timing and utilization reports, can be examined in bulk to decide the next steps. When a design fails to meet timing, instead of re-running one or two builds with different tweaks and subsequently poring over the reports, now timing results can be analyzed from a lot more builds done in parallel.
The illustration below shows timing slack values (Y-axis) plotted against 30 different synthesis and P&R builds (X-axis) for an actual design that I ran using a compute cloud (Click Here
to see a larger, more detailed version of this image):
Initially, this design did not meet timing. Reading the compilation reports for the initial build, I got some insight into the critical paths, the congested regions, and the modules where the placer seemed to be spending the most time. Then I started to come up with a list of changes that I think might help close timing. Due to the fact that cloud resources were available, my space for exploring possible solutions in a shorter amount of time became greater than before. I was able to tweak design constraints and tool settings (synthesis, P&R) to come up with 30 different builds, and then run them in parallel. Plotting the results, I quickly found out which builds came closer to meeting timing – and which strayed further off the path. Somewhat akin to a search process, from the figure above I was able to narrow my search space to builds, "qse_18" and "qse_19."
Out of the 30 builds, "qse_18" and "qse_19" produced setup and hold times that were closest to meeting timing (smallest negative slack values). I then analyzed these in greater detail to decide which changes in the constraints and the RTL were necessary. While considering the next round of changes, I was also able to compare results from the original set of 30 builds to get a sense of which seemed detrimental to the overall timing.
Overall, instead of spending a few days or weeks running tens of builds, one after the other, I was able to analyze more possibilities and make the next design decision in a matter of hours. This approach suggests a design methodology change – no longer is a design engineer restricted to running one, two, or three builds at a time, waiting for a narrow range of results before deciding next steps. With a planned cloud-based approach, design teams can explore 10, 20, and even hundreds of builds in advance, run them in parallel and have a lot more data on hand to make the required analysis and subsequent changes. Questions about what modifications can be made to get to design closure can potentially be made in days rather than in months. In addition, there is more room to explore optimizations like:
- Will performance improve if we try this?
- Can power consumption be further reduced if we do that?
However, this sudden freedom to run multiple builds in parallel should be considered a productivity aid rather than a substitute for good engineering practices. For example, while it may be tempting to simply "brute-force" all possible variations of constraints or tool options once there is a timing problem, too much resulting data can complicate analysis and even mislead the designer (not to mention, shock your project manager with a huge cloud usage bill). Without first spending time to debug a design, an engineer will find it very hard to progress in knowledge and experience.
Inevitably, as users of cloud computing, we will probably all arrive at the security question. A senior colleague remarked that there seems to be a disconnect between the use of cloud computing in the consumer space versus that in an industrial setting, in the sense that when a designer or project manager imagines confidential IP leaking out from a company, he or she might actually be thinking about something like online credit card scams. Personally, I think uploading design files to our semiconductor foundries is similar – we trust the recipient and we transmit only what is necessary. In the case of FPGA design, I might start using the cloud by sending netlists and not RTL, or by uploading older designs that are less important. Or perhaps use a company's internal cloud – although that presents the problems of limited scale and elasticity again.
In summary, besides increasing application in the consumer and enterprise space, a cloud-based approach can help an FPGA design engineer in certain tasks like synthesis and P&R. Beyond speeding up individual parts of the design process, such an approach can greatly accelerate the overall FPGA design workflow by abstracting multiple, parallel builds as a group of builds to examine. As a result, the potential shortening of the design cycle and, consequently, the product's time-to-market, is a benefit that arguably far exceeds that of potential IT savings. From the project manager's point of view, imagine what a headstart of even one or two weeks can do for one's product.
However, as they say, with great power comes great responsibility. Cloud computing in FPGA design may represent more of a methodology change than a quick IT fix. Analysis tools, engineering practices and even business models must evolve accordingly in order to manage this methodology and take full advantage of its potential benefits. Done properly, this is an application of existing technology that can greatly speed up a design engineer's daily work.About the author
Harnhua Ng is one of the founders of Plunify (www.plunify.com
), which provides customization, automation, and management capabilities on a secure, scalable, on-demand cloud computing platform preloaded with chip design software tools.
You can contact Harnhua at Harnhua@plunify.com
If you found this article to be of interest, visit Programmable Logic Designline
where – in addition to my Max's Cool Beans
blogs – you will find the latest and greatest design, technology, product, and news articles with regard to programmable logic devices of every flavor and size (FPGAs, CPLDs, CSSPs, PSoCs...).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for my weekly newsletter – just Click Here
to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).