For purposes of this particular exercise, that's exactly what went on, i.e. the 512 MCU's executed the precise same script in lock step, sending a command line to the system under test, and, once it was done, they simply waited for a response, which didn't have to be precisely in sync, but once they received it they sent a notification to the supervisory processor, which notification didn't have to be synchronized, because, for that MCU, the exercise was over. The whole point of this test was to verify that the system under test, a large multiuser system, could respond to a given script within a predetermined time window.


You're right ... it comes up quite seldom. However, precise synchronization, and not just within one or two cycles, is more common. Just think about bit-banging a 20480-byte data stream in 2.5 MHz Manchester code. You have to find the "sweet spot" for sampling so the 100 ppm oscillators you're using at both ends aren't going to allow you to slip from leading to lagging the clock that is embedded in the data stream.

Per's right, BTW, in that there are ways of implementing redundancy without precisely synchronous operation, but sometimes it's less trouble to use triplets and vote, and then it's easy to do only if they're in precise synchronization, so you can isolate the errant processing system and, since these setups tend to be cyclical, bring it back on line during the next major cycle.



Yes, precise synchronization is not so common, owing mainly to the fact that, for many years, and in many tasks, MCU's, while slower than the logic they replaced, were much faster than the tasks they were asked to perform. The closer the required performance is to the maximal performance of the MCU, the more critical synchronization issues become. In some cases, it means choosing an oscillator that more closely meets your requirement for synchronization, rather than using a "standard" frequency that simply serves your wishes for asynchronous serial communication.

RE