Bagaimana sinkronisasi 2-ff memastikan sinkronisasi yang tepat?


9

Menggunakan sinkronisasi 2-ff telah menjadi standar bagi sinyal untuk melewati batas jam. Dan ada banyak kertas / gambar yang menggambarkan mekanisme ini, seperti ini:masukkan deskripsi gambar di sini

Tampaknya bclk hanya dapat mencicipi denyut nadi adat satu kali (pada ujung kedua bclk yang meningkat ), yang menyebabkan keluaran metastabilitas pada bq1_dat . Bagaimana bisa bq1_dat dicicipi "tinggi" di tepi jam aktif berikutnya?


Selain pertanyaan saya, saya ingin menambahkan apa yang saya pikirkan agar sinyal dapat masuk dengan aman ke domain jam lain (misalkan 2-FF sudah cukup untuk memenuhi persyaratan MTBF). Harap perbaiki saya jika ada kesalahan.

masukkan deskripsi gambar di sini

ps: Keadaan metastabil tidak menampilkan gelombang "berkeliaran", tetapi level yang bukan '1' atau '0'. Gambar berikut menunjukkan contoh output metastable.masukkan deskripsi gambar di sini

Angka asli berasal dari catatan Kuliah untuk EE108A, Kuliah 13: Kegagalan Metastabilitas dan Sinkronisasi (ow Ketika Flip-Flops Baik Menjadi Buruk) oleh WJ Dally.


4
Saya hanya ingin mengatakan bahwa diagram yang menunjukkan keluaran metastable "berkeliaran" sangat menyesatkan. Sama sekali bukan metastabilitas. Ketika sebuah FF menjadi metastable, outputnya menuju ke tegangan menengah spesifik tunggal (nilainya tergantung pada teknologi implementasi) dan tetap di sana. Setelah beberapa waktu yang tidak dapat diprediksi, voltase kemudian akan berayun baik tinggi atau rendah, dan ke mana ia pergi juga tidak dapat diprediksi.
Dave Tweed

@Dave Tweed ♦ Terima kasih atas komentarnya. Di hampir semua dokumen yang saya baca tentang metastabilitas, saya melihat gelombang "berkeliaran". Saya mencari-cari dan menemukan sebuah posting ( Jika flip flop memiliki pelanggaran setup dan menjadi metastable, apakah dijamin puas dengan nilai input ketika selesai berosilasi? ) Yang berisi pemotretan dari o-scope dengan keadaan metastable yang ditangkap. Tautan ke referensi asli gambar termasuk dalam pos itu.
fiedel

Ya, itu mengilustrasikan poin saya dengan sempurna, dan presentasi Powerpoint asalnya memiliki banyak informasi bagus di dalamnya.
Dave Tweed

Jawaban:


8

Jawaban sederhananya adalah mereka tidak melakukannya sendiri. Sinkronisasi ada di sana untuk memastikan data tidak sampai, tetapi memastikan Anda tidak berakhir dengan sinyal metastabil yang memberi makan banyak sinyal lain dan menyebabkan masalah. FF kedua seperti yang ditunjukkan diagram menangkap keluaran FF pertama yang dapat metastabil dan mencegahnya menyebar lebih jauh melalui desain.

Ada berbagai macam sinyal, dan bagaimana Anda memasukkan sinkronisasi tergantung pada sinyal apa yang Anda bicarakan. Tetapi mari kita lihat beberapa tipe umum:

  1. Sinyal Pemicu - atau sinyal apa pun yang pada dasarnya adalah pulsa yang harus memulai sesuatu yang lain berjalan. Ini umumnya tidak membawa data, dan yang Anda minati adalah bahwa, katakanlah, ada kemajuan untuk memulai sesuatu yang terjadi di domain jam lain. Untuk mendapatkan ini untuk menyeberang, Anda akan memerlukan sinkronisasi (pada dasarnya melakukan apa yang ditunjukkan dalam diagram Anda), tetapi Anda perlu sedikit lebih banyak.

    Opsi paling sederhana adalah memperpanjang pulsa - pada dasarnya Anda memastikan pulsa input lebih dari 1 jam periode dari jam tujuan (seharusnya lebih dari 1 siklus dengan setidaknya lebih besar dari pengaturan dan waktu tunggu untuk register tujuan) . Misalnya jika Anda beralih dari jam 20MHz ke jam 15MHz, Anda akan memastikan pulsa Anda adalah dua siklus jam pada input yang akan memastikan bahwa itu disajikan ke jam tujuan dan tidak hilang. Ini juga menjawab pertanyaan Anda tentang bagaimana sinyal dijamin dapat melintasi. Jika denyut nadi lebih luas dari satu periode jam tujuan itu berarti bahwa jika bergerak metastable di tepi jam pertama dan akhirnya dilihat sebagai 0, maka pada tepi jam kedua itu pasti akan menangkap pulsa.

    Karena dengan jenis sinyal ini Anda hanya tertarik bahwa pulsa telah melintas, tidak masalah jika sinyal output berakhir dengan dua siklus clock tinggi beberapa waktu dan hanya satu siklus sisanya. Jika Anda perlu memastikan itu adalah pulsa siklus tunggal, Anda dapat instantiate rangkaian detektor tepi sederhana.

  2. Kontrol Bus - atau mungkin jenis bus data. Ini bisa dibilang lebih sulit karena jika Anda memiliki aliran data multi-bit yang perlu tetap disinkronkan. Dalam hal ini yang akan Anda lakukan adalah mengimplementasikan sesuatu yang disebut "handshaking". Anda pada dasarnya memuat data Anda pada jam sumber dan menahannya. Kemudian Anda mengirim sinyal permintaan (seperti dalam 1) melalui sinkronisasi. Setelah sinyal permintaan melintas Anda tahu bahwa bus data juga akan distabilkan di domain tujuan. Anda kemudian dapat memasukkannya ke bank register di tujuan. Tujuan kemudian mengirimkan pulsa terima kasih kembali untuk memberi tahu sumbernya bahwa ia dapat memuat kata berikutnya.

    Anda akan menggunakan bus semacam ini jika Anda perlu mengirim kata kontrol ke jam tujuan yang Anda perlu tahu bahwa itu sudah ada sebelum Anda mengirim yang lain (misalnya jika Anda mengirim perintah untuk melakukan sesuatu).

  3. Bus data - untuk data di mana Anda memiliki sumber yang mengeluarkan data secara terus-menerus atau dalam ledakan, Anda bisa dibilang lebih baik menggunakan FIFO daripada sinkronisasi. FIFO menggunakan memori dua jam untuk menyimpan data, bersama dengan penghitung untuk melacak berapa banyak data yang ada di FIFO. Anda menulis data ke FIFO ketika ada ruang, dan kemudian menambahkan alamat tulis. Alamat ini kemudian biasanya dikodekan ke dalam skema "Pengkodean Abu-abu" yang memastikan bahwa setiap kenaikan alamat hanya menyebabkan satubit di bus alamat untuk berubah (artinya Anda tidak perlu menyinkronkan beberapa bit). Alamat ini kemudian ditransfer ke domain tujuan (melalui salah satu rantai sinkronisasi Anda), yang dibandingkan dengan alamat baca. Jika ada data di FIFO, maka dapat dibaca dari memori menggunakan port jam tujuan. Alamat baca juga memiliki kode Gray dan dikirim kembali ke sumber melalui sinkronisasi lain sehingga port tulis dapat menghitung jika ada ruang di FIFO.

  4. Atur Ulang Sinyal - ini biasanya menggunakan versi sinkronisasi yang dimodifikasi dalam apa yang dikenal sebagai "Asynchronous Assert, Synchronous Deassert". Dalam versi modifikasi ini, input data ke flip flop pertama dikaitkan dengan GND, dan sebagai gantinya sinyal reset masuk dihubungkan ke sinyal preset asinkron dari setiap flip-flop di sinkronisasi. Ini menghasilkan sinyal output yang sepenuhnya tidak sinkron ketika menjadi tinggi, tetapi rantai sinkronisasi memastikan bahwa ia rendah secara serempak dengan jam tujuan dengan menghitung angka nol dalam rantai register.

    Jenis sinkronisasi ini buruk untuk data dan kontrol, tetapi sangat cocok untuk mengatur ulang sinyal. Jika semua logika tujuan memasukkan output rantai ini ke input reset asinkron dari register apa pun di domain, maka ada sedikit kekhawatiran tentang metastabilitas saat ditampilkan (meskipun asinkron) karena semua register dipaksa ke kondisi yang diketahui. Kemudian ketika sinyal reset di-deasserted di domain sumber, itu secara sinkron deasserts di domain tujuan yang berarti semua register keluar dari reset pada siklus clock yang sama (daripada +/- 1 siklus jika deassert asynchronous).


Seperti yang dapat Anda lihat di atas, jauh lebih kompleks untuk melakukan lintas domain-jam daripada hanya menempelkan sinkronisasi 2 flip-flop pada sinyal. Metode persis yang digunakan tergantung pada aplikasi.


Selain jawaban Tom, saya ingin menambahkan referensi ke PoC , yang memiliki implementasi untuk kasus-kasus ini. Dokumen sinkronisasi tersedia di RTD. Tambahan untuk teori chaining 2 flip-flop untuk sinkronisasi 2-FF dasar, PoC menyediakan implementasi khusus ( sync_Bits) untuk Xilinx dan Altera FPGAs untuk meningkatkan perilaku metastabilitas. Sinkronisasi 2-FF digunakan misalnya sync_Strobeuntuk membuat sinkronisasi yang lebih kompleks untuk pulsa.
Paebbels

Terima kasih atas pengantar yang rumit untuk strategi sinkronisasi. Gambar ini berasal dari "Jam domain persimpangan (CDC) desain & teknik verifikasi menggunakan systemverilog" oleh Clifford E. Cummings. Saya mengerti bahwa untuk sinyal satu-bit, lebarnya harus setidaknya 1 jam siklus + waktu pengaturan + waktu tunggu dari sisi penerima agar dapat melewati dengan aman. Dalam gambar ini, kriteria ini tidak terpenuhi karena denyut nadi adat disampling oleh sampel bclk hanya sekali pada ujungnya, yang menyebabkan bq1_dat menjadi metastable.
fiedel

... Sebagai hasilnya, pembacaan bq1_dat di tepi naik berikutnya dari bclk bisa berupa '0' atau '1'. Jadi sinkronisasi dalam gambar tampaknya tidak berhasil. Apakah saya benar?
fiedel

@ Paebbels Terima kasih untuk referensi. Akan kita lihat =)
fiedel

Anda harus mengedit ini dalam pertanyaan Anda, bukan mempostingnya sebagai jawaban, tetapi pada dasarnya, ya, Anda mungkin atau tidak bisa mendapatkan 1 pada output dalam contoh itu.
Tom Carpenter

1

1) Menggunakan gambar Anda sebagai contoh, aclk dan bclk saling tidak sinkron. Dengan kata lain, mereka memiliki sumber jam yang berbeda. Mereka menunjukkan adat sebagai data yang valid tetapi hanya disinkronkan ke ACLK. Di sinilah sinkronisasi bclk berperan.

2) Gambar ini mengasumsikan skenario terburuk, di mana bq1_dat adalah output yang berantakan karena bq1 FF hanya menangkap sebagian dari akhir data, menciptakan keadaan metastabil di mana output biasanya berupa sampah. Inilah triknya. Bq2 memiliki bclk yang sama dengan bq1, tetapi dibutuhkan 2 jam siklus bclk agar data dapat lewat dan muncul di bq2_dat.

3) Bagian bclk pertama yang diambil dari data, menghasilkan output yang berantakan, tetapi bclk kedua adalah satu siklus jam kemudian, cukup waktu untuk data ambigu dari bq1_dat untuk menetap dalam keadaan tinggi atau rendah. Denyut bq1_dat berantakan berlangsung cukup lama untuk bq2 untuk menangkap logika yang valid '1' (logika tinggi), dan meneruskannya ke bq2_dat sebagai data yang valid dan sekarang disinkronkan (logika tinggi).

4) Downstream, setiap jam menggunakan bclk akan memiliki data yang disinkronkan untuk bekerja dengannya. Perhatikan bahwa hanya FF bclk pertama yang harus berurusan dengan kondisi metastabil . Hasilnya bisa menjadi logika rendah jika adat hanya terlambat pico atau nano detik. Ingat sandal jepit ini sampel input data hanya di tepi naik jam. Apa yang terjadi sebelum atau sesudah sisi naik diabaikan.


Namun perlu dicatat, bahwa penundaan bclk hanya memberikan ukuran keselamatan yang probabilistik, dan jumlah persisnya tergantung pada teknologi FF dan periode bclk. Dalam beberapa kasus hi-rel 3 atau lebih tahap mungkin diperlukan untuk menurunkan tingkat kesalahan ke tingkat yang dapat diterima.
WhatRoughBeast

@WhatRoughBeast. Saya tahu bahwa dalam skenario terburuk banyak tahap sinkronisasi diperlukan, ditambah penyaringan digital. Jelas jawaban saya terlalu sederhana.
Sparky256

@ Sparky256 Apa yang membingungkan saya adalah 3) dalam komentar Anda. Bagaimana bisa bq2 menangkap '1' saat bq1_dat dalam kondisi metastable?
fiedel

@fiedel, dua hal berkontribusi pada bq2 karena dapat menangkap input bersih (setidaknya). Pertama, kondisi metastabil perlu bertahan untuk siklus clock penuh. Kedua, nilai metastable (pseudo-mid-rail) dari bq1 bisa tidak mungkin (atau dioptimalkan untuk menghindari) berada di jendela yang juga akan menyebabkan bq2 menjadi metastable - tetapi terutama yang pertama dari ini. Katakanlah hasil teknologi dalam peluang 5% dari metastabilitas bertahan cukup lama. tahap sinkronisasi 3-FF akan mengurangi ini menjadi 0,25% karena kedua sel harus gagal. Messy dalam praktiknya merupakan penyimpangan eksponensial yang jelas dari keadaan hampir stabil.
Sean Houlihane

@SeanHoulihane. Terima kasih untuk penjelasannya. Istilah 'naik tepi' membingungkan beberapa karena jendela menerima data (metastabil atau stabil) berada di titik tengah tepi naik, hanya berlangsung beberapa pico atau nano detik saja. Hanya pada saat itu adalah data input pada logika '1' atau '0', apakah itu metastable atau stabil, tergantung pada level tegangannya dibandingkan dengan ambang IC untuk logika 1 atau 0.
Sparky256
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.