Странности со STate Machine, Летает, блин!.. Опции

[Вовка_Бызов]

Имеем проект для Cyclone III. Один из фрагментов содержит State Machine переменную. Так вот, этот самый state machine через некоторое время улетает в неопределенное состояние, из которого возвращается только сбросом. Как такое может быть и чем лечится?

Вот, код на VHDL. Вывод TST был добавлен для поиска состояния, в котором исполнение виснет. Так вот - TST так и не стал '1' после зависания

Код

library ieee;
use ieee.std_logic_1164.all;
use IEEE.numeric_std.all;

entity IO_SPLITTER_LOW is
    port (
        HOLD_in1, HOLD_in2 : in bit := '0';
        DI_in1, DI_in2 : in bit_vector (31 downto 0);
        DI_out : out bit_vector (31 downto 0);
        DO_out1, DO_out2 : out bit_vector (31 downto 0);
        DO_in : in bit_vector (31 downto 0);
        START_in1, START_in2, WnR_in1, WnR_in2 : in bit;
        DONE_1, DONE_2 : out bit;
        START_out, WnR_out, TST : out bit;
        DONE : in bit;
        RESET, CLK : in bit
    );
end IO_SPLITTER_LOW;

architecture pll_type of IO_SPLITTER_LOW is
    type State_Machine is (S0, S1, S2, S3, S4, S5);
    signal mode : State_Machine;
    signal dir, connected, lstart, eof_flag : bit;
begin
    DI_out <= DI_in1 when dir = '0' else DI_in2;
    WnR_out <= WnR_in1 when dir = '0' else WnR_in2;
    DO_out1 <= DO_in;
    DO_out2 <= DO_in;
    DONE_1 <= DONE when connected = '1' and dir = '0' else '0';
    DONE_2 <= DONE when connected = '1' and dir = '1' else '0';
    lstart <= START_in1 when dir = '0' else START_in2;
    START_out <= lstart when connected = '1' else '0';
    
    TST <= '1' when mode = S2 or mode = S3 else '0';
    
    process (connected, DONE)
    begin
        if DONE = '0' and DONE'event then
            eof_flag <= '1';
        end if;
        if connected = '0' then
            eof_flag <= '0';
        end if;
    end process;
    
    process (CLK, RESET)
    begin
        if CLK = '1' and CLK'event then
            case mode is
                when S0 =>
                    if START_in1 = '1' and HOLD_in2 = '0' then
                        mode <= S2;
                    else
                        mode <= S1;
                    end if;
                when S1 =>
                    if START_in2 = '1' and HOLD_in1 = '0' then
                        mode <= S3;
                    else
                        mode <= S0;
                    end if;
                when S2 =>
                    dir <= '0';
                    mode <= S4;
                when S3 =>
                    dir <= '1';
                    mode <= S4;
                when S4 =>
                    connected <= '1';
                    if eof_flag = '1' then
                        mode <= S5;
                    else
                        mode <= S4;
                    end if;
                when others =>
                    connected <= '0';
                    mode <= S0;
            end case;
        end if;
        if RESET = '1' then
            mode <= S0;
            dir <= '0';
            connected <= '0';
        end if;
    end process;
end pll_type;

[slash_spb]

Имеем проект для Cyclone III. Один из фрагментов содержит State Machine переменную. Так вот, этот самый state machine через некоторое время улетает в неопределенное состояние, из которого возвращается только сбросом. Как такое может быть и чем лечится?

Еще одна возможная причина - это метастабильность. Проверьте сигналы управления конечным автоматом. Они все синхронные???? нет асинхронщины????

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

1. проверить в симуляции
2. проверить входные сигналы

Сообщение отредактировал slash_spb - Nov 16 2011, 14:01

[Вовка_Бызов]

Еще одна возможная причина - это метастабильность. Проверьте сигналы управления конечным автоматом. Они все синхронные???? нет асинхронщины????

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

1. проверить в симуляции
2. проверить входные сигналы

Похоже - оно... Входные данные (один сигнал ) оказались асинхронными. Вылечил! Огромное спасибо!

[Вовка_Бызов]

Ну - в общем, вылечить-то вылечил - но не до конца.
Опишу весь девайс. Имеем шину типа Unibus с одной стороны и EMIF TMS320C6455 - с другой. Внутри FPGA реализован контроллер шины и 4 макро-функции работы с периферией. Маркофункции реализованы в виде отдельных блоков, соединенных с контроллером шины с помощью мультиплексора шины с сигналами запуска (в сторону контроллера шины) и завершения выполнения (в обратную сторону). Все это стробируется внутренней частотой 200 МГц. Мультиплексор сидит на заднем фронте, макро-функции и контроллер шины - на переднем - за счет этого ухожу от метастабильности автоматов, которые есть в каждом из блоков (в том числе - и в мультиплекоре). Внешние сигналы, влияющие на автоматы, тоже стробируются.

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

А вопрос вот какой. Что надо сказать компилятору, чтобы он правильно определял условия построения проекта? К сожалению, опыта в таких больших проектах у меня нет - все обычно заканчивалось программкой на VHDL или небольшой схемой - и работало сразу без проблем. А тут все как-то сложно стало.. Может - надо дополнительно что-то сигналам описать? И каким? Шинам? Клоку? Стробам запуска/готовности?

Рад буду помощи!

[bogaev_roman]

Ну - в общем, вылечить-то вылечил - но не до конца.
Все это стробируется внутренней частотой 200 МГц. Мультиплексор сидит на заднем фронте, макро-функции и контроллер шины - на переднем.....
.....Как только я вывожу на внешние пины (тестовые выводы для осциллографа) пару четко определенных внутренних сигналов, вся система снова начинает периодически виснуть - точно также, как и при асинхронных входных данных.

Сообщение 2, пункт 1. И если я правильно понял, то Вы работаете и по заднему и по переднему фронту на 200МГц, т.е. фактически на 400МГц, то это много для cycloneIII. Временные ограничения вообще задавали, хотя б на тактовую частоту?

[Вовка_Бызов]

Сообщение 2, пункт 1. И если я правильно понял, то Вы работаете и по заднему и по переднему фронту на 200МГц, т.е. фактически на 400МГц, то это много для cycloneIII. Временные ограничения вообще задавали, хотя б на тактовую частоту?

Увы - нет. В общем-то я и спрашиваю - как их задавать, в каком виде и для каких цепей (в моем частном случае, хотя бы). Я читал про констрейны - но так толком и не понял принципов их использования, особенно для сигналов, генерируемых внутри ПЛИС.

[bogaev_roman]

Увы - нет. В общем-то я и спрашиваю - как их задавать, в каком виде и для каких цепей (в моем частном случае, хотя бы). Я читал про констрейны - но так толком и не понял принципов их использования, особенно для сигналов, генерируемых внутри ПЛИС.

Почитайте блог des00 про timequest для начала. http://embedders.org/blog/des00
Потом походу будут возникать вопросы их и задавайте.
Я б для начала все Ваши входы-выходы SM повесил на регистры и через виртуальные пины подключил, задал ограничения на тактовую частоту (кстати как Вы ее подключаете?) в TQ и посмотрел критичные пути. Если все будет хорошо, то дальше можно будет и остальные ограничения ввести.

[Вовка_Бызов]

Спасибо! Полез читать блог. Надеюсь, после этого я без проблем и глупых вопросов типа "а как это", сделаю то, о чем вы пишете:

Я б для начала все Ваши входы-выходы SM повесил на регистры и через виртуальные пины подключил, задал ограничения на тактовую частоту в TQ и посмотрел критичные пути. Если все будет хорошо, то дальше можно будет и остальные ограничения ввести.

Да, внутренняя тактовая формируется как внешняя (20 МГц), умноженная (PLL) на 10. Там же я получаю и 40МГц, передаваемые процессору...

[bogaev_roman]

Да, внутренняя тактовая формируется как внешняя (20 МГц), умноженная (PLL) на 10. Там же я получаю и 40МГц, передаваемые процессору...

Ну если у Вас вообще одна частота как исходная используется, то дожно быть все просто
Определяете как входную

Код

create_clock -name {clk} -period 50.000 -waveform { 0.000 25.000 } [get_ports {clk}]

и все исходные от нее формируются командой

Код

derive_pll_clocks

timequest будет анализировать все пути register-to-register для получившихся частот

[Вовка_Бызов]

Ну если у Вас вообще одна частота как исходная используется, то дожно быть все просто
Определяете как входную

Код

create_clock -name {clk} -period 50.000 -waveform { 0.000 25.000 } [get_ports {clk}]

и все исходные от нее формируются командой

Код

derive_pll_clocks

timequest будет анализировать все пути register-to-register для получившихся частот

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

Пробую скомпилироваться с derive_pll_clocks

Ну вот - попробовал. В списке клоков появились выходы pll, но внешне это ни на что не повлияло..
Да - и надпись

Код

Critical Warning: Timing requirements not met

не исчезла..

И блог почему-то не открывается Полная непруха..