Closed Oxygen-Chu closed 2 years ago
Hi Oxygen,
Thanks for your suggestions about the tool!
AutoBridge is inherently a hack to the commercial HLS tool so it is sensitive to versions as expected. As you noticed, it is impossible to keep up with the updating of HLS ---- every version changes a little bit of something and breaks the flow.
Instead, what we are doing is to fully integrate with the TAPA compiler also from our lab. Basically, TAPA serves as a middle layer between AutoBridge and HLS. We will generate all the glue RTL to compose the modules together, instead of relying on HLS.
This approach has been stable and robust in our internal usage of AutoBridge. But much more work is still needed to make it clean enough to be used by others. We are actively working on it. We will keep the ./src as it is, and all the updates go to the ./in-develop directory.
We are sorry about the inconvenience currently.
Best, Licheng
Xilinx 2020 是 HLS 的分界线,在之前叫做 Vivado HLS,之后叫做 Vitis HLS。不仅仅是名字的改变,更是 Xilinx 整个设计方法学和商业策略的改变。Vitis 之前是以 FPGA 为中心,之后是以 CPU 为中心。所以我相信 HLS 已经彻底从 Vivado HLS 转向了 Vitis HLS 版本,而且将会持续10年以上不会改变。那也就意味着 Vitis HLS #pragma 至少 10 年都仅仅是扩充,而不是改变。 所以,我个人的判断是针对 Vitis HLS 2021.2 做出改变,是一项值得投资的计划。因为它会长期保持和繁荣,而不会改变。 同时,也期望 AutoBridge 能够更多的利用 LLVM 13,GCC 11 等新版本的特性,并且能够适应新的操作系统,比如 Ubuntu 21 或者 RHEL 8,当然如果 Clear Linux 也能够支持,那就更好了。(我倒是愿意做小白鼠来做 AutoBridge 的测试,因为我有很多 HLS 的案例) 期盼 AutoBridge for Vitis HLS
Hi Oxygen,
Thanks for your reply. I appreciate it if we can communicate in English so that more people could understand the dialogue.
First, AutoBridge is purely Python-based, and it does not have any dependence on LLVM or GCC.
Second, I don't see much difference between Vivado/Vitis HLS. The most exciting changes since Vitis HLS 2020.2 are (1) the partially open-source front end (2) the support of free-running pipelines to reduce control broadcast. (DAC '20 ) Otherwise, they are essentially the same thing to me. Maybe more front-end passes to improve QoR.
Can you share what is changed regarding "design methodology" and "commercial strategy"?
BTW, by "difference in each version" in my last post, I mean "trivial" things like changes of file names, changes of the generated RTL pattern, etc, which will break the flow because we are post-processing the HLS-generated RTL. Unfortunately, such updates happen all the time. Therefore, the roadmap ahead is to combine AutoBridge and TAPA for a robust and stable flow.
-Licheng
OK, I’ll try to use international language.
:- )
From: @. @.> On Behalf Of Licheng Guo Sent: Thursday, December 2, 2021 12:33 PM To: Licheng-Guo/AutoBridge @.> Cc: Oxygen-Chu @.>; Author @.***> Subject: Re: [Licheng-Guo/AutoBridge] Issue with Vitis HLS 2021.2 (Issue #14)
Hi Oxygen,
Thanks for your reply. I appreciate it if we can communicate in English so that more people could understand the dialogue.
First, AutoBridge is purely Python-based, and it does not have any dependence on LLVM or GCC.
Second, I don't see much difference between Vivado/Vitis HLS. The most exciting changes since Vitis HLS 2020.2 are (1) the partially open-source front end (2) the support of free-running pipelines to reduce control broadcast. (DAC '20 https://vast.cs.ucla.edu/sites/default/files/publications/dac20-hls-timing.pdf ) Otherwise, they are essentially the same thing to me. Maybe some change in pragma names.
Can you share what is changed regarding "design methodology" and "commercial strategy"?
BTW, by "difference in each version" in my last post, I mean "trivial" things like changes of file names, changes of the generated RTL pattern, etc, which will break the flow because we are post-processing the HLS-generated RTL. Unfortunately, such updates happen all the time. Therefore, the roadmap ahead is to combine AutoBridge and TAPA for a robust and stable flow.
-Licheng
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Licheng-Guo/AutoBridge/issues/14#issuecomment-984284252 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AFL2FSVENYXWN6VVUALIUHTUO3ZJBANCNFSM5JDY2BAQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . https://github.com/notifications/beacon/AFL2FSQNK5D5YBJGL55DLVLUO3ZJBA5CNFSM5JDY2BA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHKVPYXA.gif
Ok, let me have some comprehensive explanation. As I say, Xilinx has change the way how they "see" FPGA device. Previously, FPGA is a standalone device/chip and maybe have PicoBlaze/MicroBlaze/PowerPC as assistant processing unit. And Xilinx is targeting traditional market like wireless and A&D. With the innovation of ZYNQ and ZYNQ MPSoC/RFSoC, and the new computation demand, like edge-computing, DC and AI, FPGA has more-and-more become a hardware accelerator for ARM-based system design. The era after ZYNQ, I think Xilinx has turned its way to CPU-centric system-level design with FPGA and AIE as a peripheral (accelerating kernel). And this is the fundamental strategic difference between Vivado HLS & Vitis HLS. If you have checked the document "Migration from Vivado HLS to Vitis HLS", you'll find it true. And Vitis HLS has a new feature : Vitis Kernel Flow Target Let me come back to the AutoBridge. The current version seems have something wrong with Vitis HLS 2021.2. I have checked the AutoBridge example, and its targeting Vivado HLS. I change some tcl script to run Vitis HLS 2021.2, and step1 successes. But step2 still failed. And AutoBridge configuration processing seems heavily dependent upon old GCC/LLVM, and newer version like GCC11/LLVM13 cannot be used. It will error out during make/install progress.
完全按照作者的环境编译,是可以的,但是无法升级。我提出几点,仅供参考: