Veri yolu eşleyici devreleri için zamanlama kısıtı


10

Saat etki alanlarına geniş bir kayıt geçirmek için bir veri yolu eşleyici devresim var.

Eşzamansız sıfırlama mantığını atlayarak basitleştirilmiş bir açıklama sağlayacağım.

Veriler bir saatte üretilir. Güncellemeler birbirinden çok (en az bir düzine) saat kenarından oluşuyor:

PROCESS (src_clk)
BEGIN
   IF RISING_EDGE(clock) THEN
      IF computation_done THEN
          data <= computation;
          ready_spin <= NOT ready_spin;
      END IF;
   END IF;
END PROCESS;

NRZI kodlu taze veriler için kontrol sinyali (bu nedenle veri yolundaki geçerli bir kelime, kontrol sinyali üzerindeki bir geçişe karşılık gelir). Kontrol sinyali, bir eşleyici olarak işlev gören bir DFF zincirinden geçer.

PROCESS (dest_clk)
BEGIN
   IF RISING_EDGE(dest_clk) THEN
      ready_spin_q3 <= ready_spin_q2;
      ready_spin_q2 <= ready_spin_q1;
      ready_spin_q1 <= ready_spin;
   END IF;
END PROCESS;

Senkronizör devresi, veri yolunun dengelenmesi için bolca zaman sağlayan kısa bir gecikme sağlar; veri yolu, metastabilite riski olmadan doğrudan örneklenir:

PROCESS (dest_clk)
BEGIN
   IF RISING_EDGE(dest_clk) THEN
      IF ready_spin_q3 /= ready_spin_q2 THEN
         rx_data <= data;
      END IF;
   END IF;
END PROCESS;

Bu, bir Siklon II FPGA içine sentezlendiğinde derlenir ve iyi çalışır. Ancak TimeQuest, senkronizörü tanımadığından kurulum ve tutma süresi ihlallerini bildirir. Daha da kötüsü, Quartus el kitabı diyor

En kötü boşluğu gösteren yolları geliştirmeye odaklanın. Tesisatçı, en kötü gevşekli yollarda en çok çalışır. Bu yolları düzeltirseniz, Tesisatçı tasarımdaki diğer başarısız zamanlama yollarını iyileştirebilir.

Bu yüzden Quartus'un Fitter çabasını tasarımın diğer alanlarına harcayabilmesi için projeme doğru zamanlama kısıtlamalarını eklemek istiyorum.

set_multicycle_pathDoğru SDC (Synopsis Tasarım Kısıtı) komutunun olduğundan eminim , çünkü veri satırları hedef saatin stabilize edilmesi için birden fazla döngüye sahip olacak, ancak saat etki alanı geçiş mantığını tanımlamak için bu komutu kullanarak tam örnekleri bulamıyorum .

Senkronizörler için SDC zamanlama kısıtlamaları yazma konusunda bazı rehberliklerden gerçekten memnun olurum. Bu yaklaşımla ilgili bir sorun görürseniz, lütfen bunu da bana bildirin.


Saat detay:

Harici saat üreteci: İki kanal, refclk = 20 MHz, refclk2 = refclk / 2 (10 MHz ve ilgili).

Altera PLL: src_clk = refclk * 9/5 = 36 MHz

Altera PLL: dest_clk = refclk2 * 10 = 100 MHz

Ayrıca 100 MHz src_clk ve 36 MHz dest_clk ile diğer yöne giden veri var.


TL; DR: Yukarıdaki kod için doğru SDC zamanlama kısıtlamaları nelerdir?


1
Bu, önerilen FPGA Tasarım sitesinde daha iyi olurdu, ancak bu teklif henüz beta sürümüne ulaşmadı.
Ben Voigt

Src_clk ve dest_clk için saat tanımlarını gönderebilir misiniz? Herhangi bir şekilde ilişkili mi (senkron katlar)? Eğer ilgisiz saatler ise, bu durumda set_false_path kullanmak tipiktir.
Andy

@Andy: Bazı detayları ekledim. Bu konuda yardım ettiğiniz için teşekkürler.
Ben Voigt

Yanıtlar:


9

Quartus ile deneyimim yok, bu yüzden bunu genel tavsiye olarak kabul edin.

Saat alanları arasındaki yollar üzerinde çalışırken, zamanlama araçları saatleri dönemlerinin en az kullanılan katına genişletir ve en yakın kenar çiftini seçer.

36 MHz saatten (27.777 ns) 100 MHz saatine (10 ns) kadar yollar için, hızlı hesaplamaları doğru yaparsam, en yakın yükselen kenar çifti kaynak saatte 138.888 ns ve hedef saatte 140 ns'dir. Bu, bu yollar için etkili bir şekilde 900 MHz'lik bir kısıtlamadır! Yuvarlamaya bağlı olarak (veya ilişkisi olmayan saatler için), bundan daha kötü olabilir.

Bu yapı için kısıtlama yazmanın en az üç yolu vardır. Saatleri arayacağım fast_clkve slow_clksanırım illüstrasyon için daha net.

1.Seçenek: ile zamanlamayı devre dışı bırakın set_false_path

En kolay çözüm, set_false_pathsaatler arasındaki zamanlamayı devre dışı bırakmak için kullanmaktır :

set_false_path -from [get_clocks fast_clk] -to [get_clocks slow_clk]
set_false_path -from [get_clocks slow_clk] -to [get_clocks fast_clk]

Eşitleyicinin düzgün çalışması için zamanlama gereksinimleri olduğundan bu kesinlikle doğru değildir. Fiziksel uygulama, verileri kontrol sinyaline göre çok fazla geciktirirse, senkronize edici çalışmaz. Ancak, yolda herhangi bir mantık olmadığından, zamanlama kısıtlamasının ihlal edilmesi olası değildir. set_false_pathdüşük olasılık başarısızlıkları için çaba ve risk dengesinin FPGA'lardan daha ihtiyatlı olduğu ASIC'lerde bile bu tür yapı için yaygın olarak kullanılır.

2.Seçenek: Kısıtlamayı set_multicycle_path

İle belirli yollar için ek süreye izin verebilirsiniz set_multicycle_path. Çok ilişkili yollarla (örn. 1X ve 2X saatleri etkileşen) çok tekerlekli bisiklet yollarını kullanmak daha yaygındır, ancak araç yeterince destekliyorsa burada çalışacaktır.

set_multicycle_path 2 -from [get_clocks slow_clk] -to [get_clocks fast_clk] -end -setup
set_multicycle_path 1 -from [get_clocks slow_clk] -to [get_clocks fast_clk] -end -hold

Kurulum için varsayılan kenar ilişkisi tek döngüdür, yani set_multicycle_path 1. Bu komutlar -end, kurulum yolları için bitiş noktası saatinin ( ) bir döngüsüne izin verir . -holdDaha aşağıya bakınız için, çok bisiklet yolu ayarlarken az kurulum kısıtlaması büyük bir sayı biriyle ayar hemen hemen her zaman ihtiyaç vardır.

Benzer şekilde, değişim (hızlı saatinin bir periyodu ile kısıtlamasını rahatlatıcı) diğer yönde constrain yollarına -endiçin -start:

set_multicycle_path 2 -from [get_clocks fast_clk] -to [get_clocks slow_clk] -start -setup
set_multicycle_path 1 -from [get_clocks fast_clk] -to [get_clocks slow_clk] -start -hold

Seçenek 3: Gereksinimi Doğrudan set_max_delay

Bu, etkisine benzer, set_multicycle_pathancak kenar ilişkileri ve tutma kısıtlamaları üzerindeki etkiyi düşünmek zorunda kalmaz.

set_max_delay 10 -from [get_clocks fast_clk] -to [get_clocks slow_clk]
set_max_delay 10 -from [get_clocks slow_clk] -to [get_clocks fast_clk]

set_min_delayBekletme denetimleri için bunu eşleştirmek veya varsayılan bekletme denetimini yerinde bırakmak isteyebilirsiniz . set_false_path -holdAracınız destekliyorsa, bekletme denetimlerini devre dışı bırakmak da yapabilirsiniz .


Çok döngülü yollar için kenar seçiminin kanlı ayrıntıları

Her kurulum ayarıyla eşleştirilen bekletme ayarlamasını anlamak için, 3: 2 ilişkisine sahip bu basit örneği düşünün. Her basamak yükselen bir saat kenarını temsil eder:

1     2     3
4   5   6   7

Varsayılan kurulum denetimi kenar 2 ve 6'yı kullanır. Varsayılan tutma kontrolü kenar 1 ve 4'ü kullanır.

2 ile çok döngülü bir kısıtlama uygulandığında -end, varsayılan kurulum ve tutma denetimleri başlangıçta kullandıklarından sonra bir sonraki kenarı kullanacak şekilde ayarlanır, yani kurulum denetimi artık kenar 2 ve 7 kullanır ve tutma denetimi kenar 1 ve 5 kullanır. aynı frekanstaki saatler, bu ayar mantıklıdır - her veri başlatması bir veri yakalamaya karşılık gelir ve yakalama kenarı birer birer hareket ettirilirse, tutma kontrolü de birer birer hareket etmelidir. Dallardan birinin büyük bir gecikmesi varsa, bu tür bir kısıtlama, tek bir saatin iki dalı için anlamlı olabilir. Bununla birlikte, buradaki durum için, kenarlar 1 ve 5'i kullanarak bir tutma kontrolü arzu edilmez, çünkü bunu düzeltmenin tek yolu yola tüm saat gecikme döngüsünü eklemektir.

1 çoklu döngü tutma kısıtlaması (tutma için varsayılan 0'dır) hedef kontrol saatinin kenarını tutma kontrolleri için bir kenar geriye doğru ayarlar. 2 zamanlı kurulum MCP ve 1 zamanlı tutma MCP kısıtlamalarının kombinasyonu, kenarlar 2 ve 7'yi kullanarak bir kurulum kontrolü ve kenarlar 1 ve 4'ü kullanarak bir tutma kontrolü ile sonuçlanır.


2

Altera için cevabı bilmiyorum, ancak Xilinx Land'de bir saat alanından diğerine zaman gecikmesini ayarlayabilirsiniz. Matematiği çalışmanız gerekecek (tasarıma bağlı), ancak genellikle iki saat süresinin en kısa olanıdır. Bu süreyi herhangi iki sinyal arasındaki (kontrol sinyaliniz dahil) maksimum eğrilik olarak düşünün ve senkronizasyon devreniz bununla başa çıkıp çıkamayacağını çözebilirsiniz.

set_mulicycle_path kullanmak için doğru bir şey değildir, çünkü bu normalde hem kaynak hem de hedef aynı saat alanında olduğunda durumlarla ilgilenir. Yine, Xilinx deneyimimden yola çıkıyorum, böylece kilometreniz değişebilir.


1

Senkronizör üzerine bir set_false_path koymak güvenli olduğunu düşünüyorum.

Ayrıca Quartus'un senkronizörü bulmasına yardımcı olmak için qsf'ye "set_global_assignment -name SYNCHRONIZER_IDENTIFICATION AUTO" koyabilirsiniz.


Bu nasıl olurdu? set_false_path -from ready_spin -to ready_spin_q2? Ya set_false_path -from data -to rx_data?
Ben Voigt

set_false_path -from src_clk -to ready_spinSenkronize olmadığınız için yanlış yolu veriye koymanın uygun olmadığından emin değilim.
fbo

0

Sorunun, otobüs sinyallerinin kilitlendikleri noktaya yakın bir yerde değişmeyeceğini bildiğiniz halde, yazılımın bunu bilmediğinden şüpheleniyorum. En iyi seçeneğiniz, muhtemelen yazılıma gelen veri yolu sinyallerinin veri yolu saatiyle senkronize olduğunu ve gerçekte onları kilitlediğiniz yerden önce tüm optimizasyonları devre dışı bırakmaktır (bir optimizatör teorik olarak devrenizi teorik olarak eşdeğer olanla değiştirebilir) girişler gerçekten eşzamanlıysa, ancak çizdiğiniz devrenin umursamayacağı saat döngülerinde değişirse bir döngü için atılabilir).


set_multicycle_pathSentezleyici / zamanlama analizörüne kaynak sinyallerinin ne sıklıkta değişebileceğini söylemenin yolu olmaz mı? Ve "otobüs saati" ile ne demek istediğinden emin değilim, burada saat alanlarını geçen bir sinyal otobüsü var, peki hangi saati "otobüs saati" olarak adlandırıyorsun? Sanırım sentezleyicinin güncellemediğim dönemlerde aksaklıklar ortaya çıkarması durumunda hala metastabilite olabilir data. Özellikle orada DFF blokları somutlaştırmak olabilir sanırım :(
Ben Voigt

@BenVoigt: Bence "set_multicycle_path" daha çok zamanlama doğrulayıcısına iki mandallama noktası arasındaki kombinatoryal mantık zincirinin N (Tc) -Ts-Tp (N çarpı döngü süresi eksi örnek zaman eksi mandalını almasına izin verilmesi gerektiğini söylemek için kullanılır) yayılma zamanı) sadece Tc-Ts-Th yerine. Böyle bir şeyin farklı saatler tarafından mandallama ile nasıl etkileşime gireceğini bilmiyorum.
supercat
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.