C8051F120 Debug simulation on Keil

"when you have just one prototype" = this is not important.

Not necessarily. When you have a circuit that is very expensive, e.g. like medical instrumentation, you may have just one prototype to play with until very late in the development cycle. And sometimes you simply can't get access to the real end-use environment.

Even for medium to high volume you may start with just a few prototypes. Normally our hardware prototypes run in 2 or 3 phases. The first one is composed of early testbeds, where all hardware ideas are combined and tested. These are not for destructive testing, but for early software and hardware validation. They are usually soldered using hand-operated stations, so they are dearly precious. When the hardware is mature you make a definitive run with a small pre-production lot, to test the product. This is done via the full production pipeline, and will need pick'n'place setup, oven profiling, and may take a few weeks. You don't want to do project iterations on this phase.

Of course you do predictive design, plan for failsafe and such, but often you have to test your weak points with a few specific test vectors, like the ones that will happen for a few circuit single failures. The simulator will help you then, if you spent the time to setup a simulation framework. An alternative approach is guesswork and prayers.

Another real-life example: in a recent product I designed a fault-tolerant eeprom data error detection and correction subsystem, for high-reliability critical equipment. The system needed to be tested with several hardware fault error conditions that were very difficult to test in real hardware, like retention failure modes in the flash cells of eeproms, and EMI bursts in SPI lines. The simulator was invaluable during development. The hardware verification took much longer, because I had to burn-out eeprom bits in very specific patterns, for over 6 million cycles to prepare the failed eeprom chips. It took weeks to verify a few days of design. Moreover, the final harsh environment testing did not give answers that I could use during development, since it generally burned the chips with several watts of RF energy.

I am not saying that the sim will give you all the answers, eliminating the real hardware verification. Like SPICE and VHDL simulation, it will speed up your dev cycles, if you use it well. Of course it has limitations and sometimes will not give the exact hardware behavior, for example. But good simulation engine is important, and is something that I rate highly when selecting a new development environment.

"when you have just one prototype" = this is not important.

Not necessarily. When you have a circuit that is very expensive, e.g. like medical instrumentation, you may have just one prototype to play with until very late in the development cycle. And sometimes you simply can't get access to the real end-use environment.

Even for medium to high volume you may start with just a few prototypes. Normally our hardware prototypes run in 2 or 3 phases. The first one is composed of early testbeds, where all hardware ideas are combined and tested. These are not for destructive testing, but for early software and hardware validation. They are usually soldered using hand-operated stations, so they are dearly precious. When the hardware is mature you make a definitive run with a small pre-production lot, to test the product. This is done via the full production pipeline, and will need pick'n'place setup, oven profiling, and may take a few weeks. You don't want to do project iterations on this phase.

Of course you do predictive design, plan for failsafe and such, but often you have to test your weak points with a few specific test vectors, like the ones that will happen for a few circuit single failures. The simulator will help you then, if you spent the time to setup a simulation framework. An alternative approach is guesswork and prayers.

Another real-life example: in a recent product I designed a fault-tolerant eeprom data error detection and correction subsystem, for high-reliability critical equipment. The system needed to be tested with several hardware fault error conditions that were very difficult to test in real hardware, like retention failure modes in the flash cells of eeproms, and EMI bursts in SPI lines. The simulator was invaluable during development. The hardware verification took much longer, because I had to burn-out eeprom bits in very specific patterns, for over 6 million cycles to prepare the failed eeprom chips. It took weeks to verify a few days of design. Moreover, the final harsh environment testing did not give answers that I could use during development, since it generally burned the chips with several watts of RF energy.

I am not saying that the sim will give you all the answers, eliminating the real hardware verification. Like SPICE and VHDL simulation, it will speed up your dev cycles, if you use it well. Of course it has limitations and sometimes will not give the exact hardware behavior, for example. But good simulation engine is important, and is something that I rate highly when selecting a new development environment.