Geliştirme İş Akışı

Stabil bir SoC mimarisi sürdürmek için projeye katkı sağlayan herkesin belirlenen geliştirme döngüsüne uyması zorunludur. Bu süreç, yeni donanım mantığının ana sisteme dahil edilmeden önce bağımsız olarak doğrulanmasını sağlar.

Git Stratejisi

Özellik odaklı dallanma modeli kullanıyoruz. Doğrudan main veya develop dallarına işleme (commit) yapmak yasaktır.

main: Üretime hazır, tam doğrulanmış donanım kodu.
develop: Onaylanan tüm yeni özelliklerin birleştirildiği (entegre edildiği) dal.
feat/<ozellik-adi>: Yeni donanım modülleri veya sürücülerin geliştirildiği dal.

Modül Geliştirme Döngüsü

Yeni bir RTL modülü , örneğin bir zamanlayıcı veya çevre birimi eklerken bu adımları sırasıyla uygulayın. Bu sıralama, hataları olabilecek en temelde seviyede farkedebilmek için tasarlanmıştır.

1. Aşama: Tanımlama

Kod yazmaya başlamadan önce modülün sistem içindeki yerini belirleyin.

Modülü oluşturmak için otomasyon aracını kullanın: python3 tar32.py add-module <isim>
Dosyanızı Bender.yml içine ekleyin.

2. Aşama: Statik Analiz (Linting)

SystemVerilog standartlarına uygunluğu denetlemek için analizi çalıştırın:

python3 tar32.py lint --all

Neden Önemli?: Verilator, bit genişliği hatalarına ve kullanılmayan sinyallere karşı çok katı kurallara sahiptir. Bu hataları erken yakalamak, simülasyonda günlerce hata aramamızı engeller.

3. Aşama: Bağımsız Doğrulama (Birim Testi)

Modülü sistemin geri kalanından bağımsız olarak test edin:

python3 tar32.py sim unit --module <modul_adi>

Neden Önemli?: SoC'nin tüm karmaşıklığı (AXI protokolleri vs.) olmadan temel mantık ,örneğin bir sayaç veya FSM hatalarını görmek içindir. Tüm sistemi simüle etmekten çok daha hızlıdır.

4. Aşama: Sistem Entegrasyonu (SoC Simülasyonu)

Modülünüzü top_soc.sv içerisine entegre edin ve yazılım tabanlı testlerle çalıştırın:

python3 tar32.py sim soc

Neden Önemli?: Modül tek başına çalışsa bile OBI/AXI protokol kurallarını ihlal edebilir veya adres çakışmalarına neden olabilir. Yazılımın donanımla uyumunu burada doğrularız.

5. Aşama: Sentez Doğrulaması (Pipeline)

Tasarladığınız mantığın fiziksel donanıma çevrilebilirliğini ölçün:

python3 tar32.py pipeline

Neden Önemli?: Simülasyon sadece mantığı kontrol eder. Sentez ise kodunuzun gerçek bir FPGA'ya sığıp sığamayacağını (Alan) ve saat hızlarına yetişip yetişemeyeceğini (Zamanlama) belirler.

İşleme (Commit) Kuralları

Anlaşılır bir proje geçmişi için Geleneksel Commit (Conventional Commits) yapısını kullanıyoruz ve altyapıda ingilizce commit geçmiş yapısını tercih ediyoruz:

Tür	Hedef
rtl	Donanım (RTL) mantığı ve ayarları.
sw	Sürücüler, yazılımlar ve başlatma kodları.
feat	Yeni mimari özellikler.
fix	Hata düzeltmeleri.
ci	Otomasyon scriptleri ve Docker ayarları.

Örnek: rtl: MAC unit stages have optimized for timing

Kod Birleştirme (Pull Request) Şartları

Bir değişikliğin (PR) develop dalına eklenebilmesi için şu şartları sağlaması gerekir:

Test Başarısı: python3 tar32.py pipeline komutunun hiç hata vermeden tamamlanması.
Sentez Verisi: Yeni modülün LUT/FF donanım kullanım limitlerini aşmadığını gösteren bir rapor.
Ekip Onayı: En az bir takım arkadaşının kod yapısını (RTL stili) onaylaması.