Altera ASMI_PARALLEL megafunction, Доступ к данным, залитым в конфигурационную флешь Опции

[dxp]

Всем привет!

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

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

и к этому ещё текстом сопровождение:

After the second-to-last byte of data to be read appears on the dataout[7..0]
signal, and the data_valid signal is asserted, deassert the rden signal to indicate
the end of the read command. A new byte from the next address then appears on the
dataout[7..0] signal, and the data_valid signal is reasserted before the
megafunction stops processing. Only then does the megafunction deassert the busy
signal.

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

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


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

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

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

[EvgenyNik]

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