Pushing on AXI-connected IP in FPGAs |
 |
Don Dingee Published on 11-03-2015 11:00 AM
Success stories are great. Reading how someone uses a product contributes much more insight than reading about a product. Last month we had a teaser for a presentation by Wave Semiconductor; this month, we have the slides showing how they are using FPGA-based prototyping, AXI transactions, and DPI to speed up development.
First, a mea culpa. I got the press release last month and the term DPI dangled ambiguously. My frame of reference is “deep packet inspection”, and when I inquired via email if that was the intent, the answer was yes. It seemed like a plausible response.
Wave is developing a programmable data flow computing accelerator with IP forming massively parallel reconfigurable processor arrays and a fabric interconnect. In their own words, they are “moving algorithms to the data”, a key tenet of big data analytics. From the press release just issued (link below), we see they have rebranded their architecture as Byte-Fabric. An older diagram on their website portrays the concept; this may not be the most recent version:
So, I get the slides from Wave this month, and sure enough DPI is all over them as promised. What they are really talking about is the SystemVerilog Direct Programming Interface, allowing C calls from SystemVerilog. Blogger fail. Now that we have the story straight, let’s connect the dots on this success and what it means for ASIC developers.
Wave is pushing on AXI as the strategy for IP interconnect in FPGAs for several reasons, primarily to aid in integration. Xilinx is heavily promoting the use of AXI-connected IP in FPGAs, which is a great thing to reduce partitioning differences between FPGA-based prototypes and the final ASIC. An abstracted AXI backbone helps with DMA, quality of service, out-of-order transactions, and other system-level performance characteristics.
The key to this particular success story is less obvious. By using the AXI interconnect, the FPGA-based prototyping platform from S2C can dynamically load, unload, and debug software through AXI on the FPGAs using a host PC. By applying a C language API, the same code from the verification environment can be reused in production.
Put another way, production C code can be used to verify the FPGA-based prototype. Usually testbenches are developed in SystemVerilog or maybe SystemC. In this project, Wave has used S2C’s Prodigy ProtoBridge with a driver that connects to a Xilinx PCIe IP block in the Prodigy Logic Module. This gives the PC user-level access to the AXI master, simplifying read/write to the entire FPGA using C/C++ calls. Then, a DPI-based AXI Master Transactor spans between the SystemVerilog testbench and C code.
In Wave’s environment, algorithms for big data analytics are developed in C, so running actual C code is essential to thorough verification testing. By preserving the ability to run the SystemVerilog testbench and use more conventional simulation tools, yet run production C code, Wave has combined the best of both worlds on an S2C platform.
If that type of hybrid scheme combining host-based simulation with an FPGA-based prototyping platform sounds vaguely familiar, it may be because it is. This idea bears a lot of resemblance to SCE-MI – a working group within Accellera that Toshio Nakama of S2C once chaired. The difference in this approach is the AXI connection and the heavy use of AXI-based IP in an FPGA, with a simpler API scheme that does the basics.
I’ll be curious to see what the final Wave Byte-Fabric product looks like. You can read more about what Wave has done with the S2C platform, AXI, and DPI in their development:
Wave Semiconductor Achieves Rapid Design Success Using S2C FPGA Prototyping Solutions
Case Study: AXI HW/SW Verification for FPGA (registration and PDF download)
When Wave says this approach simplified their debug environment and reduced development time, keep in mind the end product – the Byte-Fabric SoC and supporting software – is designed around AXI for performance. Tapping directly into AXI removes several interim steps in verification, particularly in creating a testbench reusing production C code on an FPGA-based prototyping platform.
This site uses cookies to collect information about your browsing activities in order to provide you with more relevant content and promotional materials, and help us understand your interests and enhance the site. By continuing to browse this site you agree to the use of cookies. Visit our cookie policy to learn more.
-383.png)
