Программирование MAX II, Раздельно CFM & UFM Опции

[Шурила]

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

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

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

[dvladim]

Если разобраться, как они "сжимают" данные (вот здесь, например, описание стандарта, на сайте Altera не нашел) и сделать генерацию ID, то можно запускать его хоть из программатора Quartus.

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

[Шурила]

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

[Stewart Little]

Пока все одно мутно, буду разбираться.

Мне представляется наиболее удобным следующий вариант.
Вам нужно написать 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

[Stewart Little]

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

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

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