Onlarca yıldır, çip tasarımındaki karmaşıklığın üstesinden gelmenin temel yolu bir tür yapısal hiyerarşi olmuştur. Her zaman mükemmel değildir ve bölmek ve fethetmek için ideal bir yol yoktur çünkü bunun gerçekleştirilen analize odaklanması gerekir. Aslında çoğu sistem, eşit derecede doğru olan ve birlikte bir heterarşi oluşturan çeşitli farklı hiyerarşilerden görülebilir.

Günümüzde kullanılan hiyerarşi biçimi hakkında düşünmenin en kolay yolu, bir mühendisten kavramsal olarak bir sistem tasarlamasını istemektir. Muhtemelen CPU, kodlayıcı, ekran alt sistemi vb. gibi etiketlere sahip büyük bloklar içeren bir blok şeması çizmeye başlayacaklardır. Bölünmüş blokların çoğunun bir işlev sağladığı düşünülse de bu işlevsel bir hiyerarşi değildir. Bu saf bir yapısal ayrışma da değildir, çünkü bir çipin içindeki her şey şekilsiz bir transistör denizine dönüşür.

Bu şema kabaca baskılı devre kartı tasarımı için geliştirilen pin hiyerarşisini takip ediyor. En düşük seviyede muhtemelen Texas Instruments 7400 serisi gibi bir mantık kütüphanesi kullanmışsınızdır. Bu cihazların pin haritaları vardı. Hiyerarşinin bir sonraki seviyesi, kart seviyesi ve arka panele bağlanan pinlerdi. Aralarında nadiren herhangi bir hiyerarşi vardı ve şemalar birden fazla 'sayfaya' yayılmıştı. Daha sonra sistemler karmaşıklaştıkça yapısal hiyerarşiler de desteklendi.

Şekil 1: Karmaşık bir çip için tipik bir blok diyagram, 2013 civarı. Kaynak: Texas Instruments

Bu hiyerarşi biçimi, blokların her birinin gelişiminin bir şekilde izole edilmesine ve karşılıklı bağımlılıkların en aza indirilmesine olanak tanıyan bir kapsülleme sağlar. Üst seviye bu blokların birbirine bağlandığı araç haline gelir. Bölünen blokların her biri daha sonra benzer bir ayrışmadan geçebilir.

Hiyerarşilerin kullanılmasının çeşitli nedenleri vardır. Ürün pazarlama müdürü Marc Swinnen "Kapasite birdir" diyor. Ansys. “Sorun çok büyüyor ve onu parçalara ayırmanız gerekiyor. Bir diğeri eşzamanlı mühendisliktir. Tasarım üzerinde aynı anda çalışmak isteyen birden fazla ekibiniz var, bu yüzden onu parçalara ayırıp parçalar üzerinde ayrı ayrı çalışıyorsunuz. Üçüncüsü yeniden kullanımdır. Başkalarının tasarladığı blokları yeniden kullanmak istiyorsunuz. Bunun incelikli bir biçimi, kendisi de bir hiyerarşi biçimi olan standart hücre kitaplığıdır. Dördüncü neden ise veri hacminin yönetilebilirliğidir. Beşinci neden, doğal olarak yeniden kullanıma sahip olduğunuz anılar ve çoklu çekirdekler gibi tekrarlayan yapılardır. Altıncı neden, her blokta farklı tasarım stillerine sahip olduğunuz analog/dijital gibi karma alanlardır. Farklı araçlar kullanacaksınız ve bunları hiyerarşik olarak parçalara ayıracaksınız."

Kapasite
Tasarımlar büyüdükçe birçok algoritmanın çalışması daha fazla zaman alır. Bunları parçalara ayırmak, yürütme sürelerinin daha hızlı olmasına ve daha az kaynak gerektirmesine neden olabilir. Kıdemli Ürün Müdürü Jim Schultz, "Büyük tasarımlarda, fiziksel uygulamaya başladığınızda, bu çok büyük tasarımların tamamlanması günler hatta haftalar sürebilir" diyor. Synopsus dijital uygulama grubu. "Bir şeyi berbat ederseniz, maliyetler önemli olabilir. Hiyerarşi bölmenin ve fethetmenin bir yoludur. Aynı anda tasarımın bir bölümünü kapatabileceğimizi bilmemizi sağlar. Biz işlevsellik eklemeye devam ettikçe ve çipler giderek büyüdükçe, bu yalnızca çalışma süresiyle ilgili değil, aynı zamanda kaynakların tükenmesiyle de ilgili; tüm bu yeniden kullanılabilir örnekleri yerleştirmek için gereken bellek miktarı, kapasiteyi aşıyor."

Hiyerarşik analiz yapabilmek için her blok için sınır koşullarının doğru ayarlandığından emin olmanız gerekir. Daha sonra en üst düzeyde sınırın ötesinde bir analiz yapmanız gerekiyor.

Synopsys'in personel ürün müdürü Rimpy Chugh, "Düz analiz çok zaman alıyor ancak tam doğruluk sağlıyor" diyor. “Hiyerarşi boyunca kara kutu yaklaşımını benimsemek size daha fazla hız kazandırır ancak doğruluğu kaybedersiniz. Bu, bir bloğa yönelik arayüz mantığının korunabileceği ve böylece aynı anda hız ve doğruluktan yararlanabileceğiniz özel bir çözüm (bkz. şekil 2) gerektirir. IP seviyesinde soyut bir model oluşturup bunu SoC seviyesinde kullanmak mümkün.”

Şekil 2: Soyut modeller kullanan hiyerarşik akış. Kaynak: Özet

Eş zamanlı mühendislik
Tasarım ekipleri artık tek bir binaya bağlı değil. Direktörü Simon Rance şöyle diyor: "Bir takım bir hiyerarşi üzerinde çalışacak ve başka bir ekip başka bir hiyerarşi üzerinde çalışacak şekilde pek çok tasarım bölümlendiriliyor ve bunlar aynı binada olabilir veya tüm dünyaya yayılmış olabilir." veri ve IP yönetimi için ürün yönetimi Keysight EDA'sı. "Ekipler artık farklı hızlarda çalıştığı için bu durum zorluklar yaratabilir. Daha sonra değişiklik yapmak zor olduğundan istikrarlı bir hiyerarşiye sahip olmak önemli hale gelir. Bu genellikle yalnızca son çare olarak gerçekleşir, ancak bunun yerine ekiplerin bunu gerçekleştirmek için yapıştırdığını veya şekerleme yaptığını görüyoruz. Çirkin olabilir ama chiplet'lerde bu zorluğun daha fazlasını görüyoruz."

Yeniden
Hiyerarşinin hem yukarıdan aşağıya hem de aşağıdan yukarıya faydalı olması gerekir. Kıdemli Ürün Pazarlama Müdürü Brian LaBorde, "İnsan vücudunda özel hücreler, kişiyi oluşturan yapı taşlarını oluşturan sistem ve organlar şeklinde organize oluyor" diyor. Ritim. "Benzer şekilde, transistör grupları, bir sisteme monte edilen makroları oluşturan devreler veya mantık kapıları oluşturur. Son birkaç on yılda, tümü tek bir çip üzerinde entegre edilmiş birçok farklı özel devreye sahip giderek daha büyük IC'ler gördük. Bu düzenlerin bölümlenmesi sanaldır ve bir düzen veritabanındaki hiyerarşiyle temsil edilir."

Veri yönetimi
Tüm tasarımlar çok fazla veri oluşturur ve bunun yönetilmesi gerekir. Keysight, "Mühendislik yaşam döngüsü yönetimi ve işlevsel güvenlik standartlarını karşılama ihtiyacıyla (otomotiv için ISO 26262 veya askeri havacılık için MIL882 standardı olsun), belgelerden doğrulamaya, test kriterlerine, doğrulama test planlarına ve sonuçlarına kadar birçok varlığa sahipsiniz" diyor. Rance. “Tam izlenebilirliğin olması için bunların hepsinin hiyerarşide tutulması gerekiyor. Her şeyi bir hiyerarşi içinde takip etmek zaten zordur, ancak aynı zamanda doğrulama ve test planları gibi tasarımın dışında da her şeye sahipsiniz. Bir şey testte başarısız olduğunda, hatta sahada daha da kötüsü, geri dönersiniz ve neyin başarısız olabileceğini bulmak için keşif yaparsınız. Hiyerarşiye eklenmiş tüm bu verilere ve meta verilere sahip değilseniz, onu asla bulamazsınız.

Tekrarlayan yapılar
Pek çok tasarım, ister bellek hücreleri, ister küçük işlemci dizileri veya arayüzler olsun, tekrarlayan yapılar içerir. Ancak bu dizilerin içinde gizli tehlikeler var. Ansys'ten Swinnen, "Diyelim ki 16X4 ızgara şeklinde düzenlenmiş 4 CPU çekirdeğiniz var" diyor. “Prensipte bunların hepsi aynı ama aslında farklı sınır koşullarına sahipler. Kenardakilerin etrafındaki ortam her biri için farklıdır. Optimizasyon yapmak istiyorsanız her birini benzersiz hale getirmeniz gerekir çünkü hepsinin kenarlarında benzersiz parazitler vardır. Bu takas her zaman vardır. Yeniden kullanılabilirliği nasıl korursunuz ve yine de benzersiz olanları nasıl bulursunuz? Termal gibi şeylere baktığınızda durum daha da kötüleşiyor.”

Birden çok alan adı
Analog ve dijital çok farklı olsa da geliştirme akışının araçların ayrılmasından yararlanan başka yönleri de vardır. Teknoloji etkinleştirme direktörü Ron Press, "EDA'nın tüm fikri, bu karmaşık sorunu alıp yapısal bir soruna basitleştirmek, parçalara ayırmak ve sorunu gerçekten basit hale getirmektir" diyor. Siemens Digital Industries Yazılımı. “Taramanın DFT için yaptığı şey budur. Eskiden ayrı çekirdekleri olsa bile her şeyi büyük, düz bir görüntüde yapmaya çalışırlardı. O zaman tasarımın ilerleyen aşamalarına kadar beklemeniz gerekir ve çok daha büyük bir problemle karşı karşıya kalırsınız. Artık dağıtılmış tasarım ekipleri ve yeniden kullanılan çekirdekler sayesinde insanların mümkün olduğunca fazla tak ve çalıştır özelliğine ihtiyacı var. DFT için tasarımlarını bitirecekler, o çekirdek için kendi modellerini oluşturacaklar ve sonra bu en üst seviyede devreye girecek. Sarma zincirleri gibi bir tür izolasyona sahip olduğu sürece, o parça üzerinde ayrı ayrı çalışabilir, DFT tasarımını tamamlayabilir ve desenlerini tamamlayabilirler. Bu, ekipleri bağımsız kılıyor ve tüm süreci çok daha kolay hale getiriyor."

Yapısal hiyerarşiyle ilgili sorunlar
Hiçbir sistem mükemmel değildir ve bu hiyerarşi biçimi bazı sorunlar yaratır. Synopsys'ten Schultz, "Bu sınırlardaki kısıtlamaların tasarımıyla ilgili kesinlikle bir yük var" diyor. “Kısıtlamaları kırıp doğru tanımlamanız ve blok sınırlarına kadar itmeniz gerekiyor. Bu sınırları doğru şekilde tanımladığınızdan emin olmak büyük bir sorundur. Diğer bir darbe ise, tasarım gereği, bir şeyi fiziksel olarak parçalara ayırdığınızda ve bunların benim bölümlerim olduğunu söylediğinizde, onu fiziksel olarak uygulamaya gittiğimde, bu sınırın ötesinde optimizasyon yapmayacağım. Optimize edemezsiniz; bu sınır artık sabittir. Bu hiyerarşide gerçekleşmesi gereken bir optimizasyon varsa bunu yapamazsınız. Sen kendinle sınırlısın."

Bu, çeşitli araçları ve akışları etkileyebilir. Siemens Press, "Hiyerarşik DFT ile üst düzey bir plan yaparlarsa, çekirdeğe çok sayıda pinin gitmesini planlayabilirler" diyor. “Sonra ortaya çıktı ki çekirdeğin çok fazla desene ihtiyacı yok ve benzer sayıda pin ayırdıkları diğer çekirdeğin çok daha fazla desene ihtiyacı var. Eğer tasarımlarını erkenden, en üst seviyeden dondurmuşlarsa, o zaman kalıp teslimleri o kadar verimli olmayacaktır.”

Yanlış hiyerarşiyi oluşturmak sizi birçok yönden sınırlayabilir. Schultz, "Özellikle büyük SoC'lerle ilgili en büyük sorunlardan biri, ağ oluşturma ve iletişimin tıkanıklık yaratabilmesidir" diye ekliyor. "Özellikle tasarım kötü bir şekilde bölümlendiğinde çip genelinde tıkanıklık görüyoruz. Blokların diğer bloklar aracılığıyla konuştuğunu görüyorum ve sizin de geçişler yaratmanız gerekiyor. Bu, tasarımda çok fazla tıkanıklığa neden olabilir. Ayrıca, böyle bir şey yaptığınızda zamanlama gereksinimlerinizi karşılamak çok daha zordur çünkü bu tam yolu kolayca optimize edemezsiniz. Her bloğu ayrı ayrı optimize etmeli ve yolların hepsinin işe yaramasını ummalısınız."

Sınırlarda ince değişiklikler meydana gelebilir. Swinnen, "İki bloğu birbirine yaklaştırdığınızda aralarında mantıksal bir bağlantı olur, ancak orada fiziksel olarak hiçbir şey yoktur" diyor. “Pimler birbirine değiyor ama tel yok. Ancak net listenizde, orada olması gereken bir kablo var. Bir dirence, bir kapasitansa sahip olması gerekiyor. Mantıksal bir bağlantınız var ancak fiziksel bir bağlantınız yok. Daha sonra kabloların bloğun bir tarafından geldiği, bloğun içinden geçtiği ve diğer ucundan çıktığı geçişleriniz olur. Pimler var, fiziksel kablolar var ama mantıksal kablolar yok. Mantıksal olarak mevcut değil. Bunu şemalarınıza çizemezsiniz.”

Bazı araçlar kötü hiyerarşilerle başa çıkabilir ancak bunları düzeltmek başka sorunlar yaratır. Schultz, "RTL'yi geliştirirken ve onu sentezlerken mantıksal bir hiyerarşiye sahipsiniz" diyor. "Fiziksel tasarımınızı yaptığınızda, bu mantıksal hiyerarşilerin bire bir fiziksel bölümle eşlenmesi gerekir. Sonuçta olan şu ki, benim mantıksal hiyerarşimde, mantıksal hiyerarşinin altındaki çocukla konuşan, başka bir ebeveynin altındaki bir şeyle gerçekten çok fazla konuşan bir çocuğum olabilir ve bu iki ebeveyn, kendilerinin fiziksel bölümleri haline gelir. Bu iki ebeveyn fiziksel olarak çipin karşıt taraflarına yerleştirilebilir. Mantıksal hiyerarşi fiziksel uygulamaya elverişli değildir. Bu durumun ele alınma şekli RTL'nin yeniden yapılandırılmasıdır. Şimdi bir şeyleri taşımaya ve mantığı onarmaya başlıyoruz, ancak bu saf bir RTL'nin veya mantıksal tasarımcının bileceği bir şey değil. Bu bilgi yalnızca fiziksel hiyerarşiyi hesaba kattığınızda ortaya çıkar. Bu fiziksel hiyerarşiyi gerçekten optimize etmek için ikisi arasında bir iletişim olması gerekiyor."

Bu, akışın diğer yerlerinde de olur. Çözümler ve iş geliştirmeden sorumlu başkan yardımcısı Frank Schirrmeister, "NoC, tüm hiyerarşinin entegrasyon yönlerine sahip olduğunuz en üst kokpit seviyesinde yer alır" diyor. arterler. "Belki de güç alanları arasındaki iki farklı işlevsel olmayan özellik nedeniyle hiyerarşide değişiklik yapılması gerektiğinde, RTL'nin yeniden faktörlendirilmesi basit olabilir. Hiyerarşi için daha yüksek düzeyde entegrasyona sahip olmak, RTL'yi buna göre yeniden düzenlemenize ve yeniden yapılandırmanıza yardımcı olur ve bunu tüm modüllerinizi manuel olarak değiştirmek zorunda kalarak gerçekten yapmak istemezsiniz."

Bunu takip etmek bir kabus olabilir. Rance, "Bir belgeye veya hiyerarşinin parçası olan bir dosyaya yönelik revizyon kontrolünü düşünün" diyor. "Yaptığınız işe bağlı olarak bu hiyerarşinin birden fazla versiyonuna veya revizyonuna sahip olabilirsiniz. PPA analizi yapan bir doğrulama ekibiniz olabilir ve bunu biraz değiştirip bu hiyerarşinin başka bir versiyonunu oluştururlarsa daha iyi performans gösterdiğini görebilirsiniz. Bunu takip etmeniz gerekiyor."

Hiyerarşiler bölmemize ve fethetmemize yardımcı olduğu kadar, bazı şeyler de bu basitleştirme girişimlerine meydan okuyor. Arteris'ten Schirrmeister, "Termal analiz gibi şeylerin çip çapında yapılması gerekiyor" diyor. “Ancak bunu çipte işlevsel olarak olup bitenlerle ve çipin içinden geçen verilerle ilişkilendirebilmeniz gerekiyor. Potansiyel olarak yaşam döngüsü perspektifinden, sıcak noktalara ve her bir işlevsellik parçasının bulunduğu yere bakacağınız ve en çok etkileneceğiniz bir çip fotoğrafı çekebilmek istiyorsunuz. Bunu verilerle ilişkilendirmek hiç de önemsiz değil.”

Diğer hiyerarşiler
İşlevsel hiyerarşi gibi başka hiyerarşiler de mevcuttur. Bugün buna en yakın olanı, bir sistemin ne yapması gerektiğine dair üst düzey tanımlarla başlayan bir ihtiyaç takip sistemidir. Bunlar, uygun gereksinimin karşılandığını doğrulayan test tezgahlarıyla birlikte, sonunda bunu sağlayan mantık veya diğer devreler tanımlanana kadar giderek daha basit görevlere bölünür.

Bazı hiyerarşiler tasarım sürecinde gelir ve gider. Schirrmeister, "Saat ağacı için bir hiyerarşiniz olabilir" diyor. “Güç dağıtım sisteminin hiyerarşisi var. Ayrıca, sistem analiz araçlarının, tam bir çip perspektifi için her şeyi birbirine nasıl bağladığını gösteren bir hiyerarşi vardır. ESL (elektronik sistem düzeyi) ile ilgili düşündüğümüz şey, her şeyi açıklayan yürütülebilir bir işlevsel özellik kavramıydı. Bu henüz ortaya çıkmamış bir şey. Bir şekilde bundan sıyrılıyor gibiyiz ki bu da şaşırtıcı.”

Fiziksel düzen başka bir hiyerarşi sağlar. En üst düzeyde, yapısal hiyerarşiyi başlangıç ​​noktası olarak kullanan kat planlaması yer alır. Bu bloklar yerleştirilir ve ara bağlantı aralarında yönlendirilir. Her blok, yine yerel ara bağlantıyla ilgilenen fiziksel sentez kullanılarak düzenlenmiştir. 3D-IC buna, yönlendirmenin artık Z yönünde mevcut olabileceği yeni bir boyut katacaktır.

Cadence'den LaBorde, "Çiplet tabanlı 2.5D ve 3D sistemlerin, çip üzerinde sistem (SoC) tasarımlarının yerini aldığını görmeye başladığımızda, hiyerarşi, fiziksel gerçekliğin temsili kadar stratejik bir yapı olmayacak" diyor. "Şematikteki makrolar, her biri kendi benzersiz sürecindeki bir sistemdeki çipleri temsil edebilir. Aralarındaki bağlantılar, düzendeki sembolik pinler yerine lehim çıkıntıları olacak.”

Sonuç
Mükemmel olmasa da, günümüzde kullanılan resmi olmayan yapısal ayrıştırmanın ustaca bir hiyerarşi olduğu kanıtlanmıştır. Akışın bazı yönleri bundan dolayı zarar görür, ancak çoğu bunu etkili bir şekilde kullanabilir ve araçlar onun yetersizliklerini telafi edebilir. Belli bir miktar optimizasyon potansiyelinin bu nedenle kaybolması söz konusu olsa da, bu muhtemelen üretkenlik adına yapılan küçük fedakarlıklardan biridir.

• SEO Destekli İçerik ve Halkla İlişkiler Dağıtımı. Bugün Gücünüzü Artırın.
• PlatoData.Network Dikey Üretken Yapay Zeka. Kendine güç ver. Buradan Erişin.
• PlatoAiStream. Web3 Zekası. Bilgi Genişletildi. Buradan Erişin.
• PlatoESG. karbon, temiz teknoloji, Enerji, Çevre, Güneş, Atık Yönetimi. Buradan Erişin.
• PlatoSağlık. Biyoteknoloji ve Klinik Araştırmalar Zekası. Buradan Erişin.
• Kaynak: https://semiengineering.com/an-entangled-heterarchy/