Is simulation a reliable technology for micro-controllers?

Yes, it is. The most sophisticated integrated circuits present in the market today, with millions of transistors, are designed by using simulation technology. There are no "emulators" for such pieces of silicon... and they work. The reason why simulation has not been used too much today in microcontrollers designing is simply the lack of tools. There are tools in the market that simulate the software part of the application, but the interaction with the external I/O (hardware) is very poorly solved. This has pushed the users to use the ICE. Now there is a better way: Visual Micro Lab.

I plug my ICE in my circuit; it works; and all is fine. Why to use "virtual prototypes"?

You have to take into account how many things are not emulated correctly with your ICE

• Does your emulator match exactly the micro I/O, even in analog characteristics?
• How much does your emulator cost, and how much does VMLAB?
• Can your emulator do "analog trace", like having a digitizing scope?
• What about the ever smaller packages that micro-controllers have? How to handle them with an emulator?
• Can your emulator "step-by-step", or break the whole application?
• Does your emulator warn you in case of improper micro peripherals use?
• What about the day your emulator requires to be repaired?
• What about team-working? Do you need an emulator/test board per engineer?

VHDL is, indeed, a standard language for silicon design: ASIC's, systems-on-chip, etc., mainly used with logic synthesis tools. However, it is not very spread among the non-silicon designers, like traditional micro-controllers applications developers. In this community, the SPICE syntax is much more popular, due to the popular PSpice(TM), used by thousands of non-silicon PCB hardware designers. But there is still another reason: VMLAB intends to handle, as in the real life, mixed analog-digital hardware, with is not supported by VHDL.

None. VMLAB integrates the official freeware AVR assembler avrasm32.exe. Whenever it is necessary to call them, it spawns a process calling this original tool.

Sorry, no. With VMLAB you won't need emulators anymore. If you, nevertheless, wish to use  an ICE,  the best way is to use AVR Studio.

A lot of things! VMLAB has the ability to 'stop the time', impossible to achieve in a real situation. When working with an emulator, you could set a breakpoint at a particular address, but what about the rest of the hardware that surrounds the micro? This is of capital importance when developing closed loop control algorithms. In addition to this, VMLAB performs a lot of checks to insure the proper use of the CPU, and micro peripherals, which is not done in the real life. This insures that a lot of bugs may show up with Visual Micro Lab, that otherwise, they would remain hidden forever when designing with the traditional ICE approach.

Indeed, it is not real time, but it takes into account the time, accurately. You do not see things in real time, but the results waveforms, instructions trace, etc.,are the same that you would obtain in real time, if you would record them.

No problem!. To solve this, you just have to use a technique employed normally by silicon designers: design first an "accelerated" version of the application: just scale the time. When all OK, just re-scale the values in the your software to the reality (just change some constant values). It is just a little change in designer's mind. ASICs designers, used to work with simulation, are always forced to work like this, with no major problems.

A lot depending on the micro. It breaks, turning the code line in red, in case of:

• Arithmetic operations with unknown data (e.g. RAM not initialized)
• Attempt to read in write-only position and vice-versa.
• Writing peripherals with unknown data.
• Watchdog trigger. Must be re-loaded before this point.
• Bizarre addressing mode. Example: if the watchdog register in accessed with the index register, is likely due to an error (index out of control), even if it not forbidden (or the programmer is really an odd guy...)
• A/D time settle violation. After switching the A/D on, some time must be left to insure an accurate conversion.
• A/D node short. Attempt to define two ports as analog simultaneously.
• A/D conversion request when no node is defined as analog.
• Interrupt vectors or reset missing: even if not used, at least a dummy vector must be placed, for a secure code.
• Unsafe ports transitions (ST6).
• EEPROM access while working (AVR).

These ones:

• Output resistance of MOS transistors..
• Hysteresys band.
• Pull-up resistor where it applies.
• All the configurations, including open drain, are correctly modeled.

Yes. Any compiler supporting Extended-COFF format or having a translator into such format will be supported by VMLAB for AVR. This includes the popular WInAVR/GNU C compiler.

Future plans for PIC, ARM7, etc have been also defined, but we cannot guarantee yet a date.