Tip:
Highlight text to annotate it
X
Hello! In this video we are going to talk about a novel approach based on Aspect-Oriented Programming
which aims to make reconfigurable technologies, such as FPGAs, more accessible to users
while allowing this technology to be fully exploited.
One of the most innovative features about our approach is that we use aspects not only to guide and control all stages of the design flow
but also to capture and reuse best practices and user-knowledge.
Here we show the LARA design-flow.
The main inputs of the design-flow are the application sources and a set of aspect descriptions which control the tools.
The LARA sources are converted to an intermediate representation called aspect-IR.
The design-flow has a set of weavers which are executed in a sequence, receiving the source and the aspect-IR as inputs
and passing the woven versions along to the next weaver.
In addition, information produced by profilers and runtime reports can be fed back to the design-space exploration tool
to refine the strategy and run the design-flow until a particular goal is met.
The LARA aspect language, which we designed in this project, can capture a number of schemes
that can be a part of a strategy to achieve a particular non-functional requirement
such as performance, safety, fault-tolerance and energy efficiency.
All these schemes, such as code transforms and mapping, are achieved using LARA’s single weaving meachanism.
So here is what a LARA strategy looks like.
On the top left hand side we have an aspect definition that invokes low-level aspects.
These low-level aspects shown on the right perform a sequence of compiler transformations
which are known to accelerate kernels mapped to FPGAs.
This aspect causes the insertion of a call to a profiling function.
After each assign to variables inside the “gridIterate” function named “acc” or whose name starts with “left” or “right”.
After each assign to variables inside the “gridIterate” function named “acc” or whose name starts with “left” or “right”.
As well as the required header file before the “griditerate” and the “main” functions.
As well as the required header file before the “griditerate” and the “main” functions.
And a call to a function for printing the final report.
As expected, the call to the function that prints the final report was inserted in the “main” function.
The include directive was inserted before the “main” and “gridIterate” functions.
The include directive was inserted before the “main” and “gridIterate” functions.
The include directive was inserted before the “main” and “gridIterate” functions.
And profiling is performed only to the selected variables.
Lets now see the execution of the weaved application.
As expected, the weaved application printed extra information related with the range of values used by each of the selected variables.
This aspect selects all functions and maps them to a Virtex 5 FPGA.
If their estimated cost on the FPGA is lower than on the PowerPC processor.
If their estimated cost on the FPGA is lower than on the PowerPC processor.
18 functions have lower cost on the FPGA.
And are therefore going to be mapped to the FPGA.
And are therefore going to be mapped to the FPGA.
The application is partitioned into code for the PowerPC processor.
The Virtex 5 FPGA.
The Virtex 5 FPGA.
Code for initialization of the MOLEN architecture.
Code for initialization of the MOLEN architecture.
Code for initialization of the MOLEN architecture.
The PowerPC stub.
And the Virtex 5 proxy.
This aspect instructs the compilation toolchain to unroll the innermost loop of the “gridIterate” function with an unroll factor of 4.
And map the “griditerate” function to a Virtex 5 FPGA.
The application synthesis step creates a VHDL hardware description from the unrolled “gridIterate” function.
The application synthesis step creates a VHDL hardware description from the unrolled “gridIterate” function.
The application synthesis step creates a VHDL hardware description from the unrolled “gridIterate” function.
As expected from unrolling with a factor of 4, the loop iteration variable “k” is incremented 4 times instead of 1.
As expected from unrolling with a factor of 4, the loop iteration variable “k” is incremented 4 times instead of 1.
So currently much of the design process is manual
where developers mix the implementation of the non-functional requirements with the main functionality
which leads to low productivity and low maintainability.
We want to move beyond the current design practices with our weaving approach
where the main functionality and non-functional requirements are maintained separately, and then combined by an automatic weaving process.
One of the benefits of our approach is that the weaver can automatically derive custom designs
based on aspect descriptions that capture specific non-functional requirements.
By keeping the functional and non-functional descriptions separate, it is easier to maintain them according to their life cycle.
Another benefit of LARA is that aspects can be reused if they are generic enough to target applications from the same domain
thus improving productivity, as well as maintanability.
Aspects in LARA can also be parametrizable
where results from profilers and tool reports can be used to generate more efficient designs
using an iterative process.
So in conclusion, in this project we have design an aspect oriented language
where complex schemes such as code optimizations can be implemented to realize non-functional requirements.
By capturing non-functional requirements, such as speed and power
the LARA language is capable of capturing best practices and user-knowledge.