Jan, The level of effort required to develop simulator timing as opposed to cycle-by-cycle timing is not particularly great. It's all done by the computer, after all. It does slow down the simulation, of course, but since modern PC's execute code at 100x the MCU's rate, in may not make much difference whether that's 100x or 10x. The scheduler is another task, but also not difficult, and its output file is an input to the simulator.
The problem with most cycle-by-cycle simulators is that they completely miss the mark when one is using a device like the Maxim/Dallas DS89C4x0's, in which you know, by now, that I have considerable interest, since firmware can control their execution rate and the length of an external bus cycle. It's deterministic, but beyond the ability of most simulators. The timing, whether in nanoseconds or in clock-ticks, is a simple calculation based on the simulator's timebase, which is virtual. However, if you want to determine how well a set of firmware synchronizes with an externally timed process, you have to have the ability to determine how the MCU responds to asynchronous stimuli. This affects interrupt response timing, and it affects built-in peripheral behavior. The underlying problem, of course, is that firmware has traditionally been generated by folks who saw programming as an art form, rather than an engineering practice, and seldom applied sound engineering principles to it. Therefore, they were happy with the cycle-by-cycle simulations, and simply guessed at whether the timing really worked. Sometimes it did, and sometimes it didn't. If it didn't, well ... back to the drawing board ... The amazing thing, so far, has been that they've gotten by with it. When engineers design the firmware, they use precise timing models and simulators based on them. Back in the early '80's we used precise timing models of 68000, 68010, 68012, and 68020, among others, together with precise models of memory, etc. Normally, one didn't have to do that. Today, even the PCB's are modeled. regards, Richard Erlacher ----- Original Message ----- From: "Jan Waclawek" <[EMAIL PROTECTED]> To: <sdcc-user@lists.sourceforge.net> Sent: Friday, August 29, 2008 4:30 PM Subject: [Sdcc-user] ucsim, was: Quickstart document,was: Virus in SDCC-2.8.0-setup.exe - MD5 etc tutorial > Richard, > > Although I am not competent to decide on this either, I don't think > Daniel's simulator goes as far as peripherals timing (in ns). > > And, IMHO, there is not too much "buying drive" to make such a > sophisticated simulator either. Some of the '51 simulations are done in > the clock domain, most are done in the instruction cycle domain. > > Although I see the potential value of such a simulator; at the end of the > day, when it comes to the nanosecond details, you need the real stuff > anyway, don't you? > > Jan > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Sdcc-user mailing list > Sdcc-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sdcc-user ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
