Всем доброго времени суток,
необходимо оценить время за которое будет конфигурироваться virtex-6 через blackfin в Serial Slave моде, насколько отличается размер hex файла от bit файла (размер bit-файла я нашел в UG360), и собственно как его получить из bit-файла. в одном из доков нашел, что его можно получить скриптом на Perl'е, который я так и не нашел (может все-таки через impact это можно сделать?) или если разница в размере несущественна обойтись bit-файлом? (различия в процессе конфигурирования процессором есть для bit и hex?)
Спасибо.

В ПЛИС загружается битовая последовательность, имеющая документированный размер. hex (mcs) - промежуточный формат (ASCII), его нельзя загрузить в ПЛИС без преобразования в бинарный, поэтому вопрос не имеет смысла. При загрузке ПЛИС из процессора используется чистая битовая последовательность (bin). Если ножек хватает, лучше грузить через SelectMAP, выдавай байт или более за 1 такт. Slave Serial из процессора - очень спорное решение.

Судя по нагуглённому тута, от бит-файла нужно только отрезать небольщой заголовочек (увы, переменной длины) и останется двоичный файл, который нужно затолкать в FPGA через SPI.

Если линковать к программе массив байтов, то не важно, получен он из бинарного файла или пришиванием HEX-а. Размер будет одинаков.

Кстати, у альтеровского квартуса в Device Options / Programming Files есть куча птичек, включая генерацию .rbf (raw binary file), .hex, .ttf (текстовый файл с числами через запятую), т.е. нет проблем получить что-то, из чего легко делается массив в программе. Должно же и у xilinx что-то такое быть прямо в родном софте.

Если мне не изменяет память, у Xilinx генерируется сразу же по умолчанию, .bin, а также его аналог в текстовом формате. Заголовок bit файла то ли документирован, то ли частично документирован. В любом случае, можно и из .bit вынуть чистый битстрим. Правда, у Xilinx есть такое понятие как bitswap, часть файлов генерится так, часть иначе. Но все описано в Configuraion Guide.

Разработчики платы из другой фирмы решили что нам хватит slave serial. насчет длины понял.


Да в ISE есть эти галочки все кроме hex


Да все генерится (кроме hex), и про битсвап тоже читал (уже правда не помню для чего это делается, просто думал есть простая процедура как получить чистый hex без заморочек.

А что такое hex, в таком случае? В смысле, зачем он нужен и какой именно формат hex-а имеется ввиду?

http://www.xilinx.com/support/documentatio...uides/ug360.pdf
page 87

HEX
Determined
by User
PROMGen or
iMPACT
ASCII PROM file format containing only configuration data.
Used mainly in custom configuration solutions.

bin -> srecord -> hex
Правилом в makefile с полной автоматикой при подбрасывании нового bin

Я все-таки никак не пойму, зачем нужен hex?
Вы собираетесь конфигурировать ПЛИС из процессора. Хорошо, а где будет хранится битстрим? Встроен в программу процессора, файл в файловой системе, область в ПЗУ? Я что-то не могу придумать ни одного случая, где потребовался бы именно hex (ASCII PROM file format!).
"Сложный" hex (в смысле, Intel Hex или Motorola S-record) часто используется при программировании ПЗУшек, что обусловлено тяжелым прошлым большого числа программаторов, малым объемом таких ПЗУшек, а также во многих (но не в этом) случаях - возможностью произвольной адресации. Простой hex (1234abcd) вобще не ясно, зачем может пригодиться. Вот, к примеру, хранить прошивку ПЛИС в любом hex-формате в файловой системе встроенного процессора - действие, близкое к безумию. Конечно, когда файловая система 4ГБайт, уже не так важно, 8МБ или 4МБ занимает файл прошивка ПЛИС, но все равно как-то неприятно.

может быть я неправильно выражаюсь) нужно из процессора (blackfin) конфигурировать плис, у процессора есть флешка (m25p64) в ней собираемся хранить прошивку ( видимо ее можно еще сжать неплохо) но вот где мне взять эту битовую последовательность, которую надо писать в плис чтобы ее сконфигурить ( у меня есть bit, bin, rbf) как из них получить эту необходимую битовую последовательность?

и действительно ли эта программа генерит нужную мне битовую последовательность?

Один из способов пришить двоичные данные к прошивке процессора -- приклеить HEX со сдвигом адресов.
Если снаружи висит последовательная флешка — её программатор тоже может hex брать.
Так что само по себе желание иметь hex не удивляет.

Ну если есть raw binary file (bin/rbf/... как там он у xilinx называется), то вот она битовая последовательность, нужно только знать -- старшим или младшим битом вперёд её нужно выдвигать в последовательный порт.

Битовую последовательность генерит FPGA-шный инструментарий. Эта програма может только преобразовать её из bin или hex представления в другое, которое нужно.

Чистый битстрим находится в файле .bin. Фактически это тот же .bit, только без заголовка. Его (bin) и нужно сжимать и записывать в ПЗУ, а потом разжимать и побитно (раз это Slave Serial) отправлять в ПЛИС. На этапе отладки загрузчика сжатие лучше не применять.
rbf - это что-то из мира Альтеры

Огромное спасибо!!! теперь понял!!!

Я делал так : специально для случая прилинковки битстрима к разным встроенным процессорам написал простенькую конвертайку *.bin(или *.bit) -> С-style const array. На выходе получается что-то типа :


Такой файлик легко прилинковывается к любому проекту, написанному на C. Если есть интерес - могу выложить сорцы конвертайки.

З Ы Да, было бы вполне логично натравить на этот массив какой-нибудь алгоритм сжатия, но у меня до этого руки не дошли...

Насчет C-array - в принципе, в
#define bitstream_length = ....;
нет необходимости, т.к. есть sizeof bitstream.

Не прокатит, т.к. массив в отдельном файле, а sizeof - это директива компилятора, а не линковщика.
Ну либо лепить в один файл с кодом, который к этому массиву обращается, что по моему ИМХО не есть гуд стайл...

Если это .h файл, подключаемый через #include, то sizeof прокатит. Как правило, это наиболее распространенный вариант, т.к. bitstream в глобальных символах обычно не нужен (объявляется как static). Хотя в хранении битстрима в .c тоже есть смысл, чтобы не перекомпилировать загрузчик при изменении битстрима. Дело вкуса.
Если .c:


В том смысле, что конвертеру специально вычислять и заполнять поле bitstream_size не нужно.

Да, конечно интерес есть! буду премного благодарен)
а сжимать его 100% надо, если проект небольшой то файл сжимается в десятки раз)

В C-шный массив можно конвертнуть тем же srecord, на который я уже давал линк. У самого были самописные приблуды bin2c, которые кочевали из одной операционки в другую с конца 80-ых, но всё забросил в пользу srecord или objcopy

Тут обсуждалось сжатие потока

Держите сорцы. Сделано это было ооочень давно, поэтому не факт что всё сразу заработает.
Про сжатие - сжимать-то надо конечно, но вот место под битстрим следует резервировать с запасом (худший случай = нежатый стрим).