VHDL: цілі числа для синтезу?

Я трохи розгублений, якщо мені слід використовувати цілі числа у VHDL для сигналів синтезу та портів тощо.

Я використовую std_logic на портах верхнього рівня, але всередині був з допомогою варіювалися цілі всюди. Однак я натрапив на кілька посилань на людей, які казали, що слід використовувати лише підписані / непідписані для синтезованого коду синтезу.

Я пішов і переробив свій поточний проект, щоб використовувати неподписаний ... і, ну, це помітно гірше.

Чи погана практика використання цілих чисел? В чому проблема? Чи є певна невизначеність, на яку ширину інструмент буде відображати цілі числа?

vhdl synthesis

— даррон
джерело

Гарне питання. Мені це було цікаво. Я почав використовувати цілі, позитивні та інші типи в усьому світі, але виявилося дуже волохатим, щоб правильно синтезуватися. Я сподіваюся, що хтось може пояснити, чому всі закінчують використовувати std_logic мовою, що набирається дуже багато.

— Trygve Laugstøl

Так. Хіба це не шалено? Високо типізована в сучасній практиці тенденція призводить до великої кількості DATA_I <= TO_UNSIGNED (32010, DATA_I'LENGTH); введіть речі ... що нікого не турбують? :) Напевно, здається, багато непотрібного багажу. (Особливо, додаючи STD_LOGIC_VECTOR () до цього) Я оголосив свій тип та розмір, це має бути DATA_I <= 32010; Це має бути неявним. Перехід між підписаним / неподписаним тощо може бути і повинен бути явним ... але пряме однозначне призначення або операція над цілими числами має бути неявним.

— darron

Відповіді:

Цілі численні в синтезі, я їх постійно використовую.

Я використовую std_logic на портах верхнього рівня, але внутрішньо я використовував діапазони цілих чисел всюди

Це чудово!

Бережись:

Ви імітуєте спочатку, чи не так :) - Цілі типи автоматично не перекидаються під час імітації - це помилка виходу із вказаного для них діапазону. Якщо ви хочете поведінку при перекиданні, вам потрібно це чітко кодувати.
$-(2^{31}-1)$ $+2^{31}-1$ $-2^{31}$ unsignedsigned
Якщо ви їх не обмежуєте, іноді ви можете отримати 32-розрядні лічильники, де менше буде (якщо синтезатор та наступні інструменти не можуть "побачити", що вони можуть оптимізувати біти).

Зверху:

Вони набагато швидше імітувати, ніж вектори без підпису / підписання
Вони не автоматично перекидаються під час імітації (так, це в обох списках :). Це зручно - наприклад, ви отримуєте попереднє попередження про те, що ваш лічильник занадто малий.

Коли ви використовуєте векторні типи, ви використовуєте ieee.numeric_std, ніieee.std_logic_arith так?

Я використовую integers, де можу, але якщо я прямо хочу "перекидання n-бітових лічильників", я схильний використовувати unsigned.

— Мартін Томпсон
джерело

Так, я використовую numeric_std. Я думаю, що я здебільшого переживаю інструменти Xilinx ... вони все ще генерують std_logic_vector для всього, і "UNSIGNED" навіть не підкреслюється у синтаксисі.

— darron

@darron Не турбуйтеся про виділення синтаксису. Редактор та його синтаксичний підсвічування - це зовсім інша частина програмного забезпечення від засобу синтезу. Крім того, без підпису є "просто" тип даних. Це частина стандартної бібліотеки, а не самої мови.

— Філіпп

Чи не натомість нижня межа -2 ^ 32 + 1? Якщо це було -2 ^ 31 - 1, вам знадобиться ще один біт, щоб представити лише одне число - дуже дивно.

— Брегалад

@Bregalad - хороший улов - це не так вже давно!

— Мартін Томпсон

@MartinThompson Або, можливо, ви можете записати це як - (2 ^ 32-1), якщо ви хочете зберегти знак мінус.

— Брегалад

Ян Декалуве написав цілу білу книгу про проблеми цілих чисел проти бітових векторів. Я очікую, що його відповіді полягають у використанні цілих чисел, коли це можливо . http://www.jandecaluwe.com/hdldesign/counting.html

— Філіп
джерело

Немає нічого поганого в використанні цілих чисел для RTL як такої , але є причини, які деякі уникають цього. Це справді питання про суб'єктивну "найкращу практику", і ви, зрештою, повинні самі дізнатися, що вам більше подобається. Як допомогу в цьому я поділюсь своїм досвідом та думками з цього приводу.

В основному я виступаю за використання (обмежених) цілих чисел, також під час написання для синтезу. Я іноді це роблю, але на практиці зазвичай дотримуюсь signedі unsigned. Я детальніше поясню, чому.

Ви все одно будете змушені використовувати векторизовані типи даних у своїй частині дизайну:

Навряд чи будь-який постачальник-IP або сторонній IP буде використовувати integerтип для портів
Наприклад, при надсиланні даних через BlockRam, навіть якщо ви виводите їх і, отже, ніколи не потрібно інтерфейсувати будь-який IP / макро / примітивний, вам, швидше за все, потрібно буде конвертувати у векторний тип
Навіть якщо жодне з перерахованих вище не стосується, вам, в основному, потрібно буде в якийсь момент інтерфейс до чогось іншого (порт верхнього рівня, якщо нічого іншого)

Оскільки ви не можете використовувати integerдля повного дизайну, ви можете пропустити все це разом, оскільки:

У деяких моментах вам доведеться все-таки зробити перетворення, і це забирає integerв першу чергу частину точки використання
Крім того, для моделювання ці перетворення, як правило, викликаються векторами 'U'або 'X'перед скиданням, або в інший час, і кожен такий виклик функції генерує попереджувальні повідомлення від функції пакету, захаращуючи ваші попередження / підказку щодо імітації

Недоліки використанняinteger :

На відміну від векторизованих типів цілі числа не мають 'U'і 'X'; Я вважаю це дуже корисним у симуляціях. Ви бачите, як неініціалізовані сигнали поширюються через конструкцію, і ви, ймовірно, реагуєте, якщо після скидання побачите багато неініціалізованих сигналів. Це не буде, якщо використовувати цілі числа.
З цілими числами існує більший ризик невідповідності моделювання / синтезу при додаванні чи відніманні, що призводить до недоліку / переповнення. (Як уже вказував хтось інший.)

Типові випадки, коли я вважаю, що integerце справді хороший варіант:

Для сигналів / лічильників налагодження, які ви контролюєте за допомогою chipScope / signalTap тощо.
Повністю внутрішнє представлення лічильників, які ніколи не переходять у або виходять із власного коду. Так, є такі випадки, наприклад , якщо ви пишете FIFO і ви мертві, зважаючи запису / читання для формування сигналів full, empty, і almostFullт.д. (проте арифметика на покажчики кращий шлях , ніж мертвий, зважаючи в цьому випадку. ..)

Мої власні висновки: я цілком використовую цілі числа іноді, але помірковано, і переважно в описаних вище випадках. Я не бачу великих витрат у використанні unsignedта signedзамість цілих чисел, тому зазвичай дотримуюся їх.

— Карл
джерело