Golikov 0 12 мая, 2017 Опубликовано 12 мая, 2017 · Жалоба Если фифо сделано правильно, то любая. Если неправильно то никакая... Может реально не в клоке проблема? А данные откуда идут? И как они с клоком связаны? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
john72 0 12 мая, 2017 Опубликовано 12 мая, 2017 (изменено) · Жалоба Если фифо сделано правильно, то любая. Если неправильно то никакая... Может реально не в клоке проблема? А данные откуда идут? И как они с клоком связаны? ФИФО сформировано Altera wizard. Данные идут по шине I2S. ФИФО используется в качестве переходного звена между клоковыми доменами с одинаковыми частотами, но асинхронными. В симуляторе все работает. Констрейны прописал. Может с клоком никак и не связано, только с одним генератором клока устройство работает несколько часов, с другим работает несколько минут и все поплыло... Изменено 12 мая, 2017 пользователем Evgeny72 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 12 мая, 2017 Опубликовано 12 мая, 2017 · Жалоба принимается I2S как? Второй клок это клок I2S? Прием на его частоте и пихание на той же частоте в FIFO или как? Опять же хорошо понять что есть поплыло. Что работать перестало понятно, но если подробнее описать как оно перестало работать, то возможно будет понятнее насчет причин. Констраины какие прописаны? Просто путь от клока к клоку зафалсен или как? С симулятором понятно. В визарде при создании какой режим защиты от мета-стабильности был выставлен? какие еще асинхронные и прочие входные сигналы есть? Защищены ли они от мета-стабильности? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sonycman 0 12 мая, 2017 Опубликовано 12 мая, 2017 · Жалоба ФИФО сформировано Altera wizard. Данные идут по шине I2S. ФИФО используется в качестве переходного звена между клоковыми доменами с одинаковыми частотами, но асинхронными. В симуляторе все работает. Констрейны прописал. Может с клоком никак и не связано, только с одним генератором клока устройство работает несколько часов, с другим работает несколько минут и все поплыло... То есть у вас в ПЛИС схема, которая имеет собственный генератор клока - к примеру, 49.152 МГц, и есть второй клок с такой же аудио частотой, но подающийся с другой платы? Получается I2S Master интерфейс с подачей внешнего мастер клока, и генерацией на его основе бит клока для источника данных? И в FIFO вы пишете с частотой внешнего клока, а считываете его с частотой (пусть одинаковой) уже другого генератора? Иначе откуда берётся асинхронность? Тогда использование FIFO для записи и чтения просто по асинхронным клокам пусть и одинаковой частоты без учёта опустошения\переполнения неправильно. Частота будет в любом случае разной, пусть и незначительно, что привёдет к рассинхронизации данных через определённое время. Попробуйте в симуляторе, как будет работать двухклоковый FIFO, если на него подать немножко разные частоты, к примеру: 49.152000 и 49.152999 МГц. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
john72 0 12 мая, 2017 Опубликовано 12 мая, 2017 (изменено) · Жалоба принимается I2S как? не совсем понял, попытаюсь описать. Имеем сигналы в I2S: BCK, LRCK, DATA. Со стороны записи в ФИФО. Сигналы BCK, LRCK, DATA не пропускаю через входные dff. Пробовал ставить на входах LRCK, DATA по одному или двум dff, тактовый на dff подавал входной сигнал BCK. По всей видимости не так отконстрейнил, не смог добиться исходного положения данных DATA, относительно сигнала LRCK - сместились на такт. Второй клок это клок I2S? Прием на его частоте и пихание на той же частоте в FIFO или как? Отчасти да. Только не входной клок, это клок с генератора (CLK_EXT), с которого работает все на стороне чтения ФИФО и дальше после него, в том числе и микросхемы ЦАП. Нужная сетка выходных частот BCK и LRCK осуществляется делителями (счетчиками) на стороне чтения. Из входного сигнала LRCK получаю импульс для записи данных в ФИФО и импульс указателя начала пакета для сигнала DATA на приемной стороне. Данные и импульс указателя передаю через ФИФО. Выходной сигнал LRCK формируется от импульса указателя начала пакета. Да, пихание происходит на частоте входного сигнала BCK, без изменений. Опять же хорошо понять что есть поплыло. Что работать перестало понятно, но если подробнее описать как оно перестало работать, то возможно будет понятнее насчет причин. Плывет импульс указателя начала пакета для сигнала DATA. На осциллографе этот импульс с выхода ФИФО начинает скакать на пол периода выходного сигнала LRCK. Соответственно, начинает плыть выходной сигнал LRCK, он получен из этого импульса, ну и данные тоже. Вывел наружу асинхронный сигнал сброса ФИФО. Сбрасываю ФИФО после такого плывуна, какое-то время работает нормально. Констраины какие прописаны? Просто путь от клока к клоку зафалсен или как? derive_clock_uncertainty create_clock -name {CLK50Mhz} -period 20.000 -waveform { 0.000 10.000 } [get_ports {clk50Mhz}] клок для другой схемы не относящийся к данной теме create_clock -name {BCK} -period 40.000 -waveform { 0.000 20.000 } [get_ports {BCK}] клок входного сигнала BCK, I2S create_clock -name {CLK_EXT} -period 20.000 -waveform { 0.000 10.000 } [get_ports {CLK_EXT}] клок с генератора, со стороны чтения ФИФО Возможно надо отконтстрейнить LRCK как клок? set_clock_groups -exclusive -group [get_clocks {BCK}] set_clock_groups -exclusive -group [get_clocks {CLK_EXT}] set_clock_groups -exclusive -group [get_clocks {CLK50Mhz}] пробовал так: set_false_path -from [get_clocks {CLK_EXT}] -to [get_clocks {BCK}] set_false_path -from [get_clocks {BCK}] -to [get_clocks {CLK_EXT}] Для ФИФО. set_false_path -from [get_registers {*dcfifo*delayed_wrptr_g[*]}] -to [get_registers {*dcfifo*rs_dgwp*}] set_false_path -from [get_registers {*dcfifo*rdptr_g[*]}] -to [get_registers {*dcfifo*ws_dgrp*}] В визарде при создании какой режим защиты от мета-стабильности был выставлен? 3 режим - Best metastability protection, best fmax, unsynchronised clocks 3 or more sync stage... How many sync stage? - 4 какие еще асинхронные и прочие входные сигналы есть? Защищены ли они от мета-стабильности? Сигнал третьего клока 50 МГц сам по себе, для других узлов внутри этой же ПЛИС. Логические входа, где просто 0 или 1, с них сигнал пропущен через пару dff. dff тактируются от CLK_EXT. И в FIFO вы пишете с частотой внешнего клока, а считываете его с частотой (пусть одинаковой) уже другого генератора? Иначе откуда берётся асинхронность? Да, все так. Тогда использование FIFO для записи и чтения просто по асинхронным клокам пусть и одинаковой частоты без учёта опустошения\переполнения неправильно. Частота будет в любом случае разной, пусть и незначительно, что привёдет к рассинхронизации данных через определённое время. Попробуйте в симуляторе, как будет работать двухклоковый FIFO, если на него подать немножко разные частоты, к примеру: 49.152000 и 49.152999 МГц. Начинаю считывать данные из ФИФО после смены состояния на выходе rdempty. Симулировал с разыми частотами, 1:1, 2:1, (вход:выход) все ок. Видимо 10мс длины симуляции мало для отображения этой проблемы. Изменено 12 мая, 2017 пользователем Evgeny72 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sonycman 0 12 мая, 2017 Опубликовано 12 мая, 2017 · Жалоба Начинаю считывать данные из ФИФО после смены состояния на выходе rdempty. Симулировал с разыми частотами, 1:1, 2:1, (вход:выход) все ок. Видимо 10мс длины симуляции мало для отображения этой проблемы. Симулировать надо не кратными частотами, чтобы увидеть рассинхрон, и на большую длительность, чтобы стало заметно, как "поплывет" фаза фронтов тактовых сигналов. К примеру, если взять 49.152000 и 49.152999 МГц, как говорил выше, то сдвиг фазы между клоками ровно на один период произойдёт примерно за одну миллисекунду. Но это должен быть сдвиг только на один период BCLK, а не половина периода LRCK, как в вашем случае. Но это если генератор со стороны чтения быстрее того, который со стороны записи. Если наоборот - то будет переполнение FIFO. А что мешает формировать BCK и LRCK для ЦАПа, взяв за основу мастер клок с входного порта I2S? С того, где принимаете данные? Вам в любом случае надо синхронизироваться от входного интерфейса, от его генератора. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 12 мая, 2017 Опубликовано 12 мая, 2017 · Жалоба Блин какой-то тупик:) Куча клоков и фифо:), а есть шанс нарисовать блок схему с тем откуда какие сигналы и на какой частоте? Как я себе вижу задачу и как я бы ее решал. BCK - это вроде как клок, к нему должны быть синхронны данные DATA и LRCK. Имеет смысл по этому клоку принять данные в сдвиговый регистр и собрать слово данных. Дальше по этому же клоку слово надо пихать в FIFO, все синхронизации с LRCK должны быть сделаны здесь, то есть сразу собирайте слова для каналов. А из фифо надо выгребать слова на другом клоке, тогда все будет работать без плаванья, ну кроме проблемы с переполнением или опустошением FIFO. Констрайнить надо BCK на период с джитером, и офсет данных и клока от BCK, остальное должно фифо само законстраинить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sonycman 0 12 мая, 2017 Опубликовано 12 мая, 2017 · Жалоба А из фифо надо выгребать слова на другом клоке, тогда все будет работать без плаванья, ну кроме проблемы с переполнением или опустошением FIFO. Так у автора эта проблема и встаёт в полный рост. Он подал на ФИФО клоки с разных генераторов и в ус не дует, что будет, когда начнётся переполнение\опустошение данных. Проблема, имхо, решается либо просто - использованием одного и того же клока на входе I2S и на выходе ЦАПа - тогда и ФИФО не нужен особо. Либо не совсем просто - если требуется пересемплирование, то надо входной клок I2S на PLL наверное подавать и множить на требуемый коэффициент. Но тогда джиттер будет наверняка. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrew_su 1 12 мая, 2017 Опубликовано 12 мая, 2017 · Жалоба Приветствую. В похожем случае организовывал чтение из фифо на заведомо большей "внутренней" частоте, чем частота, на которой оно заполняется. Для этого пришлось добавить небольшой автомат, который отслеживал момент, когда фифо становится "почти пустым". Удачи. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sonycman 0 12 мая, 2017 Опубликовано 12 мая, 2017 · Жалоба Приветствую. В похожем случае организовывал чтение из фифо на заведомо большей "внутренней" частоте, чем частота, на которой оно заполняется. Для этого пришлось добавить небольшой автомат, который отслеживал момент, когда фифо становится "почти пустым". Удачи. Такой метод приведёт к большому джиттеру на ЦАПе, когда данные на него будут поступать неравномерно. Для качественного воспроизведения аудио это не подходит. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
john72 0 13 мая, 2017 Опубликовано 13 мая, 2017 · Жалоба Симулировать надо не кратными частотами, чтобы увидеть рассинхрон, и на большую длительность, чтобы стало заметно, как "поплывет" фаза фронтов тактовых сигналов. К примеру, если взять 49.152000 и 49.152999 МГц, как говорил выше, то сдвиг фазы между клоками ровно на один период произойдёт примерно за одну миллисекунду. Но это должен быть сдвиг только на один период BCLK, а не половина периода LRCK, как в вашем случае. Но это если генератор со стороны чтения быстрее того, который со стороны записи. Если наоборот - то будет переполнение FIFO. А что мешает формировать BCK и LRCK для ЦАПа, взяв за основу мастер клок с входного порта I2S? С того, где принимаете данные? Вам в любом случае надо синхронизироваться от входного интерфейса, от его генератора. Насчет симуляции - спасибо за совет, попробую. Можно сформировать BCK и LRCK для ЦАПа из входного I2S, но тут полностью теряется смысл применения ФИФО - привязка входных сигналов к внутреннему генератору. Проще поставить кучу dff на входные сигналы I2S и тактировать их от CLK_EXT, в моем случае внутренний генератор, джиттер очистить другим способом. Блин какой-то тупик:) Куча клоков и фифо:), а есть шанс нарисовать блок схему с тем откуда какие сигналы и на какой частоте? Как я себе вижу задачу и как я бы ее решал. BCK - это вроде как клок, к нему должны быть синхронны данные DATA и LRCK. Имеет смысл по этому клоку принять данные в сдвиговый регистр и собрать слово данных. Дальше по этому же клоку слово надо пихать в FIFO, все синхронизации с LRCK должны быть сделаны здесь, то есть сразу собирайте слова для каналов. А из фифо надо выгребать слова на другом клоке, тогда все будет работать без плаванья, ну кроме проблемы с переполнением или опустошением FIFO. Констрайнить надо BCK на период с джитером, и офсет данных и клока от BCK, остальное должно фифо само законстраинить. конечно нарисую. :rolleyes: В общем, так и сделано, как вы пишите. Скорее всего, у меня проблемы с переполнением или опустошением FIFO. Частоты входа I2S и внутреннего генератора никогда не будут точными. Так у автора эта проблема и встаёт в полный рост. Он подал на ФИФО клоки с разных генераторов и в ус не дует, что будет, когда начнётся переполнение\опустошение данных. Проблема, имхо, решается либо просто - использованием одного и того же клока на входе I2S и на выходе ЦАПа - тогда и ФИФО не нужен особо. Точно, в ус не дул, пока до самого не дошло. А возможно применение в моем случае dual clock RAM? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sonycman 0 13 мая, 2017 Опубликовано 13 мая, 2017 · Жалоба А возможно применение в моем случае dual clock RAM? А для чего, вы можете объяснить? Пока что, насколько я понимаю ситуацию, можно делать либо: 1. Прямая трансляция сигналов со входа I2S сразу на выход на DAC. Безо всяких промежуточных буферов\памяти\фифо. Это если не требуется никакая обработка потока. 2. FIFO на входе, как у вас, ждём, пока накопится достаточное количество слов, вычитываем сразу все - обрабатываем - записываем в другое FIFO, на выходе. Интерфейс I2S на входе и выходе тактируется строго от одного аудио мастер клока. Обработка работает на бОльшей частоте, чем интерфейс. 3. DMA - слова со входа I2S сразу пишутся в нужное место в памяти для дальнейшей обработки. На выходе другое DMA. По констрейнам - надо, наверное, задать set_input_delay для сигналов LRCK и DATA относительно их BCK для входного I2S. И на выходе на ЦАП - set_output_delay аналогично для LRCK и DATA относительно их BCK. ЗЫ: так а клок BCK на входе I2S является входным сигналом относительно ПЛИС, или выходным? Вы же указывали ранее, что "максимальная частота bit clock 24 мГц, но он уже идет в обратную сторону, от 10M08... к EPM1270..." Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
john72 0 13 мая, 2017 Опубликовано 13 мая, 2017 · Жалоба А для чего, вы можете объяснить? ЗЫ: так а клок BCK на входе I2S является входным сигналом относительно ПЛИС, или выходным? Вы же указывали ранее, что "максимальная частота bit clock 24 мГц, но он уже идет в обратную сторону, от 10M08... к EPM1270..." осуществить Clock Domain Crossing посредством ФИФО, делал когда-то на нескольких dff, не понравилось, импульс на выходе сильно "дрожал" после этой цепочки dff. Ну и в "целях повышения образованности", как говаривал один персонаж. BCK на входе I2S является входным на ФИФО, но должен быть такой же выходной сигнал для дальнейшей обработки. Или проще - I2S вход на ПЛИС - ФИФО - полностью I2S совместимый выход с ПЛИС Тут вот как - с 1270 идет клок 49.154 на 10M08, в 10M08 делится до той же частоты, что пришел с I2S входа на 10M08. С выхода 10M08 полностью I2S совместимый выход обратно приходит на 1270. Так уж получилось, две разные платы. На 1270 вся дальнейшая обработка осуществляется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sonycman 0 13 мая, 2017 Опубликовано 13 мая, 2017 · Жалоба Тут вот как - с 1270 идет клок 49.154 на 10M08, в 10M08 делится до той же частоты, что пришел с I2S входа на 10M08. С выхода 10M08 полностью I2S совместимый выход обратно приходит на 1270. Так уж получилось, две разные платы. На 1270 вся дальнейшая обработка осуществляется. А входящий клок на 49 МГц синхронен клоку BCK интерфейса I2S? Иными словами - это клок, на базе которого работает I2S 1270? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
john72 0 14 мая, 2017 Опубликовано 14 мая, 2017 · Жалоба А входящий клок на 49 МГц синхронен клоку BCK интерфейса I2S? нет, в том то и дело, что они не синхронны. Иными словами - это клок, на базе которого работает I2S в 1270? да, все верно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться