SX Input Sync mode

Synchronous input enable (for turbo mode): This bit synchronizes the signal presented at the input pin to the internal clock through two internal flip-flops.

On the SX48/52 datasheet the following is added: Required to be enabled unless the transition on the input pin is not close to the clock edge. If enabled, port data must be read more than 2 cycles after a change to the input level mode or Schmitt Trigger mode. SYNC is always enabled on RTCC.

Paul Baker says:

The documents state that SYNC is related to the turbo mode, looking at the execution pipeline in table 2.7 on page 39 shows that the execution phase of the second instruction occurs during the write phase of the first instruction. During the execution phase of an instruction accessing one of the port registers (reading a port register occurs during the execution phase) if the previous instruction was writing to the same register (/SYNC is off) a race condition may occur, meaning some or all the bits of the write to port instruction may bleed through to the read from port instruction. This presents an unpredictable behavior which can be affected by such things as temperature and processor speed. So to eliminate this nasty behaviour Ubicom incorporated a buffer so that the register the read instruction gets it data from is not the same register as the write instruction is writing to

Tracy Allen wrote:

The issue is metastabiity. When an external signal comes into a clocked system (like the SX), there is a calculable probablility that the it will violate the setup or hold times of the input latch. The probablities are well doumented in terms of MTBF (mean time between failures) for different logic families and FPGAs. (e.g. see Xilinx urls) This probablility is lower when the logic is fast, as in the SX chips, because the setup and hold times are short. There are lots of good explantaions of how it occurs, also, and strangely, why it can never be completely eliminated, nevertheless, how it can be reduced by orders of magnitude through use of two or three stage synchroniizers. (As in SX sync bit = 0, enabled)

When the setup or hold times are violated, the input register can occasionally enter a metastable state and sit at an intermediate voltage for a relatively long time, or even oscillate. Latches are essentially cross coupled inverters, and usually they are in a either the high or the low state. It turns out that there is also a metastable state somewhere around V/2, where the cross coupled latch is operating in the linear mode and the output feeds back an input voltage that is precisely the value that is amplified to that same output voltage, thus metastable, and it can hang there for a while, and the time it does so is called the resolve time., and is stochastic. There have been lots of attempts to make clever circuits that detect and defeat the condition, but according to scholarly stuff I have read, a lot of it on line, there is something fundamental that makes eliminating metastability kind of like attempting perpetual motion. The probablilties can be reduced but not eliminated.

Let's say an input has to count pulses. If a register enters a metastable state, pulses might be missed or extra pulses counted, or if it is data, the data might be entered wrong. Whether that counts as a major failure of course depends on the nature of the system.

In a current thread on making a physical random number generator, I suggested sampling the output of the comparator set up as a jittery 25mhz oscillator. That is a prime candidate for a metastable state, because the oscillator will with certainty drive the input latch into a metastable state rather frequently. I have no idea what would happen. It might be detectable in a runs test, depending on how it manifests. I saw an article [url]http://www.sigcon.com/Pubs/news/4_4.htm[/url] that illustrates how to force metastability on purpose, just to demomnstate the effect. Imagine a clean square wave signal derived from the system clock, sent through a variable delay and applied to the D input of a clocked latch. The delay is tuned to the point where the output of the latch becomes 50%-50% zeros and ones, and slow feedback from the output holds it at that point. Then the metastable states can be captured on a storage or high persistance 'scope or otherwise scoped out. Otherwise, metastable states are quite rare and hard to capture.

When slow signals enter a system asychronously, a dual stage synchronizer (as in the SX with SYNC=0) can reduce the probablility of metastability by orders of magnitude. Might as well turn sync on. Since everything is all inputs are delayed by the same amount, it should all align. It is more difficult when the input signal frequency is close to the clocking frequency, for example, when going between two fast systems, say a 32mhz system to a 50 mhz system. Or a fancy real time scheme, where two processes have to be in real time lock-step with no delays, maybe like some that have been discussed here recently?

The SX literature says that the dual stage synchronizer is _always_ activated on RTCC. I wonder, does anybody know how the SYNC bit is set on the BASIC Stamp? I don't see any detailed schematics of the SX internals, or data on the actual setup and hold times.

Another issue is the internal clocking of the SX chip, or any microprocessor, fpga, etc. If, for example, the chip is found to lock up in operation at low temperature, or in the presence of high magnetic fields, etc., one can suspect a possible metastable state within the chip itself. A metastable state can throw off the internal execution. Say, the program counter isn't incremented properly, and consequently the code goes off into lala land. The issue of setup and hold time and clock skew violations over temperature one of the primary considerations of clocked system design. A system watchdog can help, but the fundamentals have to be addressed.