Well, it seems that noone else will take a stab at you question, so I will try my best.

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.

I may be off on the exact reasoning for /SYNC but I am fairly certain Im at least in the ballpark.

Hmmmmm... thanks Paul;
I'll need to do some testing to see if I can make more sense of that. I expect you have at least the right direction.

Too bad the documentation does not describe it better, especially since it is a feature one can enable or disable.

In my particular requirements I generally need to have the state of a port input as close to real-time as possible, so the documented 2 cycle delay is unwelcome, or even not tolerable.

Stephen/pearlsixtytwo; can you help explain this one fully?

In sync mode the purpose of the double flip flops is to prevent an input from exhibiting 'metastable' behavior.  I'll try to explain as best as I can recall how that works.

Let's assume a 'D' type flip flop, which is really a simple one bit memory of sorts.  Whatever is on the 'D' (data?) input when the rising edge of the clock occurs, gets stored in the flip flop and then appears at the output 'Q'.  A typical flip flop chip is the 7474 or 74(LS,HC,HCT etc.)374.  
The issue is that when you have a clocked flip flop, there is a period of time around the clock edge that the input has to be stable.  This is spec'd as the setup and hold time.  If the input changes during this window of time around the clock edge, the output can become indeterminate, for some period of time.  It becomes 'meta-stable'.  It eventually settles down to a high or a low, but it could be either.

In the SX, if you are trying to read a port and you happen to catch it during a change, the same thing can happen, but to one of the internal registers of the SX and you don't necessarily get the result you expect. Other than an incorrect input, I'm not sure if other 'bad things' can happen because of that.

What the sync option does, is put two flip flops in series between the input pin and the internal bus of the SX.  The input pin to the D of the first and the Q of the first to the D of the second, then the SX bus gets the Q output of the second.  They are both clocked by the processor clock.  What that does for you is that if the first flip flop catches the input pin during a change, and goes metastable, it has one clock time to settle until the next clock hits the second flip flop and clocks the now stable output of the first flip flop through to the SX.  
It ensures that the second flip flop and the internal registers of the SX have their setup and hold times met.

It also means that if you try to read an input immediately after you wrote it, you have to put more than the usual one 'NOP' between the write and read instructions.  This is because with SYNC enabled, those two flip flops delay any change on the input pin by two SX clock cycles.  So any change caused by a write to a port, isn't seen until at least two clock cycles later.

For what it's worth, I've never found it necessary to use this feature.  I've never had unexplained crashes of my SX code that I could attribute to the metastability issue.  Off hand, I can't think of how exactly you might develop a test program to see if it can cause an error.  Left as an exercise for the reader...?

Thanks for the indepth explanation Micheal, it seems the upshot is, if you make sure you don't read and write the same register in a row, and you can ensure the input pins do not transistion near the clock edge, you should be able to operate with the /SYNC option off. I did this with a design where a CPLD and the SX were in 25MHz communication with each other (max speed for full cycle of on and off), I noted which clock edge the SX did its clocking on, and programed the CPLD to do its transitions on the opposite edge, I was thinking in terms of minimum setup and hold times, but I was unaware the general term was metastability (heard of the term but always thought of it in terms of clocking a slowly moving input where the value was between the accepted high and low values). Setting the inputs to Schmiddt trigger may help keep you out of this situation, but this is a guess.

Thanks Micheal and Paul;
I fully understand the operation of two cascaded flip-flops; but I still can't understand the significance/application of SYNC when it comes to the SX.

If an input was clocked (read) at a point of transition, the processor w register would see it as a one or a zero. On the other hand, had SYNC been enabled, then the first F/F would also read it as a one or a zero because it is synced to the same clock. And one more clock later it would be through the delay chain.

So in the UNSYNCED case, a READ would put the present data into W, and in the SYNCED case it would put the value at the input two clocks ago into W.

In both cases, if the clock uccurred at the transition point of the input, the result would be uncertain; for UNSYNCED it is uncertain NOW, and for SYNCED it is equally uncertain two cycles LATER. The uncertainty is just delayed.

I don't get the usefulness of this........ but wondered what I was missing.

Hey Paul? Peter? What documentation are you referring to? Page 39 table 2.7 doesn't seem to exist on the chip datasheets or SXKey manual.

Stamp User's manual.

Hi All;
In reading the Ubicom docs again, I'm now wondering if that SYNC function was included to slow down inputs when the processor is used in "compatible" (non-turbo) mode. I just can't see any possible other use for it.

Peter,
although I also don't have a good explanation for the SYNC function, I don't think that it has something to do with the "campatibility mode" as the SX48/52 also have that SYNC feature on one hand but don't have that "compatibility" mode on the other.

The explanation in the SX48/52 data sheet is a "bit" more detailled that in the SX28 data sheet. It reads:

Hi Guenther;
Yes, you are correct regarding the SX48/52 which can only be operated in the TURBO mode, so my reasoning was wrong. In reading the docs, I fully understand what the words mean and how one causes the synchronization.

What I still don't understand is why bother with it? It seems to me it only makes things slower. But then, what do I know??

I wish one of the original designers could pipe up about this.

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 http://www.sigcon.com/Pubs/news/4_4.htm 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.

Hi Tracy;
Thanks for the rather detailed explanation....... I follow what you say, but I still don't get it.

If metastability of a raw input is the issue, then is the EXACT same not true of the input to the first of the two delay flip flops? Like, what have we gained?

And also, as you suspected, I need to have all my 18 SX's on one bus operate their interrupt in exact lock-step, so a two clock delay in sensing inputs makes my system unworkable.

One beauty of your scheme, described in the "resonator" thread, would seem to be its self correcting action. Even an occasional missed event would only cause it to slip one or two cycles, at most, and then recover. Also, syncing in that way cleverly makes the data itself synchronous, not asynchronous, so the data bits are in no danger of transitioning at the same instant as the clock edges.  At least until you push it to the limits.  I don't recall what you said about the width of your data bits, how many SX clock cycles there are there to each data bit?

As to the two clock latency on the receiver side, if SYNC is on.  Would that  _necessarily_ make your scheme unworkable?    It would be deterministic, and the same in all receivers, so it seems to me the transmitter could compensate. Well, if it were only a matter of the computers talking to one another.   I have no idea of what needs to happen.  The added latency might be unacceptable in relation to real world activitiy.

I've been (and still am, largely) puzzled by the same question: What is gained by having a synchronizer, when it only passes the metastability failures off onto the first of the two delay flip flops?    I think the answer is system specific.  One example: Suppose the main latch drives combinatorical logic that fans out into the system logic, and the thresholds of different gates are different.  The voltage in the metastable state can be above threshold for some gates and below threshold for others, so the state variable would fan out inconsistently.  One example I read concerns a priority encoder, generating an interupt but to the wrong vector.   To avoid that, the synchronizer is a straight through path, not connected to combinatorical logic.   If the first flip flop goes metastable, that doesn't spread out through the system, and the metastability is likely to be resolved by the time the next clock pulse comes along.    A two stage synchronizer improves the situation by multiplying together four low probabliities: Those are that the first flip flop will go metastable AND that it will not resolve before the next clock edge, AND that the second flip flop will go metastable (as a result of the first stage ambiguity)  AND that it will hang there unresolved until the second clock edge.  
How that might impact the SX chip, I have no idea, as the data sheets give only the skeleton of the SX internal logic and not much info on setup and hold times.   Only the designers know for sure, but they certainly gave it some consideration?   I've _never_ had a problem with SX or Stamp i/o performance that made me gulp and think oh no, metastable.  Consider the RCTIME command.   It inputs a slowly changing signal, hovering right at the threshold at the instant of clocking.   Is that a recipe for metastability, or what?   I was wondering about the SYNC bit on the Stamp.  If enabled (=0), it would practically eliminate the chance of metastability.  But would it matter?   The alternative without SYNC,  might it be benign, a measurement at most a microsecond longer than expected?

Hi Tracy;
Yes, again I follow your discussion. I can understand the need for dealing with metastability with generic logic built circuits. My specific question was in regard to the application of the SYNC feature as it pertains to the SX.

Thanks for your insight, but I still don't get the use of this for the SX.

Guys, if the RTCC input is ALWAYS run through a dual stage flip flop, that means that any "tricks" that use it as an extra input need to take that into account, no?

Also, when the RTCC is used to count external pulses, it is actually counting two less than have acctually presented at the pin? Wow...

Is that documented anywhere?

Hi James;
Regarding the "sync always on in the RTCC", is something Guenther mentioned above, I have not messed with that for proof.

But that might explain the apparent two cycle counting "stall" that occurs after one writes directly to the RTCC register. Very interesting; I need to do some testing here.

As for a two count delay on detecting external pulses on a so-configured RTCC input, I don't know the answer, and again, some testing is in order. Will report once I get around to it and understand it.