ReAl 0 13 января, 2011 Опубликовано 13 января, 2011 · Жалоба Вход на упаковку. Минусами разбито на группы по восемь байт, как это нужно для байтов масок (в байтах масок каждому входному байту упаковщика (выходному байту распаковщика) соответствет один бит. FA AC 11 00 00 00 00 00 - 00 00 04 18 21 E7 00 00 - 00 00 00 00 00 00 00 00 - 22 00 44 55 00 00 00 00 - 00 00 00 01 Выход упаковщика. Байты масок показаны в двичном коде с префиксом 0b 0b11100000 0xFA 0xAC 0x11 0b00111100 0x04 0x18 0x21 0xE7 0b00000000 0b10110000 0x22 0x44 0x55 0b00010000 0x01 При своей потрясающей простоте метод очень хорошо жмёт прошивки. Кажется, лучше, чем встроенный в квартус пожиматель / встроенный в циклоны разжиматель. Там выше ужалось в 19 байт, тут в 16. Перед массивом для разжимателя нужно указывать общую длину, так как алгоритм округляет число байтов вверх до кратного восьми. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 14 января, 2011 Опубликовано 14 января, 2011 · Жалоба При своей потрясающей простоте метод очень хорошо жмёт прошивки. Перед массивом для разжимателя нужно указывать общую длину, так как алгоритм округляет число байтов вверх до кратного восьми. Спасибо. Да, просто и со вкусом. И, как мне на первый взгляд кажется, отсутствуют "недопустимые" коды, т.е., нет избыточности. Конечно, если потерять хотя бы один байт, весь остаток кода будет испорчен. Но в ПЛИС даже часть правильного кода не нужна. Надо взять на вооружение. Рояльти платить не требуется? :) И еще, по-моему, ничего страшного не произойдет, если послать в ПЛИС чуть больше кода. Лишние биты проигнорируются. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 14 января, 2011 Опубликовано 14 января, 2011 · Жалоба Рояльти платить не требуется? :)Это не ко мне, я сам на тех же правах :-) А его можно поискать в окрестностях "спринтер"-ов или как там те ZX-клоны с ACEX-ом называются. По крайней мере, в те времена от чем-от таким занимался, форт-сопроцессор делал куда-то туда. И еще, по-моему, ничего страшного не произойдет, если послать в ПЛИС чуть больше кода. Лишние биты проигнорируются.С FLEX8000/ACEX1K, кажется, я так и делал. Для FLEX8K вообще надо было послать несколько "лишних" байтов, точнее, обеспечить пару десятков тактов "для старта". Позже, вроде бы, софт сразу в прошивку несколько FF в конце стал добавлять. По идее, после получения прошивки микросхема всё остальное просто должна игнорировать. Но в каждом конкретном случае надо бы смотреть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
NullPointer 0 16 января, 2011 Опубликовано 16 января, 2011 · Жалоба void FPGA_sendpackedfile(uint_farptr_t buf, uint32_t buf_len) //... uint32_t L; //... L = - 1; while(L <= buf_len - 1) //... Ни разу не выполнится же ж. Сделайте signed. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 20 октября, 2015 Опубликовано 20 октября, 2015 · Жалоба Битстрим (альтеровский *.rpd) по медленному радиоканалу передается, и распаковывается мелким софт-процессором без лишней памяти. Поэтому задача - сжать получше (с распаковщиком попроще). Ориентир на степень сжатия - как zip. Может кто оценки привести, как рассмотренные в этой ветке, и какие-либо другие алгоритмы, сжимают битстрим по сравнению с zip, для разной степени заполненности кристалла? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться