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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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


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


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


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

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

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

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

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


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


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


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