Isosync Feature

pjv

Hi All;

The SX family has some fuse bits that can be manipulated with the SYNC directive. According to the documentation, when this is activated·it·apparently routes all port input bits through a two stage flip flop toggled by the processor clock in order to isosync inputs to the clock....hunh?????

I have not messed with this "feature" yet as I can't understand the purpose of it.

Can anyone shed some light on this?

Cheers,

Paul Baker

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.

Hope this helps,
Paul

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

pjv

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?

Cheers,

Peter (pjv)

Tracy Allen

www.interfacebus.com/Design_MetaStable.html

Google "flip flop synchronizer" or similar for lots of hits. strange stuff

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

James Newton

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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
James Newton, Host of SXList.com
james at sxlist,com 1-619-652-0593 fax:1-208-279-8767
SX FAQ / Code / Tutorials / Documentation:
http://www.sxlist.com Pick faster!

Paul Baker

SX·User's manual.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

pjv

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.

Cheers,

Peter (pjv)

Guenther Daubach

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:

"Synchronous input enable (this bit synchronizes the signal presented at the input pins to the internal clock through two internal flip-flops). 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 (see Figure 3-2). SYNC is always enabled on RTCC."

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G

pjv

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.

Cheers,

Peter (pjv)

Tracy Allen

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 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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

pjv

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.

Thanks again, and cheers,

Peter (pjv)

Tracy Allen

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?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

pjv

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.

Cheers,

Peter (pjv)

James Newton

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?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
James Newton, Host of SXList.com
james at sxlist,com 1-619-652-0593 fax:1-208-279-8767
SX FAQ / Code / Tutorials / Documentation:
http://www.sxlist.com Pick faster!

pjv

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.

Cheers,

Peter (pjv)