Bir RISC-V tasarımı ne kadar ileri götürülebilir ve yine de uyumlu olabilir?

Cevap her zaman siyah beyaz değildir çünkü RISC V Konsept önceki açık kaynak projelerinden çok farklı. Ancak RISC-V'ye olan ilgi ve etkinlik artmaya devam ettikçe, açık standart bir ISA ile tasarlamanın bazı zorluklarını ele almak için yapıcı tartışmalar yapılıyor.

RISC-V International CTO'su Mark Himelstein, "RISC-V standardı, uygulamaların uyumlu olduğu bir şeydir" dedi. "Ancak, genellikle 'uyumlu' kelimesini kullanmıyoruz çünkü nihai hedef, uygulamaları bir Profil ile uyumlu uygulamalarda çalıştırmaktır. Uyumluluk, uyumluluğa ulaşmanın bir yoludur.”

Bu tanımlardan herhangi birini daraltmadaki sorunlardan biri tarihsel bağlamdır. OpenSPARC gibi bazı açık işlemci projelerinin aksine, kaynak kodu yoktur. OpenSPARC, RISC-V benzeri bir ISA sağlamak yerine Sun Microsystems işlemcilerinin RTL açıklamalarına erişim sağladı.

Kıdemli Teknik Pazarlama Direktörü Roddy Urquhart, "RISC-V, modüler olmasıyla önceki RISC komut setlerinden farklıdır" dedi. kodasip. "RISC-V, RV32I veya RV64I gibi bir temel tamsayı komut setinin kullanılmasını gerektirir ve isteğe bağlı olan çeşitli standart uzantıları onaylamıştır. Ayrıca, özel talimatlar için komut kodlama alanı tanımlamıştır. ISA uyumluluğu için gerekli koşul, uygun temel tamsayı kümesinin kullanılmasıdır, ancak standart uzantıların ve/veya özel uzantıların bir kombinasyonu kullanılırsa, ISA RISC-V uyumludur.

Yine de, bu yapbozun pek çok parçası ve nasıl tanımlanacağı konusunda pek çok kıpırdanma alanı var.

"RISC-V uyumlu olmak için, gerçekten yalnızca çok küçük bir talimat alt kümesi uygulamanız gerekir," dedi seçkin mimar Rob Aitken. Synopsus. "O zaman tasarımınızın RISC-V uyumlu olduğunu söyleyebilirsiniz çünkü minimum tamsayılar komut setini uygular. Bunun arkasındaki tüm fikir, bir hızlandırıcının sisteme cıvatalanabilmesiydi, ardından hızlandırıcınız için istediğiniz işlem kodlarına vb. sahip olabilirsiniz, bu da komut seti alanında RISC-V minimum komut parçasıyla birlikte var olabilir. Standardın bir parçası olarak tüm bunlara felsefi olarak izin verilir. Bu nedenle etkili bir şekilde 'uyumlu', yalnızca RISC-V'nin uyguladığımı söylediğim parçalarını uyguladığım anlamına gelir ve yaptığım diğer her şey tanımlanan genişletilebilirlik çerçevesi içindedir ve neyse odur. Bu, orada bulunan önceki ISA'lardan farklı bir canavar, burada herhangi bir genişletilebilirlik varsa, çok kısıtlı.

Richard Grisenthwaite, Başkan Yardımcısı ve Baş Mimar Kol “Uygunluk ikilidir: Ya %100 uyumlusunuz ya da uyumlu değilsiniz. Çalıştırmak istediğiniz yazılım sizin oluşturmadığınız yönergelere dayanıyorsa, donanımınız üzerinde çalışmaz. Ayrıca, cihazınızda çalışan bir yazılımın yaygın olarak kullanılan bir ekosistemin parçası olmasını istiyorsanız, diğer donanımlarda bulunmayan talimatları kullanması mantıklı değildir - bu, yazılım yazarlarını olmayan yazmaya teşvik etmek açısından sorunlu olabilir. -taşınabilir yazılım. Bu nedenle, Arm ve açık kaynak oynatıcılar da dahil olmak üzere diğer birçok ISA sağlayıcısı, mimariyi etkin bir şekilde standartlaştıran bir ad uzantıları koleksiyonuyla çalışıyor. Bu uzantılar ve spesifikasyonlar dahilinde kalırsanız uyumluluk bir sorun teşkil etmez, ancak bu size açık kaynaktan bekleyebileceğiniz esnekliği de bırakmaz.”

Açık standartla tasarım bağlamında uyumluluğu anlamak ISA'lar meydan okumaya devam ediyor.

CEO'su Simon Davidmann, "Bunu düzgün bir şekilde yapmak için inanılmaz derecede büyük miktarda kaynağa ihtiyaç var" dedi. Imperas Yazılımı. “Uygunluk, kontrolle ilgilidir. Tanımla uyumlu olmak istiyorsanız, birisinin uyumluluğu gösterme ve zorlama yeteneği sağlaması gerekir. Arm gibi şirketlerin yaptığı şey, geçmişte tüm ISA'ların yaptığı gibi, onu birçok farklı şekilde kontrol etmektir. 'Bizim tanımımız bu' diyorlar. Onu bu zarfın dışında değiştirmenize izin verilmiyor.' Arm ile talimat ekleyemezsiniz, kod çözmeyi değiştiremezsiniz, kayıt ekleyemezsiniz çünkü bunlardan herhangi birini yaparsanız, bu bir 'Arm' değildir ve size izin verdikleri lisans size izin vermez. yapmak için. Google, Samsung ve mimarlık lisansı sahibi diğerlerinin bile yasal olarak onun Arm olmasını engellemesine izin verilmiyor.”

Ancak Arm, mimari lisans sahiplerinin RTL'yi biraz değiştirmesine izin verir, ancak kaynak kodunu değiştirmez. Davidmann, "İş hattına fazladan bir aşama ekleyebilir veya Apple'ın M1 ve M2'de yaptığı gibi farklı bir şekilde uygulayabilirsiniz" dedi. "Ama bunun hâlâ bir Arm olduğu gerçeğini nasıl kabul ediyorlar? Arm ile uyumu nasıldır? Arm, neyi lisansladığınıza ve onunla ne kadar oynamanıza izin verildiğine bağlı olarak önemli bir teknoloji sağlar. Örneğin, küçük bir çekirdeği lisanslayan ve onu değiştirmesine izin verilmeyen biri, onu değiştirmek için herhangi bir şey yapmalarına izin verilmediğinden kontrol etmek için oldukça basit bazı uyumluluk testleri alacaktır. RTL'yi gerçekten değiştiremezler, bu yüzden yapılacak çok şey yok. Bunu sentezleyebilirler ve farklı şeyleri hedefleyebilirler ve farklı geçitler çıkarabilirler, ancak RTL'yi değiştirmelerine izin verilmezken, Apple veya Google veya Samsung veya MediaTek gibi bir Arm mimarisi lisans sahibi boru hattı aşamalarını değiştirebilir. İstediklerini yapabilirler ve aslında bazıları sıfırdan başlayabilir. 'Belgenizi alacağız ve onu istediğimiz gibi oluşturacağız' diyebilirler. Uyumlu olduğunu nasıl kanıtlarız? Mimari lisans sahipleri, milyonlarca dolarlarının bir parçası olarak, referanslar, testler ve çerçeveler içeren büyük miktarda uyumluluk teknolojisi elde ederler. Sonra onu inceleyip hala bir Kol olup olmadığını anlayabilirler ve düzeltmeleri gerekir."

Ayrıca, gömülü işlemci kullanıcıları yazılımlarını sıklıkla kaynak kodundan derlerken, zengin işletim sistemleri ve bunlar üzerinde çalışan uygulamalar ikili dosyalar olarak sunulur.

Urquhart, bunun tutarlı olması için bir temel tamsayı kümesi ile isteğe bağlı standart uzantıların birleşimini gerektirdiğini belirtti. "RISC-V International, standart uzantıların zorunlu bir kombinasyonunu belirten RVA22U64 gibi profilleri tanımlayarak bunu standartlaştırdı. Bu nedenle, bazı bağlamlarda, ISA'ya ek olarak bir profile uyum önemlidir. Örneğin, tasarım RTL olarak uygulanırsa, talimat doğruluğuna sahip bir modele göre doğrulanabilir mi? Bu, modelin temel tamsayı talimatlarını, seçilen standart uzantıları ve özel talimatları içermesini gerektirir.”

Örneğin Codasip Studio, bunu yapmak için bir UVM ortamı oluşturabilir. Ancak bunu bir perspektife oturtmak gerekirse, uyumluluk sürecinin tasarım veya tasarım süreci üzerinde bir etkisi vardır.

RISC-V International'dan Himelstein'a göre, birlikte çalışan talimat durumu ve davranıştan oluşan bir dizi uzantı içeren ilk “Profiller” bu yıl onaylandı. “Uzatmalar ya zorunlu ya da isteğe bağlıdır. Bir Profil ile uyumlu olmayı seçen uygulamalar, tüm zorunlu uzantıları uygulamalıdır. Profiller, işletim sistemlerine ve araç zincirlerine topluluk genelinde destek için tek bir hedef sağlar."

Uyumsuzluk sorunları varsa satıcı, yazım hataları ve bir geçmiş olsun planı yayınlar. Himelstein, "Özel değişiklikler olarak izin verilen kasıtlıysa, satıcı ürününü RISC-V Profili uyumlu olarak markalayamaz," dedi.

Her mimaride bu sorun vardır. Himelstein, "Altın sonuçlar veren simülatörleri doğrulayan temel bir dizi testimiz var" dedi. "Ancak yeterli DV, sistem testleri, yazılım testleri vb. yaptıklarını kanıtlamak satıcıya kalmıştır. Biz bir sertifika kuruluşu değiliz. Herkesi Profile uyumlu olmaya iten, uygulanabilir bir yazılım ekonomisine sahip olma ihtiyacıdır, böylece yazılım satıcıları, birden çok uygulamada çalışan işletim sistemi türü başına bir sürüme sahip olabilir. Biz bir topluluğuz ve bu topluluk sürekli iyileştirme organizasyonudur. Her zaman simülatörü ve testleri geliştirmek için çalışıyoruz.”

parçalanma riski
Parçalanma, yazılım alanında her zaman bir endişe kaynağıdır. Açık donanım standartlarının açık kaynak derleyiciler tarafından desteklenmesi gerekmese de, hem LLVM topluluklarında hem de GCC topluluklarında RISC-V'yi desteklemek için büyük bir çaba harcanmaktadır ve donanım standardından sapmanın açık kaynak kodlu yazılım üzerinde etkisi vardır. kaynak uygulaması.

"RISC-V dünyasında, standardın onaylanması çok uzun süren kısmı, RISC-V standardının vektör uzantısıdır," diye açıklıyor yazılım mühendisliği direktörü Catherine Moore. Siemens Digital Industries Yazılımı. "Pek çok donanım satıcısı, onaylanmadan önce bu uzantıya gerçekten ihtiyaç duyuyordu, pek çok donanım satıcısı gidip standardın nasıl görünebileceğini düşündüklerini uyguladı ve standardın kendi sürümünü uyguladı, vb. sonunda onaylanandan sapan standardın kendi versiyonuna kodlanmıştır. Sonuç olarak, standardın yan ürünlerini desteklemek için derleme araçları geliştirmek zorunda kaldılar ve gördüğümüz şey elbette parçalanma.”

Bu da, açık kaynak derleyici araçları için özel yazılım hizmetleri sağlayan gruplar için bir fırsat yaratır.

Moore, "Bu donanım standartları parçalandığında, bu çok büyük bir destek fırsatıdır, çünkü açık kaynak bileşenleri oluşturan çoğu kişi, bunların inşa ettikleri açık kaynak topluluklarına sunulmasını ve kabul edilmesini ister," dedi. "Ancak örneğin GCC, standarttan sapan herhangi bir gönderimi kabul etmeyecektir, bu nedenle RISC-V'de vektör uzantısının tek seferlik uygulamalarına sahip sağlayıcıların, GCC veya LLVM aracılığıyla sağlanan topluluk dışı desteği desteklemesi gerekir. ”

Parçalanmanın sonuçları önemlidir ve standardın tasarımda farklı şekilde uygulanan kısmı topluluk dışında olduğu için desteklenmesi daha maliyetli olacaktır.

Buna rağmen, RISC-V özel bir talimat setine izin verir. Moore, "RISC-V standardında, satıcıların kendi özel talimatlarını oluşturmalarına izin veren bir uzantı var" dedi. "Parçalara ayırma bundan ayrıdır çünkü ayrı yönergelerin nasıl oluşturulacağına ilişkin bir standart vardır. Her şeyi ayrı ve özel olarak işaretleyen bir kodlama var. Bu şeyler bu standardın bir parçası olarak düşünülmelidir. Bir uzantıyı, standardın onaylanma şeklinden farklı bir şekilde uygulamak, en azından yazılım dünyasında sorun yaşadığınız noktadır."

Alarm sesi
Bir RISC-V tasarımının başka bir ISA ile uyumlu olması için çok miktarda doğrulama uyumluluğu testi gerekir.

Imperas'tan Davidmann, "RISC-V, bir Arm'ın yaptığı gibi uyumluluğu savunmuyor" dedi. “Uyumluluk testleri sağlayacak kaynaklara sahip değiller. Sahip oldukları şey, temelde çok basit uyumluluk olan açık topluluk testleri oluşturan gönüllü çalışmadır. Henüz çok iyi uyumluluk süitleri olduğuna inanmıyorum. İlk çalışmamızla birlikte modelimiz ve referans simülatörümüz uyumluluk grubundayken bazı testler oluşturduk ve bu konuda yardımcı olmaya çalışmak için bir referans oluşturduk ancak mevcut kaynak yoktu. Ticari şirketlerde, Intel'in silikondan bir servet kazandığını, böylece doğrulama uyumluluğuna büyük yatırımlar yapabileceğini düşünmeniz gerekir. Arm, çekirdekleri lisanslayarak çok para kazanıyor, bu yüzden bunların büyük gelir akışları var ve yaptıkları şey, bunu ekosistemlerine yatırmak ve uyumluluk altında çok şey var. RISC-V ekosisteminin finansmanı yoktur. Herkes bir bireydir. Uyumlulukta yaptıklarına 'İşte bazı basit testler, bunları baştan geçirmeniz gerekiyor' deniliyor. Bunları inceledikten sonra bize verilerinizi gönderin, biz de RISC-V uyumlu olduğunuz rozetini kullanmanıza izin verelim.' Ancak bu ticari açıdan sağlam bir sigorta poliçesi değil.”

Ek olarak, uyumluluk, doğrulamanın gerekli ancak yeterli olmayan bir bileşenidir.

Codasip'ten Urquhart, "Bir mikro mimari tasarım, ISA veya profil uyumluluğuyla hiçbir ilgisi olmayan çeşitli hatalara sahip olabilir" dedi. "Örneğin, kesintiler veya önbelleklerle arayüz oluşturan yarış koşulları veya sorunları olabilir. Bir işlemci tasarımının çok geniş bir durum alanına sahip olduğu göz önüne alındığında, RTL'nin doğrulanması, kablolu hızlandırıcı bloklardan çok daha karmaşıktır. Hataları bulmak için genellikle doğrudan testler, kısıtlanmış rastgele yöntemler ve resmi doğrulama gibi çeşitli yöntemler birleştirilir.”

Synopsys'ten Aitken, uyumluluk testinin zor olduğunu kabul etti. "Bu ister açık ister kapalı bir ISA olsun, bu doğrudur. Özelleştirilebilir veya genişletilebilir bir nesne için uyumluluk gerçekten daha zor hale geliyor. Bununla ne demek istiyorsun? Arm veya x86'da yasadışı bir işlem kodunuz varsa, sadece 'illegal talimat' der, hikayenin sonu. Ancak bir RISC-V tasarımında, işlem kodunun ne olduğuna bağlı olarak, uygulanan aslında yasa dışı işlem kodu olabilir. Birilerinin eklediği bir şey olabilir. Bunu kimseye anlatmak zorundalar mı? Bu alanda bulunabilecek pek çok gri alan var ve potansiyel olarak böylesine bir karmaşa olduğu için insanlar, tüm soruyu bir kenara bırakan iyi tanımlanmış alt kümeleri seçerek bundan kaçınıyor.”

Sabit bir ISA için uygunluk ve doğrulama arasındaki fark, genişletilebilir bir ISA için olduğundan biraz daha açıktır. "Bu şey yapması gereken talimatları uyguluyor mu? Bu cevaplaması kolay bir soru,” dedi Aitken. “Yaptığını iddia ettiği diğer şeyleri yapıyor mu? Bunu uyumlu bir şekilde yapıyor mu? Bunun kaldığı yer ile bir tür uygulama hatasının başladığı yer arasında gri bir alan vardır ve bunun nedeni kısmen ISA ile mimari veya mikro mimari ve bu mikro mimarinin belirli bir uygulaması arasındaki farktır. Tek bir tane varsa, sorun nerede? Bir şeyin kullanıcısı olarak, hiçbir fikriniz olmayabilir. Bir şeyin geliştiricisi olarak bile, probleminizin bu sürekliliğin neresinde olduğundan gerçekten emin olamayabilirsiniz. "Burada" ise ve spesifikasyonu yanlış yorumladıysak, bu bir uyumluluk sorunudur. Spesifikasyonu doğru yorumladıysak, ancak yanlış uyguladıysak, yanlış uyguladığınız için tam olarak ne yaptığınıza bağlı olarak bu bir mimari hata, bir mikro mimari hata veya bir uygulama hatası olabilir.

Geliştirici nasıl kesin olarak biliyor? "Yapmıyorsun," dedi. "Eninde sonunda neyin yanlış olduğunu anlamanız ve düzeltmeniz gerekeceğini biliyorsunuz. Ancak neyin kırıldığının ve onu ne olarak tanımladığımızın kesin tanımı mutlaka net değildir. Dolayısıyla, 'Daha önce işe yaramadı ve şimdi işe yarıyor' pragmatik görüşüne inecek. Kutuyu kontrol et.' Neden daha önce işe yaramadı? Eh, bu karmaşık.

Bir uyarı notu
Davidmann, günün sonunda, RISC-V'deki uyumluluk testlerinin doğrulama olmadığını, yani bittiğinde gerçek yetenekler açısından spesifikasyonun %10 veya %20'sini kapsayabileceklerini söyledi. “RISC-V'nin başını gerçekten belaya sokan nokta, bir müşterinin uygulamada yapabileceği o kadar çok seçeneğin olması ki, tüm bu farklı tasarımlar için çalışan testler yazmak gerçekten çok zor. RISC-V ile verdikleri özgürlük, yazılım tarafından tanımlanan çipler oluşturmaya çalışan bir endüstri için harika, ancak bu özgürlük, uyumluluk açısından tam bir kabus olduğu anlamına geliyor. RISC-V endüstrisi, bu uyumluluk sorununun karmaşıklığını tam olarak anlamadı ve kesinlikle kaynakları buna yatırmıyor."

Arm'dan Grisenthwaite ekledi, "Uygunluk gerçekten doğrulamanın bir parçasıdır, ancak uyumlu olmak için neyin oluşturulması gerektiğine dair kesin ve kapsamlı spesifikasyonlara sahip olmak önemlidir. Bireysel talimatlar söz konusu olduğunda, bu basittir; diğer öğeler için daha karmaşıktır ve ince uyumsuzluklar, yazılım söz konusu davranışa dayanıyorsa bariz hatalar kadar büyük bir sorun olabilir. Uyumluluğun, performans anormallikleri de dahil olmak üzere belirli bir uygulamaya özgü sorunlara çok daha yakından bakmayı içeren doğrulamanın bir alt kümesi olduğunu unutmamak önemlidir. Doğrulama, açıkça tasarım sürecinin merkezinde yer alır - genellikle en çok zaman alan bileşendir - ve bir doğrulama metodolojisi, geniş bir kullanıcı ekosistemindeki milyonlarca tasarıma dağıtıldığı için güvenilir ve esnek hale gelir."

Genişletilebilir bir mimari, bunu daha da zorlaştırır.

Davidmann, "Genişletilebilir bir ISA istiyorsanız, bu çok daha zorlu hale geliyor," diye bitirdi sözlerini. “Buna yatırım yapacak fonu olan bir şirket var. Topluluk yatırımı hobilerle çalışmaz. Arm, Linux ile bir sorun yaşadığında, yıllık 30 milyon veya 40 milyon dolarlık bir yatırım olan Linaro'yu bir araya getirdiler. Burası hobi kulübü olamaz. Tam zamanlı kararlı mühendisler olmalıdır. RISC-V için, muhtemelen 20 kişilik tam zamanlı bir bina uyumluluğu teknolojisi ekibine sahip olmalısınız. Referansları, doğrulama yeteneği ve testleri. Asya'da birkaç hobi mi? Üzgünüm, bu oraya varmayacak. Tüm bunların etkisi, bir işlemciyi lisanslıyorsanız iki şeyi bilmeniz gerektiğidir. Her şeyin işe yaraması için standardı karşılıyor mu? İçinde başka hatalar var mı? Bunlar, her IP tedarikçisinin müşterileri tarafından sorulacak sorulardır ve RISC-V International bugün olması gereken düzeyde uyumluluk konularıyla ilgilenmemektedir. Kağıt üzerinde olduğunu söylüyorlar. Davranışları bu konuda endişelendiklerini göstermez.”

• SEO Destekli İçerik ve Halkla İlişkiler Dağıtımı. Bugün Gücünüzü Artırın.
• EVM Finans. Merkezi Olmayan Finans için Birleşik Arayüz. Buradan Erişin.
• Kuantum Medya Grubu. IR/PR Güçlendirilmiş. Buradan Erişin.
• PlatoAiStream. Web3 Veri Zekası. Bilgi Genişletildi. Buradan Erişin.
• Kaynak: https://semiengineering.com/the-uncertainties-of-risc-v-compliance/