regarding Craig's comment,

"If you really need clock-cycle-by-clock-cycle simulation, you don't need a simulator: You need an emulator. And do emulators even do that? I've never done clock-cycle-by-clock-cycle simulation or emulation. The smallest degree of step-by-step debugging I've done was one instruction at a time, which may be anywhere from 1 to 48 clock cycles depending on the derivative and instruction. "

I'm sure it's much less than 1% of the user base that needs such device specifics, but, in the case of the various timing-related features that actually modify the length of a cycle, that the simulator should reflect those things. Once the simulator gives you incorrect values, it's no longer a simulator. It should simply not provide false information, since that's less useful than none.

True, it could make simulation slower, but, what difference does an order of magnitude make? The simulation proceeds at a high rate with respect to the simulated processor, so what difference does it make whether it's at 5x or 500x the speed of the simulated processor? The display can only be updated at a fixed rate.

I can assure you that there are no "emulators" that can provide you with software that reflects, accurately, the timing of the 89C4x0 family without a hardware environment. That's not necessary. Back in the "old days" when air was clean and sex was dirty, as they say, I wrote lots of simulations. They were not general in nature, and not in a high-level language, but I do have an idea of what a simulator can and, perhaps, should, do.

What I see as the target of most of the 805x simulators I've seen is the guy who wants to find out whether his code runs at all, which he should be able to determine pretty easily over the ocurse of a few minutes' study. It's not targeted at really simulating THE MCU in THE hardware environment, even if it's a pretty simple one.

I'm thinking it's really not fair to leave users out there without a "real" tool with which to simulate the MCU in its target environment. That means it should have an external event table (a schedule) to check for external events, at a minimum, and, perhaps it should be treated more as a hardware device rather than as a software vehicle.

Hardware product vendors seldom produce models of their devices that enable one to simulate them with a simulator capable of integrating them with other vendors' products. SPICE provides a means that might enable that to happen. It's already happened for analog components. If only there were enough pressure to get vendors to support their MCU's with SPICE and IBIS models.

RE