Всем привет!

Имеется плата, на которой есть ПЛИС (Циклон 4Е) и процессор (Blackfin). Для удобства обновления фирмвари придумано хранить прошивку процессора в той же загрузочной флешке (M25P64), с которой грузится ПЛИС. План такой: сперва оживает ПЛИС, потом грузит процессор через SPI. Для доступа к данным, хранящимся в конфигурационной флеши, Альтера предоставляет мегафункцию ASMI_PARALLEL, которая через простой параллельный 8-битный интерфейс предоставляет доступ к конфигуратору.

В общем и целом реализовать задуманное удалось, но в процессе всплыл непонятный момент, о чём, собственно, и данный топик. В документации на модуль ASMI_PARALLEL есть картинка с диаграммой сигналов при чтении:
Нажмите для просмотра прикрепленного файла
и к этому ещё текстом сопровождение:


Что означает, что для завершения чтения нужно перевести сигнал rden в лог 0, после этого модуль выдаст ещё один байт, после чего деактивирует сигнал busy. Т.е деактивировать rden нужно на предпоследнем читаемом байте.

Так я и делал, но в итоге последний байт в прошивке проца (там контрольная сумма CRC32) не прочитывался. Копание вывело на то, что по факту модуль прекращает выдавать байты сразу при деактивации сигнала rden:
Нажмите для просмотра прикрепленного файла

На картинке отчётливо видно, что когда сигнал rden (второй сверху) падает в ноль, никаких сигналов, что произошла выдача данных (сигнал dvalid_reg2 - это data_valid так квартус изуродовал) больше не происходит. Таким образом, реальное поведение модуля не соответствует документированному. Переделал логику формирования сигналов - rden держу всё время чтения, всё заработало как надо.

Собственно, вопрос следующий: это я что-то неправильно понял или реально косяк у альтеры? Настораживает то, что раз поведение отличается от документированного, то где гарантия, что при выходе следующей версии квартуса (сейчас это v12SP2) этот код не перестанет работать. Кто-нибудь сталкивался с подобным? Баг это или фича такая?

P.S. Попутно ещё спрошу. На этой версии столкнулся с неприятным поведением отдельных модулей - программатора и сигналтапа. Программатор в составе оболочки квартуса вообще не работает - запускаешь программатор - всё виснет. Сигналтап запускается с трудом (очень долго открывается) и при попытке подключить бластер тоже виснет. Запускаемые отдельно варианты того и другого работают сносно (за исключением того, что в stand-alone signaltap нельзя добавить сигналы - приходится сигналы добавлять в оболочке ква, а запускать на stand-alone варианте). Никто не сталкивался?

Стандартный вопрос 12.1 пробовали? возможно там уже исправили данные проблемы

Нет, не пробовал. 12.0 SP2 не так-то давно скачал и установил, не улыбается тянуть гигабайты без хоть какой-то обоснованной надежды, что там будет лучше. По опыту знаю, что когда выходит новая версия, не нужно спешить её ставить. Нужно дождаться хотя бы сервиспака. А лучше второго. Так и поступил - аж второй сервиспак стоит. Возможно, конечно, что это у меня на компе какие-то косяки (оба инструмента "завязаны" на USB-Blaster), поэтому и задал вопрос - это у всех подобное наблюдается или это исключительно особенности моего контекста.

Несколько в иной плоскости вопрос задам - почему выбрано направление загрузки SPI-FLASh > FPGA > CPU, а не SPI-FLASH > CPU > FPGA (passive serial)?
Последнее решение имеет меньше заморочек и, теоретически, более удобно для смены прошивки ПЛИС силами процессора, опять же, по причине меньшего числа заморочек и бОльшей развитости процессорной части системы по интерфейсам и т.п.

Законный вопрос. Действительно, организация загрузки процессором проще в реализации и гибче. Ответ, почему выбрано иное решение, заключается в том, что в устройстве предусмотено обновление фирмвари (и ПЛИС, и процессора), которая заливается через USB (High Speed, на Cypress FX2LP), а этот скоростной канал зацеплен на ПЛИС. Таким образом, ПЛИС является первичным устройством, которое стоит на пути потока данных.

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