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

[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