@Betajet: I did notice the ARM AXI interface was mentioned. That implies an ARM and that implies ZYNQ and that implies high cost -- just as you said.
Vivado/HLS only supports 7 series and whatever they call the latest devices. The methodology is modular IP based.
1) design or acquire IP as a module that can be connected by the fabric. The IP is a complete design with timing closure. If all ports are registered, the timing that matters is the port connections. Like adding a chip to a PCB, but on chip.
2) write the algorithms in C and HLS automates the DSP/accellerator design. Do the rest of the design as before, but create a "pluggable" HDL module. Let us wait and see if the "HLS" does anything more than DSP and IP module interconnect using AXI.
I wonder if the purpose of HLS is to ensure you can't get timing closure with slower, cheap devices like Spartan and instead have to use faster, expensive chip families. Ditto for efficient use of logic cells.
it was all about fitting your design into the FPGA and getting timing closure by trying random changes because you really couldn't understand what was going on at the netlist level...
Now it's all about designing at the highest level possible and as quickly as possible. Are we going to go back to the days when to achieve timing closure 'up front' we are going to be making random changes because we don't know what's going on at the high-level? I hope not...
HLS tools are already there for several years. But the issue is the quality of RTL generated is not as efficient as hand written one in general, though I have not used Vivaldo HLS and can not comment on its quality.
I feel HLS tool can not be generic in nature (like synthesis tool). The style of efficient RTL writing depends heavily on the application and HLS tool needs to be customized for application. For example a RTL code doing video processing needs to run at significantly high frequency and hence the the output generated by HLS tool should be such that it does not create a long combinational logic between two flops. Also video data on which the processing is done stays in off-chip memory. Hence the RTL code should be such that it fetches significant chunk of data at a time as otherwise the processor memory transaction will delay the processing
@Barun - Xilinx acquired startup AutoESL (out of UCLA) a couple of years ago and now sells it as an add-on, Vivado HLS. An ESL approach complements what Tom Feist presents for impementation and at Space Codesign, our SpaceStudio design software serves as an ESL design creation front-end (with true hardware/software co-design) to Xilinx's Vivado, able to go down to silicon with their HLS tool. For implementation, you may be reusing IP out of libraries or from a third party, which the ESL modules could be mapped to, and Tom's presented methodology (which we follow) would be really helpful there along with results from running HLS.
Efficient high level synthesis tool is the need of hour to make programmable logic (particularly FPGA) really useful to the user community. In a good amount of situations programmable logic is used by system engineers who are more comfortable with C/ C++ languages than RTL. High level synthesis will be really helpful for them. Off course there are few high level synthesis tools are available in market. But the efficiency of output RTL code is far from quality compared to the hand written RTL code. In terms of efficiency the output RTL code should be at least 80% in terms of area, power or frequency efficinecy compared to hand written RTL code
Replay available now: A handful of emerging network technologies are competing to be the preferred wide-area connection for the Internet of Things. All claim lower costs and power use than cellular but none have wide deployment yet. Listen in as proponents of leading contenders make their case to be the metro or national IoT network of the future. Rick Merritt, EE Times Silicon Valley Bureau Chief, moderators this discussion. Join in and ask his guests questions.