Table 1: Instruction sequence for an inverse Fast Fourier transform
ISS and executable software have been demonstrated to be ineffective in evaluating the metrics of an optimal architecture. 1000 lines of code will simply repeat a small set of instructions, thus providing very little variability. Table 1 shows the instruction sequence for a 1000 lines of code. This is especially true for DSP and data flow code. Control logic has little more diversity but still the sequence is not different.
Emulating software operations
A number of good alternatives exist to emulate software operation for architecture exploration. System modeling experience shows that three types of software modeling work quite well. At a statistical-level, a delay value for each function is sufficient to trigger the traffic on the bus and the memory devices. At the hardware-level, an application-specific instruction allocation called instruction-mix table provides an extremely accurate representation of a software task. The last method is to annotate performance-intensive portions of the code and generate instruction trace during execution. This last technique is good to test the architecture behavior for a benchmark or set of benchmarks. This is also good to evaluate how a piece of code will behave in a multi-core environment.
The first approach requires a table with the name of the task and the associated delay. During execution, the processor model does a table lookup and based on the task (A_Task_Name in Table 2) from the RTOS delays the processor based on the number and type of instructions in the task.
Table 2: Instruction mix table for a software task
The application-specific instruction allocation technique is the most versatile and can be used for software testing, hardware