VHDL: Mimari adlandırma ve yorumlama

Not: Xilinx'in İMKB'sini kullanıyorum ve çalışmak için bir FPGA kartım var (anahtarlar ve ışıklar vb.) Ve şimdiye kadar bazı basit projeleri birlikte hackledim. Aynı zamanda yaptığım şey için bir temel oluşturmak için birkaç öğretici okuyorum.

Yaşadığım referans materyallerinde belirtilen çeşitli varlıkları ve mimarilerini gördüm, ancak adlandırma genellikle kafa karıştırıcı. Genellikle "mimari rtl .." veya "mimari yapısal ..." yerine " ... mimari foo ", hatta " ... mimari kemer "

Bu sorunun önlenmesi için daha tutarlı adlandırma kurallarının kullanılabileceğini öne süren stil kılavuzları olmasına rağmen, mimari adın varlık adlandırma kadar keyfi olduğunu (gecikmeli olarak) anlıyorum. Bu beni birkaç soruya yönlendiriyor:

• Bir varlığa bakıldığında, mimari adından ipuçları olmadan kullanılan gerçek mimari model nasıl belirlenir? RTL, davranışsal, yapısal ... öğrencilerimin gözüne oldukça benziyorlar (gördüğüm örneklerin aslında doğru isimlendirildiğini varsayarak). Basit ama açık bir örnek burada yararlı olabilir (veya bir göstergeyi).

• Tek bir varlık için (mümkün olduğunu anladığım) birden fazla mimariyi belirtiyorsanız, mimarilere aynı dosyada farklı isimler mi veriyorsunuz yoksa ...?

• Mimari adları belirli bir varlıkla sınırlı mı (yani, birden çok varlık üzerinde aynı mimari adını kullanarak "ad alanları" ile ilgili bir sorun var mı)?

Düzenleme: ve bir tane daha:

• RTL ve davranış arasında bir ayrım var gibi görünüyor, ancak yukarıda belirtildiği gibi gördüğüm örneklerde gerçekten görmüyorum (genellikle sadece bir mimarinin tanımlandığını görüyorum). Bir mimari diğerlerinden daha yaygın mıdır?

Aradığım şey, en iyi uygulamalar (uygun adlandırma, hepsi tek bir dosyaya sıkıştırılmadı, vb.) Düzgün hazırlanmış örnek projeleri temel ilkeleri ve en iyi uygulamaları aydınlatmak için çok yararlı buluyorum. Böyle bir örnek proje biliyorsanız, ben de ona bir işaretçi için minnettar olurum. (Başka bir şey yoksa, belki bir kez bunu anladığımda kendimden birini paylaşabilirim ...)

Bir varlığa bakıldığında, mimari adından ipuçları olmadan kullanılan gerçek mimari model nasıl belirlenir?

Yapamazsınız - somutlaştırıldığında veya yapılandırıldığında mimari (seçilebilecek birden fazla varsa) belirtilebilir veya sizin için bir varsayılan seçilecektir.

Tek bir varlık için (mümkün olduğunu anladığım) birden fazla mimariyi belirtiyorsanız, mimarilere aynı dosyada farklı isimler mi veriyorsunuz yoksa ...?

Onlara farklı isimler veriyorsunuz. Aynı dosya içinde olması gerekmez (aslında VHDL hangi dosyada ne olduğunu düşünebileceğinizden çok daha az umurundadır)

Mimari adları belirli bir varlıkla sınırlı mı (yani, birden çok varlık üzerinde aynı mimari adını kullanarak "ad alanları" ile ilgili bir sorun var mı)?

Bunlar bir varlığa "bağlıdır", bu nedenle tekrar kullanılabilirler.

Sıklıkla kullanırım a1 sentezlenebilir her şey için benim mimarisi olarak kullanıyorum

• rtl yazdığımdan daha düşük seviye (birçok okuyucu için) anlamına gelir.
• behavioural çoğu zaman sentezlenemez (bazı okuyuculara)
• synth sentezleyici tarafından modeli için kullanılır (aksi takdirde bunu kullanırdım)

a1 şu ana kadar çelişkili olmamış ve karışıklığa neden olmamıştır;)

Aslında birden fazla mimarim varsa, bunları ayrıntılı olarak adlandırırım (örneğin hard_multipliersvelut_multipliers MUL18 bloklarını başlatan - ya da olmayan - bir filtre için).

Çoğu zaman sadece bir mimariniz var, bu yüzden önemli değil. İyi varlık isimleri çok daha önemlidir.

RTL ve davranış arasında bir ayrım var gibi görünüyor, ancak yukarıda belirtildiği gibi gördüğüm örneklerde gerçekten görmüyorum (genellikle sadece bir mimarinin tanımlandığını görüyorum). Bir mimari diğerlerinden daha yaygın mıdır?

Tarihsel - "davranışsal" kodu sentezleyemediniz (bir noktada ekleme gibi şeyler dahil ettiniz) - böylece toplayıcıları ve benzerlerini başlatan bir RTL sürümü oluşturdunuz. (Anladığım kadarıyla - VHDLing'e 1999'da başladığımdan beri davranışsal (ve yine de sentezlenebilir) kod yazıyorum!)

İşte mimari türleri:

Davranışsal:

Genel Notlar:

• Geleneksel olarak hiçbir heirarşi (yalnızca bir dosya, hiçbir bileşen somutlaştırılmamış), ancak bu araçlar arasında farklılık gösterir.
• Benzetmek çok hızlı.
• Sinyal davranışları tanımlanmıştır.
• Davranışsal simülasyon için sadece kullanıldığında sentezlenemeyen kod içerebilir. Sentez amaçlı davranış doğal olarak sentezlenebilir olmalıdır.

Xilinx'e özel notlar

• Genel olarak çekirdek jeneratör modelleri pre-synthesis .vhd dosyalarıdır

Yapısal:

Genel tanım

• Yalnızca bileşenleri başlatır ve birbirine bağlar (hiyerarşik).
• Simüle etmek davranışsal olmaktan daha yavaştır.
• Üst düzeyde gerçek sinyal davranışı tanımı yok.
• Sadece sentezlenebilir kod.

Xilinx xpecific notlar

• Çekirdek jeneratör modelleri zamanlamayı dikkate almaz.
• Genel olarak çekirdek jeneratör modelleri sentez sonrası ağ listelerini başlatır

Yukarıdakiler temelde mimarinin geleneksel iki ana hayvanıdır. Çok yaygın olarak, her ikisinin özelliklerini içeren bir "karışık" tanım kullanılır.

RTL:

Gün sonunda FPGA'ya gerçekte konan RTL. Bu, sistemin davranışını tanımlayan ve bir kod hiyerarşisinden oluşan
sentezlenebilir bir koddur: Alt katmanlar, sinyal davranışının nitrit taneciklerinin tanımlandığı ve üst düzeylerin yapısal olacağı, davranışsal bileşenler büyük bir üst düzey "blok şeması" oluşturmak için birlikte bağlanırsanız.

Birden fazla mimariye açık:

Mimarilerin hepsi tek bir dosyada veya birden fazla dosyada olabilir. Tek önemli şey, öncelikle varlığın derlenmesi ve kullanılacak mimarinin belirtilmesidir.

Bu kitap çok kullanışlı ve bu tür şeyleri oldukça iyi detaylandırıyor.

Farklı davranışsal ve yapısal modellere sahip olma veya sadece bunları karıştırma açısından işlerin nasıl yapılması gerektiği konusunda sert ve hızlı bir kural yoktur. Genellikle büyük ürün yazılımı tasarımlarında (veya kodun paylaşıldığı ve yeniden kullanıldığı büyük şirketlerde), konuları basitleştirmek için ikisi arasında ayrım yapmak yararlıdır, ancak günün sonunda sizin için neyin işe yaradığına bağlıdır.

Her şeyden önce, gerçek dünya mimari tasarımları kesinlikle bu şekilde kategorize edilemez. Neden kendini sınırlarsın? Diğer varlıkları başlatmak ve onları "yapısal olarak" bağlamak isteyebilirsiniz, ancak buraya "rtl" mantığı eklemek için buraya bir süreç veya eşzamanlı atama eklemek ve belki de bazı "davranışsal" kodlama kalıplarını kullanmak, böylece sentezleyicinin önemsemediğiniz ayrıntılar (alan / pipeline / performans parametreleri ile özel olarak bir adder somutlaştırmadan ekleme gibi), hepsi aynı mimaride.

Daha da önemlisi, şu anki asic / fpga teknolojilerinde neyin sentezlenebileceğini ve neyin olmadığını anlamanız gerekir ve bu mimari modelden bağımsızdır.

Bir varlık, biraz farklı davranışlara bile izin vererek birden çok şekilde uygulanabilir, böylece aynı varlık için birden çok mimariniz olabilir. Buna ek olarak, büyük simülasyonların bir bütün olarak test edilmesi sırasında kullanışlı olabilecek "gerçek" versiyondan daha hızlı simüle edebilen sadece simülasyon için (genellikle sentezlenemez) bir mimariye sahip olabilirsiniz. Bu mimarilere, onları diğerlerinden farklı kılan şeyleri hatırlamanıza yardımcı olacak isimler vereceksiniz ve gerçek dünya tasarımlarının melez doğası göz önüne alındığında, bhv / str / rtl genellikle yeterli veya doğru değildir.

Özel sorularınızla ilgili olarak, mimari bildirimi bir varlık adına bağlıdır, bu nedenle farklı varlıklar için aynı adlı mimarilerle ilgili ad alanı sorunları yoktur. Aynı varlık için mimariler için farklı isimler kullanın.

Mimariler farklı dosyalarda bulunabilir, sadece varlık bildiriminin derlendiğinden emin olmanız gerekir.

Varlığı somutlaştırırken veya yapılandırma ifadelerini kullanırken hangi mimariyi kullanacağınızı seçebilirsiniz. Bunu yapmazsanız varsayılan, derleyicinin belirli bir varlık bildirimi için gördüğü son mimari 'genellikle' dir.