Плата конвейера для работы с «мультибитными» микросхемами ЦАП

[Turbo_man]

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

См. фото универсальной платы конвейера.



Заинтересованные вегалабовцы, конечно, уже в курсе о чём идёт речь, а остальным немного поясню.

Каждая микросхема «мультибитного» ЦАП имеет свои ограничения по максимальной частоте Ц-А преобразования. Как правило, это не более 8…16Fs (за Fs принято принимать стандартную частоту 44,1 или 48 кГц), полученные в цифровом фильтре (ЦФ) типа SM5847AF например.
Таким образом, пределом по частоте для них будет 352…768кГц (для разных микросхем ЦАП разная предельная частота преобразования). Хотя на практике TDA1541A прекрасно работает и на 768кГц (16х), а PCM1702P на 1536кГц (32х). Правда это не документировано и не гарантируются качественные характеристики.

Так вот, чтобы обойти эти ограничения и получить МНОГО больше, можно включить N штук (2…16) в режиме конвейера, когда они работают одновременно со сдвигом во времени в рамках одного периода частоты преобразования. Суммарный результат при этом получается в N раз более быстродействующим.
Интересно это в первую очередь тем пользователям, которые таким образом хотят снизить требования или практически исключить восстанавливающий ФНЧ после ИУ преобразователя.

Что ОЧЕНЬ позитивно сказывается на пространственных характеристиках получающегося "саунд-стейджа" фонограммы. Локализация мнимых источников звука (КИЗов) получается просто ошеломляющей. Такого не удавалось получить ни от одного другого ЦАП-а.

А поскольку при этом складываются аналоговые сигналы с выходов микросхем ЦАП с жёсткими временными сдвигами, то попутно и получить AFIR (или гребенчатый фильтр), подавляющий нежелательные остаточные продукты преобразования цифровых фильтров (ЦФ).

Кроме этого, для сторонников NOS-ЦАП-ов, в конвейере предусмотрено отключение (обход) ЦФ по желанию.

В предлагаемом устройстве дополнительно к изложенному осуществляется 16-ти кратная линейная интерполяция (ЛИ) аудио-семплов, полученных от ЦФ. То есть мы получаем итоговую скорость аудио-потока 8 (ЦФ) х 16 (ЛИ) = 128Fs. А уже этот скоростной поток мы распределяем на 8 потоков по 16Fs (или 8Fs для TDA1541(A) - переключается управляющим сигналом), с которым легко и непринуждённо справляется каждая микросхема ЦАП в конвейере. Всё изложенное справедливо для каждого исходного левого (ЛК) и правого (ПК) каналов.

Таким образом, к предлагаемой плате конвейера можно подключить до 2 по 8 микросхем «мультибитных» ЦАП-ов.
Для удобства пользователя и обеспечения гибкости использования на плате предусмотрено место для ЦФ SM5847AF (точнее там их 2, но 1 теперь не используется и был предусмотрен для экспериментов) и PLL формирователя 768Fs для неё. А также стабилизатор +5В для питания платы изолятора USB.

Существует несколько вариантов прошивки ПЛИС, специализированных для разных типов применяемых микросхем ЦАП (пока доступны для PCM1702P, TDA1541(A) и AD1862N (общая с PCM63ми). Скоро будут готово и для PCM58P, AD1865, PCM1704U). Варианта сразу для нескольких типов ЦАП не планируется. Менять прошивку можно будет дополнительно, если планы пользователя поменяются.

Теперь описание разъёмов устройства:
Х1 – вход управления режимами платы конвейера (8 управляющих сигналов).
Х2 – вход аудио-потока I2S до 384кГц от платы ФИФО или иного цифрового аудио-источника. А также входы 2х управляющих сигналов и выход +5В для питания изолятора USB.
Х3…Х6 – выходы 2 по 8 (суммарно 16) аудио-потоков для подачи на 16 моно-микросхем ЦАП (или 8 стерео типа TDA1541(A)). На каждом разъёме по 4 потока.
Х7 – вход питания платки генов 1024Fs. (+7…12В примерно 30…50 мА). Гальванически развязанный и стабилизированный.
Х8 – вход питания остальной цифровой части конвейера, включающий основную ПЛИС и PLL и стаб +5В для USB. (+7…9В примерно 70…100 мА). Гальванически развязанный и стабилизированный.

Подробное описание контактов каждого разъёма следует…



Привожу фото для иллюстрации возможного применения конвейера, управляющего 2мя платами NOS ЦАП на 8 шт. PCM1702P суммарно.

[dortonyan]

Давно собирался, но всё как-то руки не доходили. В ПЛИС-ине сделал дизеринг для 16-ти битной TDA1541(A). По рекомендациям Дортоньяна:
https://forum.vegalab.ru/showthread.p...=1#post2531783

Описанная там схема дизеринга не корректна, это я по неопытности накосячил. Хотя она работала, но математически так не совсем правильно.
Для правильного дизеринга нужно брать из LFSR 8 бит (из практического опыта лучше 9 бит) и дополнять эти 9 бит 15-ю знаковыми битами. Затем полученное 24-х битное значение суммируется с данными и после этого от данных можно отбрасывать младшие 8 бит.
Кроме того, при суммировании может возникнуть переполнение данных, поэтому результат суммирования нужно проверять на переполнение. В моем проекте ЦФ под циклон модуль округления с 24-х до 16, 18, 20 и 22-х бит с простейшим шейпингом и отработкой переполнения занимает 176 ячеек (можно пооптимизировать и уменьшить еще примерно на десяток). Если интересно - могу поделиться кодом данного модуля на верилоге.

[Turbo_man]

Offтопик:

Если интересно - могу поделиться кодом данного модуля на верилоге.

Приветствую. Буду признателен за любую помощь.

[dortonyan]

Во вложении проект с параллельным 24бит входом-выходом, который занял 122 ячейки.
Дизеринг с шейпингом выполнен отдельным внешним модулем.
По сигналу Load выполняется загрузка данных и инкремент модуля генерации ноизшейпинга. Контроль переполнения выполняется асинхронной установкой регистров при переполнении.
Так же в проекте имеется выход индикации переполнения, но его в данном случае можно исключить.
Т.к. это максимально экономичный вариант, то при суммировании дизеринга со входными данными младшие отбрасываемые разряды не обнуляются. Для этого либо нужно допиливать данный модуль, либо учитывать это дальнейшей логикой.
Шейпинг шума выполнен самым простым способом, который удалось сообразить в матлабе: БИХ ФВЧ Баттерворд 1-го порядка с максимально простыми коэф-тами 0.25 и 0.5, которые получаются простым сдвигом.
Матлабовская модель (Filter Design & Analysis) и симуляция шейпинга так же во вложении (моделил на версии матлаба R2013b).
При запуске в железе данный шейпинг, однако, показал не однозначные результаты: устранение шумов квантования получается хуже простого дизеринга. Увеличение амплитуды шума помогает, но тогда от шейпинга толку получается не так много.
Но возможно это особенности моего сетапа.

[dortonyan]

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

Тест 16 бит сигнал -40дБ без дизеринга:


С равномерным дизерингом без шейпинга:


С включенным шейпингом:


Еще момент: длину lfsr я выбирал с условием, чтобы повтор ПСП был не менее чем через 1сек. при х32 оверсемплинге на выходе. Если у вас оверсемплинг еще больше, то разрядность lfsr так же желательно повысить.

[Turbo_man]

Offтопик:
dortonyan, спасибо большое за вашу помощь. Я обязательно проштудирую ваши примеры и попытаюсь у себя их реализовать и отчитаюсь немного погодя.

---------- Сообщение добавлено 15:11 ---------- Предыдущее сообщение было 15:09 ----------

У вас сильно уменьшаются нечётные гармоники при этом. От чего?

[dortonyan]

У вас сильно уменьшаются нечётные гармоники при этом. От чего?

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

Вот то же самое но на осциллограммах на сигнале 16bit 1кГц синус уровнем -96db, т.е. когда синус вырождается в меандр.
Без дизеринга:


И дизеринг с шейпингом:

[Turbo_man]

Да, я немного ступил.
Вам удалось зафиксировать улучшения от дизеринга для выходных 18 и выше бит? Т.е. есть ли в нём смысл при этом?

[tomtit]

Немного дружественной критики.
ЛФСР лучше проматывать не на 1 бит, а на полную длину.
За один сдвиг изменения в регистре малы и очень предсказуемы, поэтому я использую другие генераторы шума,
особенно это нужно, когда оверсэмплинг 128 и выше, для ДСД, остается мало тактов на прокрутку ЛФСР.
Для ФПГА надо писать по-другому, они заточены под синхронную логику. Асинхронные ресеты ФПГА вообще не нужны,
почему их рисуют всюду - ума не приложу.
Ну и код можно написать раз в 5 короче и понятней, Верилог это позволяет,
используйте тип reg signed[n:m],
функции $signed() и $unsigned() для расширения знака,
мультипликатор полей {4{r[10]}},
сдвиги <<,>>,<<<,>>> и.т.д.

Нойз шейпинг - могучая штука. Мне удавалось сгенерить приличный синус 5мкв амплитудой с помощью ДАК у которого вес младшего бита был аж 20мкв.

P.S.
Это всё чистый перфекционизм, на самом деле, на слух никто ничего не различит.
dortonyan, ЦАП у вас хороший получился, респект.

[dortonyan]

Немного дружественной критики.

Спасибо, критика не только дружественная, но и весьма полезная.

ЛФСР лучше проматывать не на 1 бит, а на полную длину.
За один сдвиг изменения в регистре малы и очень предсказуемы, поэтому я использую другие генераторы шума,
особенно это нужно, когда оверсэмплинг 128 и выше, для ДСД, остается мало тактов на прокрутку ЛФСР.

Согласен, но это все в угоду оптимизации (минимизации кол-ва ячеек), больше промотка - больше разрядность lfsr регистра. Для лучшей рандомизации я еще использую такой прием: беру биты из lfsr не подряд, а разнородно, типа wire[5:0] random = {lfsr[24], lfsr[15], lfsr[22], lfsr[21], lfsr[17], lfsr[23]};
Такой варинат для рандомизации годится?

Для ФПГА надо писать по-другому, они заточены под синхронную логику. Асинхронные ресеты ФПГА вообще не нужны,
почему их рисуют всюду - ума не приложу.

Здесь не соглашусь. Зависит от типа используемой FPGA. Можно было бы обойтись без асинхронной логики, но в данном случае это опять же вопрос оптимизации - меньше ячеек. Например для lattice fpga, такой вариант не годится, там асинхронную логику использовать действительно нежелательно.
Вообще стиль написания кода нужно учитывать под конкретную логику.
Я пишу под lattice и под альтеру, и один и тот же функционал (например мак) описываю по разному. Просто потому, что если мак написанный под альтеру применить для латтиса, то он займет в 1,5 раза больше ресурсов и наоборот (если все собирать на ячейках, про выделенные блоки умножения речь не идет).

Ну и код можно написать раз в 5 короче и понятней, Верилог это позволяет,
используйте тип reg signed[n:m],
функции $signed() и $unsigned() для расширения знака,
мультипликатор полей {4{r[10]}},
сдвиги <<,>>,<<<,>>> и.т.д.

Опыта работы в верилоге у меня немного (здесь я самоучка), поэтому часть из описанного просто не знал.
Ну а часть сознательно не использую для самоуспокоения, чтобы быть уверенным, что компилятор правильно собрал задуманную схему (я сильно не обстрагируюсь, пишу код под придуманную схему).

[Turbo_man]

dortonyan, ЦАП у вас хороший получился, респект.

Присоединяюсь к респекту.
А можно немного подробностей по ЦАП-у? Какой ЦФ 32х (видимо в ПЛИС-ине сделан), какая микра ЦАП-а и сколько их штук, ну и какой выхлоп?

[dortonyan]

Спасибо за респекты.
Про ЦАП я давно создавал ветку (сборка на инструментальных ЦАП-ах с цифровой калибровкой): https://forum.vegalab.ru/showthread....=1#post2342889
Только сейчас вместо DAC8805 использованы AD5547, другие ОУ, ну и суммарная разрядность 24bit, просто я для экспериментов с шейпингом засылаю туда 16bit данные и 8 нулей в конце.

Сейчас ЦФ на плисине lattice LCMXO2-7000, но для ЦФ она избыточна, я просто брал с запасом для экспериментов.
По факту хватает LCMXO-2000 либо альтеровского самого мелкого и старого циклона EP1C3T100.
Вкратце ЦФ - 5-ти каскадный FIR интерполятор с овресемплингом до х32 (каждый каскад х2), с автоматическим выбором каскадов в зав-ти от входной ЧД (принимает до 768кГц) и с входным аттенюатором от 0 до -3db на выбор.
Коэффициенты 27bit, внутренняя шина данных 26bit + 1bit на переполнение, аккумулятор 37bit + 1bit на переполнение, выборка из аккумулятора с дизерингом (на циклоне разрядность шины 31+1 бит без дизеринга даных из аккумулятора). Первый каскад простой фир с ослаблением на Найквисте 60db, остальные каскады полуполосные. Про шейпинг вы уже в курсе, усеченный пример взят оттуда.
Подробнее напишу как-нить в другой раз, когда закончу оптимизацию.

[Turbo_man]

Спасибо за информацию. Я вспомил вашу тему про цап на 2х параллельниках меньшей разрядности. В целом интересно. Даже думал что-то позаимствовать и повторить частично, но в качестве цапа взять двухканальный 18битник PCM1700. Они дешёвые, как раз для опытов.

[dortonyan]

ЛФСР лучше проматывать не на 1 бит, а на полную длину.
За один сдвиг изменения в регистре малы и очень предсказуемы, поэтому я использую другие генераторы шума,
особенно это нужно, когда оверсэмплинг 128 и выше, для ДСД, остается мало тактов на прокрутку ЛФСР.

Согласен, но это все в угоду оптимизации (минимизации кол-ва ячеек), больше промотка - больше разрядность lfsr регистра.

Подумал как оптимизировать lfsr для сдвига не несколько бит и понял, что дополнительных ресурсов для этого не требуется.
Т.к. кол-во состояний lfsr нечетное, а вычитка значений из lfsr всегда (ну или в данном случае) выполняется через четное кол-во тактов мастерклока, то сдвигать lfsr можно хоть на каждом такте. Кол-во комбинаций до повтора останется неизменным.
В архиве доработанный вариант шейпера, в котором lfsr сдвигается каждый второй такт (можно сдвигать и каждый такт, если у вентилей плисины хватает скорости - выкинется один триггер).
NoiseShape.rar
Но в железе я его не испытывал.
Чтобы не искать полиномы в сети - набросал консольную программку для тестирования lfsr полиномов разрядностью до 32-з бит конфигурации Галуа со сдвигом в право: lfsr.rar
Вводите значение полинома в хексе и получаете на выходе максимально возможное кол-во состояний для такой разрядности и фактическое кол-во состояний до повтора для данного полинома. Можно самому выдумать полином и проверить его на пригодность.

Даже думал что-то позаимствовать и повторить частично, но в качестве цапа взять двухканальный 18битник PCM1700. Они дешёвые, как раз для опытов.

18 - разрядов в принципе дополнять не обязательно, такой разрядности уже хватает для получения низких шумов квантования. А для подстройки линейности можно добавить отдельные цапики попроще (14..16 бит).
Важнее построить хороший деглитчер, т.к. при разрядностях выше 16 бит начинают доминировать глитч-индуцированные искажения.

[dortonyan]

Решил проблему неоднозначности шейпинга, о которой писал вначале.
Оказалось касяк - отсутствие округления. Т.е. шум с сигналом я суммировал, но округление не выполнял, просто отбрасывал младшие разряды. Так делать нельзя.
Добавил округление до +/-0.5 LSB (для этого к результату вместе с шумом суммируется 0.5LSB от длины выходного слова) и все стало красиво, даже на минимальной амплитуде дизеринга.
Что характерно, добавление к дизерингу округления, даже без шейпинга понизило шум. Теперь шум с шейпером и без в спектаплюсе вообще не различим.
Ну и сдвиг LFSR вернул один, а для лучшей рандомности подобрал более сложный полином.
Исправленный файл шейпера: NoiseShape_1.rar

[tomtit]

Что характерно, добавление к дизерингу округления, даже без шейпинга понизило шум.
Ну и сдвиг LFSR вернул один, а для лучшей рандомности подобрал более сложный полином.
Исправленный файл шейпера: NoiseShape_1.rar

Я тоже всегда округляю, причем использую симметричное округление, не создающее смещения уровня, хотя это чуть
сложнее. Всё это чистый перфекционизм, я видел много примеров, когда никто не
заморачивается тонкостями. Это одна из причин, по которой я не люблю обработку звука в софте.
Результат может сильно зависеть от квалификации девелопера, и проверить корректность весьма непросто.
Если чуть-чуть экономить на каждом шагу, то
можно получить "эффект курочки" - клюёт по зёрнышку, а весь двор - загажен.

[dortonyan]

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

Так прибавление +0.5LSB это вроде как и есть симметричное округление, т.е. отбрасывание разрядов как раз и создает асимметрию на эти 0.5LSB.
Например:
При нулевом значении на входе: если дробная часть (отбрасываемые биты) меньше -0.5 (скажем -0.8), то после суммирования с +0.5 результат на выходе будет -1 (т.к. при отбрасывании разрядов отрицательного числа знак сохраняется);
если дробная часть больше +0.5, то результат соот-но будет +1;
если больше -0.5 (например -0.2) или меньше +0.5 (+0.3), то результат на выходе будет нуль.

Соб-но потому я обратил на округление внимание, что когда после суммирования с шумом просто отбрасывал разряды, значение результата при нулевых данных на входе колебалось между нулем и -1. Когда сделал округление (добавил суммирование 0.5LSB), результат стал колебаться от +1 до -1, как и должно быть.

[tomtit]

Да, но двоичное представление чисел несимметрично относительно 0.
Отрицательных на 1 больше.

[dortonyan]

Понял.
Т.е. в моем случае округление в +1 получается при условии, когда значение после запятой >= 0.5, а округление в -1 кода значение строго < -0.5.
А симметричное, когда +0.5 округляется в единицу, а -0.5 - в минус единицу.

Offтопик:
P.S.
Вспомнил, что изначально сам так и делал (анализировал отбрасываемое значение по модулю с последующим округлением с учетом знака числа), но потом вспомнил про метод суммирования 0.5, который показался более изящным решением.

[tomtit]

Всё проще. К положительному +0.5, а к отрицательному +0.499(9). Т.е. на единичку младшего разряда меньше.
Больше напрягает обработка переноса и возможный клип после.

[sia_2]

Всё проще. К положительному +0.5, а к отрицательному +0.499(9). Т.е. на единичку младшего разряда меньше.
Больше напрягает обработка переноса и возможный клип после.

Аппаратно это реализуется добавлением перед усечением всегда 0.011111111..., и еще инвертированного знакового бита, сдвинутого на соответствующее число бит вправо. В принципе, последним в 99,9% случаев можно не заморачиваться. Все в двоичной форме, ессно. Клип/заворот проще всего предотвращать проверкой целой части на 011111...111.хххх, обнуляя в этом случае добавку перед усечением или обходя суммирование. Альтернативный вариант проверки, если сумматор внутри такта - сравнивать знаковые биты до и после суммирования, и выбирать исходный код, если знаки не равны.