Sun Sep 06 2026
Selam! 👋
Son aylarda GitHub Copilot, ChatGPT veya Cursor gibi araçlarla kod yazdıysan, AI'ın ne kadar hızlı "yardımcı pilot" olabildiğini hissetmişsindir. for döngüsü yazmak, API endpoint'i tasarlamak, hatta test senaryoları üreten bir arkadaşın var artık — ve bu arkadaş yorulmuyor.
Ama... donanım tarafı ne oluyor? 🤔
Yazılımda "derleme hatası" alırsan Ctrl+S yaparsın, tekrar denersin. Chip tasarımında hata yaparsan ise:
Yani ** maliyet, risk ve iterasyon hızı** tamamen farklı bir ligde.
Ben de merak ettim: "Peki ya AI devre kartı tasarlarsa?" diye. Birlikte keşfedelim:
| Konu | Ne Anlatacağız? |
|---|---|
| 🛠 Mevcut Araçlar | Kod yazan AI'lar donanım için ne sunuyor? (Verilog/SystemVerilog üretimi, simülasyon yardımı) |
| 🧠 ChipNeMo & Arkadaşları | NVIDIA, Google, Cadence, Synopsys gibi devler ne yapıyor? Özel modeller mi var? |
| ⚠️ Sınırlar & Halüsinasyon | AI "mantıksal ama yanlış" bir modül yazınca ne olur? Nasıl yakalarız? |
| ✅ Gerçekçi Kullanım Senaryolari | Bugün gerçekten ne işe yarıyor, ne hype? |
Bu yazı bir araştırma notu kadar samimi, bir de pratik rehber kadar faydalı olsun istiyorum. Kod örnekleri olacak, araç karşılaştırmaları olacak, "bunu denedim, şöyle oldu" anları olacak.
Hazırsan, AI'ın Verilog yazıp yazamayacağına — ve biz mühendisler olarak buna nasıl güvenebileceğimize — birlikte bakalım.
Devam edelim mi? ➡️
Hazırsan klasik EDA akışını 5 adımda özetleyelim 👇
Bu akış doğrusal görünse de, her adımda iterasyon ve manuel müdahale bol olur.
| Aşama | LLM’nin yapabileceği şeyler | Neden önemli? |
|---|---|---|
| RTL Yazma | Modül iskeleti, state‑machine, parametrik bloklar üretir | Boilerplate koddan kurtuluruz, hata oranı düşer |
| Testbench Oluşturma | Directed/random stimulus, coverage‑driven assertions yazar | Doğrulama süresini %30‑%50 kısaltabilir |
| Dönüşüm / Wrapper Scriptleri | Verilog ↔ SystemVerilog, VHDL ↔ Verilog, CDC/clock‑domain crossing wrapper’lar | El ile yazılan bash/python scriptlerini otomatikleştirir |
| Sentiz / P&R Öncesi | Constraint (SDC) önerileri, area/power tahminleri | Erken feedback döngüsü kurar |
| Doğrulama | Assertion yazma, cover‑point önerileri, hata kök nedeni analizi | Debug süresini dramatik azaltır |
Kısaca: LLM’ler kod üretimi ve yardımcı scriptler için “birinci yardımcı” olur; karar verme (mimari, timing closure) yine mühendiste kalır.
Soru: Biz mühendisler için bu ne anlama geliyor?
→ Daha az tekrar, daha çok mimari düşünce. LLM’i “junior arkadaş” gibi kullanıp, kritikal yol kararlarını biz alıyoruz.
Aşağıdaki bash snippet, basit bir counter.v modülü için ChipNeMo‑tabanlı bir wrapper’ı nasıl çağıracağımızı gösterir. Gerçek ortamda chipnemo-cli yerine kendi LLM servisinizin endpoint’i olabilir.
#!/usr/bin/env bash
# -------------------------------------------------
# counter.v için LLM‑destekli RTL üretimi + testbench
# -------------------------------------------------
set -euo pipefail
MODULE_NAME="counter"
SPEC_FILE="specs/${MODULE_NAME}.yaml" # LLM’e gidecek doğal‑dil / YAML spec
OUT_DIR="generated/${MODULE_NAME}"
mkdir -p "${OUT_DIR}"
# 1️⃣ RTL kodu iste
chipnemo-cli generate rtl \
--spec "${SPEC_FILE}" \
--module "${MODULE_NAME}" \
--lang systemverilog \
--output "${OUT_DIR}/${MODULE_NAME}.sv"
# 2️⃣ Testbench iskeleti iste
chipnemo-cli generate testbench \
--spec "${SPEC_FILE}" \
--module "${MODULE_NAME}" \
--framework uvm \
--output "${OUT_DIR}/${MODULE_NAME}_tb.sv"
# 3️⃣ Basit bir lint kontrolı (opsiyonel)
verilator --lint-only "${OUT_DIR}/${MODULE_NAME}.sv" \
&& echo "✅ Lint temiz" \
|| echo "⚠️ Lint uyarıları var, elle bakın"
echo "🚀 ${MODULE_NAME} modülü ve testbench hazır → ${OUT_DIR}"
Ne oluyor burada?
specs/counter.yaml dosyasında doğal dil veya YAML ile modül davranışını tanımlıyoruz.chipnemo-cli generate rtl → LLM SystemVerilog RTL üretir.chipnemo-cli generate testbench → UVM tabanlı testbench iskeleti çıkar.verilator --lint-only ile hızlı bir syntax/lint kontrolü yapıyoruz.Bu scripti CI/CD’nin başına koyarsanız, her spec değişikliğinde RTL + testbench otomatik güncellenir 🎉.
Sonuç: LLM’leri EDA akışının kod‑ağır kısımlarına (RTL, TB, script) entegre ederek iterasyon hızını artırıyoruz. Mimarî kararlar, timing closure ve sign‑off yine senin uzmanlığında kalıyor.
Hadi bir sonraki bölümde prompt mühendisliği ve fine‑tuning stratejilerine dalalım! 🚀
Hazırsan başlayalım 🚀
| Araç | Geliştirici | Temel Odak | Öne Çıkan Özellik |
|---|---|---|---|
| AlphaChip | Google DeepMind | Physical design (placement, routing) | RL tabanlı macro placement, PPA optimizasyonu |
| VSO.ai | Synopsys | Verification & Sign‑off | ML‑guided coverage closure, assert generation |
| Cerebrus | Cadence | Full‑flow optimization | Multi‑objective (power, performance, area) tuning |
| ChipNeMo | NVIDIA | RTL & script generation | Natural‑language → Verilog, debug assist |
İpucu: Açık kaynak modelleri kendi veri setinizle fine‑tune ederek şirket içi IP koruyabilirsiniz.
Aşağıda Hugging Face pipeline ile yerel bir ChipNeMo‑benzeri modelden “4‑bit sayıcı Verilog kodu yaz” isteği gönderip cevabı alan basit bir Python snippet var.
from transformers import pipeline
# 1️⃣ Modeli yükle (örnek: "NVIDIA/ChipNeMo-7B" veya kendi fine‑tuned modelin)
generator = pipeline(
"text-generation",
model="NVIDIA/ChipNeMo-7B", # ← model adı / yolu
tokenizer="NVIDIA/ChipNeMo-7B",
device_map="auto", # GPU varsa otomatik kullanır
torch_dtype="auto"
)
# 2️⃣ Prompt hazırla
prompt = (
"Aşağıda Verilog kodunu tamamla:\n"
"// 4-bit artan sayıcı, aktif yüksek reset\n"
"module counter_4bit (\n"
" input logic clk,\n"
" input logic rst_n,\n"
" output logic [3:0] q\n"
");\n"
)
# 3️⃣ Üretim parametreleri
outputs = generator(
prompt,
max_new_tokens=256,
temperature=0.2, # deterministik çıktı için düşük
top_p=0.95,
do_sample=True,
eos_token_id=generator.tokenizer.eos_token_id
)
# 4️⃣ Sonucu yazdır
generated = outputs[0]["generated_text"]
print("=== Üretilen Verilog ===")
print(generated)
Ne oluyor burada?
pipeline ile modeli tek satırda yüklüyoruz.temperature=0.2 ile tutarlı, sentetik RTL elde ediyoruz.| Özellik | ChipNeMo | AlphaChip | VSO.ai | Cerebrus | VerilogEval / HDLGPT |
|---|---|---|---|---|---|
| Doğal dilden RTL | ✅ | ❌ | ❌ | ❌ | ✅ (HDLGPT) |
| Hata ayıklama önerisi | ✅ | ❌ | ✅ | ❌ | ❌ |
| Physical design (PPA) | ❌ | ✅ | ❌ | ✅ | ❌ |
| Verification coverage | ❌ | ❌ | ✅ | ❌ | ❌ |
| Açık kaynak / özelleştirilebilir | ❌ (NVIDIA lisansı) | ❌ | ❌ | ❌ | ✅ |
| Model boyutu | 7‑13B | RL agent (custom) | Proprietary | Proprietary | 1.3‑7B (HF) |
ChipNeMo RTL yazma ve debug konusunda en pratik LLM; AlphaChip / Cerebrus ise physical design optimizasyonunda rakipsiz.
Açık kaynak seçenekler (HDLGPT, VerilogEval) küçük ekipler için hızlı prototip ve eğitim imkanı sunar.
Hangi araç senin akışına en çok yakışır? Küçük bir deneme yapıp kendi veri setinle fine‑tune etmeyi dene – farkı hemen hissedersin 🚀
Ne oluyor burada? 🎯 P&R mühendisi artık TCL script yazmak yerine LLM'e söylüyor. İşte nasıl işliyor:
module counter (
input clk,
input rst,
output reg [3:0] q
);
always @(posedge clk or posedge rst) begin
if (rst) q <= 4'b0000;
else q <= q + 1;
end
endmodule
LLM, bu küçük verilog'i Netlist'e ➜ Schematic'e ➜ Constraint Set'e kolayca dönüştürebilir. Bu sayede Alan Tahsisi daha hızlı başlayabilir.
Aşağıda, Innovus/Vivado platformları için bir LLM tarafından üretilen tipik bir kısıtlandırma scripti bulunmaktadır. Şimdiye kadar elle yazdığın scriptleri hatırlıyor musun? Artık onlara LLM'e sormak yeterli.
# --- Saat kaynağı oluştur ---
create_clock -name sys_clk -period 10 -waveform {0 5} [get_ports {clk}]
# --- Giriş gecikmeleri ayarla ---
set_input_delay -clock sys_clk [get_ports {reset_n data_in}] -max 2.0 -min 1.5
# --- Özel bir hücreyi konumlandır ---
place_cell -name custom_ip \
-cell_name {my_custom_core} \
-loc {200 300} \
[get_ports {busy}]
# --- Yerleştirilen hücrenin yönlendirme kısıtlamaları ---
set_route_area -boundaries {0 0 500 500}
Kısa özet: Bu script bir saat kaynağı tanımlar, girişler için gecikme kısıtları belirler ve özel bir IP bloğunu istenen konuma yerleştirir. LLM, bir kez doğru sorular sorduğunda, bunlar birkaç saniyede hazır olur. ❗️
Aynı LLM, sadece yerleşim kısıtları ile kalmaz; UVM tabanlı bir testbench de oluşturabilir:
Peki bu bize ne kazandırıyor? Bir TCL scripti yazmaya çalışırken karşılaştığın zaman kaybını önler ve doğrudan test üretimine odaklanabilirsin.
Sonuç: Bir P&R mühendisi artık tekrar eden, zamansız TCL komutlarını yazmak yerine, LLM'e strateji belirler ve doğrulama eder.
🎉 Sonuç: P&R süreci daha hızlı, daha az hatalı ve daha öğrenmeye dayalı bir hale geliyor – hepsi bir LLM ile "sorma" sayesinde.
Bazen bir LLM bize sözdizimsel olarak kusursuz bir Verilog örneği veriyor gibi görünür, ama daha yakından incelediğimizde gerçekten işlevsel olmayan bir şeyle karşılaşıyoruz. İlk bakışta “beklenen” kod ile “üretilen” kodun karşılaştırıldığı örnek üzerinden anlatayım.
module debounce (
input wire clk,
input wire rst,
input wire in_sig,
output reg out_sig
);
always @(posedge clk) begin
if (rst) begin
out_sig <= 1'b0;
end else begin
case (in_sig)
1'b0 : out_sig <= 1'b1; // Beklenmedik bir durumda varsayılan ifade eksik
1'b1 : out_sig <= 1'b0;
endcase
end
end
endmodule
module debounce (
input wire clk,
input wire rst,
input wire in_sig,
output reg out_sig
);
always @(posedge clk) begin
if (rst) begin
out_sig <= 1'b0;
end else begin
case (in_sig)
1'b0 : out_sig <= 1'b1;
1'b1 : out_sig <= 1'b0;
default : out_sig <= out_sig; // varsayılan – en azından bir şeyi korur
endcase
end
end
endmodule
Burada ne oluyor?
default yok → in_sig beklemeyen bir değer (örneğin tri-state) aldığında case ifadesi hiçbir işlemi tetiklemez ve out_sig önceki değerine kalır. Bu, kısmen bekletilmiş (setup/hold) bir durumdur.else bloğu içindeki <= (non‑blocking) ve dışarıdaki <= de bir karışım oluşuyor. Bu da kaydetme zamanlaması karışıklığına neden olur.Bunlar, donanım bağlamındaki halüsinasyonlardır:
default eksikliğinden dolayı genellikle %80‑90 arasında kalır.Sadece SER'e güvenmek, kara kutu sorununa yol açar: sözdizimi tam ancak tasarım mantıksal açıdan bozuktur.
Özet: Bir LLM'nin sözdizimsel açıdan kusursuz Verilog sağlayabileceği, ama yine de bunu kontrol etmemiz gerektiğini gösteriyoruz. Halüsinasyonlar, var olmayan portlardan karışık assignment'lere kadar her yerde ortaya çıkabilir. Formal fonksiyonel doğruluk gibi metrikler, masayı eşitlerken insan mühendislerinin katkısı hala çok önemli.
Hazırsan güvenli bir entegrasyon için hemen uygulayabileceğin birkaç eyleme geçirilebilir adım var 🚀
pytest / cocotb entegre edip her push’ta otomatik çalıştır..sv + .fv) sar.assert property (@(posedge clk) req |-> ##[1:3] ack); gibi temporal özellikleri tanımla."Please generate a Verilog module with the following interface:
{
\"module_name\": \"cdc_fifo\",
\"ports\": [
{\"name\": \"clk_a\", \"dir\": \"input\", \"type\": \"wire\"},
{\"name\": \"clk_b\", \"dir\": \"input\", \"type\": \"wire\"},
{\"name\": \"rst_n\", \"dir\": \"input\", \"type\": \"wire\"},
{\"name\": \"din\", \"dir\": \"input\", \"type\": \"wire [7:0]\"},
{\"name\": \"dout\", \"dir\": \"output\", \"type\": \"reg [7:0]\"}
],
\"clock_strategy\": \"async_reset_active_low\"
}"
Bu sayede model doğru arayüz ve reset davranışı üretiyor, sonraki formal verification adımında sürpriz yaşamıyorsun 🎯
documents:
- id: "coding_standard_naming_v1"
title: "Naming Convention Standard"
version: "1.0"
tags: ["naming", "style", "verilog"]
source_path: "standards/naming_convention.md"
chunk_size: 500
overlap: 50
vector_namespace: "company_standards"
- id: "cdc_rules_v2"
title: "Clock Domain Crossing Rules"
version: "2.1"
tags: ["cdc", "clock_domain_crossing", "verilog"]
source_path: "standards/cdc_rules.md"
chunk_size: 400
overlap: 40
vector_namespace: "company_standards"
- id: "library_fifo_v3"
title: "Parameterized FIFO Library"
version: "3.0"
tags: ["library", "fifo", "verilog"]
source_path: "lib/fifo/README.md"
chunk_size: 600
overlap: 60
vector_namespace: "company_libraries"
Nasıl çalışıyor?
Bu dört adımı yarından itibaren uygularsan, LLM ürettiği kod test edilebilir, formal doğrulanabilir ve şirket standartlarına uygun olacak. Kolay gelsin! 🚀
Hazırsan başlayalım 🚀
Son yıllarda VerilogEval, HDLBench ve ChipNeMo gibi benchmark’lar, LLM’lerin donanım tasarımındaki yeteneklerini sayısallaştırdı. İşte öne çıkan rakamlar ve bunların pratikte ne anlama geldiği:
| Benchmark | Model | Pass@1 | Pass@5 | Functional Correctness | Syntax Pass Rate |
|---|---|---|---|---|---|
| VerilogEval | ChipNeMo‑13B | %38 | %55 | %42 | %91 |
| CodeLlama‑7B | %31 | %48 | %35 | %88 | |
| GPT‑4 (finetuned) | %44 | %61 | %49 | %94 | |
| HDLBench | ChipNeMo‑13B | %27 | %44 | %30 | %85 |
| CodeLlama‑7B | %22 | %38 | %25 | %81 | |
| GPT‑4 (finetuned) | %33 | %51 | %38 | %90 |
✅ Artılar
❌ Eksiler
| Durum | Ne yapmalı? |
|---|---|
| Prototip / keşif | Modelden ilk taslak al, hızlı iterasyon yap. |
| Üretim kalitesi IP | Modeli yardımcı araç olarak kullan, kritik blokları senior mühendis yaz/doğrula. |
| Verifikasyon | Assertion/coverpoint üretiminde modeli başlangıç noktası yap, manuel tamamla. |
Kısaca: LLM’ler junior mühendisi hızlandırıyor, senior mühendisi henüz değiştiremiyor. Benchmark rakamları bu gerçeği net ortaya koyuyor. 🚦
Copilot modunda bir asistan sadece kod önerir, sen hâlen karar verip yazıyorsun.
Agent modunda ise LLM kendisi bir görev zincirini yönetir: spec okur, mimari kurar, RTL üretir, simüle eder, hata alırsa düzeltir, sentenz/P&R koşturur ve timing kapanana kadar iterasyon yapar. Bu, AlphaChip tarzı bir "tek dokunuş" akışının doğuşudur 🚀.
flowchart TD
A[LLM Agent] --> B[Spec Parser]
B --> C[RTL Generator]
C --> D[Simulator]
D --> E[Formal Verifier]
E --> F[P&R Tool]
F --> G[Timing Analyzer]
G -->|Timing kapatılmadı| A
G -->|Timing kapandı| H[GDS-II / Tape‑out]
Hadi düşünelim: Kod yazmak mı, mimari tasarlamak mı, yoksa agent’i denetlemek mi? Cevabı yorumlarda paylaş, beraber şekillendirelim ✨.
Hazırsan, hemen şimdi kendi donanım asistanını kurmaya başlayalım! 🚀
Küçük bir model bile, elindeki RTL kodlarını SystemVerilog'a çevirip assertion eklemek için harika bir başlangıç noktası olabilir. Adım adım gidelim:
Önce bilgisayarına Ollama kuruluysa (kurulu değilse ollama.comdan indir), terminalden hafif ve kod odaklı bir model indir.
Ben genelde deepseek-coder:6b veya codellama:7b kullanıyorum — ikisi de Verilog/SystemVerilog için yeterince yetenekli.
# DeepSeek-Coder 6B modelini indir (yaklaşık 3.8 GB)
ollama pull deepseek-coder:6b
# Alternatif: CodeLlama 7B (biraz daha genel ama yine de güçlü)
# ollama pull codellama:7b
Ne oluyor burada?
Ollama modeli yerel olarak indirip, GPU/CPU üzerinde tamamen offline çalıştırır. Verilerin hiçbir yere gitmez, gecikme minimumdur.
VS Code’u aç, Continue eklentisini (veya Cody’yi) yükle.
Ardından proje kök dizinine .continue/config.json dosyası oluştur (veya eklenti ayarlarından “Open Config” de) ve şu içeriği yapıştır:
{
"models": [
{
"title": "DeepSeek-Coder (Local)",
"provider": "ollama",
"model": "deepseek-coder:6b",
"contextLength": 8192,
"systemMessage": "Sen bir RTL tasarım uzmanısın. Verilog/SystemVerilog kodları yaz, assertion ekle ve simülasyon için hazır hale getir."
}
],
"tabAutocompleteModel": {
"title": "DeepSeek-Coder (Local)",
"provider": "ollama",
"model": "deepseek-coder:6b"
},
"allowAnonymousTelemetry": false
}
Bu sayede ne oluyor?
http://localhost:11434) bağlanır.systemMessage ile modeli “donanım asistanı” moduna sokarız.tabAutocompleteModel sayesinde Tab tuşuyla satır içi öneriler de alırsın.Şimdi eğlenceli kısım: VS Code’da bir .v dosyası aç, içine eski Verilog modülünü yapıştır (veya dosyayı sürükle-bırak yap).
Ardından Continue sohbet panelini aç (Ctrl+L / Cmd+L) ve şu promptu yaz:
“Bu modülü SystemVerilog’a çevir. Her önemli sinyal için
assert/coverekle, clock/reset protokolünü netleştir. Çıktıyı sadece kod bloğu olarak ver.”
Model saniyeler içinde temiz, assertion’lı SystemVerilog kodu üretecek.
İstersen “// TODO: bu assertion’ı formallaştır” gibi notlar da ekletirsin.
Üretilen kodu kaydet (module_sv.sv), sonra kendi simülasyon akışında (VCS, Questa, Icarus, Verilator… ne varsa) derle ve çalıştır:
# Örnek: Verilator ile hızlı lint + sim
verilator --lint-only -Wall module_sv.sv
verilator --cc --exe --build -j 0 module_sv.sv tb_main.cpp # testbench'in varsa
./obj_dir/Vmodule_sv
Ne oluyor burada?
⚡ Mükemmel olmayacak ama senin için bir başlangıç noktası yaratacak.
Bu küçük asistan, yarın sabah kahveni içerken “bu modülü de çevir bakalım” diyebileceğin bir alışkanlık haline gelebilir — hadi başla, sürprizler seni bekliyor! 🌟
Bu içerik tamamen yapay zeka destekli otomasyon sistemi ile üretilmiştir.
All rights reserved