| ??? 10/10/09 01:36 Read: times |
#169607 - Tell me more about femtosecond precision Responding to: ???'s previous message |
Richard Erlacher said:
Who's said anything about counting clock cycles? If the RESET is synchronously timed and triggered from a single source, that being the same source that clocks the MCU, the two MCU's will remain in sync until external stimuli cause one or the other to change phase. Relying on the processors to process instructions in phase with each other is counting cycles. It really doesn't matter if you design a counter to present the number of cycles consumed. The issue is that any single processor that takes a different path through the program and consumes one clock cycle more or less than the others will have diverged from the other processors. So unless you have 512 processors processing identical input data, you will have to count clock cycles for every single path in the software. It depends on what you mean by very short. I'm thinking in terms of femtoseconds, while you're thinking in terms of tens of milliseconds. Synchronization can mean only one thing, and that's that they're EXACTLY the same. Rubbish. You will not get 500 processors to toggle their outputs in fs resolution. Try route the clock signals to the chips with fs jitter between the individual processors. Or consider the number of magnitudes worse precision because of tolerances inside the chip. And the next thing is that you claim that I'm thinking in tens of milliseconds. That means that you consider processors I am using to have tens of ms of jitter responding to an interrupt while processors you are using have femtosecond jitter. Yeah right. Richard said:
If the computation step is then 100us, the precision of the oscillator will only matter for the computation step. After handling a message, the processor can resynchronize again with next message. Maybe, but nobody said it could vary that much. Many of my recent code sets (for a microsequencer, not 805x) execute in their entirety in well under 100 us since they have only a 4 ns cycle and only an 8-bit PC. 100 microseconds is a VERY long time in some contexts. So much the better. If the code takes 10us to run, then the jitter from the interrupt entry until they produce something will be even less affected by differences in clock speed. Richard said:
This way, it will be trivial to have 1000 processors synchronize with received data and perform an action in better than 1us with standard components and fully distributed oscillators. And if one processor for some reason gets noise on the input or restarts, it can directly lock into the next message again.
Since the OP has never really told hes needs, there would be no reason to ever consider how to design a system when needing ns or ps resolution. It is way more likely that ms response times is fine. My point in bringing the synchronization issue up in the first place was the the O/P hadn't made much sense with his synchronization requirement. Perhaps it's "good enough" to call someone at the second location and have them push the reset button. Perhaps half an hour is close enough. I doubt it, based on what O/P has said. But you find it likely that he needs us or better? Or why not fs resolution? Stop reaching. Richard said:
Don't relive old problems based on whatever technical limitations you may have suffered 20 years ago. Lock-step is a relative term very much depending on the relation between processor speed, amount of work to do, and allowed jitter. Those technical limitations still exist. Synchronization must be absolute in some cases, and a few ps here and there aren't tolerated at all. Jitter isn't tolerated either. Correct. And there are situations when trying to use many synchronized processors is stupid. Richard said:
But the situation is that any design should be implemented in a way that it is robust and self-synchronizing. Counting clock cycles since release of reset is an extremely bad way to run processors in lock-step. If they really need to run the program machine cycle for machine cycle in sequence, then you should most probably throw out the processors. It sounds more like a problem you could solve with discrete logic and lookup memory. It's seldom necessary to have true synchronization, but when necessary, it must be precise. A millisecond is seldom close enough. When a ms isn't enough, you can design for a us instead. Still easy without bothering with reset pulse lengths or introducing single-point-of-failures by driving multiple processors from the same clock. Shopping around a bit for a suitable processor, you could probably manage 10ns or better interrupt response time jitter. Richard said:
Richard said:
[...] number of MCU's will be in exact lock-step, so long as their inputs and code are exactly the same, again, based on that same timebase. The thing is - a robust solution will get them in sync even after their inputs have differed. "Sorry boys - we will now have to restart our 500 processors because one processer lost sync..." That would have been no problem at all. However, it was clear within less than half a minute that the system under test had failed that particular test. Restarting was entirely automatic, and rerunning the test was only a matter of restarting the system under test, waiting for it to signal to all the MCU's that it was "ready" and then having the master processor tell it to "go." Having a system that needs rebooting 500 processors definitely looks like a fragile system. It wouldn't be fun if every processor in my car had to reboot just because some chip somewhere for some reason did lose synchronization. Richard said:
One single asynchronous signal used anywhere in the system only needs ps variance between the different listeners to send them out of sync. That's why clock and other critical signals are distributed with carefully routed and meticulously driven and terminated coax cable of precisely controlled length. All they had to do was to start simultaneously. Once that was done, they could free-run ... for only half a minute, as it turns out, but anyway ... Send me your contact information. Since you have already told us you can do fs-precision routing of clock information to 500 processors, I should be able to sub-contract you for a lot of work. The big chip manufacturers have problems managing that precision when routing the clock signal inside their chips, not to mention getting fast enough rise/fall times, so they would be ready to pay a lot for a solution where all gates runs perfectly synchronized. Richard said:
And if all input signals are always synchronous and identical - throw out the processors and use logic chips. The MCU is a logic chip! The MCU is a logic chip intended for standalone operation. It supports programs, to allow it to make decisions. It isn't intended to be used as a discrete component for a VLIW design. And faking SIMD with many discrete processors would require clock cycle counting. Richard said:
Or probably: Stop and consider if you are solving the wrong problem in the first place. Fact is, we've no idea what the problem is. The only thing he made clear is that he wants 'em to start at exactly the same time. That's what those 512 single-chippers did back in '86. All they had to do was to wait for an interrupt and then regurgitate a script. That's why the absolute synchronization was necessary. It was a response to a questionable requirement, but that's what the Pentagon specified. It made my employer happy, as there was lots of labor and little complex hardware. Mostly racks and patch panels, and many man-hours moving cables from one rack to the other. Fact is: I have already said that we have no idea what the problem is. You even quoted me saying that. But the probability that the OP needs ns or now suddenly fs synchronization is miniscule. And if he thinks he needs fs synchronization, he would find economical problems realising the solution. Besides the little thing that synchronization to fractions of the time of a single instruction would strongly indicate that either the wrong problem is being solved, or the wrong solution has been selected. Can you produce information about the patch panels, where the signals got routed with path lenghs controlled to um precision? |
