Используются ли в реальной жизни расширенные конфигурации VHDL?

Конфигурации VHDL можно использовать для привязки компонентов к объектам с другим именем и даже с совершенно другими портами.[дополнительную информацию см. в этой статье]

  configuration c2 of testbench is
    for str
        for dut_inst : dut
            use entity work.unrelated(rtl)
                port map(
                    port1 => a,
                    port2 => b,
                    port3 => c,
                    port4 => "unused"
                );
        end for;
    end for;
  end configuration c2;

Кто-нибудь из вас когда-нибудь видел, как это происходит в коммерческом проекте проекта? Какова была цель добавления, казалось бы, не связанной сущности? Почему они просто не изменили код создания экземпляра?

Я могу придумывать гипотетические ситуации, но меня интересует реальный вариант использования.


vhdl
person Philippe    schedule 28.03.2012    source источник
comment
Спасибо, что задали этот вопрос - мне тоже очень интересно. По моему опыту, я никогда не видел, чтобы это использовалось лично, и я работал с большими базами кода, ориентированными на несколько плат / систем FPGA.   -  person Josh    schedule 28.03.2012
comment
Мне то же. VHDL, кажется, имеет несколько языковых элементов, из-за которых он кажется очень старым и предназначенным для другой и меньшей базы пользователей, чем сегодняшние инженеры FPGA. Списки чувствительности, конфигурации, обязательные метки, отсутствие эквивалента препроцессора C, настаивание на том, чтобы последний элемент в списке не имел завершающей запятой, или различие между std_logic и bool, когда разработчик предполагает, что «1» = true и имя сигнал соответственно. Основные концепции хороши, но кому-то нужно переделать язык с нуля.   -  person maxy    schedule 28.03.2012
comment
@maxy: С некоторыми из них я соглашусь, а с некоторыми нет. Списки чувствительности - это пережиток того времени, когда компиляторы/симуляторы не были такими способными, поэтому я дам вам это. Запятые в конце, да ладно, но я не теряю сон из-за этого. Конфигурации мощные и полезные (хотя приведенный выше пример кажется излишним). Мне не нужен препроцессор. Вы видели ужасные вещи, которые люди делают с ним? Дженерики дают вам 90% результата, но требуют соблюдения структуры. std_logic vs bool - это артефакт жестко типизированного языка, а жесткая типизация - это хорошо для RTL IMHO. Ярлыки... почему бы вам не пометить что-нибудь? :-)   -  person Paul S    schedule 29.03.2012
comment
Verilog имеет аналогичные конструкции, также называемые конфигурациями. Я тоже никогда не видел, чтобы они использовались.   -  person    schedule 30.03.2012

Ответы (3)


arrow_upward
5
arrow_downward

Никогда не видел, чтобы привязки портов менялись, но я видел, как они использовались для привязки в разных версиях компонентов с одной и той же картой портов. Некоторые примеры, которые я видел:

  • Связывание в пустых версиях при построении крупных симуляций системного уровня. Часть проекта заменена версиями, которые ничего не делают для уменьшения объема памяти при тестировании других частей проекта.
  • Аналогично, но при тестировании шинной инфраструктуры проекта свяжите простые блоки, которые реагируют «дико-дурацкими» способами.
  • Различные версии конкретного блока, которые имеют разные конструктивные компромиссы. например Одна большая и быстрая версия, другая маленькая, но медленная. Затем их можно заменить в зависимости от того, что необходимо, когда система собирается вместе или для конкретного приложения.

Ни одному из них не нужны функции, о которых вы говорите. Единственное, что я могу придумать, для чего может быть полезно использование другого компонента, - это если у вас есть что-то вроде нескольких поставщиков библиотек RAM, и вам нужно регулярно переключаться между ними. Даже в этом случае маловероятно, что вы сможете выполнить сопоставление портов один к одному. Всегда есть контакт отключения питания, который нужно инвертировать или что-то в этом роде.

person Paul S    schedule 29.03.2012
comment
Я бы добавил (1) замену поведенческих моделей на модели RTL по мере продвижения большого проекта и (2) использование конфигурации для выбора разных версий симуляции. Это обычное дело в больших проектах. Я бы также добавил, что вам нужно всего лишь поговорить с Verilogger, чтобы узнать, насколько болезненно разрешать только одно имя, когда это имя существует как разные компоненты в разных библиотеках. Конфигурации, IMO, фундаментальны для VHDL. - person EML; 23.04.2013

arrow_upward
3
arrow_downward

Нет, я никогда не видел этого в дикой природе.

Я предполагаю, что причина в том, что большинство людей (включая меня) даже не знают, что такие вещи возможны с конфигурациями.

person geschema    schedule 29.03.2012

arrow_upward
2
arrow_downward

Я использовал такую ​​конфигурацию несколько раз. Я стараюсь этого избегать, но иногда это полезно для тестирования белого ящика.

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

component Dummy is
end component Dummy;

и экземпляр

dummy_g : Dummy;

Затем в модульном тесте сигнала x в FooMachine я напишу сущность+архитектуру

entity TestDummy is
    port (
        x : in std_logic
    );
end entity;

architecture Arch of TestDummy is
    ...
end Arch;

и конфигурация

configuration conf of ... is
...
    for all : FooMachine
        ...
        for all : Dummy
            use entity work.TestDummy(Arch)
                port map (x => x);
        end for;
    end for;
...
end configuration;

И тогда я могу писать свои утверждения в TestDummy.

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

person Owen    schedule 23.04.2013
comment
отличный ответ, не многие люди понимают значение и полезность этого - person CJC; 02.02.2016