Цель обеспечения более чем одной архитектуры? - PullRequest
Новая
       22

Цель обеспечения более чем одной архитектуры?

7 голосов
/ 02 апреля 2011

Я нахожусь в процессе изучения VHDL и пытаюсь просто учиться на примерах, руководствах по синтаксису и экспериментах.

Одна вещь, которую я не совсем понимаю, - это почему вы когда-нибудь захотите предоставить более одной архитектуры.Например, это пример MUX-кода : 

architecture behv1 of Mux is
begin
    process(I3,I2,I1,I0,S)
    begin

        -- use case statement
        case S is
        when "00" =>    O <= I0;
        when "01" =>    O <= I1;
        when "10" =>    O <= I2;
        when "11" =>    O <= I3;
        when others =>  O <= "ZZZ";
    end case;

    end process;
end behv1;

architecture behv2 of Mux is
begin

    -- use when.. else statement
    O <=    I0 when S="00" else
        I1 when S="01" else
        I2 when S="10" else
        I3 when S="11" else
        "ZZZ";

end behv2;

Есть ли для этого цель или просто ради?принадлежит здесь или Electronics.SE, так что я решил сначала попробовать здесь.

Ответы [ 3 ]

7 голосов
/ 02 апреля 2011

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

Одна вещь, которую обычно делают, - это предоставление моделей черного ящикаПроектирование IP по причинам производительности, когда вы пытаетесь смоделировать другую (не связанную) часть всей конструкции SoC.

Или, возможно, у вас есть модель IP более высокого уровня, которая позволяет сократить время моделирования, а такжемодель, предназначенная для синтеза.Модели более высокого уровня часто используются для процессорных ядер, поскольку имитация всего ядра обычно не требуется при проверке остальной части проекта.

Другая возможная причина заключается в том, чтобы выборочно вести себя по-разному в схеме IP, так что слегка отличатьсяверсии могут быть созданы, когда IP интегрирован в проект SoC.Например, одна архитектура может быть предназначена для работы в одночасовом домене, а другая может иметь синхронизацию между двумя разными тактовыми доменами.

2 голосов
/ 04 апреля 2011

Архитектура может использоваться дизайнерами по-разному.

Для меня:

  • Сущность связана с определенной требуемой функциональностью.
  • Архитектура описывает детали реализации для этой конкретной функциональности. Так что если вам нужно описать одну и ту же функцию по-разному (по какой-либо причине, о которой уже упоминали многие другие), то вы можете иметь несколько архитектур.

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

2 голосов
/ 03 апреля 2011

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

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

...