please dont rip this site

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.

See also:


file: /Techref/scenix/sync.htm, 6KB, , updated: 2005/10/12 12:22, local time: 2024/10/4 02:25,
TOP NEW HELP FIND: 
3.238.82.77:LOG IN
©2024 PLEASE DON'T RIP! THIS SITE CLOSES OCT 28, 2024 SO LONG AND THANKS FOR ALL THE FISH!

 ©2024 These pages are served without commercial sponsorship. (No popup ads, etc...).Bandwidth abuse increases hosting cost forcing sponsorship or shutdown. This server aggressively defends against automated copying for any reason including offline viewing, duplication, etc... Please respect this requirement and DO NOT RIP THIS SITE. Questions?
Please DO link to this page! Digg it! / MAKE!

<A HREF="http://piclist.com/techref/scenix/sync.htm"> SX Input Sync mode</A>

After you find an appropriate page, you are invited to your to this massmind site! (posts will be visible only to you before review) Just type a nice message (short messages are blocked as spam) in the box and press the Post button. (HTML welcomed, but not the <A tag: Instead, use the link box to link to another page. A tutorial is available Members can login to post directly, become page editors, and be credited for their posts.


Link? Put it here: 
if you want a response, please enter your email address: 
Attn spammers: All posts are reviewed before being made visible to anyone other than the poster.
Did you find what you needed?

  PICList 2024 contributors:
o List host: MIT, Site host massmind.org, Top posters @none found
- Page Editors: James Newton, David Cary, and YOU!
* Roman Black of Black Robotics donates from sales of Linistep stepper controller kits.
* Ashley Roll of Digital Nemesis donates from sales of RCL-1 RS232 to TTL converters.
* Monthly Subscribers: Gregg Rew. on-going support is MOST appreciated!
* Contributors: Richard Seriani, Sr.
 

Welcome to piclist.com!

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  .