[Muscat 0]

В одном проекте был конечный автомат, внутри которого крутился счетчик

Выглядело это так

    begin 
    if (RST ='1') then 
        state <=WT;
    elsif (clk='1' and clk'event) then 
        case state is 
        when WT => 
            if (EN='1') then
                CLK_Counter<=(others =>'0');
                state<=PS;
            end if;
        when PS =>
            if (conv_integer(CLK_Counter)=14) then
                        state<=NEXT;
                       CLK_Counter<=(others =>'0');
                        BIT_Counter<=(others =>'0');
             else 
                                         CLK_Counter<=CLK_Counter+1;
            end if;

 

Вот с этим счетчиком происходило что то странное. При тактовой частоте клока 48 МГц, плиска Actel M1A3P1000L он временами "проскакивал" нужное значение счетчика. То есть примерно на каждое 10 выполнение он не замечал, что счетчик уже равен 13 и продолжал считать. Это приводило к сбоям.

 

Опытным путем прибавление единицы было вынесено из под условия IF

 

 

    begin 
    if (RST ='1') then 
        state <=WT;
        
    elsif (clk='1' and clk'event) then 
        case state is 
        when WT => 
            if (EN='1') then
                CLK_Counter<=(others =>'0');
                state<=PS;
            end if;
        when PS =>
        CLK_Counter<=CLK_Counter+1;
            if (conv_integer(CLK_Counter)=14) then
                state<=NEXT;
                      CLK_Counter<=(others =>'0');
            end if;

 

И все заработало как надо.

 

По этому поводу несколько въедливых вопросов

1) Каково объяснение этому феномену?

2) Слышал мнение, что лучше считать не с 0 до константы, а от константы до нуля, тогда точно не пропустишь? Это верно?

3) Есть ли в принципе разница между конструкциями?

conv_integer(CLK_Counter)=14
CLK_Counter=conv_std_logic_vector(14,4);
CLK_Counter="1110"

[Shtirlits 0]

1) Неверно проверялось соответствие схемы заданой тактовой частоте. Времянки не выполнялись и это не обнаруживалось до запуска. После вынесения инкремента из условия схема упростилась: счетчик отдельно, компаратор отдельно. Времянки стали выполнятся в конкретных условиях (напряжение, температура). "Прочувствовать" разницу можно рассмотрев схему после синтеза до изменений и после.

 

2) Если не задавать констрейны для схемы и не проверять их выполнение, то можно пропустить что угодно. А если тактовая 10MHz, то работает? А 100MHz? А 200? А 500? Когда останавливаться?

 

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

 

3) не вижу разницы.

[Muscat 0]

Частота при синтезе была задана на 100 МГц. Синтезатор выдал 2 предупреждения (для обеих реализаций)

 

@W:MT420 : | Found inferred clock RS_232_RX|clk with period 6.43ns. A user-defined clock should be declared on object "p:clk"

 

@W:MT420 : | Found inferred clock RS_232_RX|READ_BIT_inferred_clock with period 1.00ns. A user-defined clock should be declared on object "n:READ_BIT"

 

В каком месте он просит его объявлять, я не понял.

[andrew_b 16]

3) Есть ли в принципе разница между конструкциями?

conv_integer(CLK_Counter)=14
CLK_Counter=conv_std_logic_vector(14,4);
CLK_Counter="1110"

Читабельнее и писабельнее

 CLK_Counter=14;

[ViKo 1]

Можно проверять условие не Counter == 14, а Counter >= 14. Тогда проскочить его будет труднее.

На тактовом сигнале могли быть палки из-за отражений, и счетчик считал бы лишний фронт.

[Muscat 0]

andrew_b, почему тогда Xilinx Synthethis Tools рекомендует именно бинарное представление? Помню еще в самом начале много мучился со всеми этими типами, в итоге теперь использую только 3 типа переменных - stf_logic, std_logic_vector, integer исключительно для задания констант.

 

ViKo - а это не приводит к излишнему усложнению схемы?

 

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

[ViKo 1]

а это не приводит к излишнему усложнению схемы?

Скорее, наоборот. От числа зависит.

[Kuzmi4 0]

....

@W:MT420 : ....

Я так понимаю Synplify.

Это варнинги на отсутствие SDC файла с констрейнами. Я бы его на вашем месте всё таки написал и подключил - автоматические режимы они скрытные сабаки...

 

[sazh 8]

На тактовом сигнале могли быть палки из-за отражений, и счетчик считал бы лишний фронт.

 

В симуляторе?

 

[Muscat 0]

Спасибо! Почитаю хелп, посмотрю.

 

ViKo как я понимаю схемотехнику, сравнение на равно реализуется на элементах И по числу бит и 1 большом ИЛИ-НЕ. Сравнение больше или равно подразумевает более сложную схемотехнику. Или я не прав?

[ViKo 1]

В симуляторе?

В начальном сообщении не говорилось про симулятор.

 

ViKo как я понимаю схемотехнику, сравнение на равно реализуется на элементах И по числу бит и 1 большом ИЛИ-НЕ. Сравнение больше или равно подразумевает более сложную схемотехнику. Или я не прав?

Не правы. Определить D == 0x80 - это значит, проверить все 8 битов, а D >= 0x80 - проверить только один, старший.

[Muscat 0]

И все же я думаю, что я прав.

 

Проверить только один бит? И сколько бит вы проверите чтобы сравнить 1110 и 1101?

 

Проверки ради синтезировал следующий код

library ieee; 
use ieee.std_logic_1164.all; 
use ieee.std_logic_arith.all; 
use ieee.std_logic_unsigned.all;  

entity COMP is 
    port(
        A         : in std_logic_vector (7 downto 0); 
           B         :  in std_logic_vector (7 downto 0);
              REZ       : out std_logic);        
end COMP;

architecture BEH of COMP     is
begin
REZ<='1' when A=B else '0';
end architecture;

 

В случае строгого равенства =

Core Cells : 10 of 24576 (0%)

IO Cells : 17

Скриншот технологического вида

 

В случае больше ИЛИ равно >=

Core Cells : 23 of 24576 (0%)

IO Cells : 17

Скриншот технологического вида

 

Как мне сообщают Титце и Шенк, со страницы 732 1 тома 12 издания, алгоритм работы компаратора по величине сложнее простого. Он состоит в последовательном сравнении разрядов бит, начиная со старшего. Соответственно и схема выходит сложнее.

Исправьте меня, если я где то допустил ошибку в рассуждениях.

[nikolascha 0]

Как мне сообщают Титце и Шенк, со страницы 732 1 тома 12 издания, алгоритм работы компаратора по величине сложнее простого. Он состоит в последовательном сравнении разрядов бит, начиная со старшего. Соответственно и схема выходит сложнее.

Исправьте меня, если я где то допустил ошибку в рассуждениях.

Титце и Шенк вас не обманывают, но вы привели пример сравнения двух переменных, хотя раньше говорилось о сравнении переменной и константы. Так что

Скорее, наоборот. От числа зависит.

сказал правильно, что в большенстве случаев будет меньше. Вы проведите синтез на вашей операции (a=14 и a>=14)...

 

[Muscat 0]

REZ<='1' when conv_integer(A)=211 else '0';

 

В обоих случаях 5 ячеек, хотя схемы несколько различаются

Core Cells : 5 of 24576 (0%)

 

Для небольших чисел результат в пользу "больше или равно".

 

То есть общий вывод, что для сравнения сигналов эффективнее про ресурсам использовать строгое равенство, а для сравнения с константами больше или равно?

[Shtirlits 0]

Какой-то не слишком технологический этот вид. Может у актэл так принято?

Попробуйте сравнивать числа побольше, например, 32 бита и константы не круглые, относительно троек битов.

ProASIC может быть и сделан внутри как нарисовано в user's guide, но из фразы "each VersaTile can be configured using the appropriate flash switch connections: Any 3-input logic function" следует, что картинку 1-8 UG можно игнорировать и думать про lookup table с тремя входами. Не бывает 2-входового или 5-входового ИЛИ, может быть только то, что конструируется из 3-х входовых элементов и не важно какая логика.