Cyclone III asynchronous input signal synchroinization problem.

I didn't analyze everything you posted, but I think you have the problem in case 2 because you are using different clocks with the two main blocks.

In particular, you are clocking BitCounter_Shifter with a signal generated by the synchronizer stage. This will lead to undefined timing relationships.

You must use the same 'true' clock (CClk) throughout the design, and you'd rather use it to synchronize the other signals.

The waveforms are hard to read with the analog traces overlaying the digital. I would really prefer separated traces.

I presume you don't see actually metastability in the non-synced case rather than failing edge detection. Although metastability exists, you'd have to struggle hard to catch it on the oscilloscope screen because the probability is very small. Nevertheless you have a synchronization problem.

The design has basically the right topology in terms of signal synchronization, except for the point that a standard synchronizer uses double instead of single registering. The difference matters for metastable events which may happen with a likelihood 1:10^6 or 1:10^9.

So why does it fail? I'm willing to look at better readable and annotated waveforms, trying to understand what exactly happens.

I see however a general problem of your design. I fear it doesn't have any debouncing logic for the I2C lines, which is absolutely necessary regarding the slow edges, and at least implicitely required by the timing specification of the I2C standard.

P.S.: I completely agree with chris72 that clocking of the bit counter with a non-clock is most likely causing the observed problem. You should replace it with a fully synchronous construct where all register clock inputs are only feeded by cclk, as said.

The design looks like copied from an discrete logic IC wire entanglement. In this technolgy, you could place a small capacitors to filter unwanted glitches in a data signal used as clock. Unfortunately that's not possible in a FPGA design.

Hello again! I am trying to follow yours hints.

First of all why I think I saw metastability. I connect to IIC clock line the 0.01uf capacitor and receive this oscillogram. It is clearaly seen (on the pic 1), that when the voltage reach the Vcritical value (1.275V) a number of false clock edges occur. It looks like the input trigger have no “band gap“ between logic 0 and logic 1 voltages. I think that without this capacitor the same processes occurs. But the quantity of “false edges” strongly decreases especially with decreasing the pull-up resistors value.

What about the second register in synchronizer? I can’t understand it’s function in the scheme. Nothing changes except increased delay time between input clock edge and synchronized signal edge when I add it in design. (pic 2)

I would like to use the schmidt trigger on inputs. Unfortunately they are not included to this FPGA. Can you explain the other ways to suppress the debounce in the lines?

What about the clock signals? I think that after synchronizing it is permissible to use IIC_clock signal to start shift process in bit counter. Ok. May be I was wrong. I am trying to make shifting from CClk signal. My next realization is also wrong. It still works with the same mistake shown on the pic 3. But the last realization work’s correctly! It is shown on pic 4.

I am still confused by this. I can’t understand what happens in the previous designs that leads to “stealth reset” signal for my counter. I am just learn by rote that all registers in the one clock region must have the same clock signal without any combinational logics on its way. If you can explain it to me I would be pleasant to know it.

thank’s for fvm and cris72 for their help.

In addition I lay out more informative graphics of my digital and analog signals (pic 4)

The explanations for the pictures:

1. In IIC_Slave net is added additional capacitor, that makes fronts more smooth. Yellow line – IIC_data signal, Green line – IIC_Clock signal

1.1 – Here is shown one of the posedges with a number of the false count acts (in the red squared area).

1.2 – The same region with the counter states

2. RTL view and oscillogram. It is shown that the second register adding in the synchronizer causes no effect.

2.1 Wrong attempt to clock bit counter by the CClk.

3. Correctly works scheme. All registers are clocked by CClk. IIC_Click is used as data signal.

4. Oscillogram of the input IIC signals

4.1 The part of the same signal in detail. Here is seen the moment of start signal receiving and bit counting

--- Quote Start ---

First of all why I think I saw metastability. I connect to IIC clock line the 0.01uf capacitor and receive this oscillogram. It is clearaly seen (on the pic 1), that when the voltage reach the Vcritical value (1.275V) a number of false clock edges occur. It looks like the input trigger have no “band gap“ between logic 0 and logic 1 voltages. I think that without this capacitor the same processes occurs. But the quantity of “false edges” strongly decreases especially with decreasing the pull-up resistors value.

--- Quote End ---

Now the effect can be clearly seen. It has nothing to do with metastability, just a slow edge with superimposed noise. Most logic families have a minimal slew rate for input signals to be detected as clean edge, the number is in a 0.1 V/ns range for fast logic, e.g. FPGAs. It's true that ST inputs can be used to process signals with slow risetime, but they are analog blocks which would cause additional unwanted delay. In some cases enabling the bus hold feature can work as a poor man's schmitt trigger. The I2C pull-up resistors must be strong enough to source the bus hold overdrive current.

But much more effectively, you can debounce the noisy bus lines in digital logic. Usually it's sufficient to sample the bus lines with a moderate clock speed of a few MHz and detect changes in a state machine. So it's guaranteed that each input edge is detected once and only once.

--- Quote Start ---

What about the second register in synchronizer? I can’t understand it’s function in the scheme. Nothing changes except increased delay time between input clock edge and synchronized signal edge when I add it in design. (pic 2)

--- Quote End ---

The concept of synchronizer chains is e.g. discussed in the Quartus Software Handbook in chapter managing metastability with the quartus ii software. Generally, two is the minimal amount of registers considered safe.

Regarding "using data as clock", there are basically two issues:

- Timing. Usually data inputs of registers are driven by other registers, directly or through combinational logic. When also the clock input is driven from register outputs, you have difficulties to keep setup- and hold-time requirements. Becomes worse due to arbitrary logic and routing delays.

- Glitches. FPGA logic elements are programmable look-up tables. They are not guaranteed to have a glitch-free output if more than one input signal to a LE changes.

Thank's for the term difference explanation. I make the next version of some IIC blocks that is fully synchronized. The clock source is PLL (10MHz). I am afraid to use any other sources (combinational logic or triggers) to make clock now.

The IIC signals are synchronized by two triggers per signal in IIC_Parser module. Then they are parsed by edges on negedge CClk signal (edge detectors in IIC_Parser module). After that the negedge IIC_Clock signals are used to make counting. The counting process flows by posedge CClk. I hope it is possible to secure the Tsu and Th condition by using the different CClk edges in synchronizer and counter. And the synchronization IIC signals on CClk have to prevent the slow edge with superimposed noise false counting. No more errors on the oscillogram is observed.

The other signals of the parser module will be used later. I will read any hints or comments about my design with pleasure if any. The start topic problem is solved.

Good that your design is working.

It's possible to use both edges of the system clock, but rarely useful.

It would try with single edge and higher speed. If you want to "slow down" specific registers, e.g. to debounce an input, you better use a clock enable, a signal that ia active for 1 out of N clock cycles.