Guest
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 current 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 they help designs over many builds.
So our small team of FPGA and software developers started looking at FPGA timing closure and place-n-route problems from a statistical angle. After experimenting with current synthesis and place-n-route tools, we found that a lot more mileage can be gotten out of them.
For example,
- 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 metadata (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 practices" and apply his/her own algorithm to solve problems.
If you have a hard, annoying timing/area/power problem, please consider sharing 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 give 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 http://www.plunify.com/callfordesign/cfd..php
3) tell us what tool version it needs;
4) (if you like) tell us who you are so we can share the results and tool when they're ready.
or just send me a personal message with a URL to the files
After testing many, many designs from github, opencores, etc. we learned some requirements that make a design more "real".
They are:
- 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 about 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 from you!
Sincerely,
Harnhua
More experienced colleagues, documentation and forums (not in any order of preference!) have been extremely helpful, and something I found was that current 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 they help designs over many builds.
So our small team of FPGA and software developers started looking at FPGA timing closure and place-n-route problems from a statistical angle. After experimenting with current synthesis and place-n-route tools, we found that a lot more mileage can be gotten out of them.
For example,
- 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 metadata (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 practices" and apply his/her own algorithm to solve problems.
If you have a hard, annoying timing/area/power problem, please consider sharing 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 give 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 http://www.plunify.com/callfordesign/cfd..php
3) tell us what tool version it needs;
4) (if you like) tell us who you are so we can share the results and tool when they're ready.
or just send me a personal message with a URL to the files
After testing many, many designs from github, opencores, etc. we learned some requirements that make a design more "real".
They are:
- 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 about 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 from you!
Sincerely,
Harnhua