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

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

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

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

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

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

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

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

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

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


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


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


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


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

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

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

может быть такая конструкция на 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 - но это уже мелочи

Спасибо!

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

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

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

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

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. По крайней мере - я так понял этот текст.

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

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

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

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

Перевожу:

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?