Перейти к содержанию

    

Alex_AZ

Свой
  • Публикаций

    56
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Alex_AZ

  • Звание
    Участник

Информация

  • Город
    Челябинск
  1. Zig, благодарю за участие, особенно в выходной. Цитата(Zig @ Mar 10 2018, 14:07) Рассмотрим мультиплексор на вход которого поступает ТП с постоянной скоростью CBR (constant bit rate). Согласен, уточнение важное, не отметил сразу. Пока речь идет именно о CBR. Цитата(Zig @ Mar 10 2018, 14:07) При приеме, на входе мультиплексора, пакета с полем PCR мы из этого поля вычитаем текущее значение счетчика системной частоты SCR... ...Таким образом физический смысл коррекции меток PCR путем вычитания, на входе буфера, и добавления, при чтении из буфера, текущих значений счетчика системной частоты, есть не что иное, как добавление к значению поля PCR задержки данного пакета в буфере, выраженного в тактах системной частоты. Все реализовано так, просто в целях отладки пока сделал вычисление времени задержки (в количестве тактов SCR) при добавлении к выходному пакету. Цитата(Zig @ Mar 10 2018, 14:07) PCR accuracy error выходного потока будет зависеть от: - PCR accuracy входного потока; - соотношения между частотами системной частоты 27 МГц и 27 МГц из которых формировались метки PCR (чем больше разность между ними, тем больше будет PCR accuracy error); - времени нахождения транспортного пакета в буфере (чем дольше находится пакет в буфере, тем больше PCR accuracy error). При этом, если значение системной частоты точно равно частоте из которой формировались метки PCR, то PCR accuracy error не будет зависеть от времени нахождения пакета в буфере. - PCR accuracy входного потока - 40нс. Выходной получается 500-600нс. - 27МГц на моей плате отличаются от номинала (если верить поверенному частотомеру) герц на 20. Вроде не должно быть критично на интервале 1 пакета при битрейте выходного потока 50МБит/с и входного 24.9Мбит/с. - Пакет не задерживается дольше, чем на время одного выходного пакета при выходном битрейте 50Мбит/с. Цитата(Zig @ Mar 10 2018, 14:07) ...Любые флуктуации скорости приведут к дополнительной PCR accuracy error. Для отработки схемы коррекции PCR можно временно отказаться от приема ТП из IP и подать его, например, через DVB-ASI. Вместо этого просто задавал константой (исходя из скорости оригинального входного потока, взятого из файла) скорость чтения из большого буфера. Но уменьшить PCR accuracy ниже величин 500-600нс не получается. Цитата(Zig @ Mar 10 2018, 14:07) Для отработки схемы восстановления скорости ТП, принятого по IP можно вывести поток через DVB-ASI минуя мультиплексор и модулятор. Согласен, но это судя по результатам, пока проблема меньшего масштаба. Уже добился результатов, когда восстановленное значение скорости потока и заданное константой дают равный результат для PCR accuracy. Во всяком случае, выяснил, что понимаю алгоритм коррекции PCR правильно. Возможно стоит поискать проблемы и неточности в его реализации.
  2. Спасибо за ответ. Абсолютно согласен. Я похоже непонятно и не совсем корректно нарисовал схему, не хотел загромождать. Вычисление приращения и нового значения PCR происходит в момент, когда мультиплексор отправляет пакет, содержащий PCR, модулятору. Мультиплексор же и подменяет старое значение PCR новым вычисленным. В целом, насколько понял, примененный алгоритм ситуацию улучшает, но вносимый джиттер в PCR расходится с описанным в разных статьях (если нужно, могу выложить, но не раньше понедельника), где говорится о 40нс прироста PCR accuracy. Может ли это быть как-то связанным с преобразованием размера пакета при передаче модулятором из 188 байт в 204 после кодера Рида-Соломона? Модулятор, на первый взгляд, дает постоянную задержку данных в нем, что требуется стандартом ISO/IEC 13818. Пока даже не знаю что еще проверить.
  3. Занимаюсь разработкой DVB-C модулятора. В целом все работает, возникают только вопросы к алгоритму коррекции (перештамповке) PCR. Проблема проистекает из того, что скорость входного потока в общем случае не равна скорости потока, генерируемого модулятором. Для компенсации этой разности скоростей в поток добавляются нуль-пакеты. Такое изменение структуры потока влечет за собой необходимость коррекции меток времени, так как временные интервалы между пакетами с временными метками в общем случае изменяются. Механизм перештамповки PCR использую такой как описан, например здесь: https://electronix.ru/forum/index.php?showtopic=93519 Такой же механизм (добавление к PCR времени задержки пакета в цепях модулятора) описан и во множестве других статей. Схема в общем виде моей реализации приведена в приложении. Смущает то, что выходное значение PCR-accuracy сильно увеличивается по сравнению со входным, если верить анализатору Dektec. А именно, при входном PCR accuracy = 40нс, на выходе получаю PCR-accuracy иногда достигающее величины 500-600нс. Источник потока - программа Astra. Может кто-то сталкивался с проблемами приведенного алгоритма перештамповки PCR или сможет подсказать, где возможно наличие подводных камней.
  4. Цитата(VladimirB @ Mar 31 2017, 17:02) Появилась новая информация. 1) Если на ПК в свойствах сетевой карты убрать Автопределение скорости и жёстко поставить 100BASE-TX FullDuplex то пакеты между ПК и платой начинают передаваться без ошибок и обрезанных пакетов нет. При этом в 88E1111, при инициализации в регистрах жестко устанавливаем 100BASE-TX FullDuplex и в случае автоопределения сетевой картой скорости, связь идёт в том же режиме. Возможно, при работе в Half-Duplex режиме не отслеживаются коллизии. В ядре MAC-контроллера из ISE были сигналы tx_collision и tx_retransmit для отслеживания подобных ситуаций. При возникновении коллизии нужно было повторно отправить поврежденный пакет.
  5. Цитата(unixwz @ Jan 25 2017, 17:02) Здравствуйте. У меня возник ряд вопросов по реализации USB интерфейса на FPGA. 1. Возможно ли реализовать интерфейс USB (1.1 или 2.0), без использования микросхем USB PHY? 2. Есть ли готовые IP ядра реализующие данный интерфейс (Altera Cyclone 4). Знаю, что есть IP Core USB Controller, но не уверен, что это именно то, что мне нужно. 3. Есть ли примеры реализации USB интерфейса на FPGA? В свое время для общего развития писал на FPGA проект USB Device (работал в режимах LS, FS) без применения USB PHY и Microblaze/Nios. Работали 1 контрольный и несколько bulk интерфейсов. В качестве точки для старта брал проект университета Джона Хопкинса http://www.xess.com/projects/fpga-usb-v2-project/ . Этот проект кривоват конечно, но позволяет разобраться, что и как должно приниматься и передаваться. А дальше дело техники - убрать чисто студенческие ляпы и нормально структурировать проект.
  6. Цитата(bogaev_roman @ Dec 27 2016, 17:53) А не дойдет до RTL viewer, сразу упадет. Деление не синтезируется точно, real - скорее всего. Сам удивился, но современные синтезаторы умеют деление целых чисел синтезировать. Случилось столкнуться с таким описанием. Судя по схеме в RTL-viewer'e, просто раскрывают цикл сдвигов и вычитаний, но логики при этом используется оооочень много. Соответственно и максимальная частота работы схемы сильно падает.
  7. Ок, продублирую. Несколько дней назад писал на указанный адрес. Пока ответа не было.
  8. А подробнее по задачам на ПЛИС. Задачи у Вас вполне жизненные и, хотя я уже не начинающий, поучаствовать было бы интересно.
  9. На первый взгляд проблему решить удалось, фильтр работает, результаты очень похожи на правду. Прикладываю свои размышления и подход к построению фильтра. Критика приветствуется. За подборку литературы выражаю благодарность TSerg, надо будет ознакомиться.
  10. Возможно, я конечно усложняю решение. По Лагранжу, боюсь, что при существенно неравномерном распределении времени прихода отсчетов и интерполятор будет сильно ошибаться. Надо будет попробовать на записи реального сигнала.
  11. Спасибо за вариант решения проблемы. Возможно им и воспользуюсь. Просто кажется, что должен быть какой-то математический аппарат для построения цифровых фильтров с неравномерным временем прихода отсчетов по заданному аналоговому прототипу. По идее, решение задачи связано с решением дифф. уравнений для исходного аналогового фильтра. А для него выходной сигнал однозначно определен в любой момент времени при задании конкретных начальных условий и входного сигнала. Несколько статей получилось нагуглить по запросу "non-uniform sample rate filter", но пока в голове полного понимания не складывается.
  12. То есть предлагаете интерполировать полиномом на определенном интервале времени и затем рассчитать значения в требуемых точках?
  13. В общем-то такой вариант можно использовать. Но видится, что при таком решении может существенно возрасти объем вычислений. Входные данные приходят сравнительно редко, но есть моменты когда частота прихода новых значений возрастает примерно в 30 раз. Не хочется запускать фильтр на частоте в 30 раз выше необходимой в обычном режиме.
  14. Приветствую, уважаемые знатоки! Думаю, многие представляют и делали переход от аналогового прототипа фильтра к его цифровой БИХ реализации. Типовые решения, описанные в литературе предполагают, что частота сэмплирования данных постоянна. А мне сейчас пришлось столкнулся с задачей фильтрации сигнала, где временные интервалы между поступлением новых отсчетов непостоянны, при этом информация о времени прихода каждого отсчета есть. Для фильтра первого порядка все вроде бы ясно - можно модифицировать традиционную структуру фильтра исправляя коэффициенты фильтра в зависимости от интервала времени между приходом отсчетов. Для фильтров более высокого порядка сложнее - в традиционной структуре остается память о нескольких отсчетах выхода системы, интервал между которыми отличается от вновь принятого. И сейчас я не знаю можно ли как-то модифицировать эту структуру для решения своей задачи. Подскажите пожалуйста литературу или методики расчета структур, с помощью которых можно отфильтровать сигнал дискретизированный с непостоянным интервалом.
  15. Цитата(Krys @ May 25 2015, 09:12) Т.е. это придётся делать ручками для каждой цепи?... Можете в FPGA Editor'e в окне "Tools\Direct Routing Constraints" выделить по маске цепи, разводку которых нужно зафиксировать, и экспортировать в файл ucf.