Closed tiagolascasas closed 2 years ago
If top function, platform part number and target clock are compulsory parameters, shouldn't they be arguments of the VitisHls() constructor?
Yes, that would make sense.
Though I think some of these could have default values, rather than being compulsory: for instance, Vitis HLS assumes a target period of 10ns when nothing is specified, and I think we should preserve that behaviour.
Vitis HLS also assumes a platform by default (the same as in the example code), which I guess is available in every installation.
The top function is really the only one that must absolutely be specified.
Regardless of these default values, I agree that we should allow their initialization in the constructor(s), depending on the default values we want to assume.
There was one detail that was missing, which was to register the new files here: LaraApiResource.java
Implementation of what was described in issue #24
How it was implemented
Some generic functionality was extracted from the CMake extension, and placed in a generic
Tool
class, which CMake extends.The new Vitis HLS extension also extends
Tool
, and is implemented in packagelara.vitishls
. It requires Vitis HLS to be in the path.Having a generic
Tool
class, while a bit barren at the moment, will allow us to create further extensions in the future without having to reimplement common functionality amongst those tools (e.g., file management, clean-up, etc).The integration was validated by using it to synthesize functions from the built-in CHStone benchmark suite.
Usage example
JS test code:
Expected output:
The input C file for the above example and the test code with CHStone is available here: input.zip