WebPack 5 и 6 генерируют .bit файл разного размера, для одного и того проекта и девайса Опции

[sat]

Xilinx - для одного и того же проекта WebPack6 и WebPack5 генерируют .bit файл разного размера. Девайс одинаковый. Размер вроде бы должен быть тогда тоже одинаковым. Или я не прав?
Конкретно девайс VirtexII xc2v250-4fg256
Размер .bit файла на диске
WebPack 6 : 215 935 байт
WebPack 5 : 199 279 байт

[alex_k]

Возможно в разных версиях используются разные алгоритмы трассировки, оптимизации, еще чего-то - из этого разные размеры, а чем собственно проблема, ну разные ...

[sat]

Возможно в разных версиях используются разные алгоритмы трассировки, оптимизации, еще чего-то - из этого разные размеры, а чем собственно проблема, ну разные ...

Была проблема с доработкой старого прибора, связанная с различием в размере файла. Интересно, все же почему размеры отличаются, девайс один и тот же, т.е размер памяти конфигурации не меняется?

[alex_k]

Чесно говоря не знаю что и сказать, единственное может проверить в опциях Generate Programming File. Они соответствуют уставкам между версиями WebPack. Вдруг у тебя в одной из версий включена упаковка битстрима "Enable BitStream Compression"

[Andrey Filippov]

Чесно говоря не знаю что и сказать, единственное может проверить в опциях Generate Programming File. Они соответствуют уставкам между версиями WebPack. Вдруг у тебя в одной из версий включена упаковка битстрима "Enable BitStream Compression"

Можно сравнить файлы *.bin (я их позже нашел), *.bit содержит еще заголовок, который мне приходилось выбрасывать, находя собственно данные по маркеру:
const unsigned char sync[]={0xff,0xff,0xff,0xff,0xaa,0x99,0x55,0x66};
Наверное, в заголовке и разница - вот пример начала файла x333.bit - там есть имя файла, дата, тип микросхемы,...:

Код

00000000  00 09 0f f0 0f f0 0f f0  0f f0 00 00 01 61 00 09  |.............a..|
00000010  78 33 33 33 2e 6e 63 64  00 62 00 0c 33 73 31 30  |x333.ncd.b..3s10|
00000020  30 30 66 74 32 35 36 00  63 00 0b 32 30 30 35 2f  |00ft256.c..2005/|
00000030  30 33 2f 31 30 00 64 00  09 31 38 3a 32 34 3a 30  |03/10.d..18:24:0|
00000040  35 00 65 00 06 25 f8 ff  ff ff ff aa 99 55 66 30  |5.e..%.......Uf0|
...

[sat]

Спасибо за ответ. Буду разбираться.

[Vitёk]

Не обязательно искать последовательность 0xff,0xff,0xff,0xff,0xaa,0x99,0x55,0x66 - она разная для разных типов устройств. Заголовок является стандартным для всех типов микросхем, и для нахождения, где он заканчивается, можно использовать следующее:

Код

int SeekLcaBegin(void *xbuff, int maxsize){

// Поиск начала конфигурационной информации в файлах типа '.bit'
// созданных пакетом XACT.
// Возврат:
// -1 = начало не найдено
// все остальное - смещение конфига от начала 'buff'

 int beg = 13;
 char *buff = (char*)xbuff;
 while(buff[beg] != 0x65){

   if(beg >= maxsize) return -1; // out of range
   if((buff[beg] & 0xf0) != 0x60) return -1; //
   beg += 3 + (unsigned char)buff[beg+2];
 }
 return beg+5;
}

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

[andrew_b]

Если мешает заголовок, то почему бы вместо .bit не использовать .bin?

[Vitёk]

Специально поискал файлы *.bin в папках проектов - не нашёл. Пректы правда из под Xilinx Foundation 4.1, но тем не менее...

[sat]

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

Вот проблема в этом и была, что загружал не полностью. Теперь буду знать.

Специально поискал файлы *.bin в папках проектов - не нашёл. Пректы правда из под Xilinx Foundation 4.1, но тем не менее...

Генерация .bin файлов по умолчанию отключена. Включается в свойствах Generate Programming Files-General Options - Create Binary Configuration File