Hacker News new | past | comments | ask | show | jobs | submit login

HLS lets the compiler optimize your layouts for you more, since you're expressing your algorithm's goals at a much higher level (and have left more actual implementation details unspecified). I've implemented the same algorithm in both HLS and Verilog and with a few pragmas the HLS code, the result was infinitely more tweakable on the space/speed gradient - I was pretty much able to utilize the maximal space I could to achieve maximal execution speed - and limited to the same area I had used for the verilog implementation, it had almost identical performance.

It's also incredibly time saving in that with HLS you can actually rapidly unit test your designs (outside of a simulator), and you can usually get a codegen for bindings for the SoC you're designing for so you don't have to write any headers/interface code for the onboard processor yourself.

IMO, people who don't think HLS is a win either have years of experience invested in older toolchains and are more productive with them (and don't see HLS as worth their time), or haven't actually tried it.

I've mostly used a slightly hamstrung C++ as a HLS language with a Xilinx SoC. C++ is infinitely nicer than an HDL, but I can't help but feel that Rust's safety model more closely matches how an HLS wants to structure its invariants, so I feel like it could be an excellent HLS language in the future, given the chance.




Having worked with a few variations that promised gold and delivered very little, allow me disagree.

For complex designs I always came back crawling to vhdl and systemverilog.

(Jury is still out on Chisel, but it doesn't look good right now. Looks more like it was designed by CS folks who just didn't get modern hardware design)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: