std_logic или std_ulogic?

24

Кажется, что мир решил, что std_logic(и std_logic_vector) - это способ представления битов в VHDL по умолчанию. Альтернатива будет std_ulogic, которая не решена.

Это удивляет меня, потому что обычно вы не описываете шину , поэтому вам не нужны несколько драйверов и вам не нужно разрешать сигнал. Преимущество std_ulogicзаключается в том, что компилятор предупреждает вас заранее, если у вас несколько драйверов.

Вопрос: это просто культурно-историческая вещь, или все еще есть технические причины использовать std_logic?

vhdl 
— Philippe
источник
3
Мир ошибается. Умные инженеры используют std_ulogic, потому что он имеет правильную семантику.
— WJL
@wjl Я буду толковать это как "культурно-историческую вещь". Ваш ответ ниже гораздо полезнее, чем комментарий здесь.
— Филипп
Сначала я написал комментарий, а затем подумал, что было бы более уместно оставить ответ с более подробной информацией. Извините, я думаю, это звучит немного легкомысленно. Но мой комментарий буквален в том смысле, что большинство людей начинают использовать std_logic, потому что они изучают его таким образом, а затем через некоторое время начинают задумываться о std_ulogic, они ищут его, понимают его семантику и затем конвертируют в него. =)
— WJL

Ответы:

16

Std_logic является подтипом std_ulogic и имеет ровно одно дополнительное свойство: оно разрешается при наличии нескольких драйверов.

Независимо от обычной практики std_ulogic является правильным типом, который следует использовать для неразрешенных сигналов, которым требуется 9-значная логика. (Часто использование «бит» является еще более правильным - например, на некоторых архитектурах ПЛИС, которые не имеют такой вещи, как «X» или «U»).

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

— WJL
источник
8
Архитектура может не иметь буквы «U», но часто полезно имитировать, как если бы она была, поскольку вы можете найти неправильные инициализации. +1 за «лучшее, что нужно сделать, это использовать правильный тип для работы», но мы, как правило, узнаем о том, что «лучше» :)
— Мартин Томпсон
8

Моя история такова:

Я начал (примерно в 1999 году IIRC), используя std_ulogic*все время - как это правильно делать по тем причинам, которые вы описываете.

Затем я должен был взаимодействовать с кучей сгенерированных мастерами IP-адресов поставщиков, которые были std_logicвсе по всему интерфейсу. Что означало преобразования в отображениях портов (для _vectorэлементов), и я стал ленивым и перешел к использованию std_logic*.

Тем не менее, я, кажется, делаю очень мало «двойных» ошибок, поэтому я не пропустил std_ulogicстолько, сколько мог бы подумать. И команда Modelsim driversпозволяет очень легко найти «кто за рулем, что», когда мне иногда нужно ...

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

IIRC рекомендовал знаменитое Руководство по методологии повторного использования std_logic(_vector), поэтому, возможно, методологические группы в компаниях и т. Д. Распространяют это далее в виде (обязательных) руководств по кодированию. Лично +1 за использование по std_ulogicвозможности.

— cmarqu
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.