[stoker 0]

Наверное это глупый вопрос, так что заранее прошу не пинать.

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

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

 

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

[fontp 0]

Наверное это глупый вопрос, так что заранее прошу не пинать.

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

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

 

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

 

Внешние устройства снабжены клоком синхронизации - не важно когда Вы загружаете ему регистры.

Главное не опоздать. Если что-то флагами выписывать - то понятно будет джитер.

Когда пытаются какой-нибудь CLOCK изобразить задним числом, забыв его при проектировании, флагами - то так и бывает. Или ещё устройство какое-нибудь, типа I2C, любят изобразить

из флагов люди, мыслящие по-микроконтроллерному типу. На, низких частотах, понятно, джитер не критичен, но процессор используется не по назначению

 

Если времени обработки не хватает - то это беда. Тогда обработку не делают

Если вопрос именно во времени обработки прерывания (не в алгоритме) то снизить издержки помогает блочная обработка и DMA

[rufitskiy 0]

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

 

Не совсем так...

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

 

> И ещё, если например порядок фильтра большой, то возможен ли случай когда частота вызова прерывания больше чем его обработка?

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

 

Примечание:

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

[fontp 0]

> И ещё, если например порядок фильтра большой, то возможен ли случай когда частота вызова прерывания больше чем его обработка?

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

 

Хм... Поздно пить "Ноотропил"

Что Вы будете склеивать, если не успеваете обработать ВСЕ отсчёты?

Или речь о чём?

[blackfin 28]

Что Вы будете склеивать, если не успеваете обработать ВСЕ отсчёты?

Или речь о чём?

Речь, видимо, о том, что не ВСЕ задачи требуют обработки ВСЕХ отсчетов.

Например MJPEG кодер вполне может пропустить неколько кадров, если не успевает их сжать.

[fontp 0]

Речь, видимо, о том, что не ВСЕ задачи требуют обработки ВСЕХ отсчетов.

Например MJPEG кодер вполне может пропустить неколько кадров, если не успевает их сжать.

 

Принимается.

Я даже могу представить себе ещё одну ситуацию.

Если обработка достаточно сложная (с условными переходами) то время обработки некоторого блока является случайной величиной. Тогда можно даже варьировать размер блока в зависимости от оставшегося времени. При достаточно глубокой буферизации это может работать.

Тогда можно перейти от максимального времени обработки к среднему

 

Но возвращаясь к вопросу о фильтре :-) Тут или-или

[stoker 0]

Короче, ФПГА подсоеденена к ДСП через EMIF(внешний интерфейс памяти), из ФПГА завожу прерывание на ДСП - по которому ДСП будет брать отсчёты. Использую с6713b 300Мгцовый.

 

В общем, я ещё пока не делал серьёзную обработку, просто на всякий случай спрашиваю, вдруг столкнусь с проблеммой.

Там на EMIF шине ещё 1 прерывание - типа от коммуникационного блока. Но тут я могу и поллингом

сделать. И ещё СДРАМ сидит там же.

 

> Хм... Поздно пить "Ноотропил"

Надеюсь не придётся. :)

 

Насчет ДМА тоже думал, но никогда с этим не работал. Вкратце прочитал - вроде не должно быть сложно.

Смысл обработки:

НЧ Фильтрация 300Гц. действительная и мнимая часть. Нахождение угла и амплитуды. Частота дискретизации может быть разной. Скорее всего 10-100Кгц. Пытаюсь прикинуть...Короче это в общих чертах, так как в математике я ещё до конца не разобрался.

Изменено 24 октября, 2007 пользователем stoker

[blackfin 28]

Но возвращаясь к вопросу о фильтре :-) Тут или-или

...или фильтр адаптивный.. ;)

[stoker 0]

...или фильтр адаптивный.. ;)

Нет, думаю обычны FIR

Забыл написать. Обработанные данные я должен отослать в ту же ФПГА.

Изменено 24 октября, 2007 пользователем stoker

[blackfin 28]

Нет, думаю обычный FIR

Забыл написать. Обработанные данные я должен отослать в ту же ФПГА.

А затолкать фильтр в ФПГА никак?

[stoker 0]

А затолкать фильтр в ФПГА никак?

Там просто другие фильтры и обработка стоит. Да и умножителей не ососбо там, использую Спартан 3. Просто сделать фильтр скажем, на 60 коэфициентов, наверное, прощще будет в дсп сделать.

К тому же хочется перейти к floating point арифметике.

Изменено 24 октября, 2007 пользователем stoker

[rufitskiy 0]

Хм... Поздно пить "Ноотропил"

Что Вы будете склеивать, если не успеваете обработать ВСЕ отсчёты?

Или речь о чём?

 

ИМХО задача обработки реального времени на ДСП можно побить на три шага

1. Захват буфера

2. Обработка буфера

3. Передача результата.

 

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

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

 

Теперь несколько слов о "склеивании".

Когда идёт работа с видео и другими хорошо пакетизируемыми сигналами - это не проблема. Пришёл кадр,упал в буффер, вызвалось прерывание, он обработан, ждём следующего.

А в случае непрерывных сигналов (например, аудио сигнал, или биосигналы: плетисмограмма, энцефалограмма) нельзя фильтровать в пределах буфера. Т.е. в случае оконного фильтра свёрточное окно "доползло" до конца буффера и упёрлось в его окончание . Сворачивать его с нулями нельзя, отбрасывать - тоже (будут характерные щелчки). Вот здесь и возникает необходимость "склеивания" соседних буфферов. т.е. нельзя выкидывать последние отсчёты предыдущего буфера при приходе очередного.

Близкая песня для видео-компрессоров. В H.263 требуется предыдущий кадр, чтобы сформировать очередной P-кадр. Однако, если нужно отсылать только I-кадры - учёт предыдущего кадра делать смысла нету.

 

2 stoker:

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

Обратную передачу можно провести так же: ДСП пишет буффер в память, делает writeBack кэша, ели память внешняя и "прерывает" FPGA (наверное, через GPIO проца).

Изменено 24 октября, 2007 пользователем Vasiliy Rufitskiy

[stoker 0]

ИМХО задача обработки реального времени на ДСП можно побить на три шага

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 или более - это выльется в ошибку измерения фазы.

Изменено 24 октября, 2007 пользователем stoker

[DS 0]

Конкретно в Вашем случае лучше подойдут БИХ. Вы же сигнал потом в системе обратной связи будете использовать, там не очень важна крутизна спада, зато важно поведение фазы. Тут лучше взять цифровой аналог фильтров на операционниках, заодно и нагрузка на процессор сильно уменьшится.

При 300 Мгц проце не должно возникнуть ситуации с тем, что не успеете обработать отсчеты в 100 Кгц. Даже если синус - косинус вычислять каждый раз, а не таблицу брать.

[petrov 7]

Там просто другие фильтры и обработка стоит. Да и умножителей не ососбо там, использую Спартан 3. Просто сделать фильтр скажем, на 60 коэфициентов, наверное, прощще будет в дсп сделать.

 

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

 

Амплитуду и аргумент комплексного числа можете одним CORDICом последовательным обсчитать.

 

Конечно если делать на FPGA то усилий от разработчика больше потребуется чем при программной обработке на процессоре.

Изменено 25 октября, 2007 пользователем petrov