Şimdilerde işimin yanında Cadence’ın Xcelium simulatörüne dair hazırladığı dersi inceliyorum, buraya notlarını düşeceğim.
MULTI CORE
Dikkat çekmek istediğim ilk özellik multi-core özelliği. Uzun süren testlerde sistemin daha verimli çalışabilmesi için cadence tarafından geliştirilmiş bir özellik. Anladığım kadarıyla cadence bizden bilgi olarak core sayısını istiyor ve verilen core sayısından 1 core’u host 1 core’u multi engine controller olarak kullanıyor. Geri kalan core’lar ise ayrı birer makine şeklinde çalışarak kendilerine controller tarafından gönderilen emirleri işliyor. Örneğin; uzun olan testin 10 saniye sürdüğünü ve 7 core tanımlandığını varsayarsak sistem 2 core yönetim için 5 core da işlemler için kullanılır. Her işlem core’u 3’er saniye çalışarak işi bitirir ve test 3 saniyede tamamlanmış olur ama fark edeceğiniz üzere toplam işlem süresi 15 saniye oldu. Yani sistem toplam process time’ı artırdı ama geçen süreyi kısalttı.
Normal bir simülasyonda adımlar;
Compile → Elaborate → Simulate
şeklinde ilerler mutli core işlemde ise aşağıdaki gibi
Compile → Elaborate → Multi Core Build → Multi Core Sim
CPU based accelerator işlemi dependent olan kısımları independent parçalara bölerek işler. Örneğin sisteminizde 2 path var ve ikisi de birbirini etkilemiyor ama girişleri ortak. Bu noktada simülatör iki path’i iki farkli device üzerinde koşar ve ikisine de gerekli girişleri verir. Bu sayede tek core iki path’i de hesaplayacakken her bir core bir independant path hesaplar.
MULTI CORE PREDICTION
Asıl can alıcı nokta ise gerçekten günler süren testlerde multi core engine kullanmak mantıklı bir tercih mi sorusu. Çünkü siz başlattıktan sonra ne olacağını kimse bilmiyor. Belki de pathlerinizin tamamı dependent ama xcelium gidip bütün core’ları kullanmak için çalışacak. Bu noktada gene xcelium’un bir tool’u mevcut “-mce-acc-estimation“ flag’i kullanılarak sistem çalıştırılabilir. Burada sistem prediction yapar ve sonrasında size bir rapor sunar, raporda hızlandırma oranına yönelik tahmin verilir. xcelium belgelerinde geçene göre 1.5x in altında bir sonuç dikkate almaya değecek bir hızlandırma değildir. Eğer sonuç 1.5x in altında geldi ise tek core ile koşmanın daha mantıklı olduğu söyleniyor.
RACE DETECTOR
Clock ve data arasında bulunan race durumları predict eder. İdeal durumda hepimiz simülasyon yaparken gate ve kablo bileşenlerinin delaylerini göz ardı ediyoruz ancak bu ilerleyen aşamalarda problemlere sebep olabiliyor. Özellikle gate level netlist ile simülasyon koşulmaya başlandığında beklenmedik sıkıntılarla karşılaşılabiliyor. Bunun önüne geçmek için xcelium race detector adındaki bir tool’u öneriyor. Race detector sayesinde gate level netlist simülasyonuna geçmeden önce sisteme dair bir prediction’da bulunulabiliyor.
Peki neden bu sisteme ihtiyaç var diye sorulduğunda xcelium şöyle bir açıklamada bulunmuş:
X-propagation adında bir konu mevcut kısaca giriş yapalım.
Simülasyon sistemlerinin tamamında bulunan x-optimism ve x-pessimism adında iki konu mevcut. Örnekle açıklayalım.
if (sel)
out = a;
else
out = b;
| SEL | A | B | Out (verilog sim) | FOX | CAT |
|---|---|---|---|---|---|
| x | 0 | 0 | 0 | x | 0 |
| x | 0 | 1 | 1 | x | x |
| x | 1 | 0 | 0 | x | x |
| x | 1 | 1 | 1 | x | 1 |
Verilog sim’de görüldüğü üzere her zaman else state’i aktif kabul edilmiş.
x-optimism: Sisteme tanımlı olmayan bir sinyal seçim ağacına bağlı ise sistem optimistik davranır ve x olan gişe ait seçim ağacında eğer else state’i varsa else kullanılır. x optimism aynı zamanda q <= d ataması için 0→x ve x→1 gibi geçişlerde q<=d atamasını yapar.
x-pessimism: Gate level simülasyon (GLS) koşarken sistem her zaman en kötü olanı yapar, yani örneğin sistemin girişi 1 1 x ise x (sel) ne olursa olsun zaten çıkış 1 olacak. Ama GLS burada sisteme pessimistik yaklaşır ve çıktıya x der. Bu da gereksiz bir debug sürecine sebep olabilir.
FOX modu: FOX modunda girişten bağımsız olarak x görüldüyse çıkış x sürülür.
CAT modu: CAT modunda ise x’in çıkışa etki ettiği durumlar göz önüne alınır geri kalan durumlarda sistem davranışını verilogda olduğu gibi modeller
Sonuç olarak race detector gereksiz debug veya gereksiz optimistik özellikleri engellemek için kullanılırsa daha temiz sonuçlar elde edilebilir.