Здравствуйте.

Есть у нас девайс на FPGA, крутятся там FSM-ы, работает он в обсчем. Ну а теперь вот требуется вести лог состояний всех стейт-машин в этом реальном устройстве (в железе всмысле): записывать последние N состояний, вести учёт состояниям FSM ну и так далее. По запросу с ПК - считывать эти данные...

Для меня это более чем удивительно конечно , но хотелось бы узнать - это вообсче то где то применяется для FPGA? Если да - то где, как, зачем (всё же интересно) и где можно посмотреть правильную реализацию этого самого логирования..
Если нет - то как бы это объяснить красиво, что так не делают ??

Такое полезно разве что при отладке. В этом случаепросто выел регистр state на signal tap, и все. Чтоб постоянно мониторить надо было - не встречал. Впрочем ситуации бывают разные, может и полезно бывает.

Реализовывать, на мой взгляд, проще так же как и в signal tap сделано. Выводим все подлежащие мониторингу сигналы на один из портов двухпортового ОЗУ, формируем сигнал разрешения записи и счетчик адреса. А со второго порта считываем результат, когда надо.

Сделать то не сложно (если есть свободные ресурсы в FPGA), если просят, но зачем вопрос открытый

2 Artem_Petrik - в принципе так и думал сделать для запоминания последних состояний (или скорей всего фифошку поставлю), а вот со счётчиком этих самых состояний как быть ??
2 Elresearch - ну нужно посмотреть на эти состояния вживую людям наверно...

Из ожидаемых последствий, кроме как падение времянки, может быть что-то из разряда подводных камней ??

так если на каждом клоке записывать в память зачем Вам счётчик? или Вы хотите соптимизировать и писать только по изменению состояния + счётчик сколько в каком состоянии был клоков?

По изменению не получится - нужен именно лог последних N состояний машины (тут фифо видимо) + счётчик сколько раз после ресета стейт-машина была в этом состоянии..

и на какой частоте Вам предлагают это сделать? зная частоту + количество состояний можно оценить какое фифо Вам понадобиться и возможно идея лога себя изживёт

2 Elresearch - эта идея вообсче мне с самого начала не нравится... А частота тут не при чём - лог пока ожидается как запись при последних N изменений состояний машин (их там несколько - одни постоянны, вторые меняются) в циклический буфер и всё (N -пока задаётся параметром).
Со счётчиками есть идея (сама суть этих счётчиков в оригинале - достоверно писать сколько в каком состянии машина была без задержки) но она мне кажется кривоватой...

Так от частоты и будет зависеть Ваш "счётчик состояния от ресета" сколько разрядов на каждое состояние (а то ведь переполниться и конец достоверности) + кол-во состояний вот Вам и затраты

Я вас недопонял наверное - пока остановились на 32-х разрядах, сказали что пока хватит им.

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

Ну, фифо конечно понятие растяжимое, но я все же уточню. Обычное FIFO как бы не рассчитано на то, что будет переполнение, и, обычно, ведет себя в этом случае неподходяще для этого случая.

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

Счетчик состояний - самое простое. Делаем регистр, в который записываем старое значение STATE. Если новое равно старому - счетчик инкрементируется, если не равно - обнуляется. Также, если не равно, инкрементируется указатель записи. Вроде все.

И снова здравствуйте
В обсчем как оно мне не нравилось, а всё таки заваял я этот логер (правда это только логер изменяющихся состояний).
Прицепил
Нажмите для просмотра прикрепленного файла
Кому будет интересно - глянте, интересны мнения
(Обновил чуток: 02 -> 03, теперь вроде всё есть и работает как нужно)

ИМХО кое где сумбурно написано, кое где излишне усложненно и перерасход ресурса и если бы вы были моим подваном за такое описание КА "уши бы я вам пооткрутил" (с) старый мульт. Естественно это все на мой вкус и цвет.

2 des00 - ну так я и выложил сюда, чтоб послушать мнения
А подетальнее можно - что именно сумбурно, "излишне усложненно "- это где?, чем описание КА страшное, .. ??

блок wr_logger, логика однократного срабатывания после сброса. Вы городите подобие КА, которое тут ну совершенно не к месту. ИМХО проще сделать так :




кодирование состояний у вас в голове и это цифры, которые нужно помнить и анализировать. Куда нагляднее читать в коде что то вроде STATE_INIT_RAM_CLEAR/STATE_RAM_CLEAR чем мифические 4'd02/4'd03 и т.д.



совершенно лишнее использование макросов для задания границ счетчиков, есть ненужный перерасход ресурса и комменты стоят странно, часть фсм полностью расписана вплоть до примитивных действий (что ИМХО не нужно), другая часть вообще не комментирована.

PS. Вспомнил основную причину сумбурности, на мой взгляд, вашего кода. У вас плавает стиль в пределах одного и того же модуля. ИМХО если вы используете какой-либо стиль описания, то придерживайтесь его хотя бы в одном модуле, а то у вас намешано и Паскаль и Кемел и тип с подчеркиваниями %)

2 des00 - не понял что есть можете на пальцах объяснить ?

ЭтоСтильПаскаль
вотЭтоКэмел
а_это_с_подчеркиваниями

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