Hi,
I use Keil to simulate C8051F120 but I cannot view the all peripherals of MCU (No hardware debug). I can view all peripherals if I use C8051F005. Anyone know about it? Am I missing something?
Thanks, pak
"if you are a 'software only' guy, the that may be different, but that would hamper you in many other ways when doing small embedded?"
Well, if you are a 'software only' guy it will probably be harder for you to tackle an embedded design from head to toe.
My point in this discussion is that the simulator is a very good tool in the development flow. Both the simulator and the on-chip debugger are important in different phases of the system debug and verification.
For example, during development the simulator allows you to feed specific complex patterns to a system using signal functions. You can isolate the software component being tested, sometimes impossible in the full running hardware. This setup is extremely versatile, and can be used to test the system in conditions unfeasible/difficult to setup in real hardware. Also, it allows to test for a variety of 'noise' stimuli under very controlled conditions. On the same token, the on-chip debugger could be used to validate and verify the simulation tests on real hardware.
For example, I use the simulator to predict failsafe conditions on several external failures that would be expensive to test when you have just one prototype of the hardware. These are then verified in the pilot stress and destructive testing.
In addition to that, a good set of bench equipment are also invaluable. I use a multitrace digital storage oscilloscope much more than the on-chip debug after the thing learned to walk and talk. Especially in the 8051, I always have a few pins used as hardware debug flags to monitor and validate the real hardware response.
I totally do not understand arguments like this: "predict failsafe conditions" = important product "when you have just one prototype" = this is not important.
Erik
"when you have just one prototype" = this is not important.
A while back I worked on a diesel locomotive performance analyzer. I had to test the entire thing with simulation. Why? Because I did not have 24/7 access to a diesel locomotive-even though I am an engineer :-)
Many of the systems I have worked on REQUIRED that everything be tested thoroughly under simulation. This was because the system being controlled cost hundreds of thousands or even millions of dollars. And, a run-away controller could destroy a very, very expensive piece of equipment or cause large-scale loss of life.
In any case, MOST of the really important systems I have created or worked on had only one or two prototypes. Typically, due to complexity or cost.
Jon
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.