Skip to content

Teknik Konseptler

Bu belge, tar32 projesi içinde kullanılan temel teknolojilerin arka planını açıklar.

Verilator: Simülasyonu

Olay bazlı simülatörlerin (örneğin IVerilog) aksine, Verilator bir derleyici gibi davranır. SystemVerilog RTL kodunu yüksek performanslı, multithreaded C++ modellerine çevirir.

Neden Kullanıyoruz?

  1. Çalışma Hızı: Verilator geleneksel simülatörlerden 10 ila 100 kat daha yüksek verim sağlar. Bu sayede yazılım ve RTL donanımını saniyeler içinde simüle edebiliriz.
  2. Modern Doğrulama: C++ çıktıları sayesinde, standart C kütüphanelerini test benchlerimize entegre edebiliriz.
  3. Statik Mantık Analizi: Verilator, SystemVerilog standartlarını sıkı bir şekilde uygular ve hatalı olabilecek tasarımları örneğin istenmeyen bit genişliği uyuşmazlıkları derleme aşamasında yakalar.

Verilator İçin Özel RTL Düzeltmeleri

Verilator'un katı kuralları nedeniyle bazı standart SystemVerilog kullanımları uyarı vermektedir . Örneğin $clog2 kullanımı sırasında ortaya çıkabilecek uç durumları düzeltmek için üçlü operatör yapıları kullanılabilir , bu durum verilator içinproje üzerinde tar32_obi_to_axi_patched.sv altında geçici düznlemesi yapılmıştır:

// Verilator Düzeltmesi: Genişlikler eşit olduğunda $clog2(0) verebileceği için
// statik analizde hata vermesini engellemek adına 1 değeri zorlanır.
localparam int EXTRACT_W = (W1 == W2) ? 1 : $clog2(...);

Bender: Bağımlılık Yönetimi

Bender, donanım IP'leri için temel bağımlılık yöneticimizdir. Yazılım dünyasındaki paket yöneticileri (örn. Cargo, NPM) gibi çalışır.

Çalışma Mantığı

  1. Manifest Tanımı: Bender.yml gereken IP'leri ve sürümlerini veya Git etiketlerini listeler.
  2. Sürüm Sabitleme: Bender.lock tüm geliştiricilerin aynı IP sürümlerini kullanmasını sağlar.
  3. Yerel Çözümleme: bender checkout komutu, bağımlılıkları gizli .bender dizinine indirerek depoda yer kaplamasını engeller.

Docker & Gosu: Ortam İzolasyonu

Geliştirme ortamındaki toolchain tutarlılığını sağlamak için Docker kullanıyoruz.

Neden Kullanıyoruz?

GCC derleyicileri, Verilator ve sistem kütüphanelerini bir konteynere almak donanım geliştirmedeki versiyon uyumsuzluklarından kaynaklanan hataları engeller.

Senkronizasyon (Gosu)

Konteynerin root yetkisiyle oluşturduğu dosyaların ana işletim sisteminde sorun yaratmasını engellemek için Gosu kullanılır. Bu araç, konteyner içindeki işlemleri kullanıcının UID/GID bilgileriyle eşleyerek erişim sorunlarını çözer.

Protokol Mimarisi: OBI ve AXI

Sistem, çekirdek performansı ile sistem birimleri arası iletişimi dengelemek için katmanlı bir veriyolu mimarisi kullanır.

OBI (Açık Veriyolu Arayüzü / Open Bus Interface)

CV32E40P çekirdeğinin kullandığı protokoldür. Düşük gecikmeli bellek erişimi için optimize edilmiş bir yapıya sahiptir.

AXI (Gelişmiş Genişletilebilir Arayüz / Advanced eXtensible Interface)

Sistem geneli bağlantılar için endüstri standardıdır. Daha karmaşık ağ yapılarını kurmak ve standart IP birimlerini entegre etmek için ana veriyolumuzda AXI4 kullanıyoruz.

Protokol Köprüsü

rtl/bus/obi-axi-bridge içindeki bu yapı, OBI ile AXI arasındaki iletişimi çevirerek çekirdek ile çevre birimlerini bağlar.

Sentez Stratejisi: Out-of-Context (OOC)

Modül doğrulaması için Out-of-Context (OOC) sentez yöntemini kullanıyoruz.

Neden Kullanıyoruz?

Normal sentezde tek bir modülü test etmek için tüm sistemi derlemek gerekir. OOC sentezi ile bağımsız modülleri izole olarak sentezleyebilir, mantık alanı (LUT/FF) sonuçlarını tüm sistemi işlemeden saniyeler içinde görebiliriz.