Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Выложил документацию на эмулятор ПЗУ до хх040
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
NeoN
Удобно использовать для девайсов на ПЛИС, у которых конфигурацию процессор грузит из своей памяти. Т.е. связка ПЛИС + х51 + хх040 позволяет грузить до 4Мбит конфигурации и сама еще работает smile.gif
страница проекта
zltigo
Цитата(NeoN @ Jan 12 2008, 20:45) *
Т.е. связка ПЛИС + х51 + хх040 позволяет грузить до 4Мбит конфигурации и сама еще работает smile.gif

Контроллеры для загрузки FPGA действительно удобно использовать, но из собственной набортной или
сериальной FLASH. При отдадке - через JTAG в цепочке с контроллером, ну или через внешний интерфес контроллера. Но уж не через эмулятор flash в DIP корпусе подключенному как внешняя память к контроллеру с недостаточными ресурсами. 21 век на дворе.
NeoN
Объясняю. Указанный в топике вариант _оптимален_ для выполнения следующих требований: возможность самостоятельной замены прошивки заказчиком при сохранении защищенности от копирования. Часть прошивки при этом лежит во встроенном флеше контроллера, который (о, ужас!), то же в DIP корпусе. Второй момент, сподвигнувший меня на данную разработку, необходимость отлаживать систему из 3..4 одинаковых устройств одновременно.
В прочем, как говорят, не нравиться - не ешь...
zltigo
Цитата
В прочем, как говорят, не нравиться - не ешь...

Естественно smile.gif. Если Вы думаете, что я почему-то буду кого-то агитировать за неиспользование данного девайса, то это не так - просто изложил свое видение проблемы и используемые мной решения.
Цитата(NeoN @ Jan 13 2008, 11:29) *
возможность самостоятельной замены прошивки заказчиком при сохранении защищенности от копирования

Аналогичное требование выполняются в любом варианте построения системы, где присутствует прошиваемый производителем бутовый загрузчик загружающий в последствии шифрованные образы. При этом, если далее речь идет о загрузке в FPGA, то она естесвенно может быть перехвачена на этапе загрузки в FPGA (если в FPGA нет собственной поддержки шифрования) при любом построении системы.
NeoN
Цитата(zltigo @ Jan 13 2008, 12:50) *
При этом, если далее речь идет о загрузке в FPGA, то она естесвенно может быть перехвачена на этапе загрузки в FPGA (если в FPGA нет собственной поддержки шифрования) при любом построении системы.


Защищенность в данном случае обеспечивает обмен ПЛИС с защищенным процессором, выбор ПЛИС с шифрованием, увы, не велик.
В прочем, это совсем другая тема, разросшаяся уже в отдельную огромную ветку.
dvladim
Цитата(NeoN @ Jan 13 2008, 13:52) *
Защищенность в данном случае обеспечивает обмен ПЛИС с защищенным процессором, выбор ПЛИС с шифрованием, увы, не велик.

Защищенность от чего? Если от снятия конфигурации ПЛИС, то не обеспечивает.
Если ПЛИС без шифрования, то канал загрузки ПЛИС всегда можно прослушать.
NeoN
Цитата(den_realan @ Jan 13 2008, 18:00) *
Защищенность от чего? Если от снятия конфигурации ПЛИС, то не обеспечивает.
Если ПЛИС без шифрования, то канал загрузки ПЛИС всегда можно прослушать.

Защищенность всей системы от копирования.

ПЛИС постоянно запрашивает у контроллера хэш от ПСП, если результат не совпадает - вырубается.

P.S. Насчет прогресса в средствах отладки и т.д.
Я не любитель MCS51 и практически - ненавистник интела, как разработчика архитектур.
Но есть ряд разработок, исторически построенных на 51-х, которые бессмысленно переводить на более прогрессивные контроллеры с ISP. Совокупность наработанного программного обеспечения и тупой, но очень предсказуемой архитектуры 51-х заставляет отказаться от перехода на новый контроллер.
Собственно в этой ситуации, эмулятор и был сделан. Был бы готовый - купили бы не раздумывая, время дороже wink.gif
И конечно, все это никак не отменяет загрузки ПЛИС через JTAG, загрузки XCF через JTAG или использования IAP-контроллера, что и используется в других наших разработках smile.gif


P.P.S. А кто мою тему в 51-х грохнул? Там она ИМХО была уместней...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.