specs-feup / lara-framework

Tools and APIs to develop weavers for the LARA language (LARA Compiler, LARA Interpreter, Weaver Generator, etc...)
Apache License 2.0
13 stars 2 forks source link

Adds Vitis HLS integration #26

Closed tiagolascasas closed 2 years ago

tiagolascasas commented 2 years ago

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 package lara.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:

laraImport("lara.vitishls.VitisHls");

var vitis = new VitisHls();

// Compulsory parameters: top function, platform part number and target clock
vitis.setTopFunction("maddv");
vitis.setPlatform("xcvu5p-flva2104-1-e");
vitis.setClock(10);

// Optional. If not specified, it assumes current AST is the source
// Multiple source files can be specified, one at a time
vitis.addSource("example.c");

// Takes an optional boolean as an arg to specify whether to show the
// verbose realtime output of Vitis HLS onscreen (default is true)
var success = vitis.synthesize();

if (success) {
    // XML synthesis report is converted into a cleaned-up JSON
    var report = vitis.getSynthesisReport();
    vitis.prettyPrintReport(report);
}

Expected output:

--- AST parsing report ---
[VITIS-HLS] Setting up Vitis HLS executor
Changes in file 'C:\Users\Tiago\clavaWorkspace\woven_code\example.c'
[VITIS-HLS] Executing Vitis HLS
    (omitted Vitis HLS output for brevity)
[VITIS-HLS] Finished executing Vitis HLS
[VITIS-HLS] Processing synthesis report
[VITIS-HLS] Finished processing synthesis report
----------------------------------------
Vitis HLS synthesis report

Targeted a xcvu5p-flva2104-1-e, with target clock 10.00ns

Achieved an estimated clock of 7.30ns (136.99MHz)

Latency of 587 cycles for top function maddv
Estimated execution time of 0.000004285100000000001s

Resource usage:
FF:   5686 (0.47%)
LUT:  4880 (0.81%)
BRAM: 0 (0.00%)
DSP:  0 (0.00%)
----------------------------------------

The input C file for the above example and the test code with CHStone is available here: input.zip

joaobispo commented 2 years ago

If top function, platform part number and target clock are compulsory parameters, shouldn't they be arguments of the VitisHls() constructor?

tiagolascasas commented 2 years ago

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.

joaobispo commented 2 years ago

There was one detail that was missing, which was to register the new files here: LaraApiResource.java