We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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
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.
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.