Zamanlama (scheduling) — kapıları zaman eksenine oturtan transpiler aşaması

Routing aşaması kapıların hangi sırayla ve hangi qubit çiftlerinde yürütüleceğini belirlerken, scheduling aşaması aynı kapıların ne zaman başlayıp ne kadar süreceğini belirler. Bu ayrım, yazılımın donanım zamanlama kısıtlarına uyumunu kontrol ettiği yerdir: örneğin aynı kontrol hattına bağlı işlemlerin çakışmaması veya ölçüm pencerelerinin makul sıraya oturması. Sonuç, yürütücünün anlayacağı zaman çizelgesi uyumlu bir devredir; çoğu kullanıcı arayüzünde bu, kapıların süre alanlarıyla görünür hâle gelir.

Bu sayfanın sınırı

Darbe düzeyinde pulse tasarımı ve açık kanal modelleme bu sayfada işlenmez; odak transpiler'ın mantıksal–fiziksel devre üzerindeki zamanlama soyutlamasıdır. Topolojik sıra ve SWAP üretimi yönlendirme ve SWAP ekleme başlıklarında kalır. Genel boru hattı sırası transpiler pipeline ile çerçevelenir.

Neden layout ve routing sonrasıdır?

Süre tahminleri fiziksel qubit hatları ve izin verilen iki-qubit kenarlarına bağlıdır; bu bilgi yerleşim ve yönlendirme netleştikten sonra anlamlıdır. Erken bir zamanlama taslağı, sonradan eklenen SWAP'larla geçersiz kalır; bu yüzden preset zincirlerde sıra disiplinini korumak önemlidir.

Transpiler iç temsilinde devre bir DAG olarak durur; düğümler işlemler, kenarlar ise qubit başına veri akışıdır. Zamanlama bu grafiğe her düğüm için süre etiketi ekler ve kaynak kısıtları altında başlangıç zamanlarını seçer. Aynı ön katmanda birbirinden bağımsız iki tek-qubit kapısı teoride paralel başlatılabilir; fakat donanım bağlantısı veya kontrol elektronik kısıtı bunu engelleyebilir. Bu ayrıntı hedef modeline göre değişir.

Ön katman ve paralellik

Routing bölümünde anlatılan ön katman düşüncesi, zamanlama tarafında “aynı zaman diliminde güvenle yürütülebilecek küme” seçimine dönüşür. Paralellik her zaman kazançtır demek doğru değildir; bazı mimarilerde seri yürütüm gürültü veya kalibrasyon açısından daha öngörülebilir olabilir.

Kaynak modeli soyutlaması

Qiskit preset zamanlaması, donanımın tam mikrodalga şemasını açıkça çizmez; süre ve sıra kısıtlarını soyut bir kaynak modeli üzerinden uygular. Özel donanım için ince ayar özel pass ve üretici araçlarıyla birleştirilir.

Zamanlama için gerekli süre bilgisi çoğu zaman Target içindeki InstructionProperties kayıtlarından okunur: belirli bir kapı, belirli bir qubit demetinde ne kadar sürer? Bu süreler kalibrasyon turlarıyla güncellenir; dün alınmış bir çizelge bugün geçerli olmayabilir. Devrenin toplam süresi çoğu arayüzde dt birimiyle ifade edilir; bu birim donanım zamanına projeksiyon sağlar.

Kalibrasyon köprüsü

Süre ve hata alanlarının canlı okunması kalibrasyon verisi ve backend özellikleri sayfalarıyla ilişkilidir. Zamanlama çıktısı, o anki kalibrasyon anlık görüntüsüne bağlı bir tahmindir.

Eksik süre bilgisi

Bazı yollar veya özel kapılar için süre tanımlı değilse, zamanlama pass'i hata verebilir veya varsayılanlara düşebilir; bu durum üretim öncesi doğrulama ile yakalanmalıdır. Taban kümesi ile süre sözlüğünün uyumu taban kapıları başlığında vurgulanan üçlü soru (isim, demet, süre) ile kontrol edilir.

ASAP (as soon as possible), bağımlılıklar izin verdiği anda işlemleri mümkün olduğunca erken başlatmayı hedefler; kritik yol genelde uzun kalır ama ara tamponlar kısa olabilir. ALAP (as late as possible) ise işlemleri mümkün olduğunca geçe iter; bazen gürültü ve idle süre dengesi veya klasik senkronizasyon ihtiyaçları için tercih edilir. Hangi politikanın üretimde varsayılan olduğu hedef ve sürüme bağlıdır; kıyaslama yapmadan “ALAP her zaman iyidir” demek güvenli değildir.

Kısıt ve hedef fonksiyonu

Her iki politika da önce bağımlılık ve kaynak kısıtlarına uyar; fark, mümkün olan zaman penceresi içindeki tercihtedir. İleri düzeyde, donanım sağlayıcıları ek hedefler (örneğin belirli qubitlerde idle süresini sınırlama) ekleyebilir; bu genelde özel derleme zincirlerinin konusudur.

Simülatör farkı

İdeal simülatörde süre modeli basitleştirilebilir veya yok sayılabilir; gerçek donanımda ise zamanlama çıktısı yürütme fidelitesi için belirleyicidir. Aynı transpile betiği iki hedef arasında taşınırken bu fark gözden kaçmamalıdır.

Mantıksal derinlik (kapı sayısı değil, kritik yoldaki katman sayısı) ile zamanlanmış toplam süre aynı metrik değildir: farklı kapılar farklı süre taşır; paralelleşebilen bölgeler toplam süreyi kısaltır. Bu yüzden “derinliği düşürdüm” iddiası, süre birimleri yazılmadan tam olarak doğrulanamaz. Raporlarda iki ölçütü birlikte vermek disiplin gerektirir.

optimization_level ile ilişki

Daha yüksek optimizasyon seviyesi bazen kapı sayısını düşürürken zaman çizelgesini yeniden şekillendirir; toplam süre her zaman azalmayabilir. Seviye politikası optimization seviyeleri sayfasında özetlenir.

Derinlik azaltmanın zaman etkisi

İki kapı birleştirildiğinde derinlik kısalabilir; fakat birleşik kapının süresi önceki iki sürenin toplamından kısa olmayabilir. Bu nedenle devre sadeleştirmesi ile zamanlama ayrı değerlendirilmelidir.

transpile ve preset pass manager çağrılarında zamanlama politikası için ek parametreler (örneğin scheduling_method) kullanılabilir; tam isim ve varsayılanlar sürüme göre değişebilir. Genel kural: önce resmi belgede imzayı doğrulayın, sonra aynı betiği hedef backend ve fake backend üzerinde karşılaştırın. optimization_level yükseldikçe zamanlama öncesi ve sonrası pass dalgaları değişebileceği için, yalnızca scheduling parametresini değiştirdiğinizde bile çıktı süresi beklenmedik şekilde sıçrayabilir.

Preset içinde yer

Zamanlama pass'leri preset zincirinin sonlarına doğru yerleşir; öncesinde taban, layout ve routing kararları oturmuş olmalıdır. Sırayı bozan özel bir pass yazıyorsanız pass manager disiplinine başvurun.

TranspilationConfig notu

Yeni sürümlerde yapılandırma nesneleri ile aynı parametreler gruplanmış olabilir; eğitim kodunda eski anahtar sözcükler çalışıyorsa, üretimde sürüm kilidi veya ince uyarlama yapılmalıdır.

Ölçüm işlemleri zaman çizelgesinde ayrı bir rol taşır: okuma hattı, tetikleme ve sonuç toplama süreleri klasik tarafla bağlantılıdır. barrier ise zamanlama ve optimizasyon pass'lerine “buradan geçme” veya “burada hizala” sinyali verebilir; gereksiz bariyerler paralelliği kısarak toplam süreyi uzatabilir. Semantik ayrıntı bariyer ve akış kontrolü ile ölçüm mantığı sayfalarında işlenir.

Dinamik devreler

Klasik geri beslemeli akışlarda zamanlama, ölçüm sonucuna bağlı dallanmayla etkileşir; statik zamanlama analizi her zaman tam sonuç vermez. Dinamik devreler başlığı bu bağlamı tamamlar.

Raporlama

Deney raporunda zamanlama politikası, toplam süre birimi ve mümkünse çizelge özeti (veya donanım günlüğü referansı) yer almalıdır; yalnızca kapı listesi yeterli değildir.

Örnekler yerel FakeManilaV2 ile çalışır: transpile sonrası devre süresi ve birim, scheduling_method kıyası ve komut düzeyinde süre alanlarının okunması. Sürümünüzde parametre adı yoksa yorum satırına alın.

from qiskit import QuantumCircuit, transpile
from qiskit_ibm_runtime.fake_provider import FakeManilaV2

qc = QuantumCircuit(2)
qc.h(0)
qc.cx(0, 1)
qc.measure_all()

backend = FakeManilaV2()
tqc = transpile(qc, backend=backend, optimization_level=2, scheduling_method="asap")
print("duration (dt):", tqc.duration)
print("unit:", getattr(tqc, "unit", None))

from qiskit import QuantumCircuit, transpile
from qiskit_ibm_runtime.fake_provider import FakeManilaV2

qc = QuantumCircuit(3)
qc.h(range(3))
qc.cx(0, 1)
qc.cx(1, 2)
qc.measure_all()

backend = FakeManilaV2()
for method in ("asap", "alap"):
    tqc = transpile(
        qc,
        backend=backend,
        optimization_level=2,
        scheduling_method=method,
        seed_transpiler=0,
    )
    print(method, "duration", tqc.duration, "depth", tqc.depth())

from qiskit import QuantumCircuit, transpile
from qiskit_ibm_runtime.fake_provider import FakeManilaV2

qc = QuantumCircuit(2)
qc.h(0)
qc.cx(0, 1)

backend = FakeManilaV2()
tqc = transpile(qc, backend=backend, optimization_level=2, scheduling_method="asap")
for inst in tqc.data:
    op = inst.operation
    name = getattr(op, "name", type(op).__name__)
    dur = getattr(inst, "duration", None)
    unit = getattr(inst, "unit", None)
    print(name, "duration", dur, "unit", unit)

Zamanlama, transpiler'ın soyut devreyi yalnızca topolojik ve taban açısından değil, zaman ekseninde de yürütülebilir kılan aşamasıdır. ASAP ve ALAP politikaları aynı bağımlılık grafiğinde farklı zaman seçimleri sunar; süreler Target ve kalibrasyondan beslenir. Raporlarda toplam süre, birim ve politika birlikte yazılmalıdır.

• Yönlendirme ve SWAP ekleme — zamanlama öncesi sıra ve permütasyon.
• Taban kapıları — süre sözlüğü ile birlikte okunan native küme.
• Transpiler pipeline, pass manager, optimization seviyeleri.
• Donanım topolojisi — zamanlama ile birlikte düşünülen fiziksel bağlam.
• Kalibrasyon verisi — süre ve hata güncelliği.