Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Virtex 4FX (c PPC) сам себя загружает partial reconfiguration
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
yes
есть потрепность экономить память ПЗУ (и не ставить платформ флаш или CPLD/контроллер для загрузки), то есть хочется битстрим зиповать (gzip --best) и распаковывать в процессе загрузки,
большая флаш-ка используется PPCшкой для работы и подцепить ее еще и к какому-то внешнему микроконтроллеру без glue logic не получается, в V4 selectmap не генерит адреса, ну и сжать хочется посильнее, чем встроенная компресия

---------------------------------------

теоретически вижу такое решение (прошу его покритиковать):

генерится прошивка "пустышка" с PPC, ICAP, UART, портом к памяти и шинной заглушкой к логике (пока пустая), она зипуется, причем зипуется хорошо, я оцениваю: в 200к должна влезть. то есть, в память микроконтроллера влезет вместе с zlib-ой

эту прошивку микроконтроллер раззиповывает и загружает при старте в ПЛИС.

до этого в большую флашку, подключенную к ПЛИС, заливается программа PPC и партишиал битстрим (data) с логикой (он большой и зипуется плохо - 1МБ, не меньше, это я проверял). залить программу/битстрим можно либо сконфигурив ПЛИС по JTAG специальной прошивкой, либо добавить в прошивке "пустышке" UART и код загрузчика в BRAM

в "пустышке" стартует PPC раззиповывает и через ICAP загружает из большого партишиал битстрим логику, подключенную к шинной заглушке

после этого система работоспособна, PPC используется для вычислений

дополнительный бонус, что партишиал битстримов в большой флашке может быть несколько

-----------------------------

да, в задании есть доля маразма
заменить микроконтроллер или подцепить к нему большую флаш нельзя (то есть этот микроконтроллер уже есть в системе), использовать платформ флаш или какую-нибудь CPLD для загрузки виртекса с подключенной к нему флашки также нельзя (ну и битстрим с ксайлинской компресией на 1-1.5МБ больше чем зазипованый). даже использование V4 тоже маразм, но такие условия задачи


я с партишиал конфигурейшин не сталкивался, особенно для V4, вопрос: имеет ли право на жизнь такая схема, или я чего-то не учитываю?


krux
partial reconfiguration насколько я помню когда я его ковырял, поддерживал перегрузку только при разбиении чипа колонками. т.е. например 1/4 кристалла справа - конфиг #1, всё остальное слева - конфиг #2. при этом частоты для связи между кусками у меня выше 40 МГц получить не удалось, соответственно PLB, если её нужно пробрасывать в вашем случае, будет работать весьма и весьма небыстро.

имхо, забросьте программистские изыски, пока с железом ясно не станет
Flood
Ну, изрядная доля ограничений делает задачу только интереснее sm.gif
Другое дело, что чем старше кристалл, тем partial reconfiguration грубее. По логике, если не задействовать или задействовать с ограничениями ресурсы, используемые для загрузчика, то все должно получиться. По-моему, достаточно вдумчиво и подробно прочесть Configuration мануал на V4FX и соответствующие апноты, чтобы понять, насколько это реально, и что придется делать ручками, а что в состоянии учесть автомат при разводке основной прошивки.
yes
Цитата(krux @ Sep 25 2012, 20:48) *
имхо, забросьте программистские изыски, пока с железом ясно не станет


если я выберу такой вариант, то по другому железо уже не запрограммируешь
а если так нельзя, то нужно отказываться от этого задания

то есть пока не будет ясности с программированием, с железом тоже ничего не понятно



Цитата(Flood @ Sep 25 2012, 23:03) *
По-моему, достаточно вдумчиво и подробно прочесть Configuration мануал на V4FX и соответствующие апноты, чтобы понять, насколько это реально, и что придется делать ручками, а что в состоянии учесть автомат при разводке основной прошивки.


да, скорее придется этот проект сделать и посмотреть отчеты STA, как минимум.
но хотелось бы, какое-то экспертное мнение нахалявку sm.gif получить, прежде чем время тратить
litv
ethernet to jtag - http://www.byte-tools.com/index.php?main_page=xilinx
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.