I have to agree that only a very few people actually care about precise simulation. In fact, I'd speculate that the ones who care most about the simulator are the same ones who really don't know ahead of time whether their code is properly designed at all.

As an example, however, I can suggest you consider the one-clocker with the serial port in synchronous mode, i.e. mode 0. That's not a common thing to use anyway, BUT, since the mfg, e.g. Dallas, in the case in which I'm interested, doesnt' tell the little guy anything about the timing of the transmitter or receiver interrupt bit, relative to the instruction sequence, I'm thinking that a simulator author might have enough clout to get 'em to turn loose of that information. With the Dallas one-clocker, for example, you still have to "get around the loop" after clearing the interrupt flag in time to reload the data buffer before the next bit goes undefined. The relationship between the instruction execution engine and the shift register is quite critical. Given proper information input, it would be possible to determine whether a given sequence of instructions, any number of which could possibly be adequate, but some of which clearly would not be, the simulator could save a lot of time with logic analyzer, 'scope, or whatever, and yield useful information more readily. Now, that's just one rather contrived example, but I think, in light of the various timing options available in the DS89C4x0 series, it's a good example of where one could benefit from a precise timing simulation.

The thing that would interest me even more, about such a simulator, would be that it enables one to determine durations of sequences that force changes in the MCU timing. The overarching desire, of course, is to know how long it takes to get from here to there, not in the general case, but in this specific set of code, which does this specific set of things. The goal, of course, is to avoid having to set up hardware in order to make such an estimate or verify it.

Sadly, the KEIL tools don't tell you about how long it takes to get from here to there, nor do they exhibit any features that would help with the problem I posed. They don't support any kind of timing simulation, in fact, if you use the "page-mode" external memory addressing that the Dallas one-clockers support. In fact, when I contacted the KEIL folks about this matter, the answer I got, simply put, was that it was not possible to determine the timing, which, of course, is entirely incorrect. The person with whom I was in contact clearly felt that the memory timing was not deterministic, which, of course, it is, given that one has the entire set of code on hand for any given simulation. What I gathered from that exchange was that they really didn't know that the DS89C4x0 types were one-clockers, and that they have a wide range of variable timings that can be altered under firmware control. They also didn't recognize what the page-mode or extended timings for external memory access really were, so their simulation was incapable of yielding reliable precise timing under any circumstances.

RE