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? 

Why have you selected an "old" SPICE-like hardware description language, instead VHDL? 
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. 

What difference exists between the official ST6 tools and the ones used by Visual Micro Lab for ST6? 
None. VMLAB integrates the official ST tools for ST6. Whenever it is necessary to call them, it spawns a MS-DOS process calling the original tools: AST6, LST6, CST6, EEPROMER. All the design database is built upon the results given by these tools. 

What difference exists between the official AVR Studio assembler  and the one used by VMLAB?
None. VMLAB integrates the official freeware AVR assembler avrasm32.exe. Whenever it is necessary to call them, it spawns a MS-DOS process calling this original tool.

Can I connect VMLAB to an ICE200?
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.

What can I see with VMLAB that cannot be seen with an emulator plus an oscilloscope? 
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.

Simulation is not real time. How can I insure that things will run in real time?
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. 

Being like this, what about applications with long delays?. It would take ages in Visual Micro Lab! 
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. 

What kind of execution warnings does VMLAB  flag? 
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).

What I/O ports effects does Visual Micro Lab take into account? 
These ones: 

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

Will you support more ST6 family members? 
We have the intention to support EEPROM members: ST626X, ST6230, but officially we cannot commit a date yet.

Will you support C compilers for AVR? 
Yes we will. Any compiler supporting COFF format or having a translator into such format will be supported by VMLAB for AVR. This includes the popular GNU C compiler.

Will you support  AVR ATMegaXX devices? 
Yes we will. Initial forecast is for Q4/02, although a date cannot be guaranteed yet.

Will you support other microcontrollers? 
Future plans for PIC, Motorola and 8051 micros have been also defined, but we cannot guarantee yet a date.