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