достоинства и недостатки variable?, Давайте совместно разберемся! Опции

[Мур]

Приветствую всех!
Практика использования VHDL дает возможность применять кроме SIGNAL еще и variable. Не знаю, как вам, а мне хватало всегда SIGNAL. Но вот когда стал смотреть чужой код, что столкнулся с проблемой невозможности наблюдения в ModelSim этих самых variable..
Тупая замена на SIGNAL - верный прием наблюдать желаемое

НО! Остается вопрос, где эти самые variable просто незаменимы?

Что скажут корифеии HDL-дизайна?.. Должна быть (не только у меня) ясность в этом вопросе.
Спасибо!

[andrew_b]

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

Разумеется. Переменные не имеют истории.

Тупая замена на SIGNAL - верный прием наблюдать желаемое

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

НО! Остается вопрос, где эти самые variable просто незаменимы?

Я не назову таких случаев, чтобы вот просто незаменимы.
Их можно использовать для хранения больших массивов данных, история изменений которых не важна, чтобы уменьшить количество используемой памяти ЭВМ при симуляции. Например, через переменные можно описать модели памяти.

Код

process
variable x : std_logic;
begin
    if (ce2 = '1') then
        x := i;
    else
        o (0) <= i;
        o (1) <= x;
    end if;
end process;

Это преобразование последовательного 1-битного потока данных в 2-битный параллельный. x можно сделать сигналом. Но поскольку он используется только в одном процессе, используется переменная, чтобы не засорять пространство имён архитектуры вспомогательными сигналами.

[Мур]

Разумеется. Переменные не имеют истории.

Понятно. Это мера углубляться в архитектуру для экзотических случаев чего-то там не использовать или наоборот, как в for.

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

Чувствуется верилоговец. Это не так. Триггер будет только в случае запоминания при тактировании. Кстати, с точки зрения ресурса макроячейка будет использована(без триггера) на логику

Я не назову таких случаев, чтобы вот просто незаменимы.
Их можно использовать для хранения больших массивов данных, история изменений которых не важна, чтобы уменьшить количество используемой памяти ЭВМ при симуляции. Например, через переменные можно описать модели памяти.

Пожалуй - это аргумент для бенча. Чтобы не нагружать машину дурной работой.

Это преобразование последовательного 1-битного потока данных в 2-битный параллельный. x можно сделать сигналом. Но поскольку он используется только в одном процессе, используется переменная, чтобы не засорять пространство имён архитектуры вспомогательными сигналами.

Локализация понятна. Четко отмечено!

[andrew_b]

Чувствуется верилоговец.

Бог миловал.

Это не так. Триггер будет только в случае запоминания при тактировании.

Код

process (clk)
variable s : unsigned ();
begin
    if (rising_edge (clk)) then
        s := a + b;
        o <= s;
    end if;
end process;

Замена s на сигнал приведет к созданию триггера и задержке на один такт, о чём я и говорил.

Локализация понятна. Четко отмечено!

Я там в процессе клок забыл, но идея понятна.

[Мур]

Замена s на сигнал приведет к созданию триггера и задержке на один такт, о чём я и говорил.

Так это же под клоком. Естественно будет триггер!..
Скорее удобно применять в generate, чтобы изящнее отразить особенность архитектуры подключений...

[Amurak]

При написании функций (function) переменные незаменимы.

[Мур]

При написании функций (function) переменные незаменимы.

Нет возражений. Конечно!))

[andrew_b]

Так это же под клоком. Естественно будет триггер!..

Тупая замена на SIGNAL - верный прием наблюдать желаемое

Вы путаетесь в показаниях.

Скорее удобно применять в generate

Это вряд ли.

При написании функций (function) переменные незаменимы.

С учётом того, что внутри функции нельзя использовать сигналы (только как аргументы), это само собой разумещееся.

[Мур]

Вы путаетесь в показаниях.

Скорее это связано с текстом, что писал новичок.

Это вряд ли.

Акцентирую внимание на описание в секции коммутаций сущностей. Там история не нужна конечно.

С учётом того, что внутри функции нельзя использовать сигналы (только как аргументы), это само собой разумещееся.

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

[Maverick]

Приветствую всех!
Практика использования VHDL дает возможность применять кроме SIGNAL еще и variable. Не знаю, как вам, а мне хватало всегда SIGNAL. Но вот когда стал смотреть чужой код, что столкнулся с проблемой невозможности наблюдения в ModelSim этих самых variable..
Тупая замена на SIGNAL - верный прием наблюдать желаемое

сделать например

Код

signal ODD : std_logic := '0';

process (A)
   variable TMP : std_logic := '0';
begin
   TMP := '0';
   for I in A'low to A'high loop
      TMP := TMP xor A(I);
   end loop;
   ODD <= TMP;
end process;

для моделсима выводите сигнал ODD

Латчей синтезатор не выдает?

[Мур]

сделать например

Код

signal ODD : std_logic := '0';

process (A)
   variable TMP : std_logic := '0';
begin
   TMP := '0';
   for I in A'low to A'high loop
      TMP := TMP xor A(I);
   end loop;
   ODD <= TMP;
end process;

для моделсима выводите сигнал ODD

По любому предстоит дополнительная компиляция... Я так тоже делаю. Под настроение... Спасибо!

Латчей синтезатор не выдает?

Хорошее замечание. Тут ушки на макушке!... Может быть. Надо смотреть пространство перебора и синхронность. Ничего не пропустил?.. Если пропущено, то синтезатор вставит латч. Особенно при асинхроне!
Идея понятна.

[KalashKS]

Не знаю, как в моделсиме, а в NCsim и Aldec переменные вполне наблюдаются. Просто они объявлены внутри процесса и искать их надо внутри процесса, а не архитектуры.
Незаменимыми я их не назову, но в ряде случаев, как в примере выше, они сильно экономят время написания и уменьшают объем/увеличивают читаемость кода.

[FPG]

Вот применение! Пользуюсь регулярно! где-то спер идею )))


process(ADDR_in)
variable tmp0 : std_logic := '0';
begin
tmp0 := '1';

for i in 23 downto 0 loop
tmp0 := tmp0 and not (ADDR_in(i) xor conv_std_logic(ADDR,24)(i));
end loop;

decoder_yes <= tmp0;
end process;

[andrew_b]

Вот применение! Пользуюсь регулярно! где-то спер идею )))

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

[FPG]

функция дешифрации основана как раз на свойстве variable по неблокирующему присваиванию