Learning about and working with FPGAs, many times I've wondered if there is a common pool of design knowledge and best practices that I can refer to, especially when facing a particular tough critical path or fitting a design that's just about over the device's limit.
More experienced colleagues, documentation and forums (not in any order of preference!) have been extremely helpful, and something I found was that cu rrent FPGA tools are more powerful than previously thought, it's just that most engineers don't have the time to explore some features and see how the y help designs over many builds.
So our small team of FPGA and software developers started looking at FPGA t iming closure and place-n-route problems from a statistical angle. After ex perimenting with current synthesis and place-n-route tools, we found that a lot more mileage can be gotten out of them.
- there are fixed trends in how synthesis and place-and-route affect timing results
- understanding these patterns, it is possible to coax results in certain directions
- these patterns are influenced by the design, device family and tools
We'd like to ask the community for help to test these ideas.
Unlike random seed sweeps, our compilation builds use probability to guide FPGA designs towards desired results. The algorithm learns from past builds and improves itself based on device, design and tool characteristics. The "lessons learned" are then saved for future reference in the form of metada ta (characteristics, not the logic, not the application).
To try this out, we've built a software plugin for some FPGA tools, and are making an API so that every FPGA designer can tap this database of "best p ractices" and apply his/her own algorithm to solve problems.
If you have a hard, annoying timing/area/power problem, please consider sha ring the design with us so that this pool of shared knowledge can grow.
In return, we'll do our best to improve your design's performance and solve its problems (think of it as $0 consulting). If you like, we'll gladly giv e you a license once the tool is ready and be your friend for life!
To share a design, simply:1) zip up your project files; 2) add them into the upload box at
or just send me a personal message with a URL to the files
After testing many, many designs from github, opencores, etc. we learned so me requirements that make a design more "real".
- above 50% utilization;
- has a real application (logic wasn't randomly generated to fill the FPGA) ;
- can compile successfully
Please let me know what you think.
Would you upload your company's latest and greatest FPGA design? I wouldn't. And we're certainly not asking you to do that. But if you have an older design, something that you don't mind sharing, please consider. We will gladly sign an NDA to facilitate things. If you think this is a really bad idea or have heard too many bad stories a bout sharing design data, then don't do it. But if you are open to honest, good ol' fashioned engineering collaboration for the sake of solving your FPGA problems, we look forward to hearing fro m you!