Çok çekirdekli heterojen sistemlerin tasarımı, uygulanması ve programlanması, genellikle yazılım iş yükleri tarafından yönlendirilerek daha yaygın hale geliyor, ancak işlemcileri, ara bağlantıları ve belleği optimize etmeye yardımcı olacak araçlar kopuk.

Son birkaç yılda, belirli bir yazılım seti için optimize edilmiş, tek bir işlemcinin tanımlanmasına ve uygulanmasına yardımcı olan birçok araç ortaya çıktı. Cadence ve Synopsys gibi şirketler onlarca yıldır kendi özel mimarileri için dahili araçlara sahipken, RISC-V bu tür araçlar için yeni ve açık bir pazar yeri yarattı. Mevcut seçeneklerin genişliği ve bunları desteklemek için gerekli ekosistem ile benimseme oranı hızlı olmuştur.

Ancak bir tasarım, birden fazla işlemci veya heterojen bilgi işlem ortamları içerdiğinde, araçlar çok daha az kullanılabilir hale gelir. Bellek alt sistemini veya iletişim ağını göz önünde bulundururken yazılımın bölümlenmesine veya bir işlemcinin optimize edilmesine yardımcı olabilecek çok sayıda araç vardır. Sistem içindeki veri akışını analiz edebilen araçlarda da boşluklar var. Bu görevlerden bazılarını yapabilen bir avuç araç olsa da hepsini yapabilecek hiçbir şey yoktur ve görevi gerçekleştirmek için birden çok aracı birleştiren akışlar yoktur.

Çoklu çekirdek devreye girer girmez pek çok soru ortaya çıkıyor. Pazarlamadan Sorumlu Başkan Yardımcısı Frank Schirrmeister, "RISC-V çok çekirdekli bir çılgınlık var" diyor. arter IP'si. "Genellikle bunları benzer şekillerde genişletirsiniz. Belki birden fazla kümeniz vardır. Küme içinde birden fazla bilgi işlem biriminiz olabilir ve belki de bilgi işlem ve taşımayı birlikte optimize edersiniz. Küme ile ilişkilendirilmiş veya her bir çekirdeğe iliştirilmiş bir uygulama hızlandırıcıya sahip olmaya karar verebilirsiniz. Her işlemci, Codasip'ten CodAL veya Synopsys'ten LISATek/NML gibi bir şey kullanan, büyük ölçüde optimize edilmiş uygulamaya özel talimat işlemcisi (ASIP) olabilir. Bir uygulama hızlandırıcı oluşturmak için üst düzey sentez kullanabilirsiniz."

Ne kayıp
Bir akışın bazı temel parçaları basitçe mevcut değildir ve diğerleri gerektiği kadar sorunsuz bir şekilde birlikte çalışmaz. Ama bazı ilerlemeler kaydediliyor.

CTO'su Zdeněk Přikryl, "Tasarım metodolojisindeki boşluklar her zaman daha az otomatik, geleneksel RTL tasarım yaklaşımlarını kullanabilir" diyor. kodasip. "İşlemci tasarımı otomasyon araçları daha da geliştikçe, boşlukların kapanmasını ve eksiksiz bir donanım/yazılım ortak tasarım metodolojisinin ortaya çıkmasını bekleyebiliriz."

Akışta büyük boşluklar kalır. Sanal prototipleme baş mühendisi Tim Kogel, "Homojen çoklu çekirdek için bile, hatta heterojen çok çekirdekli sistem için bile otomatik paralelleştirme aracı gibisi yoktur" diyor. Synopsus. "İnsanlar doğru veri modelini bulmakta zorlanıyor. NVIDIA'nın CUDA franchise'ına büyük bir yatırımı var ve bunu ele almak için her türlü programlama modelini geliştiriyor. Hala olması gereken çok şey var. Bugün gördüğüm şey, farklı alt sistemler için ayrı alet zincirlerine sahip olmanız. Örneğin, sinir ağlarınız için makine öğrenimi derleyici araç zincirine sahipsiniz ve ardından CPU için geleneksel derleyici araç zincirine sahipsiniz ve ardından bunları birleştirmek biraz çaba gerektiriyor.”

Kısıtlamalar yapıldığında, çözümler daha olası hale gelir. Bluespec CEO'su Charlie Hauck, "RISC-V'nin hızlandırıcıları bir işlemciye sıkı bir şekilde entegre etme yeteneği büyük bir avantaj çünkü Linux tarafından desteklenmesi gereken heterojenlik aralığını azaltıyor" diyor. "Bunu, hızlandırıcılar tarafından uygulanan heterojenlik aralığını kısıtlamadan yapabilir. Bu, heterojen bir çoklu işlem ortamında etki alanına özgü işlemcileri desteklemek için gereken araç değişikliklerinin kapsamını en aza indirir. Bu, uygulamaya ve doğrulamaya geçmeden önce teknik özellikleri iyileştirmek için hızlı mimari keşif için döngüye yaklaşık sistem seviyesinde C/SystemC modellemeyi içerir.”

Yazılım odaklı olması için oradan başlayıp donanıma kadar çalışması gerekir. Tasarım doğrulama teknolojisi strateji direktörü Neil Hand, "Modele dayalı sistem mühendisliği ile, yazılım, donanım, fiziksel gibi birden çok alanı aşan genel işlevsellikle başlıyorlar" diyor. Siemens Digital Industries Yazılımı. "Aşağı bastırmaya başladıklarında, donanım ve yazılım ayrımına, yani her bir işlemciye neyin girdiğine bakıyorlar. Ve genellikle, işi en etkili şekilde yapacak işlemciyi tercih ederler. Algoritmayı tek bir yekpare işlemci üzerinde çalıştırmaktan kurtulabilirlerse, muhtemelen bunu yaparlar. Gereksinimleri karşılamıyorsa, bunu ortadan kaldırmanın ve hangi işlevselliğin kendi yerleşik çekirdeğine veya kendi hızlandırıcılarına sahip olduğuna karar vermenin bir yolunu istiyorlar.”

Ancak aralarına herhangi bir ağ biçimi koyar koymaz, iletişim yükünü analiz etmeniz gerekir. Arteris'ten Schirrmeister, "Akışın çalışan alt kümeleri var" diyor. "Örneğin, araç grubumuzda, NoC'nin kendisini analiz etmenize yardımcı olan bir model ortaya koyuyoruz. 10 başlatıcı ve 15 hedefiniz olduğunda kaç anahtara ihtiyacınız olduğunu anlarsınız. Bunlar benim önceliklerim. Bu mimari analizini yaparsınız ve sonra bunu bağlam içinde çözersiniz. Ardından onu Platform Architect gibi bir şeye aktarırsınız. Bu ilişkiler yerinde, ancak daha büyük sorun, bağlantılarının kopmuş olması. Teknik akış orada olsa bile, bir kişinin veya hatta bir ekibin, mimari geri bildirime dayalı tüm bu analiz optimizasyonlarını yapmak için verimli bir şekilde etkileşim kurma kapasitesi çok dağıtılmıştır.

Ve her zaman doğru soruları soramayabilirler. Siemens'teki Catapult HLS ekibinin program direktörü Russell Klein, "Çip şirketlerinin sunduğu ağ tekliflerine baktığınızda, dünyayı hala herhangi bir görevi yerine getirmek isteyen sistemler olarak görüyorlar" diyor. "Taşımanız gereken verilere, hangi gecikmelere sahip olduğumuza, hangi bant genişliğinin gerekli olduğuna bakıyorlar. Ancak bu belleği alıp "buraya, bu hesaplama alanına" koyma olasılığını düşünmüyorlar. O zaman verilerin hiçbir zaman ara bağlantıyı taşıması veya kullanması gerekmez. Veri gruplarını ihtiyaç duyulduğu yerlerde ayırır ve bunları bilgi işlem öğeleriyle gruplandırırsak, iletişim en aza indirilebilir. Peki ya bellek içi bilgi işlem? Ara bağlantılarınıza bakarken bu tür şeylerin dikkate alınması gerekir. Bunlardan hangisini ara bağlantıdan çıkarabiliriz ve en başta onu taşımamıza bile gerek kalmaz? Bu sorunu anlayabilecek ve çözüm sunabilecek araçlara sahip olduğumuzu düşünmüyorum.”

Çok daha fazlası gerekiyor. Siemens'ten Hand, "Bir çeşit keşif, bölümleme ve ortak tasarım yetenekleri var ve bugün kaba kuvvet kullanarak yolunuza devam edebilirsiniz" diyor. "Fakat gereken daha çok şey var. 'Hedeflerime ulaştım mı?' sorusunu yanıtlamaya yardımcı olacak birçok yeteneğe sahibiz. Ancak yukarıdan aşağıya akışın zorluklarından biri, ölçümler yapabilmeniz, tahminler yapabilmeniz ve bunun için modellere, performans bilgilerine, sistemin yükünü anlamak için yazılıma, sistem takasları. Bu çözmesi gerçekten zor bir problem. Bir NoC'niz varsa, paylaşılan belleğiniz varsa veya paylaşılmamış belleğiniz varsa, bunlar genel performans üzerinde çok büyük etkilerdir. Ve ne yazık ki bunu bir yazılım kapsayıcısında soyutlayamazsınız.”

Yazılım hazırlığı
Yazılımın mevcut bir donanım parçasına en iyi eşlemesini bulabilmek veya bir yazılım parçası için en uygun donanım mimarisini tanımlayabilmek, kapsamlı analiz yetenekleri gerektirir.

"Fantezi donanım özelliklerine sahip karmaşık bir çipe sahip olduğunuzda, yazılım geliştirici bundan nasıl faydalanır? Synopsys'ten Kogel, en büyük zorluğun yattığı yer burasıdır” diyor. "Birçok kişi yapay zeka için donanım geliştiriyor, ancak savaş alanı makine öğrenimi derleyicisidir. Güzel hızlandırıcı donanımı tasarlayabilirsiniz, ancak derleyici onu verimli bir şekilde kullanamıyorsa, büyük olasılıkla kullanılmayacaktır. Bu çözülmesi gereken büyük bir problem.”

Bugün, bu ortamlar dağıtılmıştır. şirketinde Tensilica Xtensa işlemci IP ürün pazarlama grubu yöneticisi George Wall, "Bu analizi yapmanıza izin veren bir yazılım ortamına sahip olmak değerlidir" diyor. Ritim. "Ama bu muhtemelen birden fazla yazılım ortamıdır. Muhtemelen, işlemci satıcınızın geliştirme araçlarını kullanarak etrafında bir SystemC modeli olan bir ISS gibi bakabileceğiniz çok işlemci merkezli bazı ortamlar vardır. Ve sonra muhtemelen sanal platformla daha üst düzey bir parça var.

Tam özgürlük kullanıldığında RISC-V bile yazılım ekosistemini sürdürmek için mücadele ediyor. Kogel, "Yazılım karmaşıklığını kontrol altında tutmak için komut seti değişkenlerinde standartlaştırmanız gerekiyor" diyor. “Tamsayı ve kayan nokta için ve her talimat seti için, genel altyapıdan faydalanmak için kullanmanız gereken önceden tanımlanmış bir sete sahipler. Böylece tamamen açmak yerine standart profiller tanımlanır. Ama onları kullanmamayı seçersen, o zaman kendi başınasın.”

Profiller, yazılım ekosistemini basitleştirmeye yardımcı olmak için donanımı kısıtlar. Codasip'ten Přikryl, "RISC-V yazılım ekosistemi buna hazırlanıyor" diyor. "Temel olarak neyin beklendiğini ve alana özgü özelliklerin nasıl kullanılabileceğini güzel bir şekilde özetleyen profillere ve platformlara ayrılmış farklı gruplarımız var. Bu yerinde olduğunda, yazılım ekosistemi güzel bir şekilde büyüyebilir çünkü yazılım yığınının farklı bölümlerinin nasıl ele alınması gerektiği açıktır.”

Heterojenlik söz konusu olduğunda işler daha az netleşir. Siemens gömülü yazılım ürün yönetimi başkanı Jeff Hancock, "İnsanların heterojen sistemlere hipervizörler yerleştirdiğini görüyoruz" diyor. "Elbette, bu, uygulama çekirdeklerinde tek iş parçacıklı olarak kabul edilebilir, ancak otomotivde örneğin bir hipervizörde, dörtlü bir A53'te veya buna benzer bir şeyde Linux ve Android Auto çalıştırıyorlar. Ve sonra, Autostar'ı çalıştıran aynı çipte bulunan bu R çekirdeklerine sahipler. Yani birden çok çekirdeğe sahip tek bir SoC'de bile, aslında heterojen türde ortamlar çalıştırıyorlar."

Domaine özel çözümler üretiliyor. Kogel, "Arm'ın SOAFEE girişimini otomotiv alanında görüyoruz" diyor. “Bu, yazılım geliştirmeyi, bulutta yerel geliştirmeden konuşlandırmaya sorunsuz bir şekilde geçebileceğiniz, liman işçileri ve sanallaştırma ile her şeyi kapsüllemeye çalışarak resmileştirme girişimidir. Bu düzeyde bir şey bulmak için bunun gibi çok şirketli inisiyatifler gerekiyor.”

Ama yazılımın değişmesi gerekiyor. Siemens'ten Klein, "İster dizüstü bilgisayarınızda sekiz Intel çekirdeği, ister telefonunuzda bir düzine çekirdek olsun, programlama modeli hala tek iş parçacıklı bir uygulamadır" diyor. “Ve bu sınırlayıcı faktör. Yazılımcılar tek çekirdekli programlamamızı talep edecekleri ve işlemcideki tek şeyin biz olduğumuz yanılsaması olduğu sürece - bunu geçene kadar, denemeye devam etmek zorunda kalacağız. daha büyük işlemciler oluşturun ve bu modeldeki işleri hızlandırın. Bu modeli kırdığınız anda, her türlü harika şey oluyor. Ancak bu bir donanım teknolojisi sorunu değil. Bu bir yazılım, kültürel mesele.”

Tek bir iş parçacığını birden çok çekirdeğe bölmek için girişimlerde bulunuldu. kurucusu ve CEO'su Simon Davidmann, "Bu sistemleri inşa eden mimarlar, bir şeyleri nasıl parçalara ayırabileceklerini ve bunları paralel olarak nasıl yapabileceklerini düşünüyorlar" diyor. Imperas Yazılımı. "Uygulamalar tek bir C iş parçacığı değil, çünkü bununla bir şey yapmak çok zor olurdu. C kodunu paralelleştirmede sihir yok.”

İsteğe bağlı yazılımı alıp bunu isteğe bağlı donanıma hedefleyebilmek kutsal kâsedir. Bunun sadece bir adımı, bir veri akış modeli türetebilmektir ve bu, genel durumda çözülmesi çok zor bir problemdir.

Kogel, "Başlangıç ​​için daha uygun bir veri modeline sahip olduğunuz için makine öğrenimi çerçeveleri için çalışıyor" diyor. "TensorFlow, rastgele bir C, C++ kodu parçasından çok daha güzel bir şekilde tanımlanan içsel paralelliğe ve veri bağımlılıklarına sahiptir. Şu anda gördüğümüz şey, insanların gerçek bağımlılıkları ayıklamak için uygulamaları sanal platformlarda veya hedef donanımda çalıştırmaktan bu bağımlılıkları yeniden tasarlamaya çalışarak izlemeyi kullandıklarıdır. Statik veya dinamik kod analizine dayalı olarak bunu otomatik olarak yapmak zor bir problemdir. Bu yönde girişimler gördük, ancak bu hala daha çok bir araştırma konusu. Çözülürse büyük fayda sağlar.”

Sorun her zaman veri bağımlılıkları olmuştur. Klein, "Sinir ağlarıyla ilgili bir şey, düzenli bir yapıya sahip olmaları ve utanç verici bir şekilde paralel olmalarıdır" diyor. “Orada o kadar çok paralellik var ki, herhangi bir veri bağımlılığı getirmeden farklı hızlandırıcılarda nelerin bölümlenebileceğini anlamak çok daha kolay hale geliyor. Genel amaçlı yazılımlara, genelleştirilmiş algoritmalara geçerken, bu hala kimsenin çözemediği bir ceviz. Bilgisayarda tek olacakları ve tek iş parçacıklı bir uygulama olacağı yanılsamasıyla birinin yazdığı C programını nasıl alıp birden çok küçük CPU'ya taşıyabiliriz? Bu hala çok zor bir problem. Ve yine, yazılım topluluğu oraya gitmenin potansiyel faydalarını benimsiyor gibi görünmüyor.”

Sorun tüm uygulama alanlarında var. "AI/ML bünyesindeki çoğu tasarım ekibi ve fikri mülkiyet sağlayıcısı, bir numaralı kurala odaklanıyor - iş yüküyle eşleşen işleme beygir gücü sağlayın" diyor Steve Roddy, pazarlama müdürü kuadrik. "Fakat iki numaralı kuralı ihmal ettiler - uygulama yazılımı geliştiricisine yük olmayın. Çoğu makine öğrenimi çözümü, eski bir CPU veya DSP'den grafik işlemenin bir kısmını boşalttı, ancak makine öğrenimi grafik iş yükünün tamamını değil. Bu, yazılım geliştiricinin hayatını daha da zorlaştırıyor.”

Değişim zordur. Cadence's Wall, "Oraya ulaşmak istiyoruz" diyor. “Mimariden tamamen ayrılmış bir yazılım geliştirme ortamına sahip olmak son derece zorlu bir problem. Kişi OpenMP gibi bir şeyden yararlansa bile, her zaman bir düzeyde mimari bağımlılık olacaktır.”

Masada çok şey bırakılıyor. "Performans ve verimlilik açısından masaya bıraktığınız şey - ve donanımı tasarladığınızda ve ardından onu duvara fırlattığınızda veya başka bir şirkete sattığınızda ve ardından yazılımı yazarken sistemin genel kapasitesi - çok büyük." diyor Klein. “Çok fazla yetenek kaybı var, çok fazla verimlilik kaybı, çok fazla performans kaybı var. Gerekli kişilerin oturup üzerinde çalışacak yazılımın mimarisini düşünürken donanımı tasarladığı çok az kuruluş biliyorum. Neredeyse her zaman odaklandıkları şey, herhangi bir tek iş parçacıklı uygulamayı çalıştırmak için donanım tasarlamak ve onu bu kalıba sığdırmaya çalışmaktır. Bu bozulmaya başlıyor olabilir.

Bir ekip alır. Schirrmeister, "Sorunları anlamak ekip çalışması gerektirir" diyor. "Bir dizi mimar gerektiriyor ve inanılmaz derecede karmaşık bir görev. Aynı zamanda, sistem karmaşıklığı muazzam bir hızla artıyor. Araçların bunun gerçekten işe yaraması için yeterince bağlantılı hale gelebileceği bir döneme yaklaşıyoruz. Aletleri dikey olarak bağlıyoruz ve bazı akışlar yerinde. Bazı mimari optimizasyon araçları vardır. Kesinlikle hepsini yönetebilecek insanlara sahip değiliz, bu yüzden bu bir eğitim sorunu. Ancak bunu makine öğrenimi ve yapay zeka ile birleştirirseniz, anlamlı varyasyonlardan geçmek için döngüleri karşılayabilirseniz, o zaman bir şansımız olur."

Sonuç
Son 25 yıldır insanlar, donanım ve yazılımı kapsayabilecek sistem düzeyinde araçların potansiyeline bakıyorlar. Her ikisini de optimize edebilmenin ve birini diğeriyle eşleyebilmenin bariz avantajları vardır, ancak bunlar açıkça yazılım üretkenliği sorununun üstesinden gelmek için hiçbir zaman yeterli olmamıştır. Pazara daha hızlı girmek, daha hızlı çalışan, daha az güç tüketen veya daha ucuz olan bir üründen daha önemlidir. Sektördeki birçok kişi değişimin kaçınılmaz olduğunu düşünüyor ancak uzun süredir yanılıyorlar.

• 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. Otomotiv / EV'ler, karbon, temiz teknoloji, Enerji, Çevre, Güneş, Atık Yönetimi. Buradan Erişin.
• Blok Ofsetleri. Çevre Dengeleme Sahipliğini Modernleştirme. Buradan Erişin.
• Kaynak: https://semiengineering.com/not-all-there-heterogeneous-multiprocessor-design-tools/