Есть Плис семейства spartan 6 от Xilinx. Есть файл конфигурации расширения .mcs и сопутствующие ему.

Есть ПО, которое может, загрузить в конфигурационную флаш память прошивку для ПЛИС (каким образом не важно, важно что мы имеет доступ через ПО к флаш). Цель: обновлять прошивку используя данный софт, используя конфигурационный файл.
Покопался в файле .mcs, осознал структуру (используется intel hex) и нашел в них ту часть файла, в которой хранится данные.

Теперь вопрос, как это "ложиться" в flash? Просто подряд, последовательно считываю и записываю во флаш или есть хитрые алгоритмы(к примеру, перемежение)?
Т.е. как этот файл записать во флаш? по какому алгоритму?



Так как еще читал, что изначальный поток данных зеркалится (свапинг ), прежде чем образуется .mcs

А почему именно формат .mcs? Гораздо проще и в двое компактнее заказать при имплементации конфигурационный файл в формате .bin. Что же касается формата размещения во FLASH, все зависит от тех программых средств с которыми Вы будете с ним работать, самый правильный и вместе с тем самый сложный организовать на FLASHке файловую систему.

Скажем так, задание такое.
В принципе можно использовать и другие форматы....главное осознать структуру файла и как это во флаш загнать .

Файловая система не вариант. Есть работающее устройство, просто необходимо обновлять прошивку/конфигурацию ПЛИС. Используется собственноручное написанное ПО, которое может "общаться " с флаш.

Вот так вот. Файл бин просто не разбирал, попался только mcs, поэтому сел за него.


Я просто понял, что фалй mcs он уже как-то подготовлен специально для записи в память...

go2winner
Файл в формате bin записываете во flash как массив байт.
Потом последовательно (или параллельно) загружаете.
Это всё, что требуется.

А сам формат файл bin представляет собой последовательность данных информационных , без контрольных сумм и другой служебной информации?

В любом случае буду теперь в этом направлении смотреть...

На всякий. Вот я точно видел файл формата bit, из него, как я понимаю, получают mcs

А где файл формата бин? или Как я понимаю они идентичны с bit?

Запись во флаш получается последовательная без всяких хитростей?

Еще вопрос...как флаш подготовить? получается я ее предварительно стираю и на чистую записываю файл конфигурации..?


Спасибо за быстрые ответы)

А для чего тогда в файле mcs происходит зеркаливание битов? Если записать во флаш нужно в прямом порядке?

В настройках генерации выходного файла поставьте галочку делать bin файл - это просто последовательность байт которую надо положить во флэш
bit файл что делается по умолчанию это тоже самое с дурным заголовком.
mcs файл - это hex формат bin файла, для 1 битной SPI флэшки там прям один в один bin файл с добавленным адресом и контрольными суммами по строкам.

свап и реверс нужен для параллельных флэшек, это связано с механизмом работы автомата загрузки.

Самая главная беда это то что Spartan6 записывает память через програмvный ногодрыг организованный JTAG, потому это дико медленно и надо еще прошивку вертеть.

Запись в SPI флэш надо прочитать в инструкции к флэше, некоторые из них имеют функцию автоматического стирания страницы перед записью, некоторые надо стирать изначально. Завист от вашей флешки

Спасибо, вы очень ясно ответили.
Вчера как раз разобрался самостоятельно изучив служебные файлы, которые генератор создает вместе с конфигурационным.
по крайней мере вопросов по структуре файлов, выбор формата выходного файла и т.п. у меня нету уже.

За свап спасибо, потому что я догадывался , что это опция нужна для параллельных, но пока не видел подтверждения

Моя флеш имеет функцию чип ераз, которая как раз пригодится, я так думаю.
Тему не закрою, т.к. если вопросы будут(а они будут скорее всего), сразу сюда буду задавать, чтобы не создавать "пустые топики".

ug380.pdf - там можете почитать, там есть и про свап и про ICAP и прочие интерфейсы, это если прям хочется%)




не всегда лучшее решение, к примеру стирать флешку 64 МБит - это не менее 3 секунд, иногда постранично стереть нужную область быстрее. Потом если у вас есть обновлялка прошивки, почему бы не сделать мультибут систему с golden имеджем который будет не затираемым? Тут опять стирать все - это не верно. Опять же во флэшку можно положить настройки, зачем им страдать при обновлении прошивки... ну и так далее...

Я обычно всегда стираю под конкретную область, которую надо записать, даже если приложение одно во флешке, мало ли что будет в будущем.

У меня два вопроса
1) открываю Prom file formatter, выбираю spi flash->single FPGA->выбираю размер->но нет сохранить в формате bin....только mcs,ufp,exo
Бинарного формата нету
Размер flash 64
2) Вот кто-то создал другую прошивку для Плис. Разве прежде чем "залить" ее на флаш не нужно ли предварительно стереть ее полностью? Если не полностью, как Плис узнает, где окончание прошивки?




Если вы про какие-то настройки, которые вообще используются(к примеру, некие коэффициенты), то для них есть своя память


Сяду дальше изучать данный вопрос пока что..гайд почитаю за одно

насчет мультибут и т.п. поизучаю...реализовать пока не смогу т.к. видно, что мои знания несколько скудны

Не то открываете. Бинарный формат это не 'Prom file', это то, что делается непосредственно из результатов разводки FPGA. И скорее всего (если у вас стандартный flow в ISE или Vivado) он уже сгенерирован.

В самой прошивке записано.

"
File Format: PROM files can be generated in any number of industry standard formats. Depending on the PROM file format your PROM programmer uses, you output a MCS, HEX, UFP, ISC or BIN file. MCS is the most popular. ISC is used when targeting programming flows that utilize IEEE Std 1532. Third Party socket-based programmers usually accept any of the listed formats. If you are using a microprocessor to configure your devices, you output a HEX, UFP, or BIN file."

Это гласит, что такая возможность в prom есть...
Файла бин нашел total commander, в папке проект..xst/work
Но он не совпадает по содержанию с mcs.поэтому я в недоумении

Это не тот bin. Тот bin который надо служит входным файлом для Prom formatter'а (или bit - сейчас точно не скажу)
Это оно
Ну у них форматы разные (хотя содержание отчасти и одинаковое), так что не мудрено

bin, как и bit, получается на выходе bitgen. Ищите настройку там.

bin файл заказываете на в промформаторе, а как Вам сказал Golikov A.: "В настройках генерации выходного файла поставьте галочку делать bin файл" (то есть там, где Вы делаете имплементацию - в ISE)

Выставил найстройку на create binary configuration file.....

Но теперь я потерял идею...
Если mcs получается из bin/bit, тогда куски какие-то должны быть равными(без учета контрольных сумм и адресов)...у меня не очень сходиться

Как тогда получаем mcs файл из бит/бин по какому алгоритму?


В описании (гайд) все ясно написано Bin-"Binary configuration data file with no header information" и mcs-адрес+конфигурация+сумма
Значит же должны совпадать? mcs bin?
но чем же mcs еще отличается...в идеале я должен же явно куски из бин находить в mcs?
Чтобывечно не редактировать сяду хорошенько дочитаю денек другой...как я понял mcs включает загаловок bit и синхрослова оттуда.
SYNC WORD и тому подобное не нужная(в моем случае) служебная информация?
ЗАчем она нужна тогда?

))
mcs - ASCII файл


еще раз
bit - что делается по умолчанию там бинарный формат данных, и заголовок - этот файл родной для ксалинкса он помогает промгену сделать файл для заливки через impact

в настройках выходного файла можно включить bin - это чисто бинарь, только сама прошивка, отличается от bit отсутствием ксалинксовского заголовка. Тут важно понять что это не загрузочный заголовок, не для плис, а для программ на РС.

если вы посмотрите каким-то hex редактор типа winhex вы найдете общие куски в bit и bin, то есть в bit лежит прям bin и еще какая-то дрянь в начале.


Так далее вы берете пром ген и скармливаете ему bit файл и он делает mcs файл - это файл в формате intel hex, это ASCII формат то есть если у вас в бинаре лежит 0x16, то тут будет 2 аски символа 16, к этому добавляется адрес, команда, тип пакета, контрольная сумма. Время от времени смещение сегмента, почитайте в википедии про этот формат, он очень понятный.

То есть чтобы найти куски bin в mcs вам надо bin смотреть hex редактором, а mcs обычным текстовым.

Этот файл нужен исключительно для impact, потому что он в таком виде принимает данные для записи и по другому не хочет. Почему так - хрен знает, формат на самом деле излишне большой и анализировать его не удобно...


если же смотреть на bin в hex редакторе, то вы найдете и все синхро слова, АА665599, и команды записей general1,2,3,4 и настроечные режимы, и прочее прочее прочее. Для мультибута вы найдете там заголовок и так далее....

Огромное спасибо за ответ""!!

В целом я так и знал и делал.
Прочитал про intel hex до того, как открыл топик.
Просто не понятно,в бин файле последний адрес 1ff80
В mcs 16A670
В бит файле последний адрес 1fff0
Бит и бин по-правде практически целиком идентичны(заголовок только исключение)

Вот и интересно, что еще такого mcs приписывает?(ведь там информация плюс адреса и кнотрольня сумма..)

ну адресация в интел хексе, та что в начале строки данных она 16 битная, потому добавляются еще команды выбора страницы
команда 04 кажется, строки начинаются обычно с :02
если у вас больше 65 кбайт прошивка, можете помотать файл и вы увидите там между блоками вставлены более короткие строчки

далее последняя строка тоже короткая типа 00000001FF - это уже не адрес а признак конца файла

еще добавляются длины данных в строке, номера команд и прочее...


и да это не адрес адреса там 16 битные%)

ну я же не совсем бум-бум))
Я не количество строк смотрел а именно смотрел адреса (а адреса даются информационный байтам)...адрес больше-> информационный байтов больше
(сумма и служебные команды не учитываются адресом, учитываются только 16 байтов информационных в строке)
(Если bin содердит только информационные байты, а mcs формируется из bit, то они тоже не сильно должны отличаться количество информационных символов(не считая служебные mcs))


Это почти конечный адрес(я скопировал просто адрес строки...а полностью конечный адрес 16A673, так же в лог файле фигурирует).....он расширен путем команды расширения адреса, которое расширяет стандартное 16 битное адресование до 32 битного(вводя команды расширения , к примеру, :02000004000BEF).
Расширяется путем добавления команды расширения и можно свести к 32 адресованию xx:xxxx (вроде Вы и имеете это в виду)




Вот и логичный вопрос.....откуда лишние информационные байты(т.к. адрессом учитываются только информационные байты, а количество байтов к.сумма и т.п. не учитывается)?
При этом пока не натыкался на объяснения..

ох....
я чего-то не понимаю. Я взял bit файл, сделал из него mcs файл, и вижу в нем тупо этот файл без заголовка...

в конце бит файла 00053390: 0x20 0x00 0x20 0x00
в mcs
:020000040005F5 - то есть задать адрес на 50000
и в конце
:0433900020002000F9
то есть по даресу 3390 записать 20 00 20 00, в итоге с начальным смещением, полный адрес 53390 и по этому адресу 20 00 20 00

Вот и логичный вопрос, о чем вы говорите?

Может вы делаете не обычный MCS файл, а еще с какими то данными или несколькими ревизиями или для какой-то хитрой флешки которая требует чего-то еще...

нашел свою ошибку....он файл mcs не перезаписал..сравнивал со старым, поэтому не сходилось...тема закрыта пока что)

ОГРОМНОЕ СПАСИБО!!