std_logic чи std_ulogic?

24

Здається, світ вирішив, що std_logic(і std_logic_vector) є типовим способом представлення бітів у VHDL. Альтернатива була б std_ulogic, яка не вирішена.

Це мене дивує, тому що зазвичай ви не описуєте шину , тому вам не потрібно кілька драйверів і вам не потрібно розв’язувати сигнал. Перевага std_ulogicполягала б у тому, що компілятор попереджає вас рано, якщо у вас є кілька драйверів.

Питання: це просто культурно-історична річ, чи є ще технічні причини використовувати std_logic?

vhdl 
— Філіп
джерело
3
"Світ" помиляється. Розумні інженери використовують std_ulogic так, оскільки він має правильну семантику.
— wjl
@wjl Я тлумачу це як "культурно-історичну річ". Ваша відповідь нижче набагато корисніша, ніж коментар тут.
— Філіпп
Я написав коментар спочатку, потім подумав, що було б доречніше залишити відповідь з більшою специфікою. Вибачте, я думаю, це звучить трохи легковажно. Але мій коментар буквальний тим, що більшість людей починають використовувати std_logic, тому що вони це дізналися, потім через деякий час вони починають замислюватися про std_ulogic, вони дивляться на нього, розуміють, що це семантика, а потім перетворюють на неї. =)
— wjl

Відповіді:

16

Std_logic є підтипом std_ulogic і має рівно одне додаткове властивість: воно вирішено, якщо є кілька драйверів.

Незалежно від загальноприйнятої практики, std_ulogic - це правильний тип, який слід використовувати для нерозв’язаних сигналів, для яких потрібна 9-значення логіки. (Часто використання "біта" ще правильніше - наприклад, для деяких архітектур FPGA, у яких немає такого поняття, як "X" або "U").

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

— wjl
джерело
8
В архітектурі може не бути "U", але часто корисно моделювати так, ніби це було так, як ви можете знайти неправильні ініціалізації. +1 за "найкраще зробити це - використовувати правильний тип роботи", але ми схильні вчитися, коли йдемо про те, що "найкраще" :)
— Мартін Томпсон,
8

Моя історія така:

Я почав (приблизно в 1999 р. IIRC), використовуючи std_ulogic*весь час - як це правильно робити, саме з описаних вами причин.

Тоді мені довелося інтерфейсувати до купки майстрів, створених IP-адресами постачальника, який був std_logicу всьому інтерфейсі. Що означало перетворення на картах портів (для _vectorелементів), і я лінивий і перейшов до використання std_logic*.

Однак я, здається, допускаю дуже мало помилок "подвійного водія", тому я не пропустив std_ulogicстільки, скільки б міг подумати. І driversкоманда Модельсіма дозволяє дуже легко знайти "хто керує", коли мені час від часу потрібно ...

— Мартін Томпсон
джерело
Так, IP-ядра (і особливо речі, які автоматично перекладаються з Verilog), як правило, використовують std_logic. Здається, ваша відповідь говорить про те, що причина в основному "культурно-історична".
— Філіпп
Вам ніколи не доведеться конвертувати між std_logic і std_ulogic на порти. Ви мали на увазі, що вам доведеться конвертувати між std_logic_vector та std_ulogic_vector?
— wjl
@wjl: Вибач, так, це я мав на увазі. Я оновлю публікацію.
— Мартін Томпсон
AFAIK, std_logic та std_ulogic сумісні із завданнями, оскільки вони мають однаковий базовий тип. Отже, не повинно бути необхідності в ручному перетворенні.
— Валь
@ Val: саме так сказав wjl (і я згоден), - але *vectorчастини порту все ще потребують перетворень
— Мартін Томпсон
4

IIRC рекомендував відомий Посібник з повторного використання std_logic(_vector), тому, можливо, групи методологій у компаніях тощо розповсюджуються далі у формі (обов'язкових) посібників з кодування. Особисто +1 для використання, std_ulogicколи це можливо.

— cmarqu
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.