|
Программирование MAX II, Раздельно CFM & UFM |
|
|
|
Aug 4 2009, 14:37
|

Частый гость
 
Группа: Свой
Сообщений: 81
Регистрация: 28-07-07
Из: Кишинев
Пользователь №: 29 434

|
Задача: Есть не меняемая конфигурация PLD MAX II и при этом в каждом изделии надо прошивать индивидуальные данные в User Flash Memory (UFM). Причем данные надо зашивать на этапе производства (тем же ByteBlaster), при эксплуатации доступа по записи быть не должно. В проекте UFM используется с параллельным доступом. По поиску не нашел ничего вразумительного. Вопросы: 1. Возможно ли? (по логике вроде да  ) и как? 2. Можно ли подготовить данные для UFM не используя Quartus?
|
|
|
|
|
Aug 4 2009, 16:38
|
Местный
  
Группа: Свой
Сообщений: 351
Регистрация: 17-09-05
Из: Москва
Пользователь №: 8 660

|
Ясного и простого решения менять значения в .pof для изменения содержимого UFM, кроме как перекомпиляция проекта, не видел. То, что в программаторе Quartus для готового .pof можно выбирать, что программировать - прошивку или UFM, думаю, знаете. Как мне кажется, в файле .pof часть, содержащая данные UFM, защищается общей контрольной суммой. Поэтому, несмотря на то, что само содержание UFM лежит там почти открытым текстом, вряд ли получится без перекомпиляции менять .pof и пользоваться программатором Quartus. А было бы удобно - через скрипты запускать изменение значения в файле инициализации памяти и потом программатор. Сам не пробовал, но идеи такие: Смотрите в сторону Jam STAPL (глава 14 документации на Max II). Вот на сайте Altera примеры исходников и программы. Там есть команды для отдельной прошивки UFM. Также можно сформировать при компиляции jam file (Assignments->Settings->Device->Device and Pin Options) и попробовать его "похачить". Но данные в нем сохраняются в сжатом виде. Если разобраться, как они "сжимают" данные ( вот здесь, например, описание стандарта, на сайте Altera не нашел) и сделать генерацию ID, то можно запускать его хоть из программатора Quartus. А насчет доступа по записи при эксплуатации - если не задействуете в проекте nwrite и nerase, то и доступ будет только по JTAG.
|
|
|
|
|
Aug 4 2009, 17:11
|
Знающий
   
Группа: Свой
Сообщений: 654
Регистрация: 24-01-07
Из: Воронеж
Пользователь №: 24 737

|
Цитата(Sergey'F @ Aug 4 2009, 20:38)  Если разобраться, как они "сжимают" данные ( вот здесь, например, описание стандарта, на сайте Altera не нашел) и сделать генерацию ID, то можно запускать его хоть из программатора Quartus. Вот там и есть описание алгоритма сжатия. Но он вообще не нужен. Это всего-лишь инициализация массива. Значительно проще объявить массив как HEX.
|
|
|
|
|
Aug 7 2009, 12:35
|

Лентяй
     
Группа: Свой
Сообщений: 2 203
Регистрация: 11-10-04
Из: Санкт-Петербург
Пользователь №: 843

|
Цитата(Шурила @ Aug 7 2009, 15:16)  Пока все одно мутно, буду разбираться. Мне представляется наиболее удобным следующий вариант. Вам нужно написать bat-файл, который будет запускать квартус как консольное приложение. В этом бате сперва нужно стартовать квартус c предварительно созданным tcl-скриптом (этот скрипт должен подключать к проекту новый hex-файл, в котором живет содержимое UFM очередного прибора) - что-то типа quartus_sh -t <имя_скриптового_файла>.tclПри этом выполнится перекомпиляция проекта с новым хексом. В результирующем pof'е содержимое CFM останется прежним, а содержимое UFM изменится. Затем в бат-файле надо стартовать квартусовский программер ( quartus_pgm.exe) с опциями прошивки CFM и UFM. Таким образом каждый раз будет получаться новый pof (с новым содержимым UFM), который и будет прошиваться в кристалл. И при этом не нужно будет мышковать по окнам квартуса
--------------------
Чтобы слова не расходились с делом, нужно молчать и ничего не делать...
|
|
|
|
|
Aug 8 2009, 03:28
|

Частый гость
 
Группа: Свой
Сообщений: 81
Регистрация: 28-07-07
Из: Кишинев
Пользователь №: 29 434

|
Цитата(Stewart Little @ Aug 7 2009, 15:35)  Мне представляется ... перекомпиляция проекта с новым хексом. Вот как раз от этого и хотелось уйти - во первых, передача исходников на производство черевата неприятными проблемами (в плане неумышленного и\или умышленного изменения исходников) - во вторых, просто утечка информации (нет это конечно не что-то сверх естественно гениальное, но ...) Более детальный поиск в нете не дал ответов, но подобный вопрос периодически возникает: Update Altera MAXII UFM post productionProgramming UFM with serialized numberPost production UFM updateПока ориентируюсь на jam
|
|
|
|
|
Aug 10 2009, 13:06
|

Лентяй
     
Группа: Свой
Сообщений: 2 203
Регистрация: 11-10-04
Из: Санкт-Петербург
Пользователь №: 843

|
Цитата(Шурила @ Aug 8 2009, 07:28)  Пока ориентируюсь на jam  Мне кажется, что Вы ищете решение проблемы не там. Проблема не в том, что нужно раздельно запрограммировать CFM и UFM (это-то делается штатными средствами), а в том, чтобы подготовить файлы отдельно для CFM и отдельно для UFM. Что должно жить в UFM? Серийный номер? Калибровочные коэффициенты? Или что-то еще, что может быть определено только в процессе производства? Если да, то можно поступить следующим образом. Передавайте на производство следующее : - pof-файл c Вашим проектом, - "служебный" проект, который состоит только из блока UFM, аналогичного тому, что находится в рабочем проекте (т.е. для того, чтобы сделать "служебный" проект нужно из рабочего проекта выкинуть все, кроме блока UFM). Кстати, здесь удобнее передавать не проект как таковой, а бат-файл с tcl-скриптом, коим скриптом этот проект формируется  . Процесс программирования проводится в два этапа : 1. В кристалл прошивается Ваш рабочий pof, с опцией "шить только CFM" 2. В консольном режиме запускается квартус, и компилирует "служебный" проект с новым hex-файлом (содержимым UFM) - получаете новый pof. 3. В кристалл прошиваете этот новый pof с опцией "шить только UFM". Несколько трансальпийский способ, но при этом у Вас и исходники не засвечиваются, и файлы CFM и UFM отдельно получаются.
--------------------
Чтобы слова не расходились с делом, нужно молчать и ничего не делать...
|
|
|
|
|
Aug 11 2009, 10:01
|
Гуру
     
Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881

|
Цитата(Stewart Little @ Aug 11 2009, 12:02)  Отмылил. Ну и вроде все понятно... Сам сделай SVF, найди там такую последовательность: SIR 10 TDI (203); RUNTEST 93 TCK; SDR 13 TDI (0001); SIR 10 TDI (2F4); RUNTEST 93 TCK; ну и сравни то, что идет после, с hex-файлом. hint: числа выглядят как FFxx, где xx - перевернутое побитно задом наперед число из hex. так что... на мой взгляд так - оставляем начало SVF-а вплоть до ERASE, методом тыка находя там то, что стирает именно UFM, там стирается три какие-то части. Далее коцаем все PROGRAMMING вплоть до указанных мной инструкций. ну и суем свои данные. ЗЫ готовое решение не выдам, так как методом тыка тыкать некуда.
|
|
|
|
|
Aug 11 2009, 18:23
|
Частый гость
 
Группа: Свой
Сообщений: 166
Регистрация: 2-11-08
Из: Ростов-на-Дону
Пользователь №: 41 331

|
Недавно решал обратную задачу - извлекал из pof данные, которые надо прошить в флешку (для удаленного апгрейда firmware). Оказалось очень просто - прошивка для флешки лежала открытым текстом в pof куском, начиная с N-ного байта и длинной M-байт. Кстати, от версии к версии квартуса первоначальное смещение меняется! Стоит поискать содержимое UFM в pof файле. Думаю найдете его с L-ного, нет, L мало, пусть будет K-й байт. Думаю, запихать обратно в pof данные для UFM труда не представляет. Правда, есть вероятность, что там есть контрольная сумма, или нечто подобное. Узнать это можно легко - поменять в файле один байт, если квартус его кушает, значит все нормально.
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|