Задача:
Есть не меняемая конфигурация PLD MAX II и при этом в каждом изделии надо прошивать индивидуальные данные в User Flash Memory (UFM).
Причем данные надо зашивать на этапе производства (тем же ByteBlaster), при эксплуатации доступа по записи быть не должно.
В проекте UFM используется с параллельным доступом.

По поиску не нашел ничего вразумительного.

Вопросы:
1. Возможно ли? (по логике вроде да ) и как?
2. Можно ли подготовить данные для UFM не используя Quartus?

Ясного и простого решения менять значения в .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.

Вот там и есть описание алгоритма сжатия. Но он вообще не нужен. Это всего-лишь инициализация массива. Значительно проще объявить массив как HEX.

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

Мне представляется наиболее удобным следующий вариант.
Вам нужно написать bat-файл, который будет запускать квартус как консольное приложение. В этом бате сперва нужно стартовать квартус c предварительно созданным tcl-скриптом (этот скрипт должен подключать к проекту новый hex-файл, в котором живет содержимое UFM очередного прибора) - что-то типа quartus_sh -t <имя_скриптового_файла>.tcl
При этом выполнится перекомпиляция проекта с новым хексом. В результирующем pof'е содержимое CFM останется прежним, а содержимое UFM изменится.
Затем в бат-файле надо стартовать квартусовский программер (quartus_pgm.exe) с опциями прошивки CFM и UFM.

Таким образом каждый раз будет получаться новый pof (с новым содержимым UFM), который и будет прошиваться в кристалл.
И при этом не нужно будет мышковать по окнам квартуса

Вот как раз от этого и хотелось уйти
- во первых, передача исходников на производство черевата неприятными проблемами (в плане неумышленного и\или умышленного изменения исходников)
- во вторых, просто утечка информации (нет это конечно не что-то сверх естественно гениальное, но ...)
Более детальный поиск в нете не дал ответов, но подобный вопрос периодически возникает:
Update Altera MAXII UFM post production
Programming UFM with serialized number
Post production UFM update

Пока ориентируюсь на jam

Мне кажется, что Вы ищете решение проблемы не там.
Проблема не в том, что нужно раздельно запрограммировать CFM и UFM (это-то делается штатными средствами), а в том, чтобы подготовить файлы отдельно для CFM и отдельно для UFM.
Что должно жить в UFM? Серийный номер? Калибровочные коэффициенты? Или что-то еще, что может быть определено только в процессе производства?
Если да, то можно поступить следующим образом. Передавайте на производство следующее :
- pof-файл c Вашим проектом,
- "служебный" проект, который состоит только из блока UFM, аналогичного тому, что находится в рабочем проекте (т.е. для того, чтобы сделать "служебный" проект нужно из рабочего проекта выкинуть все, кроме блока UFM). Кстати, здесь удобнее передавать не проект как таковой, а бат-файл с tcl-скриптом, коим скриптом этот проект формируется .
Процесс программирования проводится в два этапа :
1. В кристалл прошивается Ваш рабочий pof, с опцией "шить только CFM"
2. В консольном режиме запускается квартус, и компилирует "служебный" проект с новым hex-файлом (содержимым UFM) - получаете новый pof.
3. В кристалл прошиваете этот новый pof с опцией "шить только UFM".

Несколько трансальпийский способ, но при этом у Вас и исходники не засвечиваются, и файлы CFM и UFM отдельно получаются.

Попробуйте сделать проще. Собрать проект с зашиванием в UFM чего-нить характерного, потом сваять SVF-файло, и глянуть на него в текстовом редакторе. Скорее всего все сразу будет понятно и прозрачно. Потом зная все это - либо сделать конвертер bin->SVF, или bin->JAM.

Ох, терзают меня смутные сомнения, что будет все совсем не просто и прозрачно...

Дай мне такой проект, где есть запись в UFM, и я постараюсь все опрозрачнить и сделать готовое решение.

Отмылил.

Ну и вроде все понятно... Сам сделай 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 вплоть до указанных мной инструкций. ну и суем свои данные.

ЗЫ готовое решение не выдам, так как методом тыка тыкать некуда.

Будем пробовать.

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

Добрый вечер.

Скажите, почему нельзя использовать другие форматы, например, RBF ?
Или это из другой оперы?

Может и можно, если есть инструмент для прошивания формата RBF в UFM. Подскажите, при помощи чего это можно сделать?

Нда. Закрыл ISE, добыл из заначки quartus, покрутил, а он и не желает делать ничего кроме pof-файлов.

Нет, все он делает.
Assignments->Device->Device and Pin Options->Programming Files
Для более сложных случаев
File->Convert Programming Files


Проблема не в том. Если посмотреть pof - да, там идет содержание UFM открытым текстом. Но после него следуют байты, которые меняются при изменении значений в UFM. У меня нет платы на MaxII, но это наводит на некоторые размышления.

Конечно, проще всего сделать как предлагает Stewart Little, учитывая, что время компиляции для MaxII не так уж и велико. Следующие по простоте - "разжать" JAM или, как предлагает SM, разобрать SVF. В JAM прошивка UFM хранится в отдельном массиве, осталось только "разжать" ее.

А я вот второй год с ISE не могу подружиться. При малейшей обоснованной возможности делаю прототип в Quartus, а потом переношу в ISE.

Добавление:

сделал mif файл со следующим содержимым (256 слов по 16 бит, сначала 0,1,2,и т.д., в конце немного поиграл значениями):

Нажмите для просмотра прикрепленного файла

В результате в SVF видим вот что:

Нажмите для просмотра прикрепленного файла

То есть, данные в каждом 16-ти разрядном слове просто "развернуты" (00FD -> BF00 и т.д.).

А вот начало массива данных UFM в JAM:

Данные оказались "несжимаемы", видимо.

Ага, попробую.

У меня есть еще разных идей

1) поменять логику микросхемы так, чтобы прошивать нужно было всегда одинаковый файл, но после конфигурирования можно было б один раз поменять ID. Или не один раз, но не все будут про это знать и иметь необходимое оборудование. Если не лень и есть место, конечно. Может оказаться, что ковыряться в POF файлах выйдет дольше.
Я не удосужился еще посмотреть в документации, как там у MAX-а JTAG убивается, но чтобы потом нельзя было сменить содержимое USER FLASH, вы что собираетесь делать?

2) нагенерить сколько нужно файлов для производства.

Интересное наблюдение. Я же игрался с 8-битным hex-файлом, и данные были в том формате, как я рассказывал. Т.е. FFxx где xx развернутый байт. Т.е. в 8-битном режиме используют младшие 8 бит, но при этом их тоже "крутят".

Метание этих дней, пробы разных вариантов, склонили меня в пользу подхода Stewart Little.
Сейчас в связи с отпусками участниками команды, комплексно проверить не могу. Но как только, дам знать.

Нет, JTAG убивать - не стоит задача (у MAX-а JTAG выделенные пины и не меняют своего назначения как в 3000).
- 2) где-то так. Вот только pof или hex будем определятся.

Кстати - ieee-1532 bsdl-ки по max-ii там - ftp://ftp.altera.com/outgoing/download/kdb/bsdl_files.zip - там можно узнать коды и форматы инструкций программирования. Правда про security bit молчат.

А для UFM в MAX II его и не существует.

ну для CFM-то существует? Но все равно инструкции ISC_PROGRAM_SECURITY не описано.