# Improving Symbolic System-Level Synthesis by Solver Coordination and Domain-Specific Heuristics
## 8 Experimental Results
### Test Instances  
The NoC-based hardware platforms of our test cases were regular \(N\times N\) 2D-meshes with \(N\in\{3,4,5,6\}\) such that a platform contained \(N^{2}=\{9,16,25,36\}\) tiles in total. The resources of the platform (PEs, routers,...) were selected to be homogeneous. Thus, all computational tasks had the same WCET on all tiles and all packets were forwarded on the resources of the NoC within the same delay (\(\forall A_{i}\in\mathbf{A}:\forall\lambda\in(\mathbf{T}_{i}^{t}\cup\mathbf{T}_{i }^{m}):\forall r,\tilde{r}\in\mathbf{R}:C_{\lambda}^{r}=C_{\lambda}^{t}\)). The delay of all packets was set to 10 cycles on all NIs and routers (\(\forall r\in(\mathbf{R}_{ni}\cup\mathbf{R}_{rtr}):C_{p}^{r}=10\)). In order to convert time, e.g., computational time or periods of computational tasks and messages, into clock cycles of the hardware platform we used a common frequency of \(f=200\) MHz in available micro controllers for automotive or industrial applications [2]. The applications in our test cases are of synthetic nature and we do not rely on open-source benchmarks. There are two main reasons for this. First, massively parallel platforms cannot be computationally utilized in a meaningful way with control software that is running on current multi-core embedded systems. Thus, with multi-core software characteristics such as described in [39], the vast bulk of the hardware platform would be in idle state. As a remedy, our applications are oriented on the characteristics of state-of-the-art control software [39] (periods, amount of inter-task communication,...) but extrapolate towards higher system utilization. Second, to the best to the authors' knowledge, there is no published open-source benchmark for automotive control applications that respects the parameters described in [39] and allows us to systematically investigate scalability of our proposed methods. Also, note that we rather need a scheme that allows us to increase the computational utilization and total number of messages along with the increase in the size of our tiled mesh hardware architectures, rather than plain benchmark instances. In the following, we summarize the scheme we used to create synthetic test cases for a systematic evaluation of our approach. The source code of an implementation of this scheme together with the test cases that are investigated in this work can be obtained by mailing the paper's last author. In order to generate the applications to be executed on a given platform with \(N^{2}\) tiles, we applied an algorithm including randomization in order to achieve diversity of the test cases within certain limits. As an important parameter in our generation scheme, the utilization factor \(U_{fact}\in\{50\%,60\%,70\%\}\) defines the percentage the overall computational resources of the platform, i.e., all PEs, are utilized. For each of our test cases, we incrementally added randomized applications \(A_{i}\) to the system until the total computational load of the system \(U_{sys}\) reached the desired overall computational load:  
\[U_{sys}=\sum_{A_{i}\in\mathbf{A}_{i}\in\mathbf{T}^{t}}\frac{C_{t}}{P_{i}}=U_{ fact}\cdot N^{2}. \tag{3}\]  
To generate the TTSP graph topology of one randomized application \(A_{i}=(g_{i}^{A},P_{i},D_{i})\in\mathbf{A}\), we choose a simplified scheme based on five templates to create new TTSP graphs. Three of these templates are shown in Figure 4 as the yellow shaded TTSP graphs, whereas the two remaining templates are two TTSP graphs with three computational tasks in parallel, respectively, four parallel computational tasks in parallel. As a first step, one topology template was chosen randomly out of the set of five predefined template TTSP graphs. Then, each computational tasks that is not a sink or a source of the chosen TTSP template was replaced by a sub-graph that was at random either one of the TTSP templates or a single computational task.