Перейти к содержанию
    

генерация '1' по импульсу

Добрый день, возник вопрос

если на вход приходят по линиям комбинации "001" "010" "011" "100", то они же идут на выход

если "000" то сигналы на выходе не изменяются

если иное, то на выходе "000"

ниже код, но возникают 2 ошибки в выделенных строчках

я так понимаю tmp <= tmp так нельзя потому что в начальный момент значения сигнала не задано?

и по первой ошибке, ведь не добавлять же tmp в список процесса?

 

library IEEE;
use IEEE.std_logic_1164.all;

entity povtor is
    port (
              BIT_in1:       IN STD_LOGIC;
              BIT_in2:       IN STD_LOGIC;
              BIT_in3:       IN STD_LOGIC;
        BIT1:        OUT STD_LOGIC;
        BIT2:        OUT STD_LOGIC;
        BIT3:        OUT STD_LOGIC
         );
end povtor;

architecture povtor_arch of povtor is
  SIGNAL tmp : STD_LOGIC_VECTOR(2 downto 0);
BEGIN
process(BIT_in1,BIT_in2,BIT_in3)
   begin
        if (BIT_in1 = '0' and BIT_in2 = '0' and BIT_in3 = '0') then
            tmp <= tmp;
        elsif (BIT_in1 = '0' and BIT_in2 = '0' and BIT_in3 = '1') or (BIT_in1 = '0' and BIT_in2 = '1' and BIT_in3 = '0') or (BIT_in1 = '0' and BIT_in2 = '1' and BIT_in3 = '1') or 
                               (BIT_in1 = '1' and BIT_in2 = '0' and BIT_in3 = '0') then 
            tmp(0) <= BIT_in1;
            tmp(1) <= BIT_in2;
            tmp(2) <= BIT_in3;
        else tmp <= "000";
        end if;
end process;   
BIT1 <= tmp(0);   
BIT2 <= tmp(1); 
BIT3 <= tmp(2); 
END povtor_arch;

 

 

Warning (10631): VHDL Process Statement warning at povtor.vhd(18): inferring latch(es) for signal or variable "tmp", which holds its previous value in one or more paths through the process
Warning (10492): VHDL Process Statement warning at povtor.vhd(21): signal "tmp" is read inside the Process Statement but isn't in the Process Statement's sensitivity list

 

Спасибо за помощь

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну, во-первых, это не ошибки, а предупреждения.

 

1) ... inferring latch(es) for signal or variable "tmp" ...

 

Означает, что чисто комбинаторной логикой здесь не обойтись т.к. необходим элемент памяти - ведь где-то же надо хрантить предыдущие значения битов, пока на входе присутствует "000". Компилятор просто предупреждает Вас о том, что по его мнению здесь нужна защелка. Если Вы с этим согласны, то все в порядке, а если нет, то Вы либо не верно описали то, что хотели, либо плохо представляете как вообще можно реализовать то, что хотите.

 

2) ... but isn't in the Process Statement's sensitivity list

 

Это всего лишь предупреждение о том, что результаты симуляции, возможно (а в данном случае 100%) не совпадут с поведением в ПЛИС. Нет ничего особенного, в том, чтобы включить tmp в список чуствительности process. Список чуствительности нужен не синтезатору, а симулятору для оптимизации и ускорения процесса моделирования.

 

Вы, видимо, еще не перестроили мышление с SW инженера на HW инженера, ну и недостаточно освоили VHDL.

 

Для вашего кода не нужно даже process и передавать сигнал побитно тоже как-то не солидно. Ну уж хотябы так написали бы

 

entity povtor is
    port (
              BIT_in:       IN STD_LOGIC_VECTOR(2 downto 0);
              BIT    :       OUT STD_LOGIC_VECTOR(2 downto 0)
         );
end povtor;

architecture povtor_arch of povtor is

  SIGNAL tmp : STD_LOGIC_VECTOR(2 downto 0);

BEGIN

process(BIT_in, tmp)
   begin
        if (BIT_in = "000") then
            tmp <= tmp;
        elsif (BIT_in = "100") or (BIT_in = "010") or (BIT_in = "011") or (BIT_in = "001") then 
            tmp <= BIT_in;
        else 
            tmp <= "000";
        end if;
end process;   

BIT <= tmp;

END povtor_arch;

 

я так понимаю tmp <= tmp так нельзя потому что в начальный момент значения сигнала не задано?

 

Вы неверно размышляете. В первую очередь для синтезатора это означает, что нужен элемент памяти. Что касается начальных значений, то синтезатор они вообще не волнуют, симулятор это никак не смутит, а вот Вы сами должны более детально понимать что произойдет. Если с самого начала на входе будет что-то отличное от "000", то выход "мгновенно" станет равным входу или "000". Если при начале работы на входе будет "000", то, в общем случае, на выходе будет случайное число, а симулятор, чтобы это "подчеркнуть" присвоит "ХХХ". Если ПЛИС по включению питания гарантирует какое-то конкретное состояниесигналов, то оно и будет. В общем, опять же, если Вы осознаете, что Вы получите в результате и это Вас устраивает, то нет никаких проблем. Если нет, то Вам явно недостает более глубокого понимания что такое языки HDL.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если нет, то Вам явно недостает более глубокого понимания что такое языки HDL.

это уж точно

спасибо за помощь

 

сделал так, но не знаю на сколько в VHDL это будет верным

то есть вообще так память выделяют

library IEEE;
use IEEE.std_logic_1164.all;

entity prob27 is
port 
(
    BIT_IN:       IN STD_LOGIC_VECTOR(2 downto 0);
    BIT_OUT:      OUT STD_LOGIC_VECTOR(2 downto 0)
);
end prob27;

architecture prob27_arch of prob27 is
  SIGNAL tmp : STD_LOGIC_VECTOR(2 downto 0);
BEGIN
process(BIT_IN, tmp)
variable i: STD_LOGIC_VECTOR(2 downto 0);
   begin
        if (BIT_IN = "000") then
            tmp <= i;
        elsif (BIT_IN = "001") or (BIT_IN = "010") or (BIT_IN = "011") or (BIT_IN = "100") or (BIT_IN = "101") then 
            tmp <= BIT_IN;
        else 
            tmp <= "000";
        end if;
        i := tmp;
end process;   
BIT_OUT <= tmp;   
END prob27_arch;

 

потому что возникают предупреждения только

Warning: Found combinational loop of 1 nodes

Warning: Node "tmp~22"

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Задайте себе вопрос: а может ли BIT_IN быть больше 4-х... Если физически такого быть не может, то тогда зачем такой сложный дешифратор?

Тогда там будет только проверка на 0.

Ну и если BIT_IN может быть больше, то что в этом плохого?

Или все же BIT_IN>0 and BIT_IN<5 ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

это уж точно

спасибо за помощь

 

сделал так, но не знаю на сколько в VHDL это будет верным

то есть вообще так память выделяют

library IEEE;
use IEEE.std_logic_1164.all;

entity prob27 is
port 
(
    BIT_IN:       IN STD_LOGIC_VECTOR(2 downto 0);
    BIT_OUT:      OUT STD_LOGIC_VECTOR(2 downto 0)
);
end prob27;

architecture prob27_arch of prob27 is
  SIGNAL tmp : STD_LOGIC_VECTOR(2 downto 0);
BEGIN
process(BIT_IN, tmp)
variable i: STD_LOGIC_VECTOR(2 downto 0);
   begin
        if (BIT_IN = "000") then
            tmp <= i;
        elsif (BIT_IN = "001") or (BIT_IN = "010") or (BIT_IN = "011") or (BIT_IN = "100") or (BIT_IN = "101") then 
            tmp <= BIT_IN;
        else 
            tmp <= "000";
        end if;
        i := tmp;
end process;   
BIT_OUT <= tmp;   
END prob27_arch;

 

потому что возникают предупреждения только

Warning: Found combinational loop of 1 nodes

Warning: Node "tmp~22"

 

Я не понимаю, зачем мудрить-то? Зачем Вам понадобилось вводить variable i? Я долго думал что же Вас заставило ввести variable, но так и не смого придумать ни одной причины. Зачем?

Чем Вас tmp <= tmp не устраивает?

 

Предупреждение про combinational loop это уже можете расценивать как Error, а не как Warning.

 

И что значит "вообще так память выделяют" ? VHDL это же не Си - в VHDL память не выделяют и не освобождают.

 

Я уже много раз говорил и Вам еще раз повторю свой совет для новичков: на первое время забудьте, что в VHDL есть variable - чтобы ими пользоваться надо сначала научиться работать с signal и вообще перестроить образ мышления с языков программирования на языки HLD.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ввел клок и предупреждения о combinational loop и предыдущие предупреждения пропали

я так понимаю, что введение clk аналогично введению в схему тактируемого триггера?

 

library IEEE;
use IEEE.std_logic_1164.all;

entity povtor is
port 
(
    clk:            IN STD_LOGIC;
    BIT_IN:            IN STD_LOGIC_VECTOR(2 downto 0);
    BIT_OUT:        OUT STD_LOGIC_VECTOR(2 downto 0)
);
end povtor;

architecture povtor_arch of povtor is
  SIGNAL tmp : STD_LOGIC_VECTOR(2 downto 0);
BEGIN
process(clk)
    begin
    if (clk'event and clk='1') then
        if (BIT_IN = "000") then
            tmp <= tmp;
        elsif (BIT_IN = "001") or (BIT_IN = "010") or (BIT_IN = "011") or (BIT_IN = "100") or (BIT_IN = "101") then 
            tmp <= BIT_IN;
        else 
            tmp <= "000";
        end if;
    end if;
end process;   
BIT_OUT <= tmp;   
END povtor_arch;

 

осталось только предупреждение

Warning: Found pins functioning as undefined clocks and/or memory enables
    Info: Assuming node "clk" is an undefined clock

но это похоже ничего страшного в квартусе

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

И все же мне интересно - зачем Вам понадобилось вводить variable? Каковы были размышления на этот счет?

 

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

 

Чем Вас latch не устраивал? Почему Вам DFF потребовался? Или Вы просто "боритесь" с Warning?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

я ввел variable i, потому что думал, что компилятор автоматически преобразует её в схеме в элемент памяти

размышляя, что ведь просто так переменная ни к чему не привязанная быть не может

 

Чем Вас latch не устраивал? Почему Вам DFF потребовался? Или Вы просто "боритесь" с Warning?

я первый раз с плис столкнулся и не знаю просто на сколько серьезные последствия от warning

 

допустим пишем

if (A = '1') then
    B <= '1';
end if;

тут уже warning и предупреждение о защелке

 

а надо ли это исправлять

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

допустим пишем

if (A = '1') then
    B <= '1';
end if;

тут уже warning и предупреждение о защелке

 

а надо ли это исправлять

А как же! Ведь что получается: при (A = '1') B становится равным 1, а когда оно будет другим? Пока что видно - никогда! После выхода из блока В остается в 1. Вот и защелка.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

я ввел variable i, потому что думал, что компилятор автоматически преобразует её в схеме в элемент памяти

размышляя, что ведь просто так переменная ни к чему не привязанная быть не может

 

Variable абсолютно никак не связана ни с защелкой, ни с триггером. Более того, использование variable может не повлечь за собой появление даже элементарных логических элементов, не то что триггеров или защелок. Синтезатор (если строго, то слово компилятор здесь вообще не подходит) решает что именно поставить и как все это соединить исходя из поведения, описанного на языке HDL. Забудьте пока про variable - нет их для новичков. Вам и signal хватит проблем :)

 

"... что ведь просто так переменная ни к чему не привязанная быть не может" - signal в VHDL и переменная в языках программирования есть абсолютно разные вещи. Это VHDL-ловская variable еще кое-как соответствует переменной в языках программирования, а вот signal - совсем нет.

 

я первый раз с плис столкнулся и не знаю просто на сколько серьезные последствия от warning

 

допустим пишем

if (A = '1') then
    B <= '1';
end if;

тут уже warning и предупреждение о защелке

 

а надо ли это исправлять

 

 

А как же! Ведь что получается: при (A = '1') B становится равным 1, а когда оно будет другим? Пока что видно - никогда! После выхода из блока В остается в 1. Вот и защелка.

 

Проблема у этого кода не в том, что В становится в 1 навсегда, а втом, что нет гарантий, что по включению питания В будет 0! Если начальное значение 1, то в коде просто нет никакого смысла. Но если ПЛИС или синтезатор каким-либо образом гарантируют, что В будет изначально в 0, то этот код вполне полезен на практике. Ситуация, когда схеме нуж но запомнить навсегда наличие какого-то события совершенно не редкость. Другое дело, что предусмотреть явный сброс в начале работы гораздо лучше со всех точек зрения!

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...