[Kuzmi4 0]

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

 

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

:1111493779:

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

Если нет - то как бы это объяснить красиво, что так не делают ??

[Artem_Petrik 0]

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

 

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

[Elresearch 1]

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

[Kuzmi4 0]

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

2 Elresearch - ну нужно посмотреть на эти состояния вживую людям наверно...

 

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

[Elresearch 1]

а вот со счётчиком этих самых состояний как быть ??

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

[Kuzmi4 0]

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

[Elresearch 1]

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

[Kuzmi4 0]

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

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

[Elresearch 1]

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

[Kuzmi4 0]

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

 

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

[Artem_Petrik 0]

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

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

 

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

 

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

[Kuzmi4 0]

И снова здравствуйте

В обсчем как оно мне не нравилось, а всё таки заваял я этот логер (правда это только логер изменяющихся состояний).

Прицепил

state_logger_v03.rar

Кому будет интересно - глянте, интересны мнения :laughing:

(Обновил чуток: 02 -> 03, теперь вроде всё есть и работает как нужно)

[des00 25]

Кому будет интересно - глянте, интересны мнения :laughing:

 

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

[Kuzmi4 0]

2 des00 - ну так я и выложил сюда, чтоб послушать мнения :laughing:

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

[des00 25]

"излишне усложненно "- это где?,

 

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

if (rst) 
  pwr_srl <= 2'b01; 
else 
  pwr_srl <= (pwr_srl << 1);
..
pwr_on_sig <= pwr_srl[1];

 

чем описание КА страшное, .. ??

 

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

 

что именно сумбурно

 

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