Чтение CRC внутри ПЛИС Опции

[Вовка_Бызов]

По требованию заказчика включили мы циклическую проверку целостности в нашем Cyclone III.
Но вопрос завис - заказчик хочет в качестве одного из регистров (ПЛИС подключена к процессору) иметь вот эту самую CRC, которую ему посчитал компилятор - в качестве контроля за версией. Вариант типа "а мы вам прошьем ту CRC, которую выдаст компилятор" ему не подходит.

В общем - не подскажет ли всемогущий Олл, как прочитать внутри проекта Cyclone III в реальном времени ее реальную CRC?

PS. В доках нашли возможность чтения оной через JTAG - это, увы, не подходит.

[SM]

PS. В доках нашли возможность чтения оной через JTAG - это, увы, не подходит.

Что приходит в голову - завести JTAG на I/O пины этой же ПЛИС, и написать автомат, читающий CRC из самой себя с использованием команд JTAG. Вроде как других вариантов особо и не наблюдается.

[ASN]

Вовка_Бызов
Не совсем понятно.
Поскольку Cyclone III fpga, то её кто-то грузит из ПЗУ.
Почему нельзя посчитать код контроля целостности по массиву, который грузится.
Если массив исказится, то fpga просто не загрузится.
А факт успешной загрузки можно определить по чтению уникального кода.

[SM]

то её кто-то грузит из ПЗУ.

Ну все таки обычно это делает она сама из подключенной к ней ПЗУ, ну либо ПЗУ ее грузит собственными силами (active или passive)

кстати, как вариант, после загрузки, она может еще раз вычитать содержимое ПЗУ и посчитать CRC. Уже не своим загрузочным автоматом, а специально сделанным автоматом.

Не ясно вот что - если CRC не сошлось, то ПЛИС не загрузится вообще, и не сможет никому сообщить, какая CRC у ее испорченной конфигурации

[vadimuzzz]

а загрузка в каком режиме? если в пассивном (проц шьет) - то он сам версию прошивки знает. если в активном, то как уже предлагали, прочитать ПЗУ в user-mode и посчитать CRC. контроль целостности по CRC циклон сам умеет делать, есть спец. нога, которая об ошибке сигнализирует

[Вовка_Бызов]

Что приходит в голову - завести JTAG на I/O пины этой же ПЛИС, и написать автомат, читающий CRC из самой себя с использованием команд JTAG. Вроде как других вариантов особо и не наблюдается.

Как-то уж больно через "левое ухо правой рукой"... А на счет "других вариантов" - на сколько достоверный ответ? С позиции знания - или с позиции предположения?

Почему нельзя посчитать код контроля целостности по массиву, который грузится.

Можно - кто ж спорит. Но - это почти то же, что и читать свою CRC из себя же через свой JTAG.

А факт успешной загрузки можно определить по чтению уникального кода.

Факт успешной хагрузки определяется по соответствующим внешним сигналам. Если ПЛИС загрузилась "неуспешно" - то она и не уйдет в User Mode.

Не ясно вот что - если CRC не сошлось, то ПЛИС не загрузится вообще, и не сможет никому сообщить, какая CRC у ее испорченной конфигурации

Ну - на этот вопрос отвечает документация - по наличию ошибки/отсутствию сигналов подтверждения загрузки делать вывод о дальнейших действиях. Кто до упора пытается в цикле перезагрузить ПЛИС, а кто - тупо свистит в какой-нить свисток вышестоящему "начальству". Но - это уже вопрос скорее системный, а не прикладной.

контроль целостности по CRC циклон сам умеет делать, есть спец. нога, которая об ошибке сигнализирует

Вопрос не в контроле целостности, а в контроле версии прошивки. Т.е. CRC практичеки определяет то, что в ПЛИС загружена легальная прошивка, соответствующая действующему ТУ, а не самопальная подделка. Грубо говоря.

Контроль же целостности, как вы тут верно заметили, делает сама ПЛИС и выдает из себя соответствующие сигналы - тут все понятно.

[dxp]

Вопрос не в контроле целостности, а в контроле версии прошивки. Т.е. CRC практичеки определяет то, что в ПЛИС загружена легальная прошивка, соответствующая действующему ТУ, а не самопальная подделка. Грубо говоря.

Контроль же целостности, как вы тут верно заметили, делает сама ПЛИС и выдает из себя соответствующие сигналы - тут все понятно.

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

[jks]

может быть такая конструкция на Verilog поможет

...
cyclone_crcblock crc_block(
.clk(sys_clk),
.ldsrc(),
.shiftnld(),
.crcerror(),
.regout()
);

и в настройках проекта включить Enable Error detection CRC


тут все подробно описано http://www.altera.com/literature/hb/cyc3/cyc3_ciii51013.pdf

[Вовка_Бызов]

может быть такая конструкция на Verilog поможет

...
cyclone_crcblock crc_block(.clk(sys_clk),.ldsrc(),.shiftnld(),.crcerror(),.regout());

и в настройках проекта включить Enable Error detection CRC

тут все подробно описано http://www.altera.com/literature/hb/cyc3/cyc3_ciii51013.pdf

О! (низко кланяясь и одновременно вчитываясь в указанный документ)
Правда, нужен VHDL - но это уже мелочи

Спасибо!

[Вовка_Бызов]

может быть такая конструкция на Verilog поможет
cyclone_crcblock crc_block( .clk(sys_clk), .ldsrc(), .shiftnld(), .crcerror(), .regout() );

Тупею.. Три выходных сигнала:
crcerror - бит несовпадения CRC после подсчета
regout - бит (!) с выхода сдвигового 32-разрядного регистра ошибки(!)
cyclecomplete - бит завершения цикла проверки

Нету ни слова об исходной контрольной сумме. Увы

Задал вопрос на форуме альтеры. Но - по опыту - спецы там не отвечают. Даже не знаю, кого спрашивать...

[SM]

Нету ни слова об исходной контрольной сумме. Увы

где ни слова нет? В документе - вроде есть.

This signal is an input into the error detection block. If shiftnld=1, the data is shifted from the internal shift register to the regout at each rising edge of clk. If shiftnld=0, the shift register parallel loads either the pre-calculated CRC value or the update register contents depending on the ldsrc port input. This port is required.

[Вовка_Бызов]

где ни слова нет? В документе - вроде есть.

This signal is an input into the error detection block. If shiftnld=1, the data is shifted from the internal shift register to the regout at each rising edge of clk. If shiftnld=0, the shift register parallel loads either the pre-calculated CRC value or the update register contents depending on the ldsrc port input. This port is required.

Нет ни слова о возможности достать эту pre-calculated CRC. Сама же эта CRC безусловно в документе упоминается - и не раз.
Опять же - указанное вами поле управляет процессом сравнения. Т.е. если 0 - то загружается (внутри атома) для сравнения pre-calculated CRC и происходит побитное сравнение с высчитанной CRC. Результат сравнения "выдавливается" в regout. По крайней мере - я так понял этот текст.

[ReAl]

Я эти слова прочёл как то, что в regout выдаётся образцовая либо вычисленная CRC (а не образцовая XOR вычисленная) в зависимости от ножки ldsrc (которая работает как адрес регистра на этом последовательном интерфейсе).

[Вовка_Бызов]

Я эти слова прочёл как то, что в regout выдаётся образцовая либо вычисленная CRC (а не образцовая XOR вычисленная) в зависимости от ножки ldsrc (которая работает как адрес регистра на этом последовательном интерфейсе).

Хм.. Возможно. Надо попробовать.

А опыт использования этого атома есть у кого-то? Меня в данном случае интересует: введение этого атома как-то повлияет на работу схемы контроля в целом? В частности - там есть выход сигнала ошибки - я его теперь ручками должен прописать туда, куда он шел по умолчанию? А еще в описании (файл .inc) атома есть упоминание о поле divider - его тоже как-то надо переуказать (я его в настройках проекта указал). И вообще - как сочетаются глобальные настройки проекта с использованием атома?

В общем - у меня есть смутное ощущение, что явное введение этого атома требует с моей стороны каких-то корректных действий. Каких (кроме подсоединения вывода) - вот в чем вопрос...

[SM]

Нет ни слова о возможности достать эту pre-calculated CRC.

Перевожу:

If shiftnld=1, the data is shifted from the internal shift register to the regout at each rising edge of clk. If shiftnld=0, the shift register parallel loads either the pre-calculated CRC value or the update register contents depending on the ldsrc port input

Если shiftnld=1, то данные сдвигаются во внутреннем регистре сдвига с выводом их на regout на каждом положительном фронте clk. Если shiftnld=0, то этот внутренний регистр сдвига производит параллельную загрузку либо рассчитанной CRC, либо значение из <апдейт-регистра> (я не знаю, что это), в зависимости от значения на входе "ldsrc".

Чем вас не устраивает загрузить в регистр сдвига эту CRC, а после вычитать ее последовательно с regout?

[Вовка_Бызов]

Квартус ругается

Error (14277): WYSIWYG CRC block or remote update block primitive "CRC_CTRL" must use CRCERROR port

Чего он от меня хочет? Вызов атома у меня выглядит вот так:

CRC_CTRL: cycloneiii_crcblock generic map (oscillator_divider=>2) port map (clk=>CLK, crcerror=>crc_error, ldsrc=>'0', shiftnld=>not GetIt, regout=>bit_crc32_value);

Мой сигнал crc_error никуда не заведен. Может - он ожидает от меня подключения ручками к соответствующему предопределенному пину? Но я в настройках указал битик использовать CRC-контроль.. До использования атома проблем (и ошибок) не было..

И еще - походу вопрос - нигде не нашел указания, с какого разряда начинается сдвиг. Т.е. regout - это отвод от младшего или от старшего разряда внутреннего сдвигового регистра?

[jks]

Квартус ругается

Error (14277): WYSIWYG CRC block or remote update block primitive "CRC_CTRL" must use CRCERROR port

Чего он от меня хочет? Вызов атома у меня выглядит вот так:

CRC_CTRL: cycloneiii_crcblock generic map (oscillator_divider=>2) port map (clk=>CLK, crcerror=>crc_error, ldsrc=>'0', shiftnld=>not GetIt, regout=>bit_crc32_value);

Мой сигнал crc_error никуда не заведен. Может - он ожидает от меня подключения ручками к соответствующему предопределенному пину? Но я в настройках указал битик использовать CRC-контроль.. До использования атома проблем (и ошибок) не было..

И еще - походу вопрос - нигде не нашел указания, с какого разряда начинается сдвиг. Т.е. regout - это отвод от младшего или от старшего разряда внутреннего сдвигового регистра?

CRCERROR надо подключить на внутреннюю логику или на внешний пин. Выход ДОЛЖЕН использоваться. Вариант с LCELL не прокатит.
Стандартный пин CRC_ERROR в любом случае будет использоваться.

CRC передается MSB first.
Регистр сигнатуры можно не читать, если ошибок не было после конфигурации то он НУЛЕВОЙ.

[Вовка_Бызов]

CRCERROR надо подключить на внутреннюю логику или на внешний пин. Выход ДОЛЖЕН использоваться. Вариант с LCELL не прокатит.
Стандартный пин CRC_ERROR в любом случае будет использоваться.

CRC передается MSB first.
Регистр сигнатуры можно не читать, если ошибок не было после конфигурации то он НУЛЕВОЙ.

Спасибо. Т.е. я могу сделать фиктивную обработку - и этого будет достаточно.. Что бы такое придумать

На счет чтения по сигналу ошибки - мне как раз нужно безо всякой ошибки прочесть CRC32 (один раз вначале), посчитанную компилятором - как CRC версии прошивки. Она будет доступна для чтения извне и прописываться в ТУ на изделие.. Требование заказчика по контролю за сменой прошивки.

[ermilovd]

Здравствуйте!
Возможно, я ошибаюсь, но. в описании (правда, на Cyclone4) написано о проверках на СRC текущего рабочего проекта!
Некоторое время назад была статья о том, что информация стиралась внутри ПЛИС под действием внешних факторов (солнечная радиация). А так как ПЛИС семейств CYCLONE загружаемая - на основе RAM. Появилась требования о проверке правильности проекта при его нормальной работе. При этом считывается "записанная" информация из ячеек ПЛИС и контролируется CRC записанная с той же ПЗУ, ранее при загрузке. При не совпадении (ветром надуло) выдается ошибка.
Если я не прав, поправьте меня! А вообще сейчас пытаюсь найти эту функцию для AHDL, пока глухо. Если есть опыт - поделитесь!

[wpost]

я считал CRC при помощи программы для NIOS. как читать EPCS я рассказывал тут http://electronix.ru/forum/index.php?showt...93233&st=15
посчитать CRC далее не составляет труда. Есть маленькое НО... неизвесно место конца прошивки. я считал CRC всей EPCS. плюс я считал по собственному полиному.
Вывод: получить CRC не трудно, но сделать так чтобы она совпадала с той что выдает байтбластер немного сложнее. Мы вышли из ситуации записью в спецификацию двух CRC. Заказчика это устроило.
Еще одно маленькое но... EPCS не самая быстрая микросхема. следовательно предложенный мною метод расчета CRC требует некоторого времени. на С3 c EPCS64 это примерно 20-30 секунд.

[jks]

я считал CRC при помощи программы для NIOS. как читать EPCS я рассказывал тут http://electronix.ru/forum/index.php?showt...93233&st=15
посчитать CRC далее не составляет труда. Есть маленькое НО... неизвесно место конца прошивки. я считал CRC всей EPCS. плюс я считал по собственному полиному.
Вывод: получить CRC не трудно, но сделать так чтобы она совпадала с той что выдает байтбластер немного сложнее. Мы вышли из ситуации записью в спецификацию двух CRC. Заказчика это устроило.
Еще одно маленькое но... EPCS не самая быстрая микросхема. следовательно предложенный мною метод расчета CRC требует некоторого времени. на С3 c EPCS64 это примерно 20-30 секунд.

CRC которая считается внутри ПЛИС не учитывает конфигурационные биты I/O блоков и биты RAM блоков.
Поэтому даже зная полином получить, то же значение CRC не получится.
Для этого надо знать распределение конфигурационных битов по блокам.
Если CRC нужна для идентификации прошивки, то достаточно прочитать первый блок прошивки и получить CRC из него.

[wpost]

CRC которая считается внутри ПЛИС не учитывает конфигурационные биты I/O блоков и биты RAM блоков.
Поэтому даже зная полином получить, то же значение CRC не получится.
Для этого надо знать распределение конфигурационных битов по блокам.
Если CRC нужна для идентификации прошивки, то достаточно прочитать первый блок прошивки и получить CRC из него.

Я решал задачу проверки целостности содержимого EPCS.