Çipler ve Yarı İletkenler

Spesifikasyondan Resmî Özelliklere: Yapay Zekâ Çip Tasarımı Doğrulamasını Hızlandırıyor, Ancak Mühendisin Yerini Almıyor

Büyük dil modelleri, çip tasarım spesifikasyonlarını SystemVerilog Assertions dilinde resmî özelliklere dönüştürmeye yaklaşıyor; bu da doğrulama taslaklarının hazırlanma süresini azaltabilir. Ancak spesifikasyonların eksik olması, sözdizimsel olarak doğru fakat mantıksal açıdan zayıf özellikler üretilmesi ihtimali ve yüksek inceleme yükü, insan gözetimini temel bir koşul hâline getiriyor. Ekonomik getirinin gerçekte ne olacağı ise hâlâ belirsiz.

2026-08-27
5 dk okuma
11 görüntülenme
فريق تحرير certi.news
Spesifikasyondan Resmî Özelliklere: Yapay Zekâ Çip Tasarımı Doğrulamasını Hızlandırıyor, Ancak Mühendisin Yerini Almıyor

Büyük dil modelleri, çip tasarımı doğrulamasındaki en zahmetli görevlerden birini gerçekleştirmeye yaklaşıyor: doğal dille yazılmış spesifikasyonları, RTL uygulamasının doğruluğunu değerlendirmek için kullanılabilecek bir dizi resmî özelliğe dönüştürmek. Semiconductor Engineering için Brian Bailey’nin gerçekleştirdiği röportajlar, mevcut araçların yararlı bir ilk taslak oluşturabildiğini; ancak yoğun mühendislik incelemesi olmadan benimsenebilecek eksiksiz bir küme oluşturmaktan hâlâ uzak olduklarını gösteriyor.

Bu gelişmenin önemi, özellik yazımının yıllardır resmî doğrulamada bir darboğaz oluşturmasından kaynaklanıyor. Doğrulama ortamına dâhil edildiklerinde assertions olarak bilinen SystemVerilog özellikleri, sinyaller arasındaki mantıksal ve zamansal ilişkileri tanımlamak için kullanılır; örneğin reset davranışı, el sıkışmalar, one-hot koşulları ve temel güvenlik kontrolleri. Bu özellikler eksiksiz ve doğru olduğunda, tasarımın nasıl oluşturulduğundan bağımsız olarak RTL uygulamasının davranışını spesifikasyonla karşılaştırmak için kullanılabilir.

Araçlar bugün ne yapabiliyor?

Büyük dil modeline dayanan bir araç, bir spesifikasyon belgesini, protokol standardını veya hatta RTL içindeki yorumları okuyarak SVA özellikleri için bir taslak önerebilir. Axiomise CEO’su Ashish Darbari, spesifikasyonların fazla değişmeyen istikrarlı standartlara dayandığı durumlarda bu kullanımın daha uygulanabilir olduğunu söylüyor. Bu durumda araç, doğrulama sürecinin tamamını üstlenmek yerine ilk kod yazımının tekrarlayan bölümünü azaltıyor.

Bazı yaklaşımlar, knowledge graph yani varlıkları ve aralarındaki ilişkileri depolayan bir bilgi grafiği oluşturarak modellerin doğruluğunu artırmaya çalışıyor. Düğümler bir sinyali, modülü, gereksinimi veya portu içerebilirken, kenarlar “sürer”, “resetler” ve “şuna yanıt verir” gibi ilişkileri tanımlayabilir. Sistem, istekle ilişkili görünen metin parçalarını geri getirmek yerine belirli gerçeklere ve bağlantılara başvurabilir; bu da bir sinyal adını uydurma veya tasarım bileşenleri arasındaki ilişkiyi yanlış anlama olasılığını azaltır. Kaynak, bu bağlamda Cohen ve Chibani’nin RAG-SVA in the Landscape of LLM-Based Assertion Generation başlıklı araştırmasına işaret ediyor.

Sorun yapay zekâdan önce başlıyor

Araç, başlangıçta yazılmamış veya karara bağlanmamış bir şeyi çıkaramaz. Synopsys Uygulama Mühendisliği Direktörü Ravindra Aneja, son otuz yılda ideal spesifikasyonun erişilebilir bir şey olmadığını söylüyor; geliştirme çoğu zaman dokümantasyon tamamlanmadan başlıyor ve bazı projelerde, özellikle türetilmiş tasarımlarda veya gereksinimler çalışma sırasında değiştiğinde, eksiksiz bir spesifikasyon bulunmayabiliyor.

Bu sorun yalnızca ifadelerle değil, değişiklik yönetimiyle de ilgili. Pazarlama ekibi yeni bir özellik ekleyebilir veya mevcut bir gereksinimi değiştirebilir; tasarım ve doğrulama ekiplerinin de bu değişikliğin etkisini belirlemesi gerekir. Siemens EDA Kıdemli Başkan Yardımcısı ve Genel Müdürü Abhi Kolpekwa, spesifikasyonu özelliklere dönüştürmenin, her seferinde yeni bir metin üreten bir ajandan ziyade değişiklik geçmişini ve bağlamını izleyen “bağlamsal zekâ” gerektirdiğini düşünüyor.

Yanlış güven riski

Mevcut yaklaşımın en büyük sınırlamalarından biri, bir özelliğin sözdizimsel olarak doğru olabilmesi, çevrilebilmesi ve doğrulama araçlarının bunu kanıtlayabilmesi; ancak gerçekte amaçlanan davranışı sınamamasıdır. Darbari, zayıf veya vacuous bir özelliğin çok sayıda davranışa izin verdiği, yanlış sinyali kullandığı ya da eksik veya aşırı kısıtlayıcı bir ön koşul içerdiği için kolayca başarılı olabileceği konusunda uyarıyor. Bu nedenle “yeşil kanıt”, tasarımın hatasız olduğu anlamına gelmez; kanıt, kanıtlanan özellikten daha güçlü değildir.

Kaynak ayrıca modellerin yapısal ve sözdizimsel kapsamda, mimari niyeti ve kuralın varlık nedenini anlamaya kıyasla daha iyi performans gösterme eğiliminde olduğunu belirtiyor. Bu nedenle modelin spesifikasyonu hatalı yorumlaması, resmî ve katı görünen bir parçaya dönüşebilirken gereksinimlerdeki bir boşluğu gizleyebilir. Bu boşluk FMEDA, güvenlik dosyaları veya ISO 26262 ve ISO 21434 ile ilişkili sertifikasyon kanıtları gibi çalışmalara taşınırsa, etkisi ilk doğrulama projesinin çok ötesine geçebilir.

Tasarım ile doğrulamanın birbirinden ayrılması konusu da öne çıkıyor. Normal Computing Ürün Tasarımı Lideri Kaye Mao, ajanların proje materyallerinin hangi bölümlerine erişebileceğinin sınırlandırılması gerektiğini belirtiyor; çünkü ajanın test senaryoları oluşturmak için tasarımın kendisini kullanmasına izin verilmesi, doğrulama sürecinin bağımsızlığını zedeleyebilir.

Pratikte ne değişiyor?

Darbari’ye göre yapay zekâ, ilk taslakların hazırlanma süresini günlerden dakikalara indirebilir; ancak sonraki işin hacmini iki katına çıkarabilir. Üretilen her özellik spesifikasyona karşı kontrol edilmeli, kapsam açısından analiz edilmeli, vacuity bakımından test edilmeli ve tasarım sinyalleriyle ilişkisi incelenmelidir; başarısızlıklar da sinyal dalga biçimlerinin analizini gerektirebilir. Özellik sayısı on katına çıkarken her biri için gereken inceleme düzeyi aynı kalırsa, inceleme yükü hızlı üretimden elde edilen kazanımı aşabilir.

certi.news’e göre asıl değişim, doğrulama mühendisinin yerini almak değil, ağırlık merkezini özellik yazımından bunların değerlendirilmesine ve kaynağının izlenmesine taşımaktır. Darbari, üretilen özelliklerin onaylanmış çıktılar değil taslaklar olarak ele alınmasını ve regression suite’e eklenmeden önce bir inceleme geçidinin oluşturulmasını öneriyor. Mühendisin uygunluğu doğrulayabilmesi için her özelliğin kaynağı da kaydedilmeli: onu üreten spesifikasyon paragrafı, gereksinim veya RTL öğesi.

Normal Computing Doğrulama Çözümleri Mühendisi Yaron Ilani’ye göre bu yaklaşım, formal verification kullanmak isteyen doğrulama mühendisleri için giriş engelini azaltabilir. Ancak bu, yatırım getirisi sorusunu yanıtlamıyor. Kaye Mao, ajanın çıktılarının doğrulanması için harcanan sürenin maliyete dâhil edilmesi gerektiğini düşünürken, Normal Computing Çözüm Mühendisliği Başkanı Arvind Srinivasan ölçeklendirmenin yalnızca hesaplamayla ilgili olmadığını; verilerin eksiksizliği ve insan incelemesinin maliyetiyle de ilgili olduğunu belirtiyor.

Sonuç olarak büyük dil modelleri, özelliklerin formüle edilmesindeki otomatik ve tekrarlayan bölümü hızlandırma kapasitesine ulaştı; ancak spesifikasyonun eksiksizliği ve tasarım niyetinin anlaşılması sorunlarını henüz çözmedi. Bu araçların değeri, modelin üretebildiği özellik sayısından ziyade tasarımı anlayan bir mühendisin bulunmasına ve kapsamı ölçmek, boş veya uygunsuz özellikleri tespit etmek için bağımsız mekanizmalara bağlı kalacak.

Haber kaynağı
Semiconductor Engineering
Özgün kaynağı aç ↗
ف
Yazar

فريق تحرير certi.news

Aynı kategoride

Bunlar da ilginizi çekebilir

Tüm haberleri gör