IP-core design methodology

This section presents the proposed design methodology supporting the designer from the al-gorithm modelling up to the system implementation. This methodology forces the designer to apply algorithm and hardware design optimizations in the proper design flow stage, ensuring to reach highly optimized IP-cores and to speed-up the overall design process.

Figure 4.1 shows the main steps composing this methodology.

Figure 4.1: IP-cores design flow

The first step to be done is the analysis of system specifications. Commonly, designers of com-plex system receive as main inputs different documents that specify the requirements in terms of functionalities, accuracy of the output results, interfaces, and performances in terms of speed and area occupation. These requirements are usually embedded in the following documents: In-terface Control Documents (ICDs), Design Requirement Documents (DRDs), and Design Require-ments List (DRL). In high complex systems, the information contained in these docuRequire-ments are integrated with Technical Notes (TNO), that provide additional technical constraints concerning some peculiar parts of the system.

As shown in Figure 4.1, after the system requirements analysis, it is possible to proceed with the Algorithm Selection phase. This phase aims at comparing the requirements with the char-acteristics of algorithms providing the needed functionality. It starts with the study and analysis of literature to identify suitable algorithms for the target application. Then, it proceeds with the execution of different tests on the identified algorithms, exploiting algorithm models and signifi-cant image datasets (Section 4.2), and it ends with the selection of the algorithm which accuracy and complexity is closest to the system requirements.

The selected algorithm is then characterized executing the Algorithm Characterization task.

This aims at tuning the internal algorithm parameters and, when needed, to modify parts of the algorithm, in order to meet the requirements in terms of results accuracy.

As shown in Figure 4.2, this phase requires as inputs: an algorithm model (i.e., an algorithm de-scription in a high level programming language, e.g., C/C++ codes or MATLAB scripts), and a significant image dataset to properly characterize the selected algorithm.

Figure 4.2: Algorithm characterization flow

To ease the selection of the most suitable image dataset, on the web a lot of freely downloadable datasets have been classified depending on the targeting image processing application (an exam-ple of classification can be found in [73]). For some applications, in order to furtherly increase the precision of the algorithm characterization, in the selected dataset are added a comprehensive set of pictures, acquired in different environmental and image conditions (i.e., different contrast, illumination, and blur conditions), representing the environment in which the algorithm has to operate.

The core operation of the Algorithm Characterization phase is a loops that iteratively provides in

input to the algorithm model the images composing the selected dataset, and extracts the output results. The output results are parameters that objectively quantify the accuracy of the obtained results. Some example of these parameters are the number of extracted features for a features extraction algorithm (Section 2.5.1.1), or the Peak Signal to Noise Ratio (PSNR) [82] for a noise filtering algorithm.

For each iteration the extracted parameters are compared with the requirements. If the obtained results are aligned with the requirements, no modification are applied to the algorithm, other-wise, the internal algorithm parameters are modified, and a new iteration started.

However, in some cases, a simple modification of the internal parameters cannot ensure to meet the required performances, especially in terms of adaptability to the environmental and image conditions. For this reasons, customization of some part of the algorithm are required to fulfil all requirements.

The outcome of this phase is a customized version of the selected algorithm that completely fits the system requirements.

Then, the customized algorithm model and the image dataset are provided in input to the Hardware Characterization phase. The main purpose of this phase is the definition of the data representation (i.e., data format and size) to be used in the hardware implementation.

Figure 4.3: Hardware characterization flow

This is a really important phase, since it can strongly affect both the result accuracy and the hard-ware resources usage, especially when fractional numbers are involved in the algorithm compu-tation.

The representation of fractional numbers in a hardware component can be obtained through ei-ther the floating point or the fixed point formats. From the one hand, the selection of floating

points representation allows to achieve really high accuracy but, at the same time, it increases the complexity, and so the hardware resources usage. From the other hand, fixed point represen-tation enables to reduce the hardware complexity, but it does not guarantee high precision for every number range.

Since in space application high accuracy and low hardware resources usage are two key fac-tors, the Hardware Characterization phase guides the designer in the selection of the data for-mat (i.e., integer, floating point or fixed-point) and size (i.e., size of each data in terms of bit) to achieve the same accuracy of the customized algorithm model, while maintaining the hardware resources usage as low as possible.

To achieve this goal, as shown in Figure 4.3, a hardware model has to be created. This hardware model, implemented as a MATLAB script, is a high level description of the algorithm exploit-ing the same data representation that will be used in the hardware implementation. MATLAB scripts have been selected since, differently from others high level programming and scripting languages, provides the Fixed Point toolbox [134] that eases the modelling of computation in fixed-point precision.

As for the Algorithm characterization, an iterative optimization task is done (Figure 4.3). At the beginning, in the algorithm model, all data are represented involving the lowest precision repre-sentation. Then, for each iteration, output results obtained providing the image dataset in input to the algorithm and hardware models are compared to find differences. If no differences are found, the data representation and format adopted in the hardware model can be considered valid, otherwise the data representation is modified to slightly increase the representation accu-racy, and a new iteration is done. This operation is repeated until the representation error has been confined in the desired range.

The last phase of the proposed methodology, called Hardware implementation, guides the designer in the mapping of the customized algorithm on an FPGA device, in order to obtain the implemented hardware component. This phase receives in input the hardware model in order to efficiently implement the customized algorithm in the FPGA device. During this implementation phase, a particular effort has to be spent on the architectural decisions to ensure the maximiza-tion of the timing performances, and so to meet the strict real-time constraint imposed by space applications.

As can be noted from the reported description, the main outcomes of the proposed method-ology are the Algorithm Model, the Hardware Model, and the Hardware Implementation. As will be described in Section 4.2, these are three fundamental components to ease the verification and validation of the implemented IP-cores.