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

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

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

Если времени обработки не хватает - то это беда. Тогда обработку не делают
Если вопрос именно во времени обработки прерывания (не в алгоритме) то снизить издержки помогает блочная обработка и DMA

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

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

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

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

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

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

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

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

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

В общем, я ещё пока не делал серьёзную обработку, просто на всякий случай спрашиваю, вдруг столкнусь с проблеммой.
Там на EMIF шине ещё 1 прерывание - типа от коммуникационного блока. Но тут я могу и поллингом
сделать. И ещё СДРАМ сидит там же.

> Хм... Поздно пить "Ноотропил"
Надеюсь не придётся.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

Сообщение отредактировал petrov - Oct 25 2007, 11:05