Фильтрация на ДСП в реальном времени, Есть вопросик Опции

[stoker]

Наверное это глупый вопрос, так что заранее прошу не пинать.
Насколько я понимаю, процесс фильтрации в ДСП в реальном времени обычно происходит по схеме: по прерыванию (частота вызовов = частоте дискретизации) происходит считывание входного отсчета и вычисление нового выходного отсчета. Время вызова прерывания не стабильно. Имеет задержки от 1 до нескольких тактов проца + задержки при считывании данных по шине. Собственно вопрос - как это может повлиять на качество выходного сигнала? Если в ФПГА все происходит синхронно, тут вопросов нет, а как это происходит в ДСП мне немного не понятно.
И ещё, если например порядок фильтра большой, то возможен ли случай когда частота вызова прерывания больше чем его обработка? Если такое бывает, как обычно поступают? Я сам еще никогда не делал обработку реального времени в ДСП, тока начинаю, поэтому пытаюсь разобраться в теории.

ps. Прошу прощения если подобная тема есть, но я вроде не нашёл.

[Vasiliy Rufitski...]

> процесс фильтрации в ДСП в реальном времени обычно происходит по схеме: по прерыванию (частота вызовов = частоте дискретизации) происходит считывание входного отсчета

Не совсем так...
ДСП имеет оттдельный интерфейс для подключения аудио кодеков. По мере того, как аудо-кодек отсылает данные, в ДСП происходит прерывание. Однако, по прерыванию приходит не один отсчёт, а целый буффер, который интерфейс ДСП пишет сразу в память. Также предусматривается буфферизация (т.е. интерфейс пишет сначала в один буффер, потом во второй, потом в третий, и снова в первый, второй, третий), так что если прерывание вовремя не было обработано, ничего страшного не произойдёт.

> И ещё, если например порядок фильтра большой, то возможен ли случай когда частота вызова прерывания больше чем его обработка?
Основная заморочка будет в "склеивании буфферов", поступающих из обработчика прерываний ДСП. Но это вполне реализуемо дополнительной буфферизацией в софте верхнего уровня.

Примечание:
Все эти комментарии не описывают конкретной реализации, а только принцип.В частности, обработчик прерывания обычно спрятан в соответствующую библиотеку, вариантов аудио-интерфейсов у ДСП тоже множество. Я описывал mcBSP у DM642

[fontp]

> И ещё, если например порядок фильтра большой, то возможен ли случай когда частота вызова прерывания больше чем его обработка?
Основная заморочка будет в "склеивании буфферов", поступающих из обработчика прерываний ДСП. Но это вполне реализуемо дополнительной буфферизацией в софте верхнего уровня.

Хм... Поздно пить "Ноотропил"
Что Вы будете склеивать, если не успеваете обработать ВСЕ отсчёты?
Или речь о чём?

[Vasiliy Rufitski...]

Хм... Поздно пить "Ноотропил"
Что Вы будете склеивать, если не успеваете обработать ВСЕ отсчёты?
Или речь о чём?

ИМХО задача обработки реального времени на ДСП можно побить на три шага
1. Захват буфера
2. Обработка буфера
3. Передача результата.

В то время, как второй и третий шаги выполняются чётко последовательно, захват буфера осуществляется по прерыванию от соответствующего интерфейса ДСП. Причём, прерывание возникает НЕ ПО ПРИХОДУ ОТСЧЁТА, а по приходу целого множества отсчётов (буффера).
Я работал только с TI-ными ДСП (обработка видео и аудио), по крайней мере там сделано так. У AD-ных блэкфинов вроде так же. Если где-то в коде обработка прерываний запрещается, а потом восстанавливается, либо время обработки прерывания велико - то возможна "потеря буффера". Во избежание этого выделяется несколько буфферов. Разумеется, потеря буффера НЕИЗБЕЖНА если время обработки буффера больше времени между приходом соседних буфферов.

Теперь несколько слов о "склеивании".
Когда идёт работа с видео и другими хорошо пакетизируемыми сигналами - это не проблема. Пришёл кадр,упал в буффер, вызвалось прерывание, он обработан, ждём следующего.
А в случае непрерывных сигналов (например, аудио сигнал, или биосигналы: плетисмограмма, энцефалограмма) нельзя фильтровать в пределах буфера. Т.е. в случае оконного фильтра свёрточное окно "доползло" до конца буффера и упёрлось в его окончание . Сворачивать его с нулями нельзя, отбрасывать - тоже (будут характерные щелчки). Вот здесь и возникает необходимость "склеивания" соседних буфферов. т.е. нельзя выкидывать последние отсчёты предыдущего буфера при приходе очередного.
Близкая песня для видео-компрессоров. В H.263 требуется предыдущий кадр, чтобы сформировать очередной P-кадр. Однако, если нужно отсылать только I-кадры - учёт предыдущего кадра делать смысла нету.

2 stoker:
Действительно ли Вам необходимо прерывать процессор по приходу каждого отсчёта? Если есть интерфейс черех EMIF, то ИМХО лучше написать из FPGA целый буффер, прервать проц, а проц уже его прочитает и обработает (только о когерентности кэша при чтении из внешней памяти не забудте!). Архитектура ДСП вроде как не расчитана на "поотсчётную" обработку: порушится конвеер, многократная передача управления обработчику прерывания и обратно также не прибавит производительности.
Обратную передачу можно провести так же: ДСП пишет буффер в память, делает writeBack кэша, ели память внешняя и "прерывает" FPGA (наверное, через GPIO проца).

Сообщение отредактировал Vasiliy Rufitskiy - Oct 24 2007, 18:31

[stoker]

ИМХО задача обработки реального времени на ДСП можно побить на три шага
1. Захват буфера
2. Обработка буфера
3. Передача результата.

В то время, как второй и третий шаги выполняются чётко последовательно, захват буфера осуществляется по прерыванию от соответствующего интерфейса ДСП. Причём, прерывание возникает НЕ ПО ПРИХОДУ ОТСЧЁТА, а по приходу целого множества отсчётов (буффера).
Я работал только с TI-ными ДСП (обработка видео и аудио), по крайней мере там сделано так. У AD-ных блэкфинов вроде так же. Если где-то в коде обработка прерываний запрещается, а потом восстанавливается, либо время обработки прерывания велико - то возможна "потеря буффера". Во избежание этого выделяется несколько буфферов. Разумеется, потеря буффера НЕИЗБЕЖНА если время обработки буффера больше времени между приходом соседних буфферов.

Смысл такой, когда в ФПГА готовы 2 компоненты сигнала I,Q, возникает прерываение. ДСП считывает обе компоненты последовательно, они по 32 бит. Потом обработка - фильтрация, нахождение угла и длинны вектора. ФПГА не ждёт ДСП успеет он или нет. Я так вроде прикинул, что должен успеть. На крайний случай, расчёт угла и длинны расположу в другом месте. Потом запись значений обратно в ФПГА для дальнейших инструкций. Из моих рассуждений получается 5 этапов:

1. Синхронно. выставление значений в ФПГА. Выставление прерывания.
2. Несинхронно. Имеется джиттер. Обработка прерывания в ДСП.
3. Расчтёт результатов.
4. Несинхронно. Имеется джиттер. Передача данных в регистр ФПГА.
5. Синхронно. В ФПГА по соответсвующему клоку данные из входного регистра уже синхронно поступают в другие модули.

Если я правильно понимаю, главное обеспечить синхронность 1 и 5 пунктов. Тогда несинхронность 2-3 пунктов не окажут влияния? Да, и время выполнения п. 2-4 должно быть меньше чем частота поступления новых отсчетов, я прав? Вообще говоря, так правильно делать?
Просто я пересел на ДСП после ФПГА, и для меня последовательный код, да и неравномерность вызова прерываний интуитивно говорят что могут быть подводные камни, поэтому пытаюсь все осмыслить.

Теперь несколько слов о "склеивании".
Когда идёт работа с видео и другими хорошо пакетизируемыми сигналами - это не проблема. Пришёл кадр,упал в буффер, вызвалось прерывание, он обработан, ждём следующего.
А в случае непрерывных сигналов (например, аудио сигнал, или биосигналы: плетисмограмма, энцефалограмма) нельзя фильтровать в пределах буфера. Т.е. в случае оконного фильтра свёрточное окно "доползло" до конца буффера и упёрлось в его окончание . Сворачивать его с нулями нельзя, отбрасывать - тоже (будут характерные щелчки). Вот здесь и возникает необходимость "склеивания" соседних буфферов. т.е. нельзя выкидывать последние отсчёты предыдущего буфера при приходе очередного.
Близкая песня для видео-компрессоров. В H.263 требуется предыдущий кадр, чтобы сформировать очередной P-кадр. Однако, если нужно отсылать только I-кадры - учёт предыдущего кадра делать смысла нету.

Хорошо, что у меня не видео...

Действительно ли Вам необходимо прерывать процессор по приходу каждого отсчёта? Если есть интерфейс черех EMIF, то ИМХО лучше написать из FPGA целый буффер, прервать проц, а проц уже его прочитает и обработает (только о когерентности кэша при чтении из внешней памяти не забудте!). Архитектура ДСП вроде как не расчитана на "поотсчётную" обработку: порушится конвеер, многократная передача управления обработчику прерывания и обратно также не прибавит производительности.
Обратную передачу можно провести так же: ДСП пишет буффер в память, делает writeBack кэша, ели память внешняя и "прерывает" FPGA (наверное, через GPIO проца).

На данный момент я полагаю что скорее всего каждый отсчет. Что означает когерентность кэша?
Насчет конвеера, я так понял, если я например попытаюсь забуферезировать 2 отсчета I,Q, то потом выдав 2 выходных отсчета, я смогу сократить время обработки? А требование к времени от приёма до выдачи данных на ФПГА уже 2-х отсчетов будет таким же?

Вообще говоря, главная задача состоит в измерении фазы входного сигнала. Если я смогу обеспечить постоянную задержку между входными и выходными отсчетами на ДСП, то это можно компенсировать, а если вдруг пропущу 1 или более - это выльется в ошибку измерения фазы.

Сообщение отредактировал stoker - Oct 24 2007, 20:07

[Vasiliy Rufitski...]

При вашей частоте дискретизации в 100 КГц вы стали бы по умножителю на коэффициент ставить? На ваш фильтр хватит одного умножителя, более того даже само умножение последовательно сделать успеете.

Этот вопрос очень правомерен. В принципе можно целиком задачу вычисления фазы переложить на ДСП, он очень даже успеет (насколько я понял, Вы рассчитываете комплексную огибающую через преобразование Гильберта).

Синхронно. выставление значений в ФПГА. Выставление прерывания.

EMIF - это интерфейс памяти. Есть прерывание проца (через GPIO входы), есть тактирование EMIF'а - это суть разные вещи. Может быть, xapp753.pdf Вам поможет...

Если я правильно понимаю, главное обеспечить синхронность 1 и 5 пунктов. Тогда несинхронность 2-3 пунктов не окажут влияния? Да, и время выполнения п. 2-4 должно быть меньше чем частота поступления новых отсчетов, я прав?

В общем, да. Есть время между захватом отсчётов, а есть время между их обработкой. На точность результата может повлиять только джиттер захвата + потери отсчётов.

Вообще говоря, так правильно делать?

Правильнее ИМХО писать блок отсчётов из ФПГА в память , прерывать проц и читать уже из проца этот же кусок памяти. Можно это делать и по 1 отсчёту, проц должен успеть. Только это будет очень некрасиво.

Обмен данными между процом и ФПГА по емиф идут через область общей памяти. ФПГА пишет по адресу некоторые данные в общую память через EMIF контроллер проца. Программно это поддерживать никак не надо, только при старте его правильно сконфигурировать. При записи данных в общую память прерываний не возникает.
К вопросу

Что означает когерентность кэша?

При записи данных внешним устройством в область внутренней памяти проца никаких проблем не будет: проц автоматически обновит закэшированные участки. А вот когда запись идёт во внешнюю память - проц об этом не догадывается. И возможна ситуация, когда ФПГА запишет данные, а проц будет читать их не из внешней памяти а из своего внутреннего L2 кэша: естественно они будут неверными. Эта ситуация (несоответствие реальных данных и закэшированных) называется некогерентностью (incoherency) кэша.

Архитектура ДСП ориентирована на обработку массивов в памяти, а не потоков по последовательной шине. Т.е. цикл for, если конвеер не рушится, может выполнять параллельно сразу несколько итераций.

Надеюсь, я ответил на Ваши вопросы.

[stoker]

Этот вопрос очень правомерен. В принципе можно целиком задачу вычисления фазы переложить на ДСП, он очень даже успеет (насколько я понял, Вы рассчитываете комплексную огибающую через преобразование Гильберта).

В ФПГА я делаю понижающее преобразование входного сигнала, перемножением на sin/cos с DDS, потом подаю на ДСП и фильтрую двойную частоту. Насчет пробразователя Гильберта, думал, его нужно ставить в ФПГА сразу после входного сигнала, тада можно исключить фильтрацию двойной частоты. Но пока этот метод оставлю на потом.

EMIF - это интерфейс памяти. Есть прерывание проца (через GPIO входы), есть тактирование EMIF'а - это суть разные вещи. Может быть, xapp753.pdf Вам поможет...

Это я понимаю. Я уже делал на этом ДСП всякого рода интерфесные вещи ну и простейшую обработку. Все делалось по прерыванию. Просто в реальном времени особо пока ничего не делал и поэтому хочу оценить насколько у меня это получится

Обмен данными между процом и ФПГА по емиф идут через область общей памяти. ФПГА пишет по адресу некоторые данные в общую память через EMIF контроллер проца. Программно это поддерживать никак не надо, только при старте его правильно сконфигурировать. При записи данных в общую память прерываний не возникает.
К вопросу
При записи данных внешним устройством в область внутренней памяти проца никаких проблем не будет: проц автоматически обновит закэшированные участки. А вот когда запись идёт во внешнюю память - проц об этом не догадывается. И возможна ситуация, когда ФПГА запишет данные, а проц будет читать их не из внешней памяти а из своего внутреннего L2 кэша: естественно они будут неверными. Эта ситуация (несоответствие реальных данных и закэшированных) называется некогерентностью (incoherency) кэша.

Точно, я уже на этот как то раз напоролся. Там помоему тип volatile решает эту проблемму.

Архитектура ДСП ориентирована на обработку массивов в памяти, а не потоков по последовательной шине. Т.е. цикл for, если конвеер не рушится, может выполнять параллельно сразу несколько итераций.
Надеюсь, я ответил на Ваши вопросы.

Насчет конвеера, я подумаю, но скорее всего ДСП успеет как говорили выше. Во всяком случае идею я понял, так что спасибо всем.

Сообщение отредактировал stoker - Oct 25 2007, 17:06