des00

поэтому я вам сразу и сказал: откладываем все корки, берем теорию, ручку, тетрадь, разбираемся в алгоритме, пишем эталонную модель на любом ЯП, обкатываем со всех сторон, делаем целочисленную модель, исследуем и все станет ясно. Работы дня на 4.

вангую что у вас с нормировкой что-то не то, типа как тут . Ну и теория теорией, но надо же понимать что в целочисленной арифметике, все зависит не только от угла, но еще и от входной амплитуды данных, от разрядности представления угла, от усечения битовой разрядности (если такое есть внутри). а оттолкнуться от статьи А. В. Захаров, В. М. Хачумов "Алгоритмы CORDIC. Современное состояние и перспективы" там этот алгоритм на пальцах разобран, перенести на любой ЯП дело получаса максимум

так раз вы уже настолько продвинулись, сделайте собственный. Начните с целочисленного прототипа в каком нить матлабо-питоне, а потом он минут за 20 переносится на верилог. А там и глянем получилась у вас теоретическая точность или нет)

эмм, да этих фифошек в сети и на гитхабе как у дурака махорки + куча статей от санберст как делать фифо

макросы ЗЛО ! 😀

adder_tree_m.v

а ниос 5 это потомок ниос 2 или просто ядро пятого риска под себя запилили?

вам описание конвейризированного дерева сумматоров нужно? или фильтр аналог? Так то обычный cic фильтр на 10 единичных коэффицентов описан, можно на дереве, можно на цепи, можно на аккумуляторе с памятью сделать)

EFFICIENT IMPLEMENTATION OF DECODER USING MODIFIED SOFT DECODING ALGORITHM IN GOLAY (24,12) CODE.pdf Пробежал глазами, да статья та, но вот блок схемы алгоритма там нет, только описание. Как помню, реализовывал на основе написанных идей. Для ПЛИС кодирование голея (24,12) делается таблично(1 блок памяти), поэтому вместо описанного алгоритма я делал две таблицы: прямую (получить 12 бит четности из 12 бит данных) и инверсную (получить 12 бит данных из 12 бит четности) ну и дальше уже искал максимальное правдоподобие.

Да, глянул, на бегу увидел MAP, подумал что там рядом и BCJR, но оказалось нет) тем не менее, по графикам у автора 0.25дб выигрыш наблюдается. Смотрю с практической точки зрения, BCJR для компонентных кодов, не нравится своей двухпроходностью по решетке. А с учетом того что компонентных кодов много, то если требуются большие пропусные способности стоит ли овчинка выделки) Но истины ради интересно погонять, да) Спасибо за статьи, SEW интересное применение, напомнило мне мягкое декодирование расширенного кода Голлея, когда разбиваем его на две половинки (data, parity), в каждой по чейзу на N стираний, потом кодируем, получаем 2*2^N кандидатов и считаем веса для выбора максимально вероятного кода. Но, ЕМНП, в моей реализации энергетический выигрыш, относительного обычного Чейза на N+1 стирание был незначителен, а ресурс требовался раза в 2 больше. Думал применить SEW (но я тогда не знал как это правильно называется) к eHamming, но пока руки не дошли, посчитал что для d = 4 он не имеет особого, практического смысла)

Decoding algorithms for shortened-extended TPC in WiMAX systems.pdf тут в статье автор рассматривает декодирование по Pyndiah и по MAP BCJR алгоритму, но как я понял статью толку не особо много. Выигрыш незначителен, а проигрыш по производительности значителен. Да столкнулся с задачей где упираться в предельное чутье не нужно, желательно отсутствие noise-floor но требуется нормальная пропускная способность при минимальном ресурсе, поэтому LDPC избыточен, CTC недостаточен, и тут вспомнил что надо закрыть гештальд по BTC кодам) Единственное что не нравиться это сборка входного/выходного блока данных с гранулярностью бит, тем более при использовании сложных укорочений. Но мне нужно ~100-150Мб/с, что можно сделать на битовом уровне) Но вот собирать такие потоки произвольно на каком нить гигабите, не представляю как, внутри одного ядра)

Ну вот я крутил крутил логи (что бы получить файлы логов надо включить decSet.log_on = 1), смотрел как ведут себя метрики, какие именно веса кодовых слов насчитываются, как применяются коэффициенты alpha/beta и пришел к следующему выводу, сформированному по правилу "нутром чую что литр": 1. Если посмотреть как применяется коэфцииент beta у Pyndiah, то по сути, при идеальной метрике бита на входе +-1, выходная метрика бита без пары равна ее увеличению на шаг (1+beta), где beta меньше либо равен 1. 2. Поиск контрслова у Pyndiah, приводит к тому, что выходная метрика бита с парой может быть значительно больше остальных метрик, потому что формируемый им список состоит из двух частей: одинаковые кандидаты(спасибо жесткому декодеру) и группа значительно отличающихся кандидатов метрика которых значительно больше(из того что видел доходило до 4 и более раза). 3. Таким образом получается что у Pyndiah на выходе есть значительная неравномерность выходных метрик/экстринсиков: биты с парой могут из -0.25 дать +4, а биты без пары, на первых итерациях, всего лишь незначительно увеличиваются на 20-30%. Поэтому, КМК и вводятся малые коэффициенты alpha на первых итерациях что бы как то "усреднить" эту не равномерность. Типа плохим битам сделаем получше, хорошим накинем чуток. 4. В предлагаемом Wang алгоритме, формируемый список сразу фильтруется на предмет одинаковых кандидатов (за счет проверки что исправленная жестким кодом ошибка стоит в месте отличном от стирания), в итоге получается в списке находится "точно попавшее" слово со стираниями (нулевой синдром и нулевая четность) и слова с исправленными битами вне позиций стертых бит (которых всего 4). 5. В итоге в отсортированном списоке метрик таких кандидатов разница между первыми двумя составляет диапазон 0.1 - 1, что при применении указанного правила, для бит без пары дает прибавку аналогичную по весу что у оригинала, а для бита с парой дает результат меньше или равный чем в оригинальном алгоритме. Но, за счет того что берется ближайшая пара, разброс метрик получается не такой большой как Pyndiah. Это позволяет не париться с alpha, сделав его аналогично LDPC кодам, фиксированным для всех итераций. Вот так я себе обьяснил наблюдаемый эффект. Спасибо, как всегда извечный копипаст, до этого я отдельно крутил квадратный турбокод на SPC (движусь к реализации wimax BTC полного кодека на 100Мб/с). Из интересного, BTC (32,31)^2, при скорости кодирования 0.94 на 5 итерациях показал результат аналогичный жесткому классическому витерби [171 133] со скоростью кодирования 1/2, а именно EbN0(1е-6) ~= 7дБ (bertool) Да, Витерби жесткий, не мягкий, но тем не менее я считаю что это приличный результат для кода, компонентные коды которого могут только определить наличие битовой ошибки)

Провел еще некоторе время над кодом: 1. Методом игры с коэффициентами, изучением логов и логикой здравого смысла подобрал коэффииценты альфа и бета такие, что самописный код стал близок к референсному. Действительно тонкое место, шаг влево-вправо влияет довольно таки сильно 2. Нашел у себя ошибку в быстром чейзе с быстрым решением (без поиска), вы будете смеяться, но....это работает. И работает как в статье, вот результат Да, результат хуже, но не так катастрофично, причем чем больше итераций тем результаты ближе. Кому интересно покрутить, проверить мой код, пример в атаче hamming.zip

angle_rad = -78318, angle_deg = -70112 cANGLE_W = 18 -> norm_coe_rad = 2^(18-3) = 32768, norm_coe_deg = 2^(18-9) = 512 итого, корка выдает atan2 (-120, -128) = -78318/32768 = -2.390076 в радианах или -70112/512=-136.9375 в градусах

Там же есть файлик readme.txt в нем указано Поэтому там любые данные на декартовой плоскости

Обсуждение конструкции является офтопиком данного форума. Обсуждение выделено в отдельную тему https://electronix.ru/forum/index.php?/topic/173363-проектирование-источника-питания-импульсного-магнетрона/ Модератор

да именно так, слово оппонент даже не ищется, просто во время выполнения быстрого чейза отсеиваются одинаковые слова, в итоговом списке получется нужное слово и следующие, на значительном расстоянии от первого. Потом без поиска берется два младших и считается метрика. Приводятся характеристики близкие к Pyndiah для того кода который там есть, но у меня они не получаются 😢 более того, попытка заменить евклидову метрику начального алгоритма на алгоритмическую, тоже показывает более плохой результат. 🤷‍♂️

На форуме замечены недобросовестные заказчики и исполнители электронных разработок. Договорные отношения, особенно на словах, являются дискуссионным предметом с диаметрально противоположной точкой зрения. Не стоит рассматривать данную тему как место сведения счетов и выяснения юридических деталей (вид пуговиц не тот, думал другое и т.д.). Поэтому в данной теме описываем только вопиющие случаи, такие как: Со стороны заказчика про исполнителя: 1. Работа не выполнена. 2. Работа выполнялась с нарушением установленного графика. 3. Работа выполнена в срок значительно превышающий оговоренный (например работа длилась 4 месяца вместо двух, или год вместо 8 месяцев и т.д.) Со стороны исполнителя про заказчика: 1. Работа не оплачена. 2. Работа оплачена не полностью. 3. Работа оплачена значительно позже чем оговорено договором. При указании работы указываем никнейм заказчика/исполнителя на форуме с кратким описанием ситуации: предмет договора, срок исполнения договора, время начала исполнения договора, текущая ситуация. Обсуждение сторон, в этой теме запрещено и будет удаляться с выписыванием горчичников. Эта тема только для сухих фактов, все остальное решайте в личке. Хвалить исполнителей/заказчиков здесь тоже не надо. Это вы можете сделать через репутацию или записи в топике исполнителя/заказчика. Администрация.

По идее, для кода с d = 4, больше 16 ти кандидатов не имеет смысла. Коэффцииенты итераций пробовал подбирать, но особого выхлопа не заметил. Он ссылается на коэффициент beta, приведеный там же. В хелпе матлаба приведены те же коэффициенты. Пробовал ими играть, но заметного результата не увидел. Более того, есть вот такая, довольно свежая, статья A Low-Complexity Decoder for Turbo Product Codes Based on Extended Hamming Codes. Она на основе быстрого алгоритма Чейза для расширенных кодов Хэмминга и арифметических метрик (просто по модулю) и очень оригинальной аппроксимацией (пара даже не ищется, коэффициенты не применяются). Сделал все в точности по статье, ошибок не нашел, но вот не достигаются указанные в статье характеристики, получается приличный проигрыш в 1дб. При этом алгоритмически все вроде как верно. Вот и не могу понять, толи лыжи у меня не той системы, то ли еще что( wang2018.pdf

Поднимем тему. Итак дано: BTC коды из Wimax на основе расширенных кодов хэмминга. Реализация по статье Near-Optimum Decoding of Product Codes: Block Turbo Codes Ramesh Mahendra Pyndiah, Member, IEEE. Все понятно, все получилось, но есть нюанс, вокруг которого хожу уже какой день и не могу продвинуться. Поэтому прошу помощи. В атаче лежат сорцы этого кодека на м-языке и приведент тест: сравнивается BER у встроенной функции tpcdec и самописной для кода (32, 26, 4)^2. Судя по хелпу, tpcdec реализован аналогично указаной статье. Но есть ньюанс, вот эталонные кривые, приводимые автором для кода из теста результат на 2.5/3.0/3.5 дб составляет ~1e-3/5e-5/5e-6. Теперь берем результат теста, для 1е6 информационных битов (достоверное измерение где то до 1е-5, но этого достаточно) done EbN0(EsN0/SNR) = 2.00(0.20/3.21) ber = 1.16e-02 vs 2.75e-02 at ch ber = 7.43e-02 done EbN0(EsN0/SNR) = 2.50(0.70/3.71) ber = 5.55e-04 vs 3.21e-03 at ch ber = 6.29e-02 done EbN0(EsN0/SNR) = 3.00(1.20/4.21) ber = 0.00e+00 vs 7.80e-05 at ch ber = 5.18e-02 done EbN0(EsN0/SNR) = 3.50(1.70/4.71) ber = 0.00e+00 vs 0.00e+00 at ch ber = 4.26e-02 собственная реализация довольно близко идет к той что в статье, но вот tpcdec на 0.5дб ее обходит, хотя судя по хелпу она аналогична. Собственно вопросы: 1. Посмотрите код, все ли я правильно сделал с 2D турбобалалайкой, может глаз уже замылися? 2. что такого сделано в функции tpcdec что она обходит родителя на целых 0.5дб? Спасибо ЗЫ. Если взять 1е7 бит, то результат аналогичен, 0.5 дб выигрыш реализации tpcdec done EbN0(EsN0/SNR) = 2.00(0.20/3.21) ber = 1.16e-02 vs 2.75e-02 at ch ber = 7.41e-02 done EbN0(EsN0/SNR) = 2.50(0.70/3.71) ber = 6.78e-04 vs 3.71e-03 at ch ber = 6.30e-02 done EbN0(EsN0/SNR) = 3.00(1.20/4.21) ber = 9.00e-06 vs 1.81e-04 at ch ber = 5.23e-02 done EbN0(EsN0/SNR) = 3.50(1.70/4.71) ber = 0.00e+00 vs 0.00e+00 at ch ber = 4.27e-02 BTC_wimax.zip Near-Optimum Decoding of Product Codes. Block Turbo Codes.pdf

я может быть скажу глупость, но MT47H64M16 это DDR2, у которой всегда было 8 банков, а на скрине у вас корка SDRAM controller, не DDR2 sdram contoller. В examples там видно PC100 что было стандартом SDRAM памяти) А у SDRAM максимум всегда был 4 банка)

ИМХО, bank machines != ram bank, это фича что бы реализовать SDRAM command out-of-ordrer execution. А именно запаралеллить работу команд открытия и закрытия банка. Больше 4-х не имеет смысла. 3 оптимально, 2 гораздо лучше чем один) А памяти у вас как было, так и останется, потому что отображение BA[] на биты адреса не меняется)

вы бы хоть лог ошибки привели, телепаты еще в отпуске)

А чем не устраивает скользящее среднее по рекурсивной схеме? Буфер памяти, аккумулятор и вычитатель?

я бы рыл в сторону документов по разводке тактовых на чипе. Мое вангование: тактовая там разводится через специальные блоки контроля доступа к глобальным линиями, на которые авторы считали что gated clock никогда не будут использоваться (т.е. тактовые всегда есть), поэтому он всегда включен и лишний такт проблемы не представляет. Но когда вы пробрасываете тактовую через порты, софт либо не делает это через глобальную разводку либо включается режим что сигнал может быть любым, в том числе gated clock, а в этом случае, включенние этого блока приведет к не корректной работе) Но багофича интересная, да, не делая асинхронный SPI, на нее сложно наткнуться) А про логи, ну судя по темам на форуме, говин много что не пишет) дело времени.