Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Взаимодействие state machines друг с другом
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Языки проектирования на ПЛИС (FPGA)
justontime
Пытаюсь поделить немерено разросшуюся FSM на несколько частей, в т.ч. выделить кусок в нечто типа функции (не в смысле понятия функции в HDL, а просто как узел, используемый из разных частей схемы).

Как правильно организовывать взаимодействие между несколькими FSM ? Флагами, или есть более красивый/правильный способ ?

И что делать, если две FSM должны управлять одними и теми же сигналами ? Например, есть автомат, производящий довольно сложный процесс инициализации устройства по SPI. Этот автомат должен использовать отдельную FSM для передачи байтов в устройство, но при этом и сам основной автомат хочет иногда подергать сигналы SPI.
Как правильнее поступать в подобных случаях ? У меня все работает, но нагромождение флагов и прочей фигни делает код нечитаемым даже для меня sad.gif

P.S. Вообще пишу на VHDL, но вряд ли это сильно зависит от конкретного языка - скорее, интересует общий подход...
iosifk
Цитата(justontime @ Dec 19 2017, 23:01) *
Пытаюсь поделить немерено разросшуюся FSM на несколько частей, в т.ч. выделить кусок в нечто типа функции (не в смысле понятия функции в HDL, а просто как узел, используемый из разных частей схемы).

Как правильно организовывать взаимодействие между несколькими FSM ? Флагами, или есть более красивый/правильный способ ?

И что делать, если две FSM должны управлять одними и теми же сигналами ? Например, есть автомат, производящий довольно сложный процесс инициализации устройства по SPI. Этот автомат должен использовать отдельную FSM для передачи байтов в устройство, но при этом и сам основной автомат хочет иногда подергать сигналы SPI.
Как правильнее поступать в подобных случаях ? У меня все работает, но нагромождение флагов и прочей фигни делает код нечитаемым даже для меня sad.gif

P.S. Вообще пишу на VHDL, но вряд ли это сильно зависит от конкретного языка - скорее, интересует общий подход...

У Вас немного прицел сбился. Надо делать так:
Наверху автомат, который ведет весь процесс. Он управляет вообще всем, что есть в проекте, либо непосредственно сигналами управления, либо другими автоматами...
Под ним работают автоматы, которые выполняют указания. Например для SPI верхний говорит "передать такие-то сообщения", а эти "средние" формируют эти сообщения и передают нижним, которые уже связаны с физикой. Например для SPI средние передают кадры, а нижние работают с битом в линии. Т.е. проверяют время бита, и если нужно, то фильтруют клоки из линии.
Обмен сигналами стандартный: "Старт" и "Готовность"...
Каждый такой автомат может иметь подключенный к нему таймер.
Рисуем блок-схему, из нее делаем граф состояний и его реализуем в виде автоматов...
Подробнее: Краткий Курс, глава дополнительная об автоматах.
Хотите подробнее - могу рассказать по скайпу...
Golikov A.
Цитата
Как правильнее поступать в подобных случаях ? У меня все работает, но нагромождение флагов и прочей фигни делает код нечитаемым даже для меня

Один раз решал подобную задачу так:
Было несколько блоков с сигналами старт-готово, и шиной управления (в вашем случае это СПИ). Блоки жили каждый в своем файле.
Был общий автомат который по очереди подключал шину управления выбранного блока к шине идущей на управляемое устройство и давал сигнал старта, потом ожидал сигнала готовности, отключал блок и переходил к следующему.

Все было достаточно управляемо

justontime
Цитата(iosifk @ Dec 19 2017, 23:22) *
Наверху автомат, который ведет весь процесс. Он управляет вообще всем, что есть в проекте, либо непосредственно сигналами управления, либо другими автоматами...
Под ним работают автоматы, которые выполняют указания. Например для SPI верхний говорит "передать такие-то сообщения", а эти "средние" формируют эти сообщения и передают нижним, которые уже связаны с физикой. Например для SPI средние передают кадры, а нижние работают с битом в линии. Т.е. проверяют время бита, и если нужно, то фильтруют клоки из линии.
Обмен сигналами стандартный: "Старт" и "Готовность"...
Каждый такой автомат может иметь подключенный к нему таймер.

В принципе, я вроде так и сделал, но все равно изящества нифига нет... Наверное, просто реализация у меня не очень... Ладно, вроде смысл понятен, попробую примеры поискать и посмотреть...
nice_vladi
Цитата(justontime @ Dec 19 2017, 21:01) *
Пытаюсь поделить немерено разросшуюся FSM на несколько частей, в т.ч. выделить кусок в нечто типа функции (не в смысле понятия функции в HDL, а просто как узел, используемый из разных частей схемы).

Как правильно организовывать взаимодействие между несколькими FSM ? Флагами, или есть более красивый/правильный способ ?

И что делать, если две FSM должны управлять одними и теми же сигналами ? Например, есть автомат, производящий довольно сложный процесс инициализации устройства по SPI. Этот автомат должен использовать отдельную FSM для передачи байтов в устройство, но при этом и сам основной автомат хочет иногда подергать сигналы SPI.
Как правильнее поступать в подобных случаях ? У меня все работает, но нагромождение флагов и прочей фигни делает код нечитаемым даже для меня sad.gif

P.S. Вообще пишу на VHDL, но вряд ли это сильно зависит от конкретного языка - скорее, интересует общий подход...


Вообще, идея в том, что бы ГЛАВНОМУ автомату никогда не хотелось самому подергать SPI. Он все делает через стоящие ниже по иерархии автоматы. Т.е. каждый автомат выполняет четко свою задачу и не лезет на другие уровни иерархии.
Главный - забирает посылку (запрашивает данные, формирует суперкадр). Средний - формирует кадры (откусывает по кадру от суперкадра, сформированного главным). Нижний - рабоает на уровне бит (роняет CS, выставляет клок, данные).

При этом каждый из них полностью завершен и очень глуп:

Нижний просто передает 1 кадр по SPI. Он не знает, сколько кадров всего, как часто передаются и т.д. Просто получает старт-передает-отдает сигнал завершения передачи.
Средний просто управляет первым. Он не знает размер посылки, умеет только забирать кусок и скармливать нижнему.
Главный формирует посылку и рулит средним.

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

Взаимодействие можно организовать по флагам-состояниям автоматов. Допустим, главный щелкает из wait->start->wait_end. Здесь состояние start будет командой среднему начать обработку посылки.
iosifk
Цитата(justontime @ Dec 21 2017, 04:35) *
В принципе, я вроде так и сделал, но все равно изящества нифига нет... Наверное, просто реализация у меня не очень... Ладно, вроде смысл понятен, попробую примеры поискать и посмотреть...

Если захотите, то могу подробнее объяснить по скайпу голосом с примерами...
dvladim
Цитата(justontime @ Dec 21 2017, 04:35) *
В принципе, я вроде так и сделал, но все равно изящества нифига нет... Наверное, просто реализация у меня не очень...

Иногда сложные автоматы проще реализовать как микропрограммные автоматы или специализированный микроконтроллер.
Maverick

во вложении пример...
justontime
Огромное спасибо всем откликнувшимся ! Вроде и великих секретов особо не открыли, но в голове как-то складываться потихоньку начинает. Буду дальше думать и пример(ы) смотреть...
justontime
Цитата(Maverick @ Dec 23 2017, 02:46) *
во вложении пример...

Кстати, за пример отдельное спасибо ! Он совсем в тему - вообще-то у меня задача изначально была проинициализировать CODEC, так что этот пример чуть ли не в лоб можно брать...
Maverick
Цитата(justontime @ Dec 24 2017, 21:45) *
Кстати, за пример отдельное спасибо ! Он совсем в тему - вообще-то у меня задача изначально была проинициализировать CODEC, так что этот пример чуть ли не в лоб можно брать...

Всегда пожалуйста... sm.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2024 Invision Power Services, Inc.