|
|
  |
Взаимодействие state machines друг с другом |
|
|
|
Dec 19 2017, 20:01
|
Местный
  
Группа: Свой
Сообщений: 236
Регистрация: 6-12-14
Из: СПб
Пользователь №: 84 003

|
Пытаюсь поделить немерено разросшуюся FSM на несколько частей, в т.ч. выделить кусок в нечто типа функции (не в смысле понятия функции в HDL, а просто как узел, используемый из разных частей схемы). Как правильно организовывать взаимодействие между несколькими FSM ? Флагами, или есть более красивый/правильный способ ? И что делать, если две FSM должны управлять одними и теми же сигналами ? Например, есть автомат, производящий довольно сложный процесс инициализации устройства по SPI. Этот автомат должен использовать отдельную FSM для передачи байтов в устройство, но при этом и сам основной автомат хочет иногда подергать сигналы SPI. Как правильнее поступать в подобных случаях ? У меня все работает, но нагромождение флагов и прочей фигни делает код нечитаемым даже для меня  P.S. Вообще пишу на VHDL, но вряд ли это сильно зависит от конкретного языка - скорее, интересует общий подход...
|
|
|
|
|
Dec 19 2017, 20:22
|
Гуру
     
Группа: Модераторы
Сообщений: 3 848
Регистрация: 8-09-05
Из: спб
Пользователь №: 8 369

|
Цитата(justontime @ Dec 19 2017, 23:01)  Пытаюсь поделить немерено разросшуюся FSM на несколько частей, в т.ч. выделить кусок в нечто типа функции (не в смысле понятия функции в HDL, а просто как узел, используемый из разных частей схемы). Как правильно организовывать взаимодействие между несколькими FSM ? Флагами, или есть более красивый/правильный способ ? И что делать, если две FSM должны управлять одними и теми же сигналами ? Например, есть автомат, производящий довольно сложный процесс инициализации устройства по SPI. Этот автомат должен использовать отдельную FSM для передачи байтов в устройство, но при этом и сам основной автомат хочет иногда подергать сигналы SPI. Как правильнее поступать в подобных случаях ? У меня все работает, но нагромождение флагов и прочей фигни делает код нечитаемым даже для меня  P.S. Вообще пишу на VHDL, но вряд ли это сильно зависит от конкретного языка - скорее, интересует общий подход... У Вас немного прицел сбился. Надо делать так: Наверху автомат, который ведет весь процесс. Он управляет вообще всем, что есть в проекте, либо непосредственно сигналами управления, либо другими автоматами... Под ним работают автоматы, которые выполняют указания. Например для SPI верхний говорит "передать такие-то сообщения", а эти "средние" формируют эти сообщения и передают нижним, которые уже связаны с физикой. Например для SPI средние передают кадры, а нижние работают с битом в линии. Т.е. проверяют время бита, и если нужно, то фильтруют клоки из линии. Обмен сигналами стандартный: "Старт" и "Готовность"... Каждый такой автомат может иметь подключенный к нему таймер. Рисуем блок-схему, из нее делаем граф состояний и его реализуем в виде автоматов... Подробнее: Краткий Курс, глава дополнительная об автоматах. Хотите подробнее - могу рассказать по скайпу...
--------------------
www.iosifk.narod.ru
|
|
|
|
|
Dec 20 2017, 07:04
|
Гуру
     
Группа: Свой
Сообщений: 4 247
Регистрация: 17-02-06
Пользователь №: 14 454

|
Цитата Как правильнее поступать в подобных случаях ? У меня все работает, но нагромождение флагов и прочей фигни делает код нечитаемым даже для меня Один раз решал подобную задачу так: Было несколько блоков с сигналами старт-готово, и шиной управления (в вашем случае это СПИ). Блоки жили каждый в своем файле. Был общий автомат который по очереди подключал шину управления выбранного блока к шине идущей на управляемое устройство и давал сигнал старта, потом ожидал сигнала готовности, отключал блок и переходил к следующему. Все было достаточно управляемо
|
|
|
|
|
Dec 21 2017, 01:35
|
Местный
  
Группа: Свой
Сообщений: 236
Регистрация: 6-12-14
Из: СПб
Пользователь №: 84 003

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

Участник

Группа: Участник
Сообщений: 43
Регистрация: 7-09-16
Из: Томск
Пользователь №: 93 239

|
Цитата(justontime @ Dec 19 2017, 21:01)  Пытаюсь поделить немерено разросшуюся FSM на несколько частей, в т.ч. выделить кусок в нечто типа функции (не в смысле понятия функции в HDL, а просто как узел, используемый из разных частей схемы). Как правильно организовывать взаимодействие между несколькими FSM ? Флагами, или есть более красивый/правильный способ ? И что делать, если две FSM должны управлять одними и теми же сигналами ? Например, есть автомат, производящий довольно сложный процесс инициализации устройства по SPI. Этот автомат должен использовать отдельную FSM для передачи байтов в устройство, но при этом и сам основной автомат хочет иногда подергать сигналы SPI. Как правильнее поступать в подобных случаях ? У меня все работает, но нагромождение флагов и прочей фигни делает код нечитаемым даже для меня  P.S. Вообще пишу на VHDL, но вряд ли это сильно зависит от конкретного языка - скорее, интересует общий подход... Вообще, идея в том, что бы ГЛАВНОМУ автомату никогда не хотелось самому подергать SPI. Он все делает через стоящие ниже по иерархии автоматы. Т.е. каждый автомат выполняет четко свою задачу и не лезет на другие уровни иерархии. Главный - забирает посылку (запрашивает данные, формирует суперкадр). Средний - формирует кадры (откусывает по кадру от суперкадра, сформированного главным). Нижний - рабоает на уровне бит (роняет CS, выставляет клок, данные). При этом каждый из них полностью завершен и очень глуп: Нижний просто передает 1 кадр по SPI. Он не знает, сколько кадров всего, как часто передаются и т.д. Просто получает старт-передает-отдает сигнал завершения передачи. Средний просто управляет первым. Он не знает размер посылки, умеет только забирать кусок и скармливать нижнему. Главный формирует посылку и рулит средним. А если главный автомат в обход среднего и нижнего захочет подергать SPI - это приведет к дикой путанице и усложнению. В идеале - растащить автоматы по разным модулям, что бы в одном модулей было не более 1 автомата. Пусть даже эти модули и будут мизерными по размеру. Взаимодействие можно организовать по флагам-состояниям автоматов. Допустим, главный щелкает из wait->start->wait_end. Здесь состояние start будет командой среднему начать обработку посылки.
|
|
|
|
|
Dec 24 2017, 19:45
|
Местный
  
Группа: Свой
Сообщений: 236
Регистрация: 6-12-14
Из: СПб
Пользователь №: 84 003

|
Цитата(Maverick @ Dec 23 2017, 02:46)  во вложении пример... Кстати, за пример отдельное спасибо ! Он совсем в тему - вообще-то у меня задача изначально была проинициализировать CODEC, так что этот пример чуть ли не в лоб можно брать...
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|