ASIC emulator board

The intention of this section is to give a brief overview on the whole framework, since the remainder of this chapter will focus exclusively on a single aspect, namely the automatic synthesis of a behavioral specification down to the ASIC emulator board. If the emulation demonstrates that an overall performance increase will be obtained through the realization of corresponding system submodules by an ASIC, other synthesis tools (such as Cathedral or Amical, described in chapters 7 and 9) have to be used to derive a final chip solution replacing the emulator. 

Structural synthesis comprises another group of transformations to be executed on the submitted flow graph. The main tasks to be solved are scheduling, allocation, and binding. The flow graph format cannot be maintained during those steps, since more and more structural information will be derived. The final output after structural synthesis will be all information necessary to customize the ASIC emulator board. 

All the synthesis steps mentioned above can be executed either automatically or interactively. The programmed ASIC emulator can be inserted directly into the overall mechatronic system to facilitate real-time test runs. In the following, all main synthesis steps will be described in the same top-down sequence as they are implemented through the synthesis script. Throughout the rest of the chapter, the terms ASIC emulator (board), rapid prototyping board, and target architecture will be used synonymously. 

After behavioral synthesis, a transformed and optimized flow graph is available, which still does not include any explicit structural information (except module-type proposals for background memory and constraints specified in the input description). The goal of the consecutive structural synthesis process is to transform this flow graph information into an actual implementation that can be executed on the ASIC emulator board. The main steps to be carried out are scheduling, allocation, and binding. The results will again be illustrated by means of the DHRC-benchmark. 

Table 2 Results of DHRC example after mapping onto the ASIC emulator board. SMstatic are static connections which do not change during runtime. SMdynamic are dynamic connections.

When binding is finished, all information is available for programming CBBs and state machines. The ASIC emulator can be customized and control code can be generated. In order to keep the controller complexity as low as possible, all loops are unrolled at the end of binding. This procedure is justifiable, since the size of the ASIC emulator has no relation to the final ASIC implementation. Note that the goal is to get some performance indications with this board. 

---