VHDL Tasarımı Verilator ve UVM ile Doğrulanır mı? DO-254 DAL A Gözünden Bir Değerlendirme

Blog · Derinlemesine Analiz | Verilator artık UVM çalıştırabiliyor. Peki emniyet kritik bir aviyonik projede, üstelik VHDL ile yazılmış bir tasarımda bu ne işe yarar? Üç senaryoyu (VHDL tasarım, SystemVerilog tasarım, Vivado netlist'i), elemental analizi ve kapsam motorlarının iç işleyişini inceledik.

Açık kaynak dünyasında son iki yılın en çok konuşulan gelişmelerinden biri, Verilator'ün UVM testbench'lerini çalıştırabilir hâle gelmesi. Accellera'nın Ağustos 2026 tarihli 2020.3.2 kiti de ilk kez bir Verilator arka ucu içeriyor (sürüm karşılaştırması yazımızda anlatmıştık). Lisanssız, hızlı ve UVM konuşan bir simülatör kulağa çok cazip geliyor.

Bu yazıda soruyu en zor yerinden soruyoruz: VHDL ile yazılmış, DO-254 DAL A seviyesinde bir FPGA tasarımını Verilator ve UVM ile doğrulamak mümkün mü, mümkünse mantıklı mı? Karşılaştırma noktamız, aynı UVM testbench'in ticari bir simülatörde (ModelSim/Questa) koşulduğu akış. Böylece metodoloji sabit kalıyor, yalnızca simülatör değişiyor.

Bir not: bu yazı araç dokümantasyonuna ve yayımlanmış kaynaklara dayanan bir masa başı incelemesidir. Araçlar hızlı değişiyor; kendi akışınızda küçük bir denemeyle doğrulamadan karar vermeyin. DO-254 yorumları da sertifikasyon tavsiyesi değildir, son söz sertifikasyon otoritenizindir.

Kısa Cevap

Gerisi bu tablonun gerekçesi.

Verilator Bugün Nerede? (Ekim 2026)

• UVM: Antmicro'nun Ekim 2025 duyurusuna göre upstream UVM 2017 kütüphanesi yamasız çalıştırılabiliyor. Mayıs 2026'daki Latch-Up konferansında UVM 2020'nin derlendiği, gerçek doğrulama kod tabanlarında (örneğin RISCV-DV) kalan çalışma zamanı sorunları üzerinde çalışıldığı aktarıldı.
• VHDL: Destek yok. Verilator bir Verilog/SystemVerilog simülatörü; karışık dilli tasarımları da okumuyor.
• Dört durumlu mantık: Verilator iki durumlu (0/1) çalışıyor. X/Z desteği aktif geliştirme altında, henüz olgun değil.
• Kapsam: Satır/dal, toggle ve expression kapsamı var; covergroup desteği gelmiş; FSM kapsamı deneysel. Ayrıntılar aşağıda.
• Zamanlama: Bildiğimiz kadarıyla SDF back-annotation yok; specify bloklarındaki zamanlama bilgisi fonksiyonel simülasyonda yok sayılıyor.

Yani "Verilator desteği geldi" cümlesi UVM için doğru, VHDL için değil.

DO-254 DAL A Ne İster?

DO-254 (Avrupa'da ED-80), havacılıkta kullanılan karmaşık elektronik donanımın geliştirme güvencesi standardıdır. DAL A, arızası felaketle sonuçlanabilecek işlevlerin seviyesidir. Konumuz açısından dört beklenti belirleyici:

1. Gereksinim bazlı doğrulama. Her test bir gereksinime izlenir, her gereksinim test edilir.
2. Elemental analiz (Appendix B). DAL A ve B için, gereksinim bazlı testlerin tasarımın her elemanını çalıştırdığı gösterilir. HDL tasarımlarda bunun kabul gören yolu code coverage'dır.
3. Araç değerlendirmesi (§11.4). Çıktısı sertifikasyon kanıtı olan araçlar için bağımsız çıktı değerlendirmesi, ilgili servis geçmişi ya da kalifikasyon gerekir.
4. Zamanlama doğrulaması. Fonksiyonel simülasyon tek başına yetmez; yerleştirme sonrası zamanlama da ele alınır.

Senaryo 1: Tasarım VHDL

Verilator VHDL okumadığı için önce tasarımı Verilog'a çevirmek gerekir. Açık kaynak yol GHDL'in sentez çıktısıdır:

# Örnek amaçlıdır
ghdl -a --std=08 src/*.vhd
ghdl --synth --std=08 --out=verilog my_top > my_top.v

Buradan sonra altı ayrı sorun başlar:

1. Doğrulanan şey tasarımınız olmaz. Testler çevrilmiş netlist üzerinde koşar. Çeviricinin doğruluğunu ve VHDL ile eşdeğerliği ayrıca kanıtlamanız gerekir.
2. Elemental analiz kırılır. Code coverage, yaşam döngüsü verisi olan VHDL kaynağına izlenebilir olmalıdır. Çevrilmiş ve çoğunlukla düzleştirilmiş Verilog'un kapsamı VHDL satırlarına geri eşlenemez.
3. İki durumlu simülasyon. std_logic'in 'U' ve 'X' yayılımı kaybolur. İlklenmemiş register, eksik reset ve bus çakışması gibi hatalar maskelenir.
4. Zamanlama simülasyonu ve vendor modelleri. SDF olmadan yerleştirme sonrası zamanlama simülasyonu yapılamaz; şifreli vendor modelleri de çalışmaz.
5. Araç değerlendirmesi. Questa/ModelSim'in yaygın sertifikasyon geçmişi var. Verilator için, çevirici ve UVM kütüphanesi dahil, argümanı sıfırdan siz kurarsınız. Sık sürüm çıkması konfigürasyon yönetimini de zorlaştırır.
6. Constrained-random ve izlenebilirlik. Rastgele testlerin gereksinimlere izlenmesi, seed tekrarlanabilirliği ve prosedür gözden geçirmesi ek süreç yükü getirir. Bu madde simülatörden bağımsızdır; UVM'i nerede koşarsanız koşun geçerlidir.

Üçüncü maddeyi küçük bir örnek somutlaştırır:

logic [7:0] cnt;                       // reset unutulmuş
always_ff @(posedge clk) cnt <= cnt + 1;

// 4 durumlu simülatör : cnt hep X kalır, hata ilk dalga formunda görünür
// 2 durumlu simülatör : cnt 0'dan (ya da rastgele bir değerden) saymaya başlar

Verilator'de başlangıç değerlerini rastgeleleştirmek (--x-initial unique ve çalışma zamanında +verilator+rand+reset+2) kısmi bir önlemdir, ama X yayılımının yerini tutmaz.

ModelSim/Questa + UVM ile karşılaştırma

Ticari simülatörde aynı iş karışık dilli simülasyonla yapılır: testbench SystemVerilog UVM, DUT ise olduğu gibi VHDL kalır. İki akışta da metodoloji UVM olduğu için farkın tamamı simülatörden gelir.

Bir not: bildiğimiz kadarıyla tam UVM (sınıflar, constrained-random, covergroup) için ModelSim yetmez, Questa lisansı gerekir. Yazının devamında bu yüzden Questa adını kullanıyoruz.

VHDL tasarım için daha uygun yollar

• UVM metodolojisi istiyorsanız: Yukarıdaki karışık dilli akış doğru adrestir. Testbench UVM olur, tasarım VHDL kalır, kapsam VHDL kaynağından toplanır.
• Lisanssız ve hızlı regresyon istiyorsanız: NVC ve GHDL, VHDL'i çevirmeden doğrudan simüle eder. Bunları kredi dışı hata avı için kullanıp resmî koşuları ticari simülatörde tutabilirsiniz. Bedeli, bu araçlar UVM çalıştırmadığı için ayrı bir testbench katmanıdır (VHDL tabanlı bir kütüphane ya da cocotb gibi).

Senaryo 2: Tasarım SystemVerilog Olsaydı

Tablo epey değişir, çünkü en büyük engel ortadan kalkar.

Çözülenler:

• Doğrulanan şey doğrudan tasarım kaynağınızdır; çevirici ve eşdeğerlik kanıtı gerekmez.
• Code coverage SystemVerilog satırlarınıza doğrudan izlenir.
• Aynı UVM testbench hem Verilator'de hem Questa'da koşabilir (Verilator'ün desteklediği alt kümede kalırsanız).

Kalanlar: iki durumlu simülasyon, SDF ve şifreli vendor IP eksikliği, araç değerlendirmesi yükü ve bir sonraki bölümde anlatılan kapsam metriği boşlukları.

Bu yüzden gerçekçi kullanım iki simülatörlü modeldir:

Bu modelde Verilator kredi iddia etmediği için araç değerlendirmesi yükü doğmaz. İki simülatörün aynı testte aynı sonucu vermesi de ticari simülatör için ek bir çapraz kontrol olur. Bedeli, testbench'i iki araçta da derlenir tutma disiplinidir. Başlangıç noktası olarak Antmicro'nun verilator-uvm-example deposuna bakılabilir.

Elemental Analiz: Aracın İşi mi, Mühendisin İşi mi?

Sık yapılan bir hata, elemental analizi bir araç özelliği sanmaktır. Elemental analiz sizin yürüttüğünüz bir analizdir: gereksinim bazlı testlerin her tasarım elemanını çalıştırdığını gösterir, kapanmayan her noktayı da tek tek gerekçelendirirsiniz. Aracın işi bunun için code coverage verisi üretmektir.

Benzetme: Kapsam aracı bir sayaçtır. Elemental analiz ise sayacın gösterdiği her boşluğun hesabını vermektir: ya yeni bir test yazarsınız, ya gereksinimin eksik olduğunu fark edersiniz, ya da o kodun neden çalıştırılamayacağını belgelersiniz.

Verilator (SystemVerilog tasarımda) bu veriyi üretiyor. Güncel kılavuza (5.052) göre durum:

Sonuç: SystemVerilog tasarımda Verilator ile elemental analiz yapılabilir, ama metrik boşluklarını elle doldurmanız ve aracı kendiniz savunmanız gerekir. Hangi metriklerin zorunlu sayılacağını planlama dokümanlarınızda (PHAC, HVP) siz tanımlarsınız; otoriteyle anlaştığınız metrik seti dar ise bu boşlukların bir kısmı sizi hiç etkilemeyebilir.

Code coverage ile functional coverage farkını ayrı bir derste anlatmıştık.

Kapsam Motoru Nasıl Çalışır?

Temel yöntem enstrümantasyondur: simülatör tasarımı derlerken kendi iç modeline sayaçlar ekler ve simülasyon sırasında bunları artırır.

• Statement/branch: Her ifade bloğuna ve her dal koluna (örtük else dahil) bir sayaç konur; yürütme oradan geçince artar.
• Condition/expression: Karar her değerlendirildiğinde alt terimlerin değer vektörü kaydedilir; her terimin sonucu tek başına değiştirip değiştirmediğine bakılır.
• Toggle: Her bit için 0→1 ve 1→0 geçişleri izlenir.
• FSM: Durum register'ı derleme aşamasında kod kalıbından tanınır; durumlar ve geçişler sayılır.
• Fonksiyonel: Covergroup'lar tanımlı olayda örneklenir, bin sayaçları artar.

Sonuçlar bir veritabanına yazılır ve koşular arasında birleştirilir. Verilator'de aynı iş, üretilen C++ modeline eklenen sayaç artırımlarıyla yapılır.

Peki tüm sinyallerin VCD'sinden kapsam çıkarılamaz mı?

Teorik olarak evet. Ancak toggle dışındaki metriklerde iş, "VCD'yi okumak"tan çıkıp fiilen ikinci bir simülatör yazmaya dönüşür.

Sorun şu: VCD değerleri kaydeder, kontrol akışını kaydetmez.

always_ff @(posedge clk) begin
  if (en) q <= d;      // d zaten q'ya eşitse VCD'de hiçbir iz kalmaz
  else    q <= q_hold; // iki dal aynı değeri atıyorsa birbirinden ayırt edilemez
end

Hangi dalın alındığını bulmak için HDL'i ayrıştırıp her process'i kayıtlı sinyal değerleriyle yeniden yürütmeniz gerekir. Sentezlenebilir RTL'de bu mümkündür, çünkü kontrol akışı sinyal değerlerinin deterministik bir fonksiyonudur. Zorluk eksik bilgidedir:

• Process içi değişkenler ve fonksiyon içleri VCD'de yoktur.
• Delta çevrimleri tek zaman damgasına çöker.
• Bellekler ve diziler çoğu zaman dökülmez.
• VHDL'de 9 değerli std_logic VCD'nin 4 değerine iner, enum tipleri de düzgün taşınmaz.

Bu yaklaşımın gerçek bir örneği açık kaynak Covered aracıdır: Verilog kaynağını ve dump dosyasını alıp satır, toggle, kombinasyonel mantık ve FSM kapsamını sonradan hesaplar. Bildiğimiz kadarıyla eski bir araçtır, bakımı yapılmıyor ve VHDL desteklemiyor.

DO-254 açısından ilginç bir kullanım da var. Tek kapsam kaynağı olarak kendi yazdığınız aracı savunmak ağır bir yüktür. Ama VCD'den bağımsız hesaplanan toggle ve FSM kapsamını simülatörün raporuyla karşılaştırmak, simülatörün kapsam çıktısı için bağımsız değerlendirme argümanını destekleyebilir. Kabul edilip edilmeyeceği otoriteyle konuşulacak bir konudur.

Pratik not: tüm sinyallerin VCD'si uzun koşularda çok büyür. Böyle bir iş için sıkıştırılmış bir format (FST gibi) ya da simülasyon sırasında akış hâlinde işleme daha uygundur.

Senaryo 3: VHDL Tasarımın Vivado Netlist'i

Akla gelen bir başka yol: VHDL'i Vivado'da sentezleyip Verilog netlist'i Verilator'e vermek.

# Örnek amaçlıdır
synth_design -top my_top -part xc7z020clg400-1 -flatten_hierarchy none
write_verilog -mode funcsim -force my_top_funcsim.v

Çıktı, UNISIM primitive'lerinden oluşan yapısal bir netlist'tir. Simüle etmek için Vivado'nun unisims Verilog kaynaklarını ve glbl.v'yi de derlemeniz gerekir.

Verilator tarafında iki şey işi kolaylaştırır: kullanıcı tanımlı primitive (UDP) desteği artık var ve fonksiyonel simülasyonda zamanlama bilgisi yok sayılıyor. Tam unisims kütüphanesinin güncel sürümde ne kadar temiz derlendiğini doğrulamadık; MMCM gibi modellerin sorun çıkarabildiği ve çoğu kişinin bunları basit bir saat üreteciyle değiştirdiği biliniyor.

Kazanç: GHDL yolundan farklı olarak araya ek bir çevirici girmez; netlist'i zaten kullandığınız tasarım aracı üretir. Yaptığınız şey sentez sonrası fonksiyonel simülasyondur ve RTL ile netlist arasındaki uyumsuzlukları yakalar.

Kayıp:

• Code coverage LUT'lara izlenir, VHDL satırlarına değil; elemental analiz kredisi vermez.
• İç sinyal adları ve hiyerarşi bozulur; iç sinyallere bakan kontroller kırılır.
• Generic'ler sentezde donar; her konfigürasyon için ayrı netlist gerekir.
• Record ve dizi portları bit vektörlerine açılır; bir sarmalayıcı (wrapper) yazmanız gerekir.
• X ve GSR davranışı modellenmez; SDF olmadığı için zamanlama simülasyonu da değildir.
• Her RTL değişikliğinde yeniden sentez gerekir; Verilator'ün hız avantajının çoğu burada erir.

Bu yol, RTL simülasyonuna ve zamanlama simülasyonuna ek bir kontrol olabilir, yerlerine geçemez.

Hangi Motivasyon, Hangi Yol?

Sonuç

Verilator'ün UVM desteği gerçek ve hızla olgunlaşıyor. SystemVerilog tasarımlarda, özellikle kredi iddia etmeyen ikinci simülatör rolünde, bugün bile ciddi değer üretir. VHDL tasarımlarda ise aradaki çeviri adımı hem teknik hem sertifikasyon açısından kazancı siliyor; orada aynı ihtiyaçları VHDL'i doğrudan okuyan araçlarla karşılamak daha doğru.

DAL A projelerinde değişmeyen kural şu: bir aracı sertifikasyon kanıtı üretmek için kullanacaksanız, o aracı ve çıktısını savunabilmelisiniz. Savunamayacağınız araç yine de işe yarar, yeter ki hata bulmak için kullanın, kanıt üretmek için değil.

Bu Sitedeki Derslerle İlişkisi

UVM serisindeki kavramlar (bileşen hiyerarşisi, fazlar, sequence'ler, scoreboard, coverage) simülatörden bağımsızdır; Questa'da da Verilator'de de aynıdır. Değişen, simülatörün dilin ne kadarını desteklediği ve ürettiği kanıtın ne kadar savunulabilir olduğudur. Bu yazı o ikinci kısmı, emniyet kritik bir proje gözünden ele aldı.

Kaynaklar

• CHIPS Alliance, Latch-Up 2026 özeti (UVM 2020 ve dört durumlu mantık çalışmaları): https://chipsalliance.org/news/latch-up2026/
• Antmicro, "Support for upstream UVM 2017 in Verilator" (Ekim 2025): https://antmicro.com/blog/2025/10/support-for-upstream-uvm-2017-in-verilator
• Antmicro, Verilator'de kapsam raporlama geliştirmeleri (Ağustos 2025): https://antmicro.com/blog/2025/08/enhancing-coverage-reporting-in-verilator
• Verilator kılavuzu, Coverage Analysis (5.052): https://verilator.org/guide/latest/simulating.html
• Verilator kılavuzu, verilator_coverage: https://verilator.org/guide/latest/exe_verilator_coverage.html
• Electronics For You, Verilator'ün sınırlamaları üzerine değerlendirme: https://www.electronicsforu.com/technology-trends/verilator-still-the-first-stop-before-silicon
• VTR, Verilator ile yerleştirme sonrası fonksiyonel simülasyon: https://docs.verilogtorouting.org/en/latest/vtr/run_func_sim_flow/
• RTCA DO-254 / EUROCAE ED-80, "Design Assurance Guidance for Airborne Electronic Hardware" (özellikle Bölüm 11.4 ve Appendix B)