Yes, they count instruction cycles, but they don't take into consideration the fact that some cycles are longer than others due to internally set timing parameters. Moreover, my gripe was that they don't make any effort, in the case of the one-clockers from Dallas, to figure in the page mode timing if it is involved. There are, of course, also stretch cycles that can be invoked if needed.

The basis for each of these items is contained in the SFR's and, from the SFR content, they should be able to develop an appropriate timing model. They don't, of course, and that results in an inaccurate cycle count in the case of the Dallas one-clockers. The reason is that, (a) in page-mode, a page miss takes an extra cycle so the page address can be steered into its latch. Further, (b) since data memory accesses, on the Dallas one-clockers, sometimes take two cycles, due to the address latch requirements, and since they only do that in the case of external memory, the simulator should make a distinction. Also, (c) a stretched cycle can take as long as programmed, depending on where it is. Additionally, (d) the system timing can be varied under firmware control, i.e. the clock can be multiplied up or divided down depending on how it's programmed, and that can change under firmware control. I haven't tried it, but I doubt, based on what I know so far, that the KEIL simulator takes any of that into account.

Yes, it would make the simulator run a mite more slowly, but probably not vastly so, at least in the case of the Dallas parts, since their timing variables are fairly global. For users of the features, aside, simply, from the faster system operation, of these Dallas one-clockers, I think it would be VERY useful to have timing markers associated with every line of code in a simulated run, giving the user the real-time from reset each time a line of code/instruction is executed. Whether it's calculated in terms of an oscillator cycle count, or in terms of real time matters very little, but an accurate count, in terms of the oscillator period is probably the "right" way to do it. That count should reflect the elapsed time in terms of oscillator periods accurately and taking into account whether that oscillator is multiplied by 1, 2, 4, or divided by 1024.

RE