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

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

9 голосов
/ 28 марта 2012

Конфигурации 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;

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

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

Ответы [ 3 ]

4 голосов
/ 29 марта 2012

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

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

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

3 голосов
/ 29 марта 2012

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

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

1 голос
/ 23 апреля 2013

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

Предположим, у меня очень большая сущность + архитектура FooMachine, и я хочу написать серию модульных тестов whitebox, относящихся к сигналам внутри 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.

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

...