Задача:
Есть не меняемая конфигурация 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 ?
Или это из другой оперы?