des00

если про метастабильность, то конечно существует. ЕМНИП при стандартном измерении длительности интервалов асинхронных сигналов, методом выделения фронта и запуска счетчика, максимальная погрешность измерения будет 2*T, ее можно снизить до T, где то видел эту информацию в книгах, но надо искать. Ну и чем меньше вы сделате T, тем вам будет лучше. ЗЫ. Там по сути ставится 4.8 счетчиков, на 4-х тактовых со сдвигом 90/45 градусов + по обоим фронтам. Они все работают классически, потом стоит логика пересчета результатов в конечный результат. ЗЗЫ. Если ваша ПЛИС позволяет, лучше поднять частот до 200-300МГц. Пересчитывать 2 счетчика, проще чем 4-8 ;)

вообще в вашем случае, лучше 4 счетчика на 4-х фазах частоты, потом комбайнер, который их обьединит)

А разве в акси нет режима работы шины в бурсте с константным адресом? Типа FIFO Вся память видится через один адрес, начальный адрес памяти задать через регистры.

слабо знаю цинк, но судя по логу, регистровых слайсов надо кучку для шин. слишком большие времена разводки. Либо шину вы выбрали не той системы, для низкоскоростных устройств.

Добрый день! Наконец то появилось время подтянуть себя в вопросах реализации кодов с вероятностным декодированием. Первая задача реализация DVB-RCS/WiMAX CTC кодера на ПЛИС, часть проекта будет выложен в опенсорс. Решил создать отдельную тему для обсуждения вопросов по реализации После штудирования литературы и примеров сорцов в сети возникла часть вопросов, на которые не хватает ума/настойчивости найти ответы: 1. Для DVB-RCS оговорены выкалывания под скорости кодирования 1/3, 2/5, 1/2, 2/3, 3/4, 4/5, 6/7. Почему не определены скорости 5/6 (удивляет "дырка" между скоростями 4/5 и 6/7) и 7/8? При этому матрица выкалывания под эти скорости возможна. 2. Полиномы RCS для Wimax и DVB одинаковые, но перемежители разные. Это сделано по политическим причинам или это результат "улучшения" характеристик декодера в процессе разработки стандарта? 3. В сверточных бинарных кодах, свойство tail-bitting используется при декодировании: В одной доке нашел что дополняют принятую последовательность вначале и в конце, затем декодируют по витерби и выкусывают нужное. В примере матлаба вообще составляют два фрейма, декодируют один за другим, потом из двух декодированных собирают один результат. Никакого намека на похожие операции в доках на турбокоды не нашел. Почему в алгоритмах SOVA/MAP/... для турбокодов это не делается? 4. По tail-bitting нашел в доках только то, что особым образом инициализируются рекурсия прямой и обратной метрики на первой итерации, а на всех остальных значения между итерациями сохраняются. Но в сорцах от CML цикл по итерациям выглядит так : for it = 1:max_iterations inx1 = X + inner_extr; [outx1, outz1]=DuobinaryCRSCDecode( inx1, inz1, poly, decoder_type); llrx1 = outx1 - inner_extr; inx2(1:3*N) = llrx1( code_interleaver_GF4); [outx2, outz2, out_info]=DuobinaryCRSCDecode( inx2, inz2, poly, decoder_type); detected_data(code_interleaver.info_intl) = (out_info>0)+0; errors(it)= sum( sum(abs(detected_data - data))); if (errors(it) == 0) break; else inner_extr(code_interleaver_GF4) = outx2 - inx2; end end Т.е. видно что последовательные вызовы функции DuobinaryCRSCDecode между собой не обмениваются этой информацией. А в самих функциях // initialization for CRSC code for (i =0; i< max_states; i++) { alpha[i][0] = 0; beta[i][len] = 0; } Т.е. не используется даже свойство одинакового начального состояния. Более того, в алгоритмах с оконным расчетом обратной рекурсии тоже забивают на свойство tail-bitting. Так насколько это важно и почему во всех доках настойчиво пишут кодировать данные 2 раза для определения состояния инициализации? 5. В алгоритмах, наследованных от Log-MAP метрика ветки считается как сумма корреляций метрик приемных битов с выходными битами решетки : gamma(Sk-1, S) = Lapri + (ys0*xs0 + ys1*xs1 + yp0*xp0 + yp1*xp1). При этом предполагается что y - надежность принятого символа , x = -1/1 выходной(переданный) бит. В сорцах от CML это место выглядит так : int m_input = 2; // 2 input bits, int max_states = 8; // total state numbers int M_input = 1<<m_input; int i, j, max_trellis = M_input * max_states; ....... for (j = 0; j< max_trellis; j++) { temp_input = j%M_input; temp_output = trellis_out[j]; gamma[j] = ( temp_input ==0)? 0: inx[ (temp_input -1)+ i*llr_height ]; //llr for systematic symbol gamma[j] += ( temp_output ==0)? 0: inz[ (temp_output -1)+ i*llr_height ]; //llr for parity symbol } Насколько я понимаю Си gamma[j] = ( temp_input ==0)? 0: inx[ (temp_input -1)+ i*llr_height ] - берет надежности символов кроме нулевого. Диапазон изменения temp_input = 0..3 или в битах 00/01/10/11. Вот этот момент мне совсем не понятен. Пока всё :) Прошу помощи тех кто в теме.

если это насовский, то там даже этого не надо. все ляжет в константы. Т.к. матрица там фиксирована и размер базовой матрицы 511х511 не изменяется)

Да, специально сделал сравнение 5G "одинаковых" кодов, например 22/26 классический и 22/28 выколотый по систематическим битам до 22/26, так вот, второй обходит первый, по моей базовой модели с неквантованной метрикой на ~0.3-0.5 дб. PS. Как будет время, турбокоды из 13ой рекомендации тоже добью и проверю этот эффект, уж больно там перемежитель хороший, всегда хотел сделать турбокодек на 200 мегабит)

Не, там все четко. Те кто разрабатывал стандарт учли многое, в том числе постановку задачи: зачем делать высокие скорости кодирования (которые на QC-LDPC приводят к большой длине проверочных матриц по горизонтали), если можно просто выколоть систематические биты, на матрице нормальной длины. Ну а дальше там все решает rate matching на циклическом буфере. Где можно дослать выколотых бит) Ну и 5G решает вопрос взять побольше (высокие скорости), плюнуть на 5-10км. Хотя сами матрицы, в самом стандарте описаны как noise floor absence. Ну и вопрос не как мерить BER, а как сравнивать кривые кодирования. В целом, результаты моих прогонов кодека в матлабе, показывают что надо идти по классическому варианту. А именно, считать что выкалываются проверочные биты(а не систематические), считать "скорость кодирования" ну и при заданном EbNo определять требуемую дисперсию генератора. ЗЫ. А сам LDPC в стандарте ИМХО хорош для применения, Жаль только что сделали "кривые" размеры базовых подматриц 3х3, 5х5, 7х7, 9х9, 11х11, 15х15, не кратные 2^N, со списком проверочных матриц и модульными операциями приведения базовых матриц к рабочим. Вот их обрабатывать довольно сложно, на универсальном ПЛИС движке(

В документации там явно отражено отдельной сноской, что это делать обязательно))) я так платы с плохой пайкой "диагностировал". Приносили несколько штук, не грузятся. Пальцем придавил - все пошло))))

размеры очень напоминают NASA GSFC? Это он? Если код класса QC-LDPC то хранить надо намного меньше. Обычный min-sum делается элементарно. Вот если там что другое, тогда смотреть надо)

Я же приводил вам список литературы: книги по UVM, OVM, AVM, Writing testbenches от Яника Берджерона. Ну и любые книги, по методологии тестирования, а не по тому, как на языке написать что-то с вывертом, что бы показать какой крутой язык. Даже вон, в закромах из нового Functional Verification Coverage Measurement and Analysis (Piziali-2004) прям название вообще никак не связано с функциональным покрытием)

Вот тут и есть ваша ошибка. Вам нужно было просто отправить жалобу, модератор раздела разберется. Модератор, как бы вам не хотелось, жестко ограничен правилами форума и правилами модерирования (да да, есть и такие, не видимые для пользователей). Он "серый" и его отношение ко всем должно быть нейтральное, просто оценка соответствия правилам, разбираться в теме обсуждения, модератор не обязан. Если модератор участвует в теме обсуждения как участник, то его "привилегии" не должны использоваться, только при явном нарушении правил форума, за исключением раздела "Общение". Если у модератора не получается отстраниться, то он сам может быть наказан администраторами. Подытожу, ваше предложение, основано на неправильных предпосылках. Вы можете сделать только хуже и потом взвоете от такого модератора. @haker_fox и именно по вашей ссылке, все началось с легкого, допустимого нарушения правил, 2.1в, но потом, переросло в 2.1а, г-д. Можно просто скрыть не нужный флейм, а можно выписать по пилюле вам обоим. От модератора раздела зависит. За сим, предлагаю вам остыть и еще раз прочитать правила форума.

Модератор дело добровольное, муторное и не благодарное)

a[1:0] может быть 'x или 'z. ЗЫ. Про ваше покрытие, уже неоднократно писал вам, ваша работа шашечки, а не ехать)

до кучи " Performance Retiming " ретайминг вещь дюже опасная. вроде все просто, но кто его знает. Стараюсь не использовать

ЕМНИП надо нужную память добавить в этот вьвер. просто так, он не показывает ничего)

Попробую расписать вот на таком примере. Положим у нас есть код 1/2 и 100 бит систематических данных, модуляция BPSK. 1. Обычная система связи. 100 бит -> кодер -> 200 бит -> 200 символов -> AWGN -> 200 метрик -> декодер -> 100 бит 2. 5G 100 бит -> кодер -> 200 бит -> выкалыватель 20% систематических данных -> 180 символов -> AWGN -> 180 метрик -> декодер -> 100 бит. Т.е. в обычной системе, в кодере и в канале скорость кодирования 1/2 и для передачи информации о 100 битах использовалось 100 символов данных + 100 проверочных символов. А в 5G, в кодере 1/2, в канале 0,44 (80/180) и для передачи информации о 100 символах использовалось 80 символов данных + 100 проверочных символов. Но количество переданной информации(100 бит), в обоих системах одинаковое. возникает вопрос, эти 20% как должны учитываються в энергии бита? Если в лоб, как в моем вопросе и как вы пишете, то при одинаковых EbNo, SNR на выколотом 5G коде будет хуже. Т.е. код мы сами "ухудшили" (выкололи), еще и гоняем тесты с большей дисперсией). Вот моя логика здравого смысла говорит что, что-то, тут не так)

а их и нет) был бы массив параметров, тогда можно было бы что-то сделать. а так, в ручную перебирать)

Всем доброго. Есть вот такой вопрос. в релизе 15 стандарта 5G https://electronix.ru/forum/index.php?app=forums&amp;module=forums&amp;controller=topic&amp;id=155109&amp;do=findComment&amp;comment=1666535 штатно оговаривается отбрасывание (похоже на усечение, но усекают добивая нулями) 2/10 или 2/22 частей систематических бит. Сделал в матлабе 5G кодек и это работает). Но есть вопрос в интерпретации результатов. При снятии характеристик, используемый для модели AWGN сигнал-шум SNR = EbNo + 10*log10(coderate*bps). В случае не усеченных, усеченных и выколотых кодов, смысл этой формулы понятен. Энергия приходится на информационный бит, вычисляем полную энергию на всю посылку, с учетом скорости кодирования. Которая в данном случае, определяется просто. Теперь переходим к отбрасыванию 5G информационных бит. Что именно в этой формуле, должно пониматься под coderate? У меня есть 2 варианта, рассмотрим второй граф стандарта 5G в режиме кодирования 10/14(главная матрица). Положим что EbNo = 5дб. Базовая скорость кодирования 10/14 (~0.7) что соответствует SNR = 6.55 : 1.Скорость в канале chrate = (10-2)/(14-2) = 0.66, тогда SNR = 6.25. 2.Скорость в канале chrate = 10/(14-2) = 0.83, тогда SNR = 7.2. Первый вариант чисто формальный(есть систематические биты, есть для них энергия), но моя логика здравого смысла в этом месте дает сбой. Ведь мы ухудшили параметры системы, забрав часть мощности кода на восстановление информации, которую сами же и выкинули. А проверяем эту систему в точках EbNo, соответствующих каналу с большей дисперссией. Второй вариант более логичен для меня, но может я подгоняю результаты под хотелки? Как правильно сравнивать вот такие коды? Можно конечно просто уйди в домен SNR, а не EbNo, но судя по всей теории кодирования, так не правильно заниматься сравнениями кодов). Интересно мнение других специалистов)

просто вы его направильно считаете. вы считаете RxMER, а не SNR. вам нужно искать мат.ожидание и дисперсию. А вы принимаете мат.ожидание равным жесткому решению. На ошибки, в вашем случае, это практически не повлияет. Но, если вам уж так принцпиально, ару по решениям, за эквалайзером, вам поможет. ЗЫ. либо уходить со слепого эквалайзирования, в пользу эквалайзирования по известным последовательностям.

Массивы модулей, с разными параметрами, назначаемыми из массива локальных параметров, всегда можно было делать. Интерфейсы, с точки зрения передачи параметров, те же модули. Про применимость согласен, весьма сомнительна)

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

уже лучше, но лет через 5, вам придет понимание, что рекомендация, а в некоторых, корпоративных случаях, обязательное требование использования операторных скобок, имеет под собой веские основания)

1. проверка по RTL-Viewer это как гадание на кофейной гуще, особенно с учетом того факта, что у квартуса он, мягко говоря, оторван от железа и это именно Register Transfer Level Viewer. 2. Автору первого кода мозг вправить на предмет более читаемого Coding Styles 3. Автору второго кода, руки оторвать, простите за прямоту. Код абсолютно не читаем, сложно сопровождаем и более того, на некоторых синтезаторах, работающих по шаблонам синтеза, может работать не корректно.

прочитать например тут https://asuneft.ru/transportirovka/gorizontalnoe-burenie-neftyanyh-skvazhin-razburivanie-sposoby.html вот сами зонды http://gtmachine.ru/catalog/Lokatsionnye-sistemy/Zondy-peredatchiki/?roistat=direct1_search_5381291005_буровой зонд&amp;roistat_referrer=none&amp;roistat_pos=premium_2&amp;yclid=238011398605790390 а фотки реального оборудования спрошу у бывших коллег, которые подобные системы делали