# ViPar: High-Level Design Space Exploration for Parallel Video Processing Architectures

Karim Mohamed Abedallah Ali, Rabie Ben Atitallah, Abdessamad Ait El Cadi, Nizar Fakhfakh, Jean-Luc Dekeyser

► To cite this version:

Karim Mohamed Abedallah Ali, Rabie Ben Atitallah, Abdessamad Ait El Cadi, Nizar Fakhfakh, Jean-Luc Dekeyser. ViPar: High-Level Design Space Exploration for Parallel Video Processing Architectures. International Journal of Reconfigurable Computing, 2019, 10.1155/2019/4298013. hal-02438042

HAL Id: hal-02438042

https://hal.science/hal-02438042

Submitted on 31 Aug 2022

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Research Article

# ViPar: High-Level Design Space Exploration for Parallel Video Processing Architectures

Karim M. A. Ali<sup>D, ¹</sup>, Rabie Ben Atitallah,<sup>2</sup> Abdessamad Ait El Cadi,<sup>1</sup> Nizar Fakhfakh,<sup>3</sup> and Jean-Luc Dekeyser<sup>4</sup>

<sup>1</sup>LAMIH, Polytechnic University of Hauts-de-France, Valenciennes, France

<sup>2</sup>Computer Science Department, University of Galatasaray, Istanbul, Turkey

<sup>3</sup>NAVYA Company, Villeurbanne, France

<sup>4</sup>CRISTAL, University of Lille1, Villeneuve-d'Ascq, France

Correspondence should be addressed to Karim M. A. Ali; karim.ali@uphf.fr

Received 13 June 2019; Revised 22 September 2019; Accepted 3 October 2019; Published 14 November 2019

Academic Editor: John Kalomiros

Copyright © 2019 Karim M. A. Ali et al. This is an open access article distributed under the Creative Commons Attribution
License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is
properly cited.

Embedded video applications are now involved in sophisticated transportation systems like autonomous vehicles and driver assistance systems. As silicon capacity increases, the design productivity gap grows up for the current available design tools. Hence, high-level synthesis (HLS) tools emerged in order to reduce that gap by shifting the design efforts to higher abstraction levels. In this paper, we present ViPar as a tool for exploring different video processing architectures at higher design level. First, we proposed a parametrizable parallel architectural model dedicated for video applications. Second, targeting this architectural model, we developed ViPar tool with two main features: (1) An empirical model was introduced to estimate the power consumption based on hardware utilization and operating frequency. In addition to that, we derived the equations for estimating the hardware utilization and execution time for each design point during the space exploration process. (2) By defining the main characteristics of the parallel video architecture like parallelism level, the number of input/output ports, the pixel distribution pattern, and so on, ViPar tool can automatically generate the dedicated architecture for hardware implementation. In the experimental validation, we used ViPar tool to generate automatically an efficient hardware implementation for a Multiwindow Sum of Absolute Difference stereo matching algorithm on Xilinx Zynq ZC706 board. We succeeded to increase the design productivity by converging rapidly to the appropriate designs that fit with our system constraints in terms of power consumption, hardware utilization, and frame execution time.

**1. Introduction**

Nowadays, embedded video processing applications are
widely spread in our daily life. Among these applications, we
can mention public area video surveillance [1], crowd be-
haviour analysis for detecting abnormal activities [2, 3], ve-
hicle tracking [4], intelligent transportation systems [5, 6],
assisted living for elder people [7, 8], simultaneous locali-
zation and mapping (SLAM) problem [9, 10], counting
passengers in vehicles [11], real-time autonomous localization
[12], yawning detection [13], monitoring systems for kids
safety, analyzing customer behaviour in markets, and so on.

Latest semiconductor technologies offer powerful low-
cost computing hardware solutions which motivate industry
and academia towards developing intelligent sensors. For
video processing, smart camera systems are becoming more
attractive due to several advantages. In such sensor, images
are captured and processed locally to avoid remote com-
puting or specific communication infrastructure. In addition
to that, complex algorithms for data analysis and decision
making could be performed to bring autonomy capability to
systems like in drones and autonomous vehicles.

In this context, field-programmable gate array (FPGA)
technology is a competitive solution for building embedded
video processing applications when compared to other
available solutions in the market like CPU, GPU, or ASIC
circuits for different reasons [14]: (i) FPGA devices are
reprogrammable platforms where the hardware architecture
can be redesigned to adapt with the rapid changes in the
image sensor technologies or in video processing algorithms
without changing the chip itself. (ii) By exploiting the in-
herent parallelism in video processing applications, FPGA
technology enables to implement massively parallel archi-
tectures due to the huge number of programmable logics
available on a single chip. (iii) FPGA-based system is
considered as a solution between ASIC and processor-based
system where FPGAs are characterized by their high per-
formance per watt; thus, they are good candidate for em-
bedded video processing applications.

Several challenges arose while designing embedded
video processing applications using reconfigurable tech-
nology. First, we need to develop a flexible parallel recon-
figurable architecture where huge amount of pixels is
transferred from/to the computing nodes. Today, the in-
creasing demand for more frame rate or increasing the
image resolution are additional challenges for video pro-
cessing applications especially when real-time constraints
are considered. This challenge is augmented in the auton-
omous vehicle industry where several image sensors are
installed in the vehicle for obstacle detection, tracking, and
classification. The combination of reconfigurability and
parallelism is a key solution for the above-described prob-
lem. Thus, we need to know how to abstract the hardware
architecture to build a flexible parallel architecture where we
can fix the parallelism level according to the desired per-
formance or the available hardware resources. Today, a
tremendous number of logic cells exist on a single FPGA
chip. Using conventional ways to design, simulate, imple-
ment, and validate such large FPGA designs are a time-
consuming process. For that reason, designers always aim to
move the design efforts to the higher abstraction levels by
using high-level synthesis (HLS) tools to increase the design
productivity and to shorten the time-to-market conditions.
In FPGA design, there is no unique solution for the design
problem, but it is common to have a space of solutions where
the design points are different from each other in terms of
hardware utilization, performance, operating frequency, and
power consumption. Indeed, it is not practical to explore
manually a design space consisting of hundreds or thou-
sands of design points. Accordingly, automating the ex-
ploration process is necessary to search rapidly for the
solution which better fits with the given system constraints.

To address the aforementioned challenges, our contri-
butions in this work can be summarized as follows:

(1) We proposed a generic model for parallel hardware video processing architecture. For that model, we defined the required parameters to describe the architecture at the system and processing element level. The architectural parameters are then considered as an input to automate the high-level code generation.

(2) Translating C/C++ code to RTL design with the help of HLS tools does not mean an efficient hardware

design. However, a set of high-level optimization
steps should be applied in order to obtain an efficient
design. In this work, we classified the HLS optimi-
zations either for improving the hardware imple-
mentation or for exploiting the inherent parallelism
in the application. In addition to that, we showed the
impact of applying each optimization step on the
overall design efficiency in terms of hardware uti-
lization, power, and performance.

(3) We developed ViPar tool to automate the design space exploration through the following steps: (i) Both resource utilization and performance were estimated for each point in the design space. (ii) An empirical power model was introduced to estimate the power consumption for each design based on the utilized resources and operating frequency. (iii) The high-level code of the parallel video processing architecture was automatically generated for experimental validation. In the frame of our industrial collaboration, during our experiments, stereo matching algorithm was chosen as a video processing application.

The rest of this paper is organized as follows: related
works are overviewed in Section 2. Section 3 explains the
stereo matching algorithm used in this work. Section 4
details our parameterizable parallel architectural model.
Section 5 lists the applied HLS optimizations to obtain ef-
ficient hardware implementation, while Section 6 describes
how ViPar tool works. The experimental results are pre-
sented in Section 7. Finally, Section 8 summarizes our
presented work.

## 2. Related Works

In the literature, hundreds of research works present the
implementation of various video processing applications
over different hardware architectures ranging from CPU,
GPU, FPGA, DSP, and ASIC. For FPGA, the property of
being reconfigurable inspires designers to build architec-
tures of soft-core processors like vector, VLIW, and GPGPU
over FPGA. VectorBlox MXP [15] is an FPGA-based soft
vector processor for performing high parallel data tasks. The
architecture is parameterized by allowing the user specifying
the number of parallel ALU ranging from 1 to 128 parallel
ALU. For video processing applications, MXP offers two
modules: FrameWriter to write image frames to the external
memory or StreamWriter to write few scanlines to the MXP
scratchpad. In the experimental results, authors imple-
mented H.264 deblocking filter by defining custom in-
structions. In addition to that, they showed the
implementation of several video applications like median
filter, motion estimation, and saliency computation [15, 16].
Authors in [17] proposed a customizable VLIW processor
with a variable instruction set for exploiting parallelism. For
experimental validation, three basic image applications were
tested on the Virtex-6 FPGA board; then, authors extended
their experiments by realizing a contactless palmprint ex-
traction algorithm for biometric applications. Their VLIW
implementation over FPGA showed an average speedup of
2.7x when compared to DSP-based implementation for the same application. FlexGrip [18] is a soft GPGPU processor where compiled CUDA binaries are directly executed on the FPGA-based GPGPU without hardware resynthesis. FlexGrip follows the single-instruction multiple-thread (SIMT) model where one instruction is fetched and executed simultaneously by multiple SP cores. In the experiments, FlexGrip was implemented for a single SM and 8-SM over Virtex-6 VLX240T board to evaluate five different highly parallel CUDA applications. FGPU [19] is another soft GPGPU processor with single level-cache optimized for FPGA. The authors developed a compiler in order to support applications written in OpenCL [20]. FGPU has an extended MIPS assembly instruction set with additional instructions to support the OpenCL execution model. In the experimental results, the authors compared 11 applications including three image filters implemented on FGPU to other platforms.

High-level synthesis design space exploration (HLS DSE) can be classified in different ways. One classification divides the DSE into two classes: (i) DSE inside the HLS tool. (ii) DSE with the HLS tool. The first class focuses on applying DSE to the internal tasks of the HLS tools (allocation, binding, and scheduling). Each task is controlled by a set of different factors which have a significant impact on the performance metrics of the resulted hardware. Some research works under this class are [21, 22]. The second class considers the HLS tool as a black box and explores the design space of the optimization parameters offered by the tool. This class can be further subdivided into (i) HLS synthesis directives and (ii) resource sharing. For the first subclass, the HLS directives are inserted into the behavioural code as comments to affect the final synthesized microarchitecture. For example, loops can be pipelined or not with complete or partial unrolling. Arrays can also be completely or partially partitioned with the possibility to be mapped to registers or BRAMs. These optimization varieties generate a design space of different combinations that can be explored for the same application. For resource sharing, a single functional unit can be shared among different operations in the source code. This is achieved by inserting multiplexers at the inputs and outputs of the functional unit. Using resource sharing produces a design space of different implementations which vary from an architecture that has one single-shared FU to a fully-parallelized one.

Authors in [23] applied HLS directives then resource sharing to reduce the design space to be explored. They proposed a probabilistic method to accelerate the DSE process by calculating the probability of each generated architecture, and then continued exploring only the designs of the highest probabilities. Their experimental results showed an acceleration of 12x in the DSE process. Resource sharing acts differently for both ASIC and FPGA. In ASIC, resource sharing reduces the total area of the design while for FPGA, it could act oppositely because of the size of the inserted multiplexers consume a lot of logic resources. For that reason, authors in [24] proposed a method to force the cost of resource sharing to be larger than that of the used multiplexers by fixing the bitwidth of the internal variables.

This approach came at the expense of introducing overflow errors in the design. The experimental results showed that the percentage error differed from one application to another. Thus, the designer should estimate if the error percentage is acceptable or not in his application. A framework for HLS DSE was presented in [25] which exploited loop array-dependency to reduce the DSE time. The results showed that the framework gave the same quality of result as the exhaustive DSE approach while lowering the exploration time with an average of speed-up of 14x. Another framework used sequential model-based optimization (SMBO) to select the HLS directives automatically. During optimization, a model of the function was constructed using machine-learning methods. From the experimental results, the convergence to the optimal HLS directive settings was improved by using transfer-learning mechanism in the SMBO model [26]. Lin-Analyzer [27] did rapid design space exploration for various HLS pragmas like loop pipelining, loop unrolling, and array partitioning without the need for doing RTL implementations. Programs were represented in dataflow graphs by using dynamic data dependence graphs (DDDG). DDDG are acyclic directed graphs where nodes represent operations, while edges represent data dependence between the nodes. Lin-Analyzer scheduled the graph nodes according to the resource constraints to obtain early performance estimation. For validation, 10 different applications were tested on Xilinx ZC702 FPGA board. Another classification for HLS DSE is based on the algorithm used during the design space exploration like using genetic algorithm [28], simulated annealing [29], ant colony [23], or machine-learning techniques [30].

In this paper, we proposed a parameterizable generic architecture for video processing where the processing elements are dedicated for a certain video application to have area and power customized. The processing element was optimized by applying HLS optimizations; then, the architecture was explored at higher design level by tuning different parameters like parallelism level, operating frequency, and so on. Comparing to the existed tools, ViPar tackles the exploration challenge at more abstracted level making profit from the application properties (image size, sliding window size, parallelism level, etc.) and the system requirements (frame rate, power consumption, etc.). Our tool compares between different design points by estimating power consumption, hardware utilization, and performance, and then it generates automatically the parallel architecture for the best candidate designs.

## 3. Sum of Absolute Difference Stereo Matching Algorithm

Stereo matching is the problem of finding the depth of objects using two or more images. These images are taken from different positions by different cameras at the same time. Stereo matching is a correspondence problem where for every pixel ($X_R$) in the right image, we try to find its best matching pixel ($X_L$) in the left image at the same scanline. The difference between the two points on the image plane is defined as *disparity*, as depicted in Figures 1(a) and 1(b).
<figure><img src="image_2.png" /><figcaption>FIGURE 1: (a) Calculating the depth of an object in stereo matching problem. (b) Disparity is defined as the distance in pixels between $(X_R)$ and $(X_L)$. (c) 5-window SAD configuration.</figcaption></figure>

Several algorithms were proposed in the literature to find the best matching [31]. One of these algorithms is multiwindow sum of absolute difference algorithm (multiwindow SAD) [32], where the absolute difference between pixels of the right and left images are aggregated within a window, such that the window of minimum aggregation is considered as the best matching among its candidates. In order to overcome the error that appears at the regions of depth discontinuity, the correlation window can be divided into smaller windows, and only nonerror parts are considered in the calculations. Figure 1(c) shows 5-window SAD configuration, where pixel (P) lies in the middle of window (E) of height = $2 * cwinV + 1$ and width = $2 * cwinH + 1$ and surrounded by another four windows named A, B, C, and D of height = $winV + 1$ and width = $winH + 1$. We defined window score as the aggregation of the absolute difference of the pixels within that window.

The algorithm is described in Listing 1, where it scans all the image pixels at every disparity value ranging from zero to

the maximum value (DISP_MAX). The calculation of window (E) is usually performed independently from the others because its size is different from others. The for-loop described between Lines 2–27 is repeated a number of times equal to the maximum disparity value (DISP_MAX). The addition operation is considered as the core computation operation since we sum up the absolute difference of pixels. If we assume an image of size $N \times N$ with an aggregation window of size $M \times M$, then $N^2(M^2 - 1)$ addition operations are needed for window aggregation at every single pixel. However, by applying box-filtering [33] in both horizontal and vertical directions, the number of additions will be reduced to $4N^2$. Box-filtering is applied in both horizontal and vertical directions (Lines 5–12) to obtain the score of windows (A, B, C, D, and E) at each pixel. The minimum score $min\_score$ is equal to the sum of the score at window (E) in addition to the best minimum two scores of the other four windows (Lines 15–21). The new score value is compared to the previously calculated value at the same pixel such that if it is smaller, then both the score array $bestscoreR$[] and the disparity map array $DISP\_IMG\_R$[] are updated; otherwise, they are kept unchanged (Lines 22–24). Occluded objects are common to happen in the stereo matching problem; therefore, Left/Right consistency check is applied to get rid of occluded pixels from the final disparity map. Left/Right consistency check needs to calculate the disparity map twice; in the first calculation, the right image is considered as the reference, while vice versa happens in the second one (Lines 22–27). Hence, the disparity maps are stored in $DISP\_IMG\_R$[] and $DISP\_IMG\_L$[]; then, for each pixel, we check if the value of the left disparity map is the same as its matching pixel in the right disparity map. If it is the case, then we validate the pixel matching; otherwise, the disparity value at that pixel is uncertain and is replaced by zero (Lines 28–31).

## 4. Parallel Video Processing Architecture Model

Our proposed parameterizable architectural model is depicted in Figure 2. It is an array-based video processing architecture, where $N$ processing elements are running in parallel. Each processing element has $i$ input ports $(X_0, X_1, ..., X_i)$ and $j$ output ports $(Y_0, Y_1, ..., Y_j)$. The input pixel streams $(I_0, I_1, ..., I_m)$ are copied and distributed to individual array structures through *Pixel Distributor*. After processing, *Pixel Collector* stores the pixels in arrays before streaming them out in order through system output ports $(O_0, O_1, ..., O_n)$. In our previous work, we implemented a generic architecture for pixel distributor/collector that depends on the properties of the image processing algorithm (like macroblock size, sliding window stride, etc.) [34].

In this model, we defined a set of parameters to describe the properties of the parallel video architecture at the processing element, the system level, and for the top-level function. At the processing element level, we defined the port properties for the input ports $(X_0, X_1, ..., X_i)$ and output ports $(Y_0, Y_1, ..., Y_j)$. These port properties include name, data type, the source of the input pixel stream (src), and the range of image scanlines which are mapped to that
ALGORITHM 1: Pseudocode for multiwindow SAD algorithm.

**Algorithm:** Multi_Windows_SAD
**Input:** every disparity(d) where d = 0 —> DISP_MAX:
**for** every element(x, y) where x = 0 —> imgW, y = 0 —> imgH:
> Abs[y][x] = abs(IMG_R[y][x] - IMG_L[y][x + d]);
**for** every element(x, y) where x = winH —> imgW—winH, y = 0 —> imgH:
> row[y][x] = row[y][x - 1] + Abs[y][x] — Abs[y][x — winH];
> rowE[y][x] = rowE[y][x - 1] + Abs[y][x] — Abs[y][x - 2 * cwinH];
**for** every element(x, y) where x = 0 —> imgW, y = winV —> imgH—winV:
> scr[y][x] = scr[y - 1][x] + row[y][x] — row[y — winV][x];
> scrE[y][x] = scrE[y - 1][x] + rowE[y][x] — rowE[y - 2 * cwinV][x];
**for** every element(x, y) where x = winH —> imgW—winH, y = winV —> imgH—winV:
> scoreA = scr[y][x];
> scoreB = scr[y][x + winH];
> scoreC = scr[y + winV][x + winH];
> scoreD = scr[y + winV][x];
> scoreE = scrE[y + winV — cwinV][x + winH — cwinH];
> min_score = scoreE + MIN_2_values{scoreA, scoreB, scoreC, scoreD};
**if** min_score < bestscoreR[y + winV][x + winH]:
> bestscoreR[y + winV][x + winH] = min_score;
> DISP IMG_R[y + winV][x + winH] = d;
**if** min_score < bestscoreL[y + winV][x + winH + d]:
> bestscoreL[y + winV][x + winH + d] = min_score;
> DISP IMG_L[y + winV][x + winH + d] = d;
**for** every element(x, y) where x = 0 —> imgW, y = 0 —> imgH:
> dispVal = DISP IMG_R[y][x];
**if** abs(DISP IMG_L[y][x + dispVal] —> dispVal) > 1:
> DISP IMG_R[y][x] = 0;

<caption>ALGORITHM 1: Pseudocode for multiwindow SAD algorithm.</caption>

port during execution (*store_scanlines_from*, *store_-scanlines_to*). For example, for the 5-window SAD algorithm, we defined six input ports for AB, CD, and E windows, where each window has two inputs for the left and right images. If the window size for AB and CD is 23 x 8, then (*store_scanlines_from* and *store_scanlines_to*) will be 0 and 8 for window AB, while it will be 8 and 15 for window CD.

At the top-level function level, we defined the properties of the input/output stream ports. These port properties include their name, data type, how many scanlines are transferred from/to the system during execution (*num_of_scanlines*), and either if pixels are grouped during transfer to optimize bus communication or not (*num_of_merging_elements*). For example, if an 8-bit pixel is transferred over 64-bit bus width, then 8 pixels can be merged and sent at once. While the system properties define the general system properties such as the size of the input/output images and what level of parallelism is realized. For example, in autonomous vehicles, our input image size was 640 x 480 for the multiwindow SAD stereo matching algorithm with a global constraint of minimum 15 frames/s. With such high-level system description, hardware implementation details are hidden; hence, it facilitates the system design for video processing developers.

When the depicted architecture is described at high-level language, we have to code how the pixels will be distributed over the parallel processing elements and how they will be collected back to stream the output. The same image scanline could be mapped to several processing elements to guarantee

data-level parallelism execution. Indeed, it could be feasible to write the distribution/collection subroutines manually for architectures of few processing elements, but it will be a real challenge to do so for an architecture of large number of processing cores. This challenge is duplicated when a large number of parallel architectures need to be examined in order to find an efficient implementation that fulfils the design requirements. Consequently, coding these architectures manually is a time-consuming process and an error-prone process. In order to address the above challenge, we developed ViPar tool which explores the design space, and then automatically generates the high-level codes for the best candidate parallel architectures. The generated code is then compiled by the HLS tool to obtain the corresponding RTL design. In the next section, we will expose the high-level optimizations introduced in order to obtain an efficient processing element before exploring the possible parallel architectures by using ViPar tool.

## 5. High-Level Synthesis Optimizations

Using high-level synthesis (HLS) tools in electronic design automation (EDA) aims at moving the design efforts to higher abstraction levels. Today, it becomes more easier to design, implement, and verify complex video processing algorithms on reconfigurable technology by using high-level synthesis tools. In this section, we will classify HLS optimizations either for improving the hardware implementation or for exploiting the inherent parallelism in the video
<figure><img src="image_3.png" /><figcaption>FIGURE 2: Array-based video processing architecture.</figcaption></figure>

processing application. In order to obtain an efficient
hardware implementation, the high-level code is subjected
to a set of HLS optimization steps [35]. We will show the
impact of these optimizations in terms of hardware utili-
zation and performance on the multiwindow SAD
algorithm.

**5.1. Optimizations for Better Hardware Implementation.**
This type of optimization modifies the software code to fit for
hardware implementation.

**5.1.1. Dividing the Image into Strips.** For window-based image processing algorithm, dividing an image into strips is an inevitable step due to the limited number of on-chip memories (BRAMs). Design #1 showed an overuse for BRAM, where the FPGA platform has maximum BRAM_18K = 1090, as listed in Table 1. In strip processing, loop boundaries and array dimensions are updated to reflect a strip size processing area instead of full image size, and the code will be repetitively executed until all the strips are processed. For example, the image height is updated from `imgH` to `stripH`. In the multiwindow SAD algorithm, the pixels can be summed in three different ways: (i) Design #2 aggregates the pixels in the horizontal direction then the result is aggregated in the vertical one. (ii) While in Design #3, the aggregation is done vertically along the column length then horizontally along the scanline. (iii) However, in Design #4, the pixels are aggregated within the window boundary in both directions. Table 1 reports the estimated hardware utilization for the three designs. By comparing, we can observe that Design #4 is more efficient in terms of BRAM usage as well as for execution time.

**5.1.2. Using Arbitrary Precision Data Types.** HLS tools support arbitrary precision data types by defining variables

with smaller bitwidth. Instead of using the native C-based
data types of width 8, 16, 32, and 64 bit, we can define our
variables with adjustable bitwidth to produce systems of the
same accuracy but with less area utilization. By doing bit-
width analysis, we can know the lower and upper limits for
each variable, and then the required number of bits can be
exactly assigned. In Table 1, Design #5 showed around 31%
reduction for LUT and 40% reduction for FF.

**5.1.3. Choosing I/O Interface Protocols.** The generated hardware block is connected to other blocks in the design through various types of I/O protocols. Different communication protocols are available where the designer is free to choose the one which fits better with his design requirements. During the synthesis process, the top-level function arguments are synthesized as RTL ports where three classes of ports can be defined as follows: (1) Clock and Reset ports. (2) Block-level interface protocol is used to control and check the current state of the HLS block (start, ready, busy, or done state). (3) Port-level interface protocol is created for each argument in the top-level function with various configurations like memory interface, two-way handshaking with valid and acknowledge signals, or as AXI4 interfaces (AXI4-Stream, AXI4-Lite, and AXI4 master). In our design, AXI-Stream was chosen for the port-level interface. While AXI-Lite was selected for the block-level interface protocol to control the operation of the hardware block. In Table 1, Design #6 listed the hardware cost after adding the I/O interface protocol.

**5.1.4. Grouping Input/Output Pixels.** If the I/O pixels are of size less than the bitwidth of the communication bus, then the designer can benefit from the available bus to reduce the required communication time by merging pixels during data transfer. This operation requires an additional attention
<table><caption>TABLE 1: Synthesis results for each optimization step.</caption><thead><tr><th></th><th>Optimization</th><th>Slice</th><th>FF</th><th>LUT</th><th>BRAM (18K)</th><th>Time (ms)</th></tr></thead><tbody><tr><td colspan="7">SW version running at 380 ms on core i7@ 2.7 GHz and 16 GB of RAM</td></tr><tr><td>#1</td><td>First synthesizable design</td><td>X</td><td>2637</td><td>5918</td><td>7392</td><td>X</td></tr><tr><td>#2</td><td>Hor. then ver. aggregation</td><td>898</td><td>1743</td><td>2735</td><td>155</td><td>30080</td></tr><tr><td>#3</td><td>Ver. then hor. aggregation</td><td>859</td><td>1758</td><td>2659</td><td>113</td><td>22410</td></tr><tr><td>#4</td><td>In both directions</td><td>1400</td><td>2552</td><td>3738</td><td>75</td><td>8163</td></tr><tr><td>#5</td><td>Arbit. prec. data types</td><td>983</td><td>1525</td><td>2567</td><td>47</td><td>5786</td></tr><tr><td>#6</td><td>I/O interface protocols</td><td>996</td><td>1575</td><td>2619</td><td>49</td><td>6307</td></tr><tr><td>#7</td><td>Grouping pixels</td><td>1135</td><td>1820</td><td>3080</td><td>49</td><td>5865</td></tr><tr><td>#8</td><td>Task-level parallelism</td><td>1110</td><td>2002</td><td>3339</td><td>67</td><td>2658</td></tr><tr><td>#9</td><td>Calculating 4 disp. lines</td><td>2790</td><td>4578</td><td>7796</td><td>102</td><td>815</td></tr><tr><td>#10</td><td>Calculating 8 disp. lines</td><td>5012</td><td>8502</td><td>14027</td><td>204</td><td>432</td></tr><tr><td>#11</td><td>Calculating 12 disp. lines</td><td>6594</td><td>12563</td><td>18476</td><td>252</td><td>339</td></tr><tr><td>#12</td><td>Loop pipelining</td><td>1161</td><td>2004</td><td>3546</td><td>67</td><td>1174</td></tr><tr><td>#13</td><td>False dependency</td><td>1115</td><td>2030</td><td>3433</td><td>67</td><td>1002</td></tr><tr><td>#14</td><td>Data-level parallelism</td><td>2771</td><td>6365</td><td>8155</td><td>59</td><td>313</td></tr></tbody></table>

from the designer while separating the pixels at the input ports or merging them at the output ports. In our design, the communication bus is 64-bit, the input pixel is 32-bit, while the output disparity is only 8-bit. Thus, we can merge up to 2 pixels at the input port and up to 8 pixels at the output port. Design #7 showed 7% improvement in the execution time as listed in Table 1.

### 5.2. Optimizations for Exploiting the Inherent Parallelism.
This type of optimization modifies the software code to exploit the parallelism in the application at different levels (pipeline-level, task-level, or data-level parallelism). We will exploit the inherent parallelism in the multiwindow SAD algorithm to improve the execution time.

#### 5.2.1. Task-Level Parallelism.
In task-level parallelism, independent data tasks can be executed concurrently. For 5-window SAD algorithm, as shown in Figure 1, the score of window (B) is used after (winH + 1) pixel shift as a score for a new window (A) along the same scanline. The same case is applied for windows (C) and (D). Thus, only three score calculation loops are needed for windows (A/B, C/D, and E). In order to execute data-independent loops in parallel, we have (i) to duplicate the common input pixels between the three loops if exist and (ii) to rewrite them in separated functions to allow the HLS tool to schedule them in parallel. The common image lines between windows are duplicated to allow data-independent window calculations. For example, the common image lines between windows A/B and E are duplicated to the local arrays of both. In Table 1, Design #8 reports the effect of applying task-level parallelism where the execution time is improved by around 50%.

#### 5.2.2. Pipeline-Level Parallelism.
In pipeline-level parallelism, the computation is divided into stages where it is possible to execute the pipelined stages in parallel. We applied pipeline-level parallelism in two different ways: (i) by restructuring the code

manually. (ii) By applying HLS directives like LOOP PIPELINE. Figure 3 depicts that there is only one image line difference between two adjacent strips. For calculating one disparity line, a strip of height = 2 * win_V + 1 is needed, while for four adjacent disparity lines, a strip of height = 2 * win_V + 4 is required. Thus, we can increase the height of the strip to benefit from the sent pixels to calculate several disparity lines. We tried to calculate 4, 8, and 12 disparity lines while using the same pipeline for Designs #9, #10, and #11, respectively, as listed in Table 1. The other way of performing pipeline-level parallelism is by adding HLS directives like LOOP PIPELINE directive to the for-loops in the algorithm. This loop transformation is done automatically by the help of the tool without the need to modify the code. Design #12 in Table 1 reported the hardware cost and the execution time after applying the pipeline directive on Design #8. The HLS tool tries to schedule all the loop iterations just one clock cycle far from each other (i.e., iteration interval (II) = 1), but sometimes due to interloop-dependency, II = 1 cannot be achieved. It is the role of the designer to check the positions where II > 1 are reported then to direct the tool to remove the false loop-dependency if exists by introducing LOOP_DEPENDENCE directive. In Table 1, Design #13 showed 15% gain in execution time than Design #12 when false interloop-dependency is removed.

#### 5.2.3. Data-Level Parallelism.
When the computation process is repeated without true loop-carried dependency between the iterations, then, it can be duplicated to operate on different sets of data in parallel. Data-level parallelism is applied in two different ways: (i) by applying ARRAY_PARTITION and LOOP_UNROLL directives and (ii) by increasing the number of parallel processing elements. The goal of array partitioning is to boost the system throughput at the expense of increasing the used hardware resources. LOOP_UNROLL directive duplicates the computation process to operate on a different set of data by creating multiple copies of the loop body. Loops can be partially unrolled by creating N copies of the loop body if factor N is defined; otherwise, the loop is fully unrolled by default.
<figure><img src="image_4.png" /><figcaption>FIGURE 3: Enlarging the strip height to calculate 4 disparity lines.</figcaption></figure>

Design #14 reported 70% improvement in the execution time with 2.3x and 3.1x increase in LUT and FF, respectively, as listed in Table 1. The other way of exploiting data-level parallelism is by increasing the number of parallel processing elements. This can be achieved by defining a new top-level function that includes multiple instances of Design #14 operating in parallel. In the next section, we will use the model described in Section 4 to define the required parameters to implement a parallel hardware architecture consisted of N processing elements by the help of ViPar tool.

## 6. ViPar Tool

In this section, we will describe the design flow of ViPar tool and how the performance metrics like area, power, and execution time are estimated by our tool at a higher design level. In addition to that, we will show how the high-level code is generated by ViPar after defining the main properties of the parallel architecture.

### 6.1. ViPar Tool Design Flow.
Figure 4 depicts the design flow for ViPar tool where the initial input is the performance metrics of the design at parallelism level = 1. These metrics include area utilization, power consumption, and execution time. During the area estimation phase, we keep increasing the level of parallelism till one of the resources (slice or BRAM) is completely utilized. The upper bound for resource utilization depends on which FPGA chip is selected during the exploration process. After that, the produced set of design alternatives is estimated for power consumption and execution time as well. According to the system constraints, the design space is pruned to the set of the candidate designs. Then, high-level code generation is done to generate automatically the C++ files for each design candidate. The generated code constrained by HLS optimizations/user constraints are considered as the input to the high-level synthesis tool to obtain the RTL design. Later, the RTL design is implemented to generate the design bit stream. Experimentally, we can measure the design metrics to verify how far are the estimations from the real values and to make sure that the system constraints are fulfilled.

### 6.2. Area Estimation.
Two factors affect the resource utilization of the implemented design: (i) Synthesis/Implementation strategy. The synthesis tool offers a set of

predefined strategies to obtain the hardware implementation. It is a multiobjective problem where each strategy has a certain objective to optimize like power, area, performance, and so on. (ii) Operating frequency. The synthesis tool tries to achieve timing closure alongside satisfying the objective of the applied strategy. At higher operating frequencies, the tool allocates more hardware resources to satisfy the timing constraints.

Figure 5 shows the relation between LUT and FF utilization at different parallelism levels. In this figure, Default synthesis strategies were used at two different operating frequencies 100 and 200 MHz, while Performance_Explore synthesis strategy was used at 100 MHz. We can deduce the following observations from the figure: (i) Utilization for LUT and FF increases linearly with the increase of the parallelism level. (ii) At the same parallelism level, the observed utilization varies either because of using different synthesis strategies or because of using different operating frequencies. (iii) The difference in LUT/FF utilization for the same design implemented by two different synthesis strategies is small at lower parallelism level, while it becomes more significant for high levels of parallelism.

In highlight of the previous observations and based on the depicted parallel video processing architecture in Figure 2, the hardware cost in terms of slice, FF, LUT, and BRAM can be divided into (i) Base cost which represents the required resources for implementing the basic blocks existing in every single design. These basic blocks include AXI-DMA blocks for pixel transfer, AXI-interconnect blocks, AXI-VDMA blocks for video target peripherals, and so on. (ii) Parallel cost which represents the required hardware resources for implementing the processing elements of the parallel architecture. We can deduce a linear relation for estimating slice, LUT, FF, and BRAM as follows:

$$ \begin{aligned} \text{estimated utilization}|_{\text{parallelism level}=N} \\ = \text{base cost} + N * \text{utilization}|_{\text{parallelism level}=1} \end{aligned} \qquad (1) $$

where Base_cost is the hardware cost for the basic blocks in the design and N is the level of parallelism. For slice estimation, we have another equation based on the fact that the slice is composed of FFs and LUTs (for example, in Zynq ZC706, one slice consists of 8 FFs and 4 LUTs). Therefore, the estimated slice utilization can be formulated as follows:

$$ \text{estimated slice utilization}|_{\text{parallelism level}=N} = \max \left\{ \frac{\text{estimate } d\_LUT|_{\text{parallelism}=N}}{\text{num\_LUT\_per\_Slice}}, \frac{\text{estimate } d\_FF|_{\text{parallelism}=N}}{\text{num\_FF\_per\_Slice}} \right\}, \qquad (2) $$

where N is the level of parallelism, estimated_LUT is the estimated LUT utilization, and estimated FF is the estimated register utilization at parallelism level = N. num_LUT_per_Slice and num FF_per_Slice is the number of LUT and FF in one Slice.

### 6.3. Power Estimation Model.
There are three types contributing to the power consumption in FPGA: static power, short-circuit power, and dynamic power. Dynamic power
<figure><img src="image_5.png" /><figcaption>FIGURE 4: Design flow with ViPar tool.</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>FIGURE 5: LUT/FF utilization at different parallelism levels for Default strategy at 100 MHz, Default strategy at 200 MHz, and Performance_Explore strategy at 100 MHz.</figcaption></figure>

could be further broken down into power consumed by clocks, interconnect wires, and hardware resources. Equation (3) [36] is used to formulate the dynamic power consumption, where n is the total number of nodes, f is the clock frequency, $V_{dd}$ is the supply voltage, $C_i$ is the load capacitance for node $n_i$, and $S_i$ is the switching activity for node $n_i$.

$$ \text{Power}_{\text{dynamic}} = \frac{1}{2} f V_{dd}^2 \sum_{i=1}^{n} C_i S_i. \quad (3) $$

For correct power estimation, a detailed placement and routing design is required to estimate the power consumption at each single node $n_i$ in the design. In fact, obtaining a detailed placement and routing design takes a considerable time which could range between 30 and – 90 min or even more for larger designs. During exploration, it is not practical to run a detailed implementation to estimate the power consumption for every single point. Instead of that, quick power estimations are accepted at that

early design stage to compare the power consumption of different design points. In this work, we will present an empirical power model based on hardware resources and operating frequency characterization.

6.4. Power Measurement. The power was measured through an UCD90120A power controller mounted on the Zynq-ZC706 board using TI Fusion Digital Power Designer software. The power consumed by the FPGA chip was measured by monitoring rail 1 (VCCINT) of the power controller with a sample rate of 5 samples/s. For correct average power values, the power was sampled for at least 10 minutes on average. The total power consumption is affected by how much hardware resources are used and at which frequency the design is operating. In order to formulate this relation, two basic hardware blocks were designed where one uses only slices, while the other uses only BRAMs. Each hardware block was implemented in a separate design at different parallelism level while operating at frequencies of
values 50, 100, 150, and 200 MHz. We kept increasing the level of parallelism till full hardware utilization. For each design, the power was measured practically, and then it was plotted versus hardware utilization, as depicted in Figure 6.

We can observe from the plots that there is a correlation between the measured power and hardware utilization (slice and BRAM). The plotted lines are not parallel to each other which reflect the interaction of frequency in the power equation. This correlation between the measured power, BRAM, slice, and frequency can be formulated by using regression analysis to obtain the power estimation model.

### 6.5. Power Regression Model.
The power estimation model was built by varying the independent variables (slice, BRAM, and frequency) as follows: slice at 9K, 15K, 25K, 35K, 45K, 50K, and 54K, BRAM at 96, 156, 246, 366, 486, 606, 846, and 1026, and frequency at 50, 100, 150, and 200 MHz. For each experiment, we measured between 2700 and -3000 samples where all the measured samples are then arranged in one spreadsheet as an input for regression analysis to estimate the relationship between power, frequency, slice, and BRAM. There are various kinds of regression models for power prediction. In our study, we will compare three models (linear, pure-quadratic, and full-quadratic) to choose the one which better fits.

Before going into the details, it is preferable to explain some statistical definitions that will be used in the analysis for comparing the models.

(i) Residual Value. It is the vertical distance between a data point and the regression line. They are positive if they are above the regression line and negative if they are below it, but if the regression line passes through the points, then the residual will be zero.

(ii) Residual Sum of Squares (Residual SS). It tells if the statistical model is a good fit for the data or not by calculating the overall difference between the data and their predicted values, where $\Sigma$ error² = $\Sigma$ (power$_{actual}$ - power$_{predicted}$)².

(iii) The Coefficient of Determination (R-squared). R² tells how many points fall on the regression line. R-squared is explained by a value ranging between 0 and 1.

$$R^2 = 1 - \frac{\text{Residual sum of squares}}{\text{Total sum of squares}}. \quad (4)$$

(iv) Adjusted R-Squared. It is adjusted for the number of coefficients in the model. This value is often used to compare models of different numbers of coefficients.

(v) Significance Level (Alpha Level ($\alpha$)). It is the probability of making the wrong decision when the null hypothesis is true, while the confidence level is defined as $(1 - \alpha)$.

(vi) P-Value. It is used in the hypothesis test for either supports or rejects the null hypothesis. P-value is an

evidence against the null hypothesis where the smaller the P-value, the stronger evidence to reject the null hypothesis.

(vii) Significance-F. It is the probability that the regression equation does not explain the variation in the dependent variable (power).

Table 2 lists the regression analysis for the three models (linear, pure-quadratic, and full-quadratic). For the three models, Table 2 showed zero value for the significance-F; therefore, the three models are valid (i.e., our results are statistically significant, and they likely did not happen by chance). Adjusted R-squared can be checked to tell us how many points fall on the regression line. It was 0.912166 for the linear model, 0.994009 for pure-quadratic, and 0.99413 for full-quadratic. Apparently, the difference in Adjusted R² between pure-quadratic and full-quadratic was not that big difference. For that reason, we can either choose pure-quadratic to have fewer model parameters or to choose full-quadratic to have the highest R². In our case, we chose the full-quadratic model. Finally, by applying a confidence level of 99% (i.e., $\alpha$=0.01), we checked the corresponding P-values for the coefficients $\beta$ of the full-quadratic model ($\beta_0$ → $\beta_9$); we could conclude that the null hypothesis is rejected for all coefficients ($\beta_0$ → $\beta_9$), where P < 0.01. The full-quadratic power estimation model is described in the following equation:

$$\text{power}_{\text{estimated}} = \beta_0 + \beta_1 * S + \beta_2 * B + \beta_3 * F + \beta_4 * S * B + \beta_5 * S * F + \beta_6 * B * F + \beta_7 * S^2 + \beta_8 * B^2 + \beta_9 * F^2, \quad (5)$$

where S is slice, B is BRAM, F is Frequency, $\beta_0$ = 0.2228, $\beta_1$ = 1.29 × 10⁻⁶, $\beta_2$ = 9.39 × 10⁻⁵, $\beta_3$ = 11.6 × 10⁻⁵, $\beta_4$ = 2.38 × 10⁻⁹, $\beta_5$ = 7.03 × 10⁻⁸, $\beta_6$ = 5.51 × 10⁻⁷, $\beta_7$ = 4.6 × 10⁻¹¹, $\beta_8$ = 9.5 × 10⁻⁸, and $\beta_9$ = 4.91 × 10⁻⁷.

We need to analyse the residual values to prove that the hypothesis behind the full-quadratic regression model holds. In the residual plot, the residuals are plotted on the vertical axis, while the independent variable (power) is on the horizontal axis. If the points in the plot are randomly dispersed around the horizontal axis, then the regression model is appropriate for that data. In addition to that, both the sum and the mean average of the residual values should equal to zero. Figure 7 shows the residual plot for the full-quadratic regression model. It is obvious from the plot that the residual points are normally distributed around the horizontal axis. In addition to that, the sum of residuals and their mean average were almost equal to zero (2.76245 e-09 and 2.75826 e-14, respectively). From this analysis, we can conclude that our full-quadratic model described in equation (5) is valid.

### 6.6. Estimating Execution Time.
The execution time for video processing application is affected by the number of parallel processing channels and the applied operating frequency. It is common to divide one image into strips during frame processing. The execution time for strip processing is formulated in equation (8) which is equal to the summation of
<figure><img src="image_7.png" /><figcaption>FIGURE 6: Measured power with BRAM and slice variation at frequencies 50 MHz, 100 MHz, 150 MHz, and 200 MHz.</figcaption></figure>

<table><caption>TABLE 2: Regression analysis for linear, pure-quadratic, and full-quadratic power estimation model.</caption><thead><tr><th></th><th>Linear mode</th><th>Pure-quadratic model</th><th>Full-quadratic model</th></tr></thead><tbody><tr><td>Regression SS</td><td>6384.396</td><td>6957.231</td><td>6958.076</td></tr><tr><td>Residual SS</td><td>614.766</td><td>41.93071</td><td>41.0856</td></tr><tr><td>Total SS</td><td>6999.162</td><td>6999.162</td><td>6999.162</td></tr><tr><td>Significance-F</td><td>0</td><td>0</td><td>0</td></tr><tr><td>Multiple R</td><td>0.955074</td><td>0.997</td><td>0.997061</td></tr><tr><td>R-square (R<sup>2</sup>)</td><td>0.912166</td><td>0.994009</td><td>0.99413</td></tr><tr><td>Adjusted R<sup>2</sup></td><td>0.912163</td><td>0.994009</td><td>0.994129</td></tr><tr><td>Observations</td><td>100152</td><td>100152</td><td>100152</td></tr></tbody></table>

clock cycles required to transfer the pixels from/to the processing element plus the clock cycles required for algorithm processing.

$$ \text{Strip processing (in cycles)} \\ = \text{cycles}_{\text{writing input pixels}} + \text{cycles}_{\text{PE processing}} \\ + \text{cycles}_{\text{reading output pixels}} \quad (6) $$

where Cycles$_{|writing input pixels}$ is the number of clock cycles required to transfer the pixels from the memory to the processing element through DMA communication, Cycles$_{|PE Processing}$ is the number of clock cycles required by the processing element for executing the application, and Cycles$_{|reading output pixels}$ is the number of clock cycles required to transfer the processed pixels back to the memory. By using the following equation, we could know how many strips are there in one image frame:

$$ \text{Num\_of\_strips} \\ = \frac{\text{Num\_image\_lines}}{\text{Num\_output\_lines}|_{\text{parallelism level}=1} * \text{parallelism level}} \quad (7) $$

where Num_image_lines is the number of scanlines in one image and Num_output_lines|parallelism level=1 is the number of image lines produced by a single processing channel from

<figure><img src="image_8.png" /><figcaption>FIGURE 7: Residual plot for the full-quadratic regression model.</figcaption></figure>

one image strip processing. From the previous equations, the frame execution time can be calculated as follows:

$$ \text{frame execution time (in seconds)} \\ = \frac{\text{Num\_of\_strips} * \text{strip processing (in clk cycles)}}{\text{frequency (in MHz)}} \quad (8) $$

6.7. Automatic High-Level Code Generation. Figure 8 shows that the high-level code generation tool has two input files which are (1) Processing Element C++ File which
<figure><img src="image_9.png" /><figcaption>FIGURE 8: High-level code generation design flow.</figcaption></figure>

Candidate design input files

**System specification file**

**Processing element C++ file**

Automatic high-level code generation

**HLS output files**

**Design C++ files**

stream out the processed image scanlines. In addition to that, the tool manages how the pixels are separated before distribution or merged at the output ports in order to reduce bus communication time. After applying *HLS optimizations/*User constraints*, the generated C++ design files are compiled by the high-level synthesis tool to give the corresponding RTL design.

Listings 2 shows an example of the specification file for video downscaler (4:1) for an input VGA image size (640 × 480). As described before, the specification file is subdivided into four main sections: *Header* section includes all header files and definitions (lines 1–12), *System Property* section (lines 14–20) defines the size of the input/output image in addition to the level of parallelism implemented by the generated architecture (line 19), *Top-level* section (lines 22–35) defines the name of the top-level function *VideoDownScaler_parallel32* (line 23) and the port properties for the system input/output ports. In this application, there is one single input port *data img* (lines 24–28) and one single output port *img_result* (lines 29–33), and *Processing Element* section is the last section in the file (lines 37–53) where the number and the properties of the input/output ports for the processing element are defined.

Table 3 lists the number of lines of code (LOC) generated by the tool for different applications at different levels of parallelism. LOC are calculated after excluding both blank lines and comments. To move from one parallelism level to another, we need to change only the value of *level_of_parallelism* parameter in `#System_Propertie#` section. Consequently, a significant design time is saved by automating that step. For example, the size of the system specification file for the 5-window SAD algorithm is 98 lines where LOC ratio between the generated code to specification

(i) *Property Extraction Phase*. From the *System Specification File*, the tool can extract *level_of_parallelism* and other input/output port properties for both top-level and processing element blocks.

(ii) *PE Property Generation*. Based on the extracted properties, the tool can derive the properties of the other processing cores in the architecture (from PE = 1 to N-1) automatically. For both pixel distributor and pixel collector, arrays are created such that each input/output port ($X_{(i,PE)}$ or $Y_{(j,PE)}$) is mapped to a single array structure.

(iii) *Building the Parallel Architecture*. Finally, the tool builds the parallel architecture by generating the C++ code for: (1) pixel distributor subroutine to store image scanlines in arrays according to the distribution pattern, (2) instantiating a number of parallel processing instances equal to the level of parallelism, and (3) pixel collector subroutine to

Figure 8 illustrates the three main phases to generate the high-level code for parallel video processing architecture.
file is 3.2 (314:98) for one processing element architecture,
and it reaches to 74 (7244:98) for an architecture containing
64 processing elements, while for the convolution filter, this
ratio is 1.3 (69:52) for one processing element and increases
to 39 (2026:52) for 64 element architecture.

7. Experimental Results

In this section, our industrial case study 5-window SAD algorithm will be explored by means of our developed ViPar tool. As a first step for exploring the design space, the processing element was implemented efficiently in terms of hardware utilization and frame rate by adding high-level synthesis optimizations. As discussed in Section 5, we obtained three different implementations by exploiting pipeline-level parallelism. These designs are named *pipe4*, *pipe8*, and *pipe12*, where 4, 8, and 12 disparity lines are processed by the same processing channel. In this section, these initial three designs will be explored at different operating frequencies (100, 150, and 200 MHz) by varying the level of parallelism till full hardware utilization. Our experiments were based on Zynq XC7Z045-FFG900 Xilinx evaluation board and 5-window SAD configured for *winH* = 23, *winV* = 7, *cwinH* = 7, *cwinV* = 3, and maximum disparity = 64. It is worth to mention that changing the 5-window SAD configuration or the hardware platform will result in a new design space that needs to be explored.

By the help of ViPar tool, we will estimate the hardware
utilization, power consumption, and execution time for each
alternative in the design space. According to the system
constraints, only the candidate designs will be selected for
synthesis. We highlight that the high-level codes of the can-
didate designs will be generated automatically, and then
synthesized to give the corresponding RTL design. The RTL
design is then implemented and experimented to verify the
estimated design metrics. Resource utilization, power, and
frame execution time were estimated by means of the derived
equations detailed in the previous section. Tables 4 and 5 list the
points in the design space. The number of disparity lines
processed by the same processing channel classifies the points
into three groups (*pipe4*, *pipe8*, and *pipe12*). For each group, the
same design was implemented at three different operating
frequencies (100, 150, and 200 MHz); then, we can exploit data-
level parallelism by increasing the parallelism level till full
hardware utilization.

7.1. *Area and Execution Time Estimations.* The designs for *pipe4*, *pipe8*, and *pipe12* at parallelism level = 1 running at 100, 150, and 200 MHz are considered as the initial points for our estimation process (designs #1, #9, #17, #25, #29, #33, #37, #40, and #43). For area estimation, we keep increasing the level of parallelism till one of the resources either slice or BRAM is completely utilized. The upper boundary for resources could differ from one case to another according to the used FPGA chip during the exploration process. For example, in this exploration, Zynq ZC706 was used with maximum hardware resources of slice = 54650, FF = 437200, LUT = 218600, and BRAM_18K = 1090.

The experimental measurements for power and perfor-
mance were conducted in order to evaluate how far the es-
timations are correct from the real values. By default, *Default*
synthesis/implementation strategies are used, but if they failed
to satisfy the timing constraints, then they are replaced by
*Performance Explore* strategies (*Performance Explore* was used
for designs #22, #35, and #44). However, some designs could
not be synthesized even after changing the strategy due to the
unsatisfied timing constraints or due to the lack of the
hardware resources required to apply that new strategy
(nonsynthesized designs are #23, #24, #36, and #45).

Figure 9 depicts the percentage of estimation error for slice, LUT, and FF such that positive values mean overestimated values and negative values mean underestimated ones, while the points of discontinuity in the plot are for the nonsynthesized designs (#23, #24, #36, and #45). The percentage estimation error ranges between -21% and 0.4%, -3.7% and 0.3%, and -14.6% and 8% for LUT, FF, and slice, respectively. The maximum estimation error for LUT occurred for design #22 by -21% and for design #44 by -15% due to the change of the implementation strategy (*Performance Explore* was used for synthesis while estimations were based on the default strategies). For BRAM, the estimation error was not plotted since both the estimated and measured values were identical. Figure 10 shows the percentage error in the estimated frame execution time where it ranges between -10.4% and 4.3% for different designs. This error arose due to the additional time consumed to set the DMA communication between the processing system (PS) and the programmable logic (PL).

7.2. *Power Estimation.* For fast power estimations at high-level design, only information about frequency and resource utilization are available. Figure 11 shows that the power consumption was underestimated by values ranging between 34% and 62.3% of the real measured values. It is reasonable to see that difference because some factors which contribute to the power consumption like switching activity, clock tree, and the interconnect wires are not considered in the model equation. For further analysis, the estimated and measured power were plotted in Figure 12. From the figure, we can deduce that the two curves behave in the same manner. In conclusion, the derived power model can be used for relative power comparison between alternative designs during the design space exploration process. However, it cannot be used to estimate a value near from the real measurements for a single design due to the lack of full design implementation details.

7.3. *Design Space Exploration.* All design variations listed in Tables 4 and 5 could be accepted as a solution but the applied system constraints will direct our final decision to choose one design among the others. Figure 13 depicts some of the candidate designs (#7, #31, #42, and #43) along with the system constraints to guide the designer towards an efficient solution. The orange shaded area represents the system constraints defined by the designer which are frame
(1) **## Header ##**
(2) #include "ap_int.h"
(3) #define IMG_WIDTH 640
(4) #define IMGHeight 480
(5) #define IMG_SIZE 307200
(6) #define IMG_WIDTH_2 320
(7) #define IMGHeight_2 240
(8) #define IMG_SIZE_4 76800
(9) #define WINHeight 2
(10) #define STRIP_SIZE_PARA32_8 5120
(11) #define IMG_WIDTH_2_PARA32_8 1280
(12) **## ENDOF Header ##**
(13)
(14) **## SystemPropertie s ##**
(15) input_image.width = 640
(16) input_image的高度 = 480
(17) output_image.width = 320
(18) output_image的高度 = 240
(19) Parallelism_level = 32
(20) **## ENDOF_SystemPropertie s ##**
(21)
(22) **## Top Level Function ##**
(23) Name = VideoDownScaler_parallel32
(24) Num_ofInputs = 1
(25) Input_0.name = data img[STRIP_SIZE_PARA32_8]
(26) Input_0.type = unsigned long long int
(27) Input_0.num_of_scanlines = 64
(28) Input_0.num_of_merging_elements = 8
(29) Num_ofOutputs = 1
(30) Output_0.name = img_result[IMG_WIDTH_2_PARA32_8]
(31) Output_0.type = unsigned long long int
(32) Output_0.num_of_scanlines = 32
(33) Output_0.num_of_merging_elements = 8
(34) Interface = AXI-Stream
(35) **## ENDOF_Top Level Function ##**
(36)
(37) **## Processing Element ##**
(38) Name = VideoDownScaler
(39) Num_ofInputs = 1
(40) Input_0.name = image[IMG_WIDTH][WIN HEIGHT]
(41) Input_0.type = unsigned char
(42) Input_0.src = data img[STRIP_SIZE_PARA32_8]
(43) Input_0.store_scanlines_from = 0
(44) Input_0.store_scanlines_to = 1
(45) Input_0.shift step = 2
(46) Num_ofOutputs = 1
(47) Output_0.name = image_result[IMG_WIDTH_2]
(48) Output_0.type = unsigned char
(49) Output_0.sink = img_result[IMG_WIDTH_2_PARA32_8]
(50) Output_0.store_scanlines_from = 0
(51) Output_0.store_scanlines_to = 0
(52) Output_0.shift step = 1
(53) **## ENDOF Processing Element ##**

<caption>ALGORITHM 2: Specification file for video downscaler (4:1) for input VGA image.</caption>

execution time ≤ 15 ms, LUT ≤ 150000, FF ≤ 120000,
BRAM ≤ 700, and frequency ≤ 150 MHz. From Figure 13,
we could deduce that design #31 succeeded to satisfy all the
system constraints (for design #31, LUT = 132475,
FF = 115727, BRAM = 571, frequency = 150 MHz, and frame
execution time = 12 ms). Design #43 had relatively less

hardware utilization (LUT = 68978, FF = 67339 and
BRAM = 275) and acceptable execution time (15.6 ms)
compared with design #31; however, it failed to meet the
frequency constraint. In such case, the designer can think
either to change the system constraints to profit from the less
hardware utilization of design #43 or to stuck to them.
<table><caption>TABLE 3: Number of code lines generated for different applications at different parallelism levels.</caption><thead><tr><th>Level of parallelism</th><th>Spec. file</th><th>1</th><th>4</th><th>8</th><th>16</th><th>32</th><th>64</th></tr></thead><tbody><tr><td>5-win SAD</td><td>98</td><td>314</td><td>644</td><td>1084</td><td>1964</td><td>3724</td><td>7244</td></tr><tr><td>1-win SAD</td><td>74</td><td>249</td><td>552</td><td>904</td><td>1608</td><td>3016</td><td>5832</td></tr><tr><td>Video scaler</td><td>54</td><td>87</td><td>195</td><td>339</td><td>627</td><td>1203</td><td>2355</td></tr><tr><td>Conv. filter</td><td>52</td><td>69</td><td>195</td><td>363</td><td>634</td><td>1098</td><td>2026</td></tr></tbody></table>

<table><caption>TABLE 4: Estimations for utilization, power, and frame execution time for *pipe4* designs.</caption><thead><tr><th>#</th><th>Freq. in MHz</th><th>Level of parallelism</th><th>Slice (54650)</th><th>FF (437200)</th><th>LUT (218600)</th><th>BRAM (1090)</th><th>Power in mW</th><th>Frame exec. time in ms</th></tr></thead><tbody><tr><td>1</td><td rowspan="8">100</td><td>1</td><td>10534</td><td>28903</td><td>31163</td><td>131</td><td>342.91</td><td>84.875</td></tr><tr><td>2</td><td>2</td><td>18444</td><td>49161</td><td>55683</td><td>243</td><td>418.29</td><td>44.85</td></tr><tr><td>3</td><td>3</td><td>26354</td><td>69419</td><td>80203</td><td>355</td><td>489.81</td><td>30.965</td></tr><tr><td>4</td><td>4</td><td>34264</td><td>89677</td><td>104723</td><td>467</td><td>557.46</td><td>24.838</td></tr><tr><td>5</td><td>5</td><td>42174</td><td>109935</td><td>129243</td><td>579</td><td>621.25</td><td>20.656</td></tr><tr><td>6</td><td>6</td><td>50084</td><td>130193</td><td>153763</td><td>691</td><td>681.17</td><td>17.854</td></tr><tr><td>7</td><td>7</td><td>44571</td><td>150451</td><td>178283</td><td>803</td><td>662.85</td><td>15.7</td></tr><tr><td>8</td><td>8</td><td>50701</td><td>170709</td><td>202803</td><td>915</td><td>710.87</td><td>14.32</td></tr><tr><td>9</td><td rowspan="8">150</td><td>1</td><td>10111</td><td>27410</td><td>31140</td><td>131</td><td>390.71</td><td>56.733</td></tr><tr><td>10</td><td>2</td><td>17754</td><td>46175</td><td>55636</td><td>243</td><td>494.28</td><td>29.975</td></tr><tr><td>11</td><td>3</td><td>25397</td><td>64940</td><td>80132</td><td>355</td><td>594.22</td><td>20.693</td></tr><tr><td>12</td><td>4</td><td>33040</td><td>83705</td><td>104623</td><td>467</td><td>690.54</td><td>16.596</td></tr><tr><td>13</td><td>5</td><td>40683</td><td>102470</td><td>129124</td><td>579</td><td>783.22</td><td>13.8</td></tr><tr><td>14</td><td>6</td><td>48326</td><td>121235</td><td>153620</td><td>691</td><td>872.28</td><td>11.927</td></tr><tr><td>15</td><td>7</td><td>44529</td><td>140000</td><td>178116</td><td>803</td><td>853.05</td><td>10.488</td></tr><tr><td>16</td><td>8</td><td>50653</td><td>158765</td><td>202612</td><td>915</td><td>925.64</td><td>9.565</td></tr><tr><td>17</td><td rowspan="8">200</td><td>1</td><td>9642</td><td>29895</td><td>31184</td><td>131</td><td>437.3</td><td>42.736</td></tr><tr><td>18</td><td>2</td><td>16893</td><td>51145</td><td>55723</td><td>243</td><td>565.37</td><td>22.574</td></tr><tr><td>19</td><td>3</td><td>24144</td><td>72395</td><td>80262</td><td>355</td><td>690.15</td><td>15.581</td></tr><tr><td>20</td><td>4</td><td>31395</td><td>93645</td><td>104801</td><td>467</td><td>811.62</td><td>12.494</td></tr><tr><td>21</td><td>5</td><td>38646</td><td>114895</td><td>129340</td><td>579</td><td>929.78</td><td>10.387</td></tr><tr><td>22</td><td>6</td><td>45897</td><td>136145</td><td>153879</td><td>691</td><td>1044.64</td><td>8.976</td></tr><tr><td>23</td><td>7</td><td>53148</td><td>157395</td><td>178418</td><td>803</td><td>1156.2</td><td>7.891</td></tr><tr><td>24</td><td>8</td><td>50740</td><td>178645</td><td>202957</td><td>915</td><td>1144.27</td><td>7.196</td></tr></tbody></table>

<table><caption>TABLE 5: Estimations for utilization, power, and frame execution time for *pipe8* and *pipe12* designs.</caption><thead><tr><th>#</th><th>Freq.in MHz</th><th>Level of parallelism</th><th>Slice (54650)</th><th>FF (437200)</th><th>LUT (218600)</th><th>BRAM (1090)</th><th>Power in mW</th><th>Frame exec. time in ms</th></tr></thead><tbody><tr><td>25</td><td rowspan="8">100</td><td>1</td><td>15608</td><td>47992</td><td>48170</td><td>203</td><td>391.73</td><td>44.85</td></tr><tr><td>26</td><td>2</td><td>28745</td><td>87339</td><td>89700</td><td>387</td><td>510.4</td><td>24.838</td></tr><tr><td>27</td><td>3</td><td>41882</td><td>126686</td><td>131230</td><td>571</td><td>618.42</td><td>17.854</td></tr><tr><td>28</td><td>4</td><td>43190</td><td>166033</td><td>172760</td><td>755</td><td>649.25</td><td>14.32</td></tr><tr><td>29</td><td>1</td><td>16625</td><td>44339</td><td>48591</td><td>203</td><td>729.75</td><td>12.167</td></tr><tr><td>30</td><td rowspan="4">Pipe8</td><td>2</td><td>30357</td><td>80033</td><td>90533</td><td>387</td><td>650.15</td><td>16.596</td></tr><tr><td>31</td><td>3</td><td>44089</td><td>115727</td><td>132475</td><td>571</td><td>813.63</td><td>11.927</td></tr><tr><td>32</td><td>4</td><td>43605</td><td>151421</td><td>174417</td><td>755</td><td>837.69</td><td>9.565</td></tr><tr><td>33</td><td>1</td><td>16278</td><td>48644</td><td>53711</td><td>203</td><td>548.49</td><td>22.574</td></tr><tr><td>34</td><td rowspan="3">200</td><td>2</td><td>30001</td><td>88643</td><td>100770</td><td>387</td><td>777.02</td><td>12.494</td></tr><tr><td>35</td><td>3</td><td>43724</td><td>128642</td><td>147829</td><td>571</td><td>993.97</td><td>8.976</td></tr><tr><td>36</td><td>4</td><td>48722</td><td>168641</td><td>194888</td><td>755</td><td>1092.14</td><td>7.196</td></tr><tr><td>37</td><td rowspan="8">100</td><td>1</td><td>26073</td><td>67071</td><td>66804</td><td>275</td><td>475.8</td><td>30.965</td></tr><tr><td>38</td><td>2</td><td>49292</td><td>125497</td><td>126967</td><td>531</td><td>652.76</td><td>17.854</td></tr><tr><td>39</td><td>3</td><td>46783</td><td>183923</td><td>187130</td><td>787</td><td>674.48</td><td>12.774</td></tr><tr><td>40</td><td>1</td><td>24133</td><td>61240</td><td>69833</td><td>275</td><td>567.12</td><td>20.693</td></tr><tr><td>41</td><td rowspan="3">Pipe12</td><td>2</td><td>45392</td><td>113835</td><td>133017</td><td>531</td><td>818.27</td><td>11.927</td></tr><tr><td>42</td><td>3</td><td>49051</td><td>166430</td><td>196201</td><td>787</td><td>893.56</td><td>8.531</td></tr><tr><td>43</td><td>1</td><td>22127</td><td>67339</td><td>68978</td><td>275</td><td>646</td><td>15.581</td></tr><tr><td>44</td><td rowspan="2">200</td><td>2</td><td>41461</td><td>126033</td><td>131286</td><td>531</td><td>957.05</td><td>8.976</td></tr><tr><td>45</td><td>3</td><td>48399</td><td>184727</td><td>193594</td><td>787</td><td>1093.59</td><td>6.418</td></tr></tbody></table>
<figure><img src="image_10.png" /><figcaption>FIGURE 9: The estimation percentage error for slice, LUT, and FF when compared to the measured values.</figcaption></figure>

<figure><img src="image_11.png" /><figcaption>FIGURE 10: The estimation percentage error for frame execution time when compared to the measured values.</figcaption></figure>

### 7.4. Comparison.
Table 6 compares between our tool ViPar and other tools in the literature that are used for high-level exploration for video processing applications. In very high-level synthesis tool (VHLS) [37], algorithms are described in Matlab or OpenCL. The synthesis of Matlab-to-RTL is explored to change the vector-oriented source code into the scalar-oriented program. While the intermediate code is represented by using control and data-flow graphs (CDFG). Finally, the generated code is classically synthesized via control and data-flow extraction and RTL generation processes. Two applications were tested: Kubelka-Munk genetic algorithm (KMGA) [39] for the multispectral image-based skin lesion assessments and level set method (LSM) [40] for very high-resolution satellite image segmentation. The experimental results showed that the design complexity for VHLS version is 50% less than its equivalent in C code. Algorithms in Lin-Analyzer [27] are written in C/C++. It explores the design space of the application when different high-level optimizations are added like loop unrolling, loop pipelining, array partitioning, and so on. For each design point, the FPGA performance metrics are estimated. The

<figure><img src="image_12.png" /><figcaption>FIGURE 11: The estimation percentage error for power consumption when compared to the measured values.</figcaption></figure>

<figure><img src="image_13.png" /><figcaption>FIGURE 12: Estimated and measured power for different designs.</figcaption></figure>

<figure><img src="image_14.png" /><figcaption>FIGURE 13: Radar chart for designs #7, #31, #42, #43, and system constraints.</figcaption></figure>

required time for exploration ranges from seconds to minutes. In [38], algorithms are represented as dataflow graphs written in RVC-CAL language [41]. The graph nodes
<table><caption>TABLE 6: Comparing between different high-level tools for video processing application.</caption><thead><tr><th></th><th>VHLS [37]</th><th>Lin-Analyzer [27]</th><th>RVC [38]</th><th>ViPar</th></tr></thead><tbody><tr><th>Programming language</th><td>Matlab or OpenCL</td><td>C/C++</td><td>RVC-CAL language</td><td>C/C++</td></tr><tr><th>Exploration level</th><td>Exploring Matlab-to-RTL synthesis</td><td>Exploring the design space for different optimization directives like loop unrolling, pipelining, ...</td><td>Exploring data-flow algorithms to C-based synthesis</td><td>Exploring the design space for parallelism level, operating frequency, power consumption, hardware cost, ...</td></tr><tr><th>Applications</th><td>KMGA LSM</td><td>Convolution 3D</td><td>HEVC decoder</td><td>Multiwindow SAD</td></tr></tbody></table>

are represented by the computational units that communicate concurrently, while the arcs represent the data flowing as tokens along unbounded FIFO channels. The dataflow-based video processing algorithm is then compiled by Open RVC-CAL compiler to generate a C-based code, which is then fed to a high-level synthesis (HLS) tool for generating a synthesizable hardware implementation. HEVC decoder was considered as the case study in [38].

Table 7 compares between the HLS implementation generated by ViPar tool versus handwritten VHDL implementation for two applications: video downscaler (16:1) and convolution filter of kernel size = 3 × 3. For video downscaler, 6 parallel processing elements were implemented, where 2 PEs were located for each colour channel. While for the convolution filter, 6 PEs were dedicated for each colour channel with a total number of 18 PEs. From the synthesis results, the hardware cost is almost similar for both HLS and handwritten VHDL implementations with difference range between 3 and 50% for different hardware resources.

## 8. Conclusion and Future Works

In this paper, we presented ViPar as a tool for high-level design space exploration dedicated for video applications. First, we introduced a parameterizable model for describing parallel video processing architectures. Second, high-level optimizations were used to obtain an efficient hardware processing element in terms of hardware utilization and frame rate. Third, ViPar tool was used to explore rapidly the design space at high design level before going into the step of detailed implementation. In order to compare between different design points in ViPar tool, we derived the required equations for estimating the power consumption, hardware utilization, and frame execution time. At the last step, by describing the parallel hardware architecture of the candidate designs in the specification file, ViPar tool was able to generate automatically the corresponding parallel architecture for synthesis and experimental evaluation. In the experimental results, 5-window SAD stereo matching was explored as our industrial case study. The design space consisted of different points varying in parallelism level, operating frequency (100, 150, or 200 MHz), and the processing pipeline (pipe4, pipe8, or pipe12). Throughout this example, we demonstrated how ViPar tool could explore the design space for the candidate designs which meet our system constraints. ViPar tool estimates the performance parameters at high design level as well as generating

<table><caption>TABLE 7: Comparing HLS and hand-written VHDL implementations for video downscaler (16:1) and convolution filter.</caption><thead><tr><th></th><th>FF</th><th>LUT</th><th>BRAM_18K</th></tr></thead><tbody><tr><th>HLSVideo_downscaler</th><td>1362</td><td>2022</td><td>15</td></tr><tr><th>VHDLVideo_downscaler</th><td>2052</td><td>1753</td><td>12</td></tr><tr><th>HLS Convolutions_filter</th><td>4968</td><td>5958</td><td>9</td></tr><tr><th>VHDL Convolutions_filter</th><td>5136</td><td>3925</td><td>9</td></tr></tbody></table>

automatically their corresponding parallel architectures for hardware implementation.

As future works, we will extend ViPar tool to consider the case of multiapplication design space exploration. In this situation, we have multiapplication multiobjective design space exploration problem where we will search for a feasible solution that satisfies the global system constraints in terms of performance, area utilization, and power consumption. Self-adaptivity for video applications like in autonomous vehicles is another case where some image filters could replace each other to adapt to the environmental changes. ViPar can be used to explore the possible hardware architectures to satisfy these scenarios of filter replacements.

## Data Availability

The data used to support the findings of this study are available from the corresponding author upon request.

## Disclosure

An earlier version of this work has been presented as a thesis in Université de Valenciennes et du Hainaut-Cambresis at the following link: https://tel.archives-ouvertes.fr/tel-01791649/document.

## Conflicts of Interest

The authors declare that there are no conflicts of interest regarding the publication of this paper.

## References

[1] M. Zablocki, K. Gosciewska, D. Frejlichowski, and R. Hofman, "Intelligent video surveillance systems for public spaces—a survey," *Journal of Theoretical and Applied Computer Science*, vol. 8, no. 4, pp. 13–27, 2014.

[2] Y. Cong, J. Yuan, and Y. Tang, "Video anomaly search in crowded scenes via spatio-temporal motion context," *IEEE
*Transactions on Information Forensics and Security*, vol. 8, no. 10, pp. 1590–1599, 2013.

[3] S. Vishwakarma and A. Agrawal, “A survey on activity recognition and behavior understanding in video surveillance,” *The Visual Computer*, vol. 29, no. 10, pp. 983–1009, 2013.

[4] W. Jiang, C. Xiao, H. Jin, S. Zhu, and Z. Lu, “Vehicle tracking with non-overlapping views for multi-camera surveillance system,” in *Proceedings of the 2013 IEEE 10th International Conference on High Performance Computing and Communications 2013 IEEE International Conference on Embedded and Ubiquitous Computing*, pp. 1213–1220, IEEE, Zhangjiajie, China, November 2013.

[5] K. C. Dey, A. Mishra, and M. Chowdhury, “Potential of intelligent transportation systems in mitigating adverse weather impacts on road mobility: a review,” *IEEE Transactions on Intelligent Transportation Systems*, vol. 16, no. 3, pp. 1107–1119, 2015.

[6] J. Zhang, F.-Y. Wang, K. Wang, W.-H. Lin, X. Xu, and C. Chen, “Data-driven intelligent transportation systems: a survey,” *IEEE Transactions on Intelligent Transportation Systems*, vol. 12, no. 4, pp. 1624–1639, 2011.

[7] F. Erden, S. Velipasalar, A. Z. Alkar, and A. E. Cetin, “Sensors in assisted living: a survey of signal and image processing methods,” *IEEE Signal Processing Magazine*, vol. 33, no. 2, pp. 36–44, 2016.

[8] S. Fleck and W. Straber, “Smart camera based monitoring system and its application to assisted living,” *Proceedings of the IEEE*, vol. 96, no. 10, pp. 1698–1714, 2008.

[9] L. Bampis and A. Gasteratos, “Revisiting the bag-of-visual-words model: a hierarchical localization architecture for mobile systems,” *Robotics and Autonomous Systems*, vol. 113, pp. 104–119, 2019.

[10] G. Grisetti, R. Kummerle, C. Stachniss, and W. Burgard, “A tutorial on graph-based slam,” *IEEE Intelligent Transportation Systems Magazine*, vol. 2, no. 4, pp. 31–43, 2010.

[11] A. Amanatiadis, E. Karakasis, L. Bampis, S. Ploumpis, and A. Gasteratos, “Viped: On-road vehicle passenger detection for autonomous vehicles,” *Robotics and Autonomous Systems*, vol. 112, pp. 282–290, 2019.

[12] C. Patruno, R. Marani, M. Nitti, T. D’Orazio, and E. Stella, “An embedded vision system for real-time autonomous localization using laser profilometry,” *IEEE Transactions on Intelligent Transportation Systems*, vol. 16, no. 6, pp. 3482–3495, 2015.

[13] M. Omidyeganeh, S. Shirmohammadi, S. Abtahi et al., “Yawning detection using embedded smart cameras,” *IEEE Transactions on Instrumentation and Measurement*, vol. 65, no. 3, pp. 570–582, 2016.

[14] P. Cooke, J. Fowers, G. Brown, and G. Stitt, “A tradeoff analysis of FPGAs, GPUs, and multicores for sliding-window applications,” *ACM Transactions on Reconfigurable Technology and Systems*, vol. 8, no. 1, pp. 1–24, 2015.

[15] A. Severance and G. G. F. Lemieux, “Embedded supercomputing in FPGAs with the VectorBlox MXP matrix processor,” in *Proceedings of the 2013 International Conference on Hardware/Software Codesign and System Synthesis (CODES+ISSS)*, pp. 1–10, IEEE, Montreal, QC, Canada, September 2013.

[16] G. Hegde and N. Kapre, “Energy-efficient acceleration of openCV saliency computation using soft vector processors,” in *Proceedings of the 2015 IEEE 23rd Annual International Symposium on Field-Programmable Custom Computing Machines*, pp. 76–83, IEEE, Vancouver, BC, Canada, May 2015.

[17] V. Brost, F. Yang, and C. Meunier, “Flexible VLIW processor based on FPGA for efficient embedded real-time image processing,” *Journal of Real-Time Image Processing*, vol. 9, no. 1, pp. 47–59, 2014.

[18] K. Andryc, M. Merchant, and R. Tessier, “FlexGrip: a soft GPGPU for FPGAs,” in *Proceedings of the 2013 International Conference on Field-Programmable Technology (FPT)*, pp. 230–237, Kyoto, Japan, December 2013.

[19] M. Al Kadi, B. Janssen, and M. Huebner, “FGPU: an SIMT-Architecture for FPGAs,” in *Proceedings of the 2016 ACM/SIGDA International Symposium on Field-Programmable Gate Arrays, FPGA’16*, pp. 254–263, ACM, New York, NY, USA, 2016.

[20] M. A. Kadi and M. Huebner, “Integer computations with soft GPGPU on FPGAs,” in *Proceedings of the 2016 International Conference on Field-Programmable Technology (FPT)*, pp. 28–35, IEEE, Xi’an, China, December 2016.

[21] A. Prost-Boucle, O. Muller, and F. Rousseau, “Fast and standalone design space exploration for high-level synthesis under resource constraints,” *Journal of Systems Architecture*, vol. 60, no. 1, pp. 79–93, 2014.

[22] A. Sengupta and R. Sedaghat, “Integrated scheduling, allocation and binding in high level synthesis using multi structure genetic algorithm based design space exploration,” in *Proceedings of the 2011 12th International Symposium on Quality Electronic Design*, pp. 1–9, IEEE, Santa Clara, CA, USA, March 2011.

[23] B. C. Schafer, “Probabilistic multiknob high-level synthesis design space exploration acceleration,” *IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems*, vol. 35, no. 3, pp. 394–406, 2016.

[24] B. C. Schafer, “Enabling high-level synthesis resource sharing design space exploration in fpgas through automatic internal bitwidth adjustments,” *IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems*, vol. 36, no. 1, pp. 97–105, 2017.

[25] N. K. Pham, A. K. Singh, A. Kumar, and M. M. A. Khin, “Exploiting loop-array dependencies to accelerate the design space exploration with high level synthesis,” in *Proceedings of the 2015 Design, Automation Test in Europe Conference Exhibition (DATE)*, pp. 157–162, IEEE, Grenoble, France, March 2015.

[26] C. Lo and P. Chow, “Model-based optimization of high level synthesis directives,” in *Proceedings of the 2016 26th International Conference on Field Programmable Logic and Applications (FPL)*, pp. 1–10, IEEE, Lausanne, Switzerland, August 2016.

[27] G. Zhong, A. Prakash, Y. Liang, T. Mitra, and S. Niar, “Lin-Analyzer: a high-level performance analysis tool for FPGA-based accelerators,” in *Proceedings of the 2016 53rd ACM/EDAC/IEEE Design Automation Conference (DAC)*, pp. 1–6, IEEE, Austin, TX, USA, June 2016.

[28] X. Gao and T. Yoshimura, “Genetic algorithm based pipeline scheduling in high-level synthesis,” in *Proceedings of the 2013 IEEE 10th International Conference on ASIC*, pp. 1–4, IEEE, Shenzhen, China, October 2013.

[29] A. Mahapatra and B. C. Schafer, “Machine-learning based simulated annealer method for high level synthesis design space exploration,” in *Proceedings of the 2014 Electronic System Level Synthesis Conference (ESLsyn)*, pp. 1–6, IEEE, San Francisco, CA, USA, May 2014.

[30] H.-Y. Liu and L. P. Carloni, “On learning-based methods for design-space exploration with high-level synthesis,” in *Proceedings of the 2013 50th ACM/EDAC/IEEE Design*
*Automation Conference (DAC)*, pp. 1–7, Austin, TX, USA,
May 2013.

[31] D. Scharstein and R. Szeliski, “A taxonomy and evaluation of dense two-frame stereo correspondence algorithms,” *International Journal of Computer Vision*, vol. 47, no. 1–3, pp. 7–42, 2002.

[32] H. Hirschmuller, “Improvements in real-time correlation-based stereo vision,” in *Proceedings of the IEEE Workshop on Stereo and Multi-Baseline Vision (SMBV 2001)*, pp. 141–148, IEEE, Kauai, HI, USA, December 2001.

[33] M. J. McDonnell, “Box-filtering techniques,” *Computer Graphics and Image Processing*, vol. 17, no. 1, pp. 65–70, 1981.

[34] K. M. A. Ali, R. Ben Atitallah, S. Hanafi, and J.-L. Dekeyser, “A generic pixel distribution architecture for parallel video processing,” in *Proceedings of the 2014 International Conference on Reconfigurable Computing and FPGAs (ReConFig)*, pp. 1–8, Cancun, Mexico, December 2014.

[35] K. M. Ali, R. B. Atitallah, N. Fakhfakh, and J.-L. Dekeyser, “Exploring hls optimizations for efficient stereo matching hardware implementation,” in *Proceedings of the International Symposium on Applied Reconfigurable Computing*, pp. 168–176, Springer, Delft, The Netherlands, April 2017.

[36] F. Sun, H. Wang, F. Fu, and X. Li, “Survey of FPGA low power design,” in *Proceedings of the 2010 International Conference on Intelligent Control and Information Processing*, pp. 547–550, IEEE, Dalian, China, August 2010.

[37] Y. Bi, C. Li, and F. Yang, “Very high level synthesis for image processing applications,” in *Proceedings of the 10th International Conference on Distributed Smart Camera, ICDSC ’16*, pp. 160–165, ACM, New York, NY, USA, 2016.

[38] M. Abid, K. Jerbi, M. Raulet, O. Déforges, and M. Abid, “Efficient system-level hardware synthesis of dataflow programs using shared memory based

[39] R. Jolivot, Y. Benezeth, and F. Marzani, “Skin parameter map retrieval from a dedicated multispectral imaging system applied to dermatology/cosmetology,” *Journal of Biomedical Imaging*, vol. 2013, Article ID 978289, 15 pages, 2013.

[40] S. Balla-Arabe, X. Gao, B. Wang, F. Yang, and V. Brost, “Multi-kernel implicit curve evolution for selected texture region segmentation in vhr satellite images,” *IEEE Transactions on Geoscience and Remote Sensing*, vol. 52, no. 8, pp. 5183–5192, 2014.

[41] J. Eker and J. W. Janneck, *Janneck J: Cal Language Report: Specification of the Cal Actor Language*, University of California, Berkeley, CA, USA, 2003.
<figure><img src="image_15.png" /></figure>

<figure><img src="image_16.png" /></figure>

<figure><img src="image_17.png" /></figure>

<figure><img src="image_18.png" /></figure>

<figure><img src="image_19.png" /></figure>

<figure><img src="image_20.png" /></figure>

<figure><img src="image_21.png" /></figure>

<figure><img src="image_22.png" /></figure>

<figure><img src="image_23.png" /></figure>

<figure><img src="image_24.png" /></figure>

<figure><img src="image_25.png" /></figure>

<figure><img src="image_26.png" /></figure>

Hindawi

Submit your manuscripts at
www.hindawi.com

<figure><img src="image_27.png" /></figure>

<figure><img src="image_28.png" /></figure>

<figure><img src="image_29.png" /></figure>

<figure><img src="image_30.png" /></figure>

<figure><img src="image_31.png" /></figure>

<figure><img src="image_32.png" /></figure>

<figure><img src="image_33.png" /></figure>

<figure><img src="image_34.png" /></figure>