Comments 24
Информация в журнале, бесспорно, интересная, но, пожалуйста, в следующих выпусках не ставьте фоном контрастную картинку позади текста. Даже если выкрутить яркость фона на максимум - визуально это все равно превращается в кашу с текстом
только если твой коммент наберет 10000 лайков
Уважаемый "Вождь FPGA комунити"!
То что вы думаете по поводу стиля общения со своими читателями - дело, безусловно, ваше.
Но все же когда к вам обращаются на Вы, тыкать незнакомому человеку не принято.
Добро пожаловать в интернет, человек без аватарки
Предводитель, Вы тут зачем публикуетесь? Привлекаете читателей?
Вы понимаете что ваши комментарии нанесли вреда намного больше, чем отсутствие статьи?
p.s. я раньше читал fpga-systems. Теперь, зная вождя, буду обходить стороной. Надеюсь, не я один.
мы потеряли ценнейший кадр, как теперь мы будем без комментатора
Эпичный случай как разогнать интересующихся.
Надеюсь сообщество понимает что из "вождь" неадекватен?
а тут обязательно надо сраться в комментах не обсуждая ни чего более предметного и полезного?
а я заказал пару журнальчиков:)
Ну так спросите это у себя.
Вы первый нахамили человеку, который хотел вам помочь сделать лучше.
Потом перешли на личности и обгавкали его.
Это не красит любого. А уж "вождя" уж тем более. Люди судят о вашем комьюнити по вашим словам. Большинство даже не напишет сюда, но будет иметь свое негативное мнение, даже не зайдя на рекламируемый вами телегра канал.
Вы первый нахамили человеку, который хотел вам помочь сделать лучше
Чем это интересно я ему нахамил? Замечание я прочитал, принял к сведению, но учитывать пожелания всех без какого либо критерия или голосования - это не возможно. Кому норм, кому нет, будет большинство за то што бы че та поменять, я поменяю какие вопросы.
Потом перешли на личности и обгавкали его.
Кого его? очередного ноунейма комментатора? Если бы я мог вернуться в прошлое и што то изменить, я бы сделал с этими "продуктивными" товарищами тоже самое
Люди судят о вашем комьюнити по вашим словам.
Штобы судить, сначала надо встать с толчка и перестать писать чушь в комментах.
И да, позовите еще своих друзей, я смотрю у вас там своя тусовка в красных рейтингах
"Это конечно не подвиг, но что-то героическое в этом есть!" (;
Михаил, спасибо за Ваш труд.
Мне не показалось - автор статьи про LDPC физически генерирует блоки circulant permutation matrix (CPM, которые он называет "циркулянтами") и потом буквально умножает на них входной вектор?
Если так, то фактически игнорируется главная фича LDPC, что умножение вектора на CPM (такого вида который используется в 5G LDPC, с одной единицей в каждой строке) эквивалентно простому циклическому сдвигу этого вектора на число бит, которое определяется положением единицы в первой строке CPM. Так что достаточно одну цифру на CPM хранить, которая этот сдвиг определяет (как это и сделано в стандарте 5G). И не надо тратить ресурсы на распаковку собственно CPM.
А сама операция сдвига вектора отлично ложится на pipeline (и структуру ПЛИС) и довольно дешёвая. Так что можно её делать без потерь пропускной способности на высокой частоте. В итоге кодер получается и компактный и производительный.
Если же автор делает какую-то другую версию LDPC, где используются CPM с больше чем одной единицей в строке (из статьи не до конца понятно, но по картинкам похоже), то делается то же самое но несколько раз на одно входное слово и результаты накапливаются через двоичный XOR. Это хотя и потребует больше одного такта на входное слово но куда лучше масштабируется, поскольку у CPM большего размера количество единиц в одной строке не меняется. А значит нужно будет то же количество тактов потратить, а рост ресурсов для сдвига более широкого вектора выражается как x*log2(x) а не x*x как в случае схемы из статьи.
P.S.Я в телеграм-каналы не хожу по определённым причинам. Но если кому-то не лень, киньте там в автора моим сообщением или ссылкой на сообщение.
Вам показалось, в статье вроде бы внятно написано, что умножение матриц в аппаратном виде вырождается в операции AND и XOR.
Что это за такая главная фича LDPC? Тот факт, что в 5G LDPC (про который я не писал ни слова) строки с одной единицей - это частный случай. В моем конкретном случае строки могут быть с любым количеством единиц и их надо хранить (вплоть до перегружаемых строк).
И дальше Вы описываете ровно то, что я делаю - несколько раз на одно входное слово и результаты накапливаются через XOR, прям как написано в статье. Про x*x и x*log2(x) я чет не понял. Для одного байта потребуется 1-байтный регистр сдвига, для 8 байт - 8-байтный. Это по какой функции рассчитывается?
в статье вроде бы внятно написано, что умножение матриц в аппаратном виде вырождается в операции AND и XOR
AND - это и есть умножение, двоичное.
Что это за такая главная фича LDPC?
Фича в том что матрица кодирования состоит из CPM, а умножение на CPM вырождается в чистый сдвиг.
Для одного байта потребуется 1-байтный регистр сдвига, для 8 байт - 8-байтный. Это по какой функции рассчитывается?
В своей реализации вы используете структуру из N слоёв, каждый шириной в N бит. А для логарифмического сдвига достаточно log2(N) слоёв mux-ов 2 в 1, каждый шириной в N бит. Эта разница не слишком большая когда N=8 (8 слоёв в вашей реализации против 3 слоёв логарифмического shifter-а), но если, скажем, N=64 то получается уже 64 слоя в вашей реализации против 6 слоёв логарифмического shifter-а.
Если у CPM несколько единиц в строке, то достаточно приложить тот же сдвиг несколько раз, потратив несколько тактов и накопив результат в XOR-аккумуляторе на выходе shifter-а. Для CPM 8х8-это может и не кажется оптимальным решением, но что насчёт CPM 64х64? Ведь единиц в строке будет существенно меньше чем нулей, поскольку в этом и идея Low-Density Parity-Check кода. А производительность можно догнать до нужной обрабатывая больше одного вектора за раз через несколько независимых shifter-ов/аккумуляторов.
Если в CPM 64x64 20 единиц в строке, надо 20 раз прогонять входной байт? Я правильно понял?
Да, всё так.
Только 20 единиц на строку в 64 бита - это уже совсем не low density. Я простой RTL-дизайнер, а не математик или специалист по кодированию, так что не могу уверенно утверждать что такой вариант не имеет практического смысла. Но в своей практике я такого не встречал.
В визуализации из вашей статьи что-то похожее на 4 единицы для строки в 32 бита, насколько я смог разглядеть на мелкой картинке. Что всё ещё достаточно разрежено чтобы сэкономить ресурсы используя shifter-ы.
В визуализации из моей статьи многое не отображено. Если в таком случае требуется 20 прогонов, то сразу вариант не вариант. И далее - получается что нужно хранить информацию о том, сколько единиц в строке и все позиции этих единиц. Это сколько памяти отожрется?
Про log2(N) я понял, мы про разные сдвиги говорили.
Конкретно я решал задачу в общем виде, под любую матрицу.
Ну значит я ошибочно решил что вы близкую к моей задачу решаете, для какого-то типового варианта LDPC, с сильно разреженной матрицей кодирования. Извините за недопонимание, если что.
Универсальный вариант понятно, что будет работать для любого случая, но за цену квадратичной зависимости ресурсов от размера CPM. Тут уже ваш выбор между универсальностью (которая может и не пригодиться) и стоимостью такого решения.
Еще вопрос. Если CPM размером 8х8, то циклический сдвиг - на 8 бит; для 16х16 - на 16 и так далее? То есть чтобы на лету можно было перестраивать размер, нужно реализовать в ПЛИС все варианты сдвигов?
Циклический сдвиг не обязательно реализовывать явно. Конечно, мы схемотехники привыкли представлять операции достаточно буквально и вариант с выбором отвода первым приходит в голову. Но он не единственный. Если у вас в пределах досягаемости есть программисты, спросите их, как бы они реализовали двоичный циклический сдвиг переменной ширины. Увы, я не могу вдаваться в подробности моей реализации, ибо NDA.
Конечно ничто не бесплатно и на такой перестраиваемый shifter нужно где-то в два с небольшим раза больше ресурсов по сравнению с фиксированным вариантом такой же (максимальной) ширины. Так что нужно считать выгодно всё это или нет исходя из максимального размера CPM и количество единиц в строке в вашей конкретной реализации. В моём случае диапазон размеров CPM был от 2х2 до 384х384 что более чем оправдывало подобную оптимизацию.
Отрицание, гнев, торг, депрессия, третий номер FPGA журнала