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
- Does your emulator match exactly the micro I/O, even in analog characteristics?
- How much does your emulator cost, and how much does
- 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
What difference exists between the official
AVR Studio assembler and the one used by VMLAB?
integrates the official freeware AVR assembler avrasm32.exe. Whenever
it is necessary to call them, it spawns a process calling this original
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
Simulation is not real time. How can I insure that things will run in real
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 VMLAB!
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
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?
- Output resistance of MOS transistors..
- Hysteresys band.
- Pull-up resistor where it applies.
- All the configurations, including open
drain, are correctly modeled.
Do you support C compilers for AVR?
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
Will you support other microcontrollers?
for PIC, ARM7, etc have been also defined, but we cannot guarantee yet