VHDL: sentez için tamsayılar?

Sentez sinyalleri ve portları vb.Için VHDL'de tamsayı kullanmam gerekirse biraz kafam karıştı.

Üst düzey bağlantı noktalarında std_logic kullanıyorum, ancak dahili olarak her yerde aralıklı tamsayılar kullanıyordum. Ancak, sadece sentez hedefli kod için imzalı / imzasız kullanmanız gerektiğini söyleyen insanlara yapılan birkaç referansla karşılaştım.

Şu anki projemi imzasız kullanmak için gittim ve yeniden çalıştım ... ve, daha da belirgin bir şekilde daha çirkin.

Tamsayıları kullanmak kötü bir uygulama mı? Sorun ne? Aracın tamsayıları hangi genişlikle eşleyeceğine dair bir belirsizlik var mı?

vhdl synthesis

— Darron
kaynak

İyi soru. Kendimi merak ediyordum. Her yerde tamsayı, pozitif ve diğer türleri kullanmaya başladım, ancak düzgün bir şekilde sentezlenmenin çok kıllı olduğu ortaya çıktı. Birisi neden herkesin son derece iyi yazılmış bir dilde std_logic kullanarak açıklayabilir umuyoruz.

— Trygve Laugstøl

Evet. Bu deli değil mi? Mevcut uygulamada yüksek oranda yazılmış çok fazla DATA_I <= TO_UNSIGNED (32010, DATA_I'LENGTH); bir şeyler yaz ... bu kimseyi rahatsız etmiyor mu? :) Çok fazla gereksiz bagaj gibi görünüyor. (Özellikle STD_LOGIC_VECTOR () eklerken ) Türümü ve boyutumu beyan ettim, bu DATA_I <= 32010 olmalı; Bu örtük olmalıdır. İmzalı / imzasız vb. Arasında geçiş yapmak açık olabilir ve olmalıdır ... ancak tamsayılar üzerinde açık ve net bir atama veya işlem örtük olmalıdır.

— darron

Yanıtlar:

Tamsayı sentezde iyidir, onları her zaman kullanırım.

Üst düzey bağlantı noktalarında std_logic kullanıyorum, ancak dahili olarak her yerde aralıklı tamsayılar kullanıyordum

Bu iyi!

Farkında olmak:

İlk önce siz simüle etmiyorsunuz :) - Tamsayı türleri simülasyonda otomatik olarak "devrilmiyor" - onlar için belirttiğiniz aralıktan çıkmak bir hatadır. Devrilme davranışı istiyorsanız, bunu açıkça kodlamanız gerekir.
$-(2^{31}-1)$ $+2^{31}-1$ $-2^{31}$ unsignedsigned
Bunları kısıtlamazsanız, bazen daha azın yapabileceği 32 bitlik sayaçlarla sonuçlanabilir (synth ve sonraki araçlar bitleri optimize edebileceklerini "göremezse").

Yukarı tarafta:

Simüle etmek imzasız / imzalı vektörlerden çok daha hızlıdır
Simülasyonda otomatik olarak devrilmezler (evet, her iki listede de var :). Bu kullanışlıdır - örneğin, sayacınızın çok küçük olduğuna dair erken uyarı alırsınız.

Eğer kullanım vektör türlerini yaptığınızda, kullandığınız ieee.numeric_std, değilieee.std_logic_arith değil mi?

Ben integers nerede yapabilirim kullanın , ama açıkça "devir n-bit sayaçları" istiyorsanız, ben kullanmak eğilimindedir unsigned.

— Martin Thompson
kaynak

Evet, numeric_std kullanıyorum. Sanırım çoğunlukla Xilinx araçları hakkında endişeliyim ... hala her şey için std_logic_vector üretiyorlar ve "UNSIGNED" sözdizimi vurgulamasında bile değil.

— darron

@darron Sözdizimi vurgulama konusunda endişelenme. Editör ve sözdizimi vurgulayıcı, sentez aracından tamamen farklı bir yazılım parçasıdır. Ayrıca, imzasız "sadece" bir veri türüdür. Dilin değil, standart bir kütüphanenin parçasıdır.

— Philippe

Bunun yerine alt sınır -2 ^ 32 + 1 değil mi? -2 ^ 31 - 1 olsaydı, sadece tek bir sayıyı temsil etmek için sadece bir bit daha gerekirdi - çok garip.

— Bregalad

@Bregalad - iyi yakalama - bu bir süredir yanlış!

— Martin Thompson

@MartinThompson Ya da eksi işaretini tutmayı tercih ederseniz - (2 ^ 32-1) olarak yazabilirsiniz.

— Bregalad

Jan Decaluwe, tamsayılara karşı bit vektörleri ile ilgili tüm bir beyaz yazı yazdı. Onun cevaplarının mümkün olduğunca tamsayılar olmasını bekliyorum . http://www.jandecaluwe.com/hdldesign/counting.html

— Philippe
kaynak

RTL için tamsayılar kullanımı hakkında hiçbir şey yanlış yok haddi zatında , ama nedeni vardır bazı önlemek öyle. Bu gerçekten öznel "en iyi uygulama" ile ilgili bir sorudur ve sonunda kendinize neyi tercih ettiğinizi bulmanız gerekecektir. Buna bir yardım olarak, bu konudaki deneyimlerimi ve düşüncelerimi paylaşacağım.

Prensip olarak , sentez için yazarken de (kısıtlanmış) tamsayıları kullanmaktan yanayım. Bazen yaparım, ama pratikte genellikle signedve unsigned. Nedenini açıklayacağım.

Yine de tasarımınızın bir kısmında vektörleştirilmiş bir veri türü kullanmak zorunda kalacaksınız:

Herhangi bir tedarikçi IP'si veya 3. taraf IP'si integerbağlantı noktaları için türü kullanmaz
Örneğin, BlockRam aracılığıyla veri gönderirken, çıkarımda bulunmanıza ve bu nedenle asla herhangi bir IP / makro / ilkel arayüze arayüze ihtiyaç duymasanız bile, büyük olasılıkla yine de vectorized türe dönüştürmeniz gerekecektir.
Yukarıdakilerin hiçbiri geçerli olsa bile, çoğunlukla az başka bir şey arayüzüne gerekecek bazı noktası (bir üst düzey limanında başka bir şey ise)

integerTam tasarım için kullanamayacağınızdan , hepsini birlikte atlamak isteyebilirsiniz, çünkü:

Bazı noktalarda, dönüşümleri yine de yapmanız gerekir ve bu integer, ilk etapta kullanım noktasının bir kısmını alır
Ayrıca, simülasyon için, bu dönüşümler tipik vektörler ile çağrılır 'U'veya 'X'reset önce ya da diğer zamanlarda ya ve her tür fonksiyon çağrısı / istemi sizin simülasyon uyarıları yığılan paket işlevinden bir uyarı mesajlarını üretecektir

Kullanmanın sakıncalarıinteger :

Vektörize tiplerin aksine, tamsayılar yoktur 'U've 'X'; Bunları simülasyonlarda çok yararlı buluyorum. Başlatılmamış sinyallerin tasarımda nasıl yayıldığını görürsünüz ve sıfırlamadan sonra çok sayıda başlatılmamış sinyal görürseniz muhtemelen tepki verirsiniz. Tamsayılar kullanıldığında durum böyle olmaz.
Tamsayılarla, toplama / çıkarma sırasında düşük / taşma ile sonuçlanan daha büyük bir simülasyon / sentez yanlış eşleşme riski vardır. (Zaten başka biri tarafından işaret edildiği gibi.)

integerGerçekten iyi bir seçenek bulduğum tipik durumlar :

ChipScope / signalTap vb. Aracılığıyla izlediğiniz hata ayıklama sinyalleri / sayaçları için.
Asla kendi kodunuza girmeyen veya girmeyen sayaçların tamamen dahili temsili. Evet, orada bir FIFO yazıyorsanız örneğin vakalardır ve ölü-hesaplaşma yazıyor vardır / sinyalleri oluşturmak üzere okur full, empty, almostFullvb (işaretçileri ancak aritmetiği bu durumda ölü hesaplaşma daha iyi bir yoldur. ..)

Kendi çıkarımlarım: Bazen tamsayılar kullanıyorum ama idareli olarak ve çoğunlukla yukarıda anlatılan durumlarda. Tamsayı kullanmakta unsignedve signedtamsayı yerine fazla bir yük görmüyorum ve bu nedenle genellikle onlara bağlı kalıyorum .

— Carl
kaynak