Every time the conversation on performance analysis and architecture exploration crops up, the questions turns to ISS or Instruction Set Simulator. ‘Do you have the ISS for XYZ processor?‘ This leads to a discussion on what is an ISS suitable for. Many EDA companies have developed ISSs, with the false promise of solving everything from software debugging and verifying the hardware, to auto-generating a board with all the peripherals pre-loaded. This gains an impression that the ISS is the solution for all your system development needs.
In reality, architectural exploration is an innovative choice to obtain results faster with quality results. An Instruction Set Simulator provides the user with the ability to load the Operating System and execute the compiled code. This is a good solution for early software debugging. It is not a good solution when you are experimenting or trying out new architectures such as a new bus topology, different memory hierarchy, or processor clock speed sizing. Moreover the OS and the executable are tied to one processor family. If you want to evaluate another processor family, or a processor with a different set of peripherals, you need to get a new ISS and recompile the entire code. Moreover, there is a significant lag between the processor release and the ISS availability. An alternate to an ISS is imperative code execution for architecture exploration.
Code execution presents a very specific sequence of instructions executing in a mostly repetitive fashion. In Table 1, one will see the instructions that execute for an inverse Fast Fourier transform of OFDM communication software. Notice how it is made up of a series of floating point add and a few branch instructions. If one is evaluating the architecture of a system, the first 20 instructions of this sequence are typically sufficient. The code has been written by one software engineer based on one standard. If the second part of this code is written to another standard with an entirely different structure, the instruction sequence will be slightly different.
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.