1.1.2.  Simulation

It is usual to create software for microprocessors not on these target systems for self-evident reasons, namely limited resources in memory and speed, often there is no operating system present. Development is done on different platforms like PCs or Workstations, where the environment is much more convenient. Using cross compiler and cross linker tools, code for the microprocessor machine can be generated. To transfer the program to the target platform either the help of a burner is utilized, if a connection between the development host and the target can be made – e. g. evaluation boards with serial interfaces – or the program is burnt directly into the ROM later in the production process. For testing purpose the first solution is the better one. Usually the ROM on an evaluation board is replaced with another sort of non-volatile memory – flash.

A simulator is used more often for testing than these hardware-solutions. An emulator, acting as the interface between the debugger and the evaluation board, has to provide 100% of the reaction of the target processor. It has to support debugging, to provide the ability of setting breakpoints, of reading memory and registers without changing the program counter and so on. A simulator has none of these restrictions. It is only software pretending to be a processor. All internal states and information can be achieved and even manipulated by the debugger. It is quite clear that an additional piece of software brings in new error possibilities, but it is the same with evaluation boards and emulators, which can contain errors, too. The real disadvantage of simulators is their speed, because the host system has to simulate all the actions occurring in the microprocessor in each cycle by software, meaning to copy or move data and to decide between different execution paths. Recent simulation techniques face this problem and make simulation faster and faster.

Now, as integrated systems cannot be physically debugged and tested, the whole SoC is to be simulated. What is usually simulated within a debugger is only the core processor. Regarding modern chips the core is rather a small module, not any more important than the other components. There are many components one can think of: complex timers with many stages and prescalers, digital-to-analogue and analogue-to-digital converters, signal generators, data transfer ports, implementing even whole protocols within the module, sophisticated memory with multi-access possibilities, watchdogs, externally triggered input and output ports and many more. Regarding the space occupied on a chip the processor with all its registers takes the smallest amount.

With simulation of whole SoCs the interaction between the components can be evaluated, timing problems can be determined and – embedding the simulator in a bigger environment – even the interaction with the rest of the world can be seen. The most thrilling possibility opened by SoC simulation for commercial customers is certainly the ability to write software for a system, including low-level drivers, before the first silicon for the chip comes out of the factory. This reduces the time-to-market for a system, because in the past the programming could not be started before the chip was there. And the time, it takes to program complex systems, of course cannot be ignored. With simulation a parallel development is possible after releasing the precise specifications of a system. While the hardware developer works on the detailed layout and refines the design, the customer can write his software and operating systems. The chip can be virtually integrated into the environment it should work in later. When, finally, the chip is physically available, only small adaptations have to be made where simulation differed from the real chip. Differences cannot be avoided, as certain effects in timing or electrical behavior are very difficult to simulate and would not be effective neither in performance nor in the resources needed to implement them.