Guideline Generation Methodology Clause Samples

Guideline Generation Methodology. A key contribution of the TULIPP project is a workflow to produce guidelines. The require- ments of the workflow are that it should (a) generate guidelines for low power image process- ing, (b) evaluate the guidelines, and (c) be aligned with all project objectives. The workflow is illustrated in Figure 19. As evident from the illustration, the workflow captures a project-wide effort towards a common vision. We explain the different steps involved in the workflow starting with the critical path next. Figure 19: The workflow to generate and evaluate guidelines that define the platform in- stance. The critical path is shown in red. such as those in the advisory board can also contribute with insights. Insights have no re- strictions on format and can be expressed in any enlightening manner. As a running example of the workflow, consider the insight expressed by an embedded sys- tems expert as a single line of text: Continuing the running example, the insight is translated into the following guideline: OS (RTOS) parameters [40]. Recommended implementation method: Configure the RTOS using vendor suggested methods [36]. Test and document candidate configurations extensively. An excerpt from a possible evaluation of the guideline formulated in the running example could read as follows: The medical image processing application missed 20/100 deadlines when the default Linux kernel 4.7.2 provided by Xilinx was used. No deadlines were missed under the HIP- ▇▇▇▇▇ RTOS configured with the Least Laxity First scheduling policy, but performance was restricted to 8 FPS, well under the required 24 FPS goal. Enabling multicore exe- cution (SMP) and a hybrid scheduling policy with both data locality and laxity awareness increased performance to 28 FPS with no deadlines missed – a clear win for HIPPEROS. their platforms to gain higher compliance. In the context of the project, technology improve- ments are delivered through the platform instance. Examples of potential technology improvements include application specific evaluation boards, high performance library routines and custom IP blocks for image processing, low power en- abling patches to RTOS schedulers, improved performance analysis techniques for Zynq SoC, workflow tweaks for Xilinx SDSoC etc. The workflow is not iterative since there are no feedback paths or cycles. Feedback is un- necessary since guidelines are based on proofs, facts and expertise. In addition to being feed-forward, the workflow proceeds in a pipe...