Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Странности со STate Machine
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
Вовка_Бызов
Имеем проект для Cyclone III. Один из фрагментов содержит State Machine переменную. Так вот, этот самый state machine через некоторое время улетает в неопределенное состояние, из которого возвращается только сбросом. Как такое может быть и чем лечится?

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

Код
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;
bogaev_roman
Цитата(Вовка_Бызов @ Nov 16 2011, 17:03) *
Имеем проект для Cyclone III. Один из фрагментов содержит State Machine переменную. Так вот, этот самый state machine через некоторое время улетает в неопределенное состояние, из которого возвращается только сбросом. Как такое может быть и чем лечится?

Причины возможны как мне кажется 2:
1. Временные ограничения не выполнены
2. Не учли какие-то состояния
На функциональном моделировании все работает?
slash_spb
Цитата(Вовка_Бызов @ Nov 16 2011, 16:03) *
Имеем проект для Cyclone III. Один из фрагментов содержит State Machine переменную. Так вот, этот самый state machine через некоторое время улетает в неопределенное состояние, из которого возвращается только сбросом. Как такое может быть и чем лечится?


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

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

1. проверить в симуляции
2. проверить входные сигналы
Мур
Выведите шину(надо организовать) состояний на джитаг. Убедитесь в очередности смены состояния, для привязки. А затем полюбуйтесь на зависание. Повезет,- сможете увидеть из какого происходит выпадание. Это уже половина решения. Внимательно просмотрите RTL на весь автомат и тогда можно упростить прицельно..

Тут правильно пишут о метастабильности. Развяжите возможные проблемные места стандартной анти-мета обвязкой...
Вовка_Бызов
Цитата(slash_spb @ Nov 16 2011, 17:00) *
Еще одна возможная причина - это метастабильность. Проверьте сигналы управления конечным автоматом. Они все синхронные???? нет асинхронщины????

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

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


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

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

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

Рад буду помощи!
bogaev_roman
Цитата(Вовка_Бызов @ Nov 21 2011, 12:17) *
Ну - в общем, вылечить-то вылечил - но не до конца.
Все это стробируется внутренней частотой 200 МГц. Мультиплексор сидит на заднем фронте, макро-функции и контроллер шины - на переднем.....
.....Как только я вывожу на внешние пины (тестовые выводы для осциллографа) пару четко определенных внутренних сигналов, вся система снова начинает периодически виснуть - точно также, как и при асинхронных входных данных.

Сообщение 2, пункт 1. И если я правильно понял, то Вы работаете и по заднему и по переднему фронту на 200МГц, т.е. фактически на 400МГц, то это много для cycloneIII. Временные ограничения вообще задавали, хотя б на тактовую частоту?
Вовка_Бызов
Цитата(bogaev_roman @ Nov 21 2011, 11:33) *
Сообщение 2, пункт 1. И если я правильно понял, то Вы работаете и по заднему и по переднему фронту на 200МГц, т.е. фактически на 400МГц, то это много для cycloneIII. Временные ограничения вообще задавали, хотя б на тактовую частоту?

Увы - нет. В общем-то я и спрашиваю - как их задавать, в каком виде и для каких цепей (в моем частном случае, хотя бы). Я читал про констрейны - но так толком и не понял принципов их использования, особенно для сигналов, генерируемых внутри ПЛИС.
bogaev_roman
Цитата(Вовка_Бызов @ Nov 21 2011, 14:18) *
Увы - нет. В общем-то я и спрашиваю - как их задавать, в каком виде и для каких цепей (в моем частном случае, хотя бы). Я читал про констрейны - но так толком и не понял принципов их использования, особенно для сигналов, генерируемых внутри ПЛИС.

Почитайте блог des00 про timequest для начала. http://embedders.org/blog/des00
Потом походу будут возникать вопросы их и задавайте.
Я б для начала все Ваши входы-выходы SM повесил на регистры и через виртуальные пины подключил, задал ограничения на тактовую частоту (кстати как Вы ее подключаете?) в TQ и посмотрел критичные пути. Если все будет хорошо, то дальше можно будет и остальные ограничения ввести.
Вовка_Бызов
Спасибо! Полез читать блог. Надеюсь, после этого я без проблем и глупых вопросов типа "а как это", сделаю то, о чем вы пишете:
Цитата(bogaev_roman @ Nov 21 2011, 13:30) *
Я б для начала все Ваши входы-выходы SM повесил на регистры и через виртуальные пины подключил, задал ограничения на тактовую частоту в TQ и посмотрел критичные пути. Если все будет хорошо, то дальше можно будет и остальные ограничения ввести.

Да, внутренняя тактовая формируется как внешняя (20 МГц), умноженная (PLL) на 10. Там же я получаю и 40МГц, передаваемые процессору...
bogaev_roman
Цитата(Вовка_Бызов @ Nov 21 2011, 14:37) *
Да, внутренняя тактовая формируется как внешняя (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 для получившихся частот
Вовка_Бызов
Цитата(bogaev_roman @ Nov 21 2011, 13:53) *
Ну если у Вас вообще одна частота как исходная используется, то дожно быть все просто
Определяете как входную
Код
create_clock -name {clk} -period 50.000 -waveform { 0.000 25.000 } [get_ports {clk}]

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

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


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

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

Ну вот - попробовал. В списке клоков появились выходы pll, но внешне это ни на что не повлияло..
Да - и надпись
Код
Critical Warning: Timing requirements not met

не исчезла..

И блог почему-то не открывается sad.gif Полная непруха..
bogaev_roman
Цитата(Вовка_Бызов @ Nov 21 2011, 15:10) *
Ну вот - попробовал. В списке клоков появились выходы pll, но внешне это ни на что не повлияло..
Да - и надпись
Код
Critical Warning: Timing requirements not met

не исчезла..

По поводу блога - у меня сейчас тоже весит, вроде еще в журналах компоненты и технологии были статьи эти. Ну можете в личку ему написать sm.gif
Ну не исчезла - значит не выполнились ограничения, запускайте timequest timing analyzer и там в макросах жмякайте report all core timings. Будут отображены до 1000 временных путей для каждой частоты (красным цветом - с временными ошибками, отрицательный slack например), каждый из них открывайте и смотрите подробнее. Сколько слоев логики, какая задержка на элементах, какая на путях (IC), какой fan-out и т.д. и т.п.
PS//Если временный ограничения не выполнены, то альтера в общем случае не гарантирует Вам правильную работу.
Будут вопросы - пишите.
Вовка_Бызов
Цитата(bogaev_roman @ Nov 21 2011, 14:38) *
Будут вопросы - пишите.

А вот и вопросы...
1. Есть у меня вход с внешней кнопки "Сброс", в внешнего сигнала "Системный сброс" и еще WDT - все это объединяется во внутренний сигнал nRST_LOC и всюду заводится.. И вот тут TA начинает ругаться на наличие отрицательный слаков между этими самыми сигналами сброса и выходными данными в интерфейс процессора.. Хотел описать set_false_path - да не тут-то было - нету в списке цепей этого самого nRST_LOC. Хотя в RTL вьюере - вот он, родимый... Думал - опишу его, как клок - но и в списке цепей этого сигнала тож нету. Он как-бы комбинированный (по "или" 4-х сигналов). В общем - странно все это.

2. По SM - на клок, заведенный на описанный выше девайс, TA сказал, что макс частота - 75 МГц. Исправил.

3. В итоге - я описал внутренние клоки. Убрал автоматическое распознавание клоков - он мне кучу всего находил и ругался на эти клоки сам. Вроде - кол-во ошибок резко поубавилось. Только осталась тревога - а все ли я описал.. Как, например, узнать, почему он мне 75 МГц посоветовал?
bogaev_roman
2/3 Вы задали TA исходную частоту, он в итоге по времянке выдает максимально возможную для худшего случая (по умолчанию - высокая загруженность кристалла, критичная температура +%). Она получается в общем случае исходя из максимального времени прохождения сигнала от триггера до триггера (есть и другие), Вы можете посмотреть эту максимальную цепочку (до 1000 наихудших по времени для каждой частоты/совместных частот), короче говоря получилось что у Вас самая длинная цепочка по времени (1/75МГц) секунд. В предыдущем посте писал как посмотреть.
1. По поводу сброса люди статьи пишут sm.gif. Ваш сброс мне не нравится - он получается с помощью комбинаторики, и по идее идет по обычной линии сигналов, а не глобальной шине (могу ошибаться), возможны гонки сигналов. Но для него все равно можно анализ закрыть, fiiter скорее всего переименовал nRST_LOC во что-то еще, посмотрите не в RTL, а в технолоджи мап вьювере.
PS// Посмотрел еще раз описание SM, в vhdl плохо разбираюсь, но меня смущает приоритет описания регистровой логики - обычно сначала по if описывается именно сброс, а уже все остальное по else. Советую убедиться, что Ваш сброс в триггере поступает именно на предназначенный для него вход.
Вовка_Бызов
Цитата(bogaev_roman @ Nov 24 2011, 13:20) *
PS// Посмотрел еще раз описание SM, в vhdl плохо разбираюсь, но меня смущает приоритет описания регистровой логики - обычно сначала по if описывается именно сброс, а уже все остальное по else. Советую убедиться, что Ваш сброс в триггере поступает именно на предназначенный для него вход.

Я смотрел, как формируется сброс и клок в моем случае - сброс на "R" вход, как и положено. Без доп комбинаторики. Структуру if-else квартус трактует именно как или-или. Т.е. в случае if-else наличие сброса еще будет и перекрывать другие сигналы. По сути - это лишнее. R и S входы чисто схематически имеют приоритет над клоком.
bogaev_roman
Цитата(Вовка_Бызов @ Nov 24 2011, 14:28) *
Я смотрел, как формируется сброс и клок в моем случае - сброс на "R" вход, как и положено. Без доп комбинаторики. Структуру if-else квартус трактует именно как или-или. Т.е. в случае if-else наличие сброса еще будет и перекрывать другие сигналы. По сути - это лишнее. R и S входы чисто схематически имеют приоритет над клоком.

В общем случае сброс и должен иметь наивысший приоритет и перебивать другие сигналы. Структура if-else приоритетна и else срабатывает только при отсутствии if. Не знаю что там на циклон3 за архитектура, но на стратикс4 синхронный сброс подается на вентиль AND вместе с данными, после чего на вход D триггера. Асинхронный - заведен специально отдельным входом aclr. Реальную структуру смотреть лучше все-таки на chipplanner, а не на RTL.
Вовка_Бызов
Цитата(bogaev_roman @ Nov 24 2011, 13:54) *
В общем случае сброс и должен иметь наивысший приоритет и перебивать другие сигналы. Структура if-else приоритетна и else срабатывает только при отсутствии if. Не знаю что там на циклон3 за архитектура, но на стратикс4 синхронный сброс подается на вентиль AND вместе с данными, после чего на вход D триггера. Асинхронный - заведен специально отдельным входом aclr. Реальную структуру смотреть лучше все-таки на chipplanner, а не на RTL.

Я как правило пользуюсь именно асинхронным сбросом (aclr). Но в случае синхронного сброса - вы абсолютно правы. И тогда имеет смысл использовать if-else
bogaev_roman
Цитата(Вовка_Бызов @ Nov 24 2011, 15:46) *
Я как правило пользуюсь именно асинхронным сбросом (aclr). Но в случае синхронного сброса - вы абсолютно правы. И тогда имеет смысл использовать if-else

Все просек, у Вас асинхронный сброс используется (vhdl плохо знаю), тогда проверьте что квартус его по глобальной шине пускает (в compilation report/resource section/global and other fast signals к примеру) и закрывайте для анализа (естественно он его переименовывает и никакого nRST_LOC там не будет).
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.