Полная версия этой страницы: Вопрос по IP Core FFT
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
Коллеги, мне тут понадобилось применить в проекте FFT на 512 точек и столкнулся с непонятным поведением выхода корки(см. видео). Сигнал source_valid ведёт себя совершенно неадекватно - длительность непредсказуема и появляется совсем не в тот момент когда должен. Прошу помощи коллективного разума, я уже не знаю что и думать. Режим работы - buffered burst. В этом же проекте рядом стоит FFT на 1024 точки и работает как танк. 512 точек какой то особый размер?
Чиста для определённости.... Ольтэра? (Знакомая мне корка хилинха на ахи).
Впрочем, по названиям сигналов можно понять что и тут смысл тот же.
Тогда имею сказать следующее::
фраза """длительность непредсказуема и появляется совсем не в тот момент когда должен"""
некорректна В ПРИНЦЫПЕ по отношению к таким шынам.
Да ничё она не должна. Код, обслуживающий корку, не имеет права предполагать, как она будет выставлять готовность входа и выхода.
Она может это делать на весь пакет сразу или по кусочкам - как ей нравится.
И это действительно может неочевидно зависеть от разных факторов (например соотношения длин заюзаных коркой буферов и длины бпф).
Так что это не критерий.
Вот если даёт неправильный бпф, тогда другое дело.
Впрочем, по названиям сигналов можно понять что и тут смысл тот же.
Тогда имею сказать следующее::
фраза """длительность непредсказуема и появляется совсем не в тот момент когда должен"""
некорректна В ПРИНЦЫПЕ по отношению к таким шынам.
Да ничё она не должна. Код, обслуживающий корку, не имеет права предполагать, как она будет выставлять готовность входа и выхода.
Она может это делать на весь пакет сразу или по кусочкам - как ей нравится.
И это действительно может неочевидно зависеть от разных факторов (например соотношения длин заюзаных коркой буферов и длины бпф).
Так что это не критерий.
Вот если даёт неправильный бпф, тогда другое дело.
Цитата(Dr.Alex @ Jun 20 2017, 20:25) 
Да ничё она не должна. Код, обслуживающий корку, не имеет права предполагать, как она будет выставлять готовность входа и выхода.
Спасибо! Только я в своё время поработал с разными фурьешками и ни разу не видел того о чём Вы сказали. На худой конец есть же ug_fft с картинками...
Но на всякий случай завтра проверю эту гипотезу.
Цитата(Dr.Alex @ Jun 20 2017, 20:25)
Вот если даёт неправильный бпф, тогда другое дело.
С этого то всё и началось. На выходе сигнал очень сильно зашумлён, по динамическому диапазону есть зона примерно децибел 30 в которой изменение уровня входного сигнала не приводит к изменению уровня выходного
Проверил, Ваше предположение не подтвердилось. Обратите внимание на дистанцию между sop и eop, маловато будет для 512 точек. И ещё обратите внимание на положение eop относительно valid, он не вложен.
Сделайте скрин настроек в визарде. И как подключили напишите. Пробовал разные размеры, работает как надо. Проверьте что на входе fftpts_in у вас, может там неправильно задан размер блока?
Цитата(Burenkov Sergey @ Jun 21 2017, 11:02)
Сделайте скрин настроек в визарде. И как подключили напишите. Пробовал разные размеры, работает как надо. Проверьте что на входе fftpts_in у вас, может там неправильно задан размер блока?
У меня режим работы - buffered burst, порта fftpts_in нет.
Код
c3 : component fft512 port map (
clk => iclk200, -- clk.clk
reset_n => reset_n, -- rst.reset_n
sink_valid => out_win_val, -- sink.sink_valid
sink_ready => sink_ready, -- .sink_ready
sink_error => "00", -- .sink_error
sink_sop => out_win_sop, -- .sink_sop
sink_eop => out_win_eop, -- .sink_eop
sink_real => out_win_data_re24, -- .sink_real
sink_imag => out_win_data_im24, -- .sink_imag
inverse => inverse, -- .inverse
source_valid => source_valid, -- source.source_valid
source_ready => hi, -- .source_ready
source_error => source_error, -- .source_error
source_sop => open, -- .source_sop
source_eop => open, -- .source_eop
source_real => source_real24, -- .source_real
source_imag => source_imag24, -- .source_imag
source_exp => source_exp -- .source_exp
);
clk => iclk200, -- clk.clk
reset_n => reset_n, -- rst.reset_n
sink_valid => out_win_val, -- sink.sink_valid
sink_ready => sink_ready, -- .sink_ready
sink_error => "00", -- .sink_error
sink_sop => out_win_sop, -- .sink_sop
sink_eop => out_win_eop, -- .sink_eop
sink_real => out_win_data_re24, -- .sink_real
sink_imag => out_win_data_im24, -- .sink_imag
inverse => inverse, -- .inverse
source_valid => source_valid, -- source.source_valid
source_ready => hi, -- .source_ready
source_error => source_error, -- .source_error
source_sop => open, -- .source_sop
source_eop => open, -- .source_eop
source_real => source_real24, -- .source_real
source_imag => source_imag24, -- .source_imag
source_exp => source_exp -- .source_exp
);
Не заметил про buffered burst, в таком режиме не тестил... Может на вход неправильный размер пакета подаете? В моделировании работает нормально?
Цитата(Burenkov Sergey @ Jun 21 2017, 11:57)
Не заметил про buffered burst, в таком режиме не тестил... Может на вход неправильный размер пакета подаете? В моделировании работает нормально?
В моделировании не пробовал, 16-й квартус не генерит файл *.vho при генерации корки. Размер пакета на входе правильный, проверяю регулярно.
Сделал 256 точек - результат на видео. Я просто в шоке...
Маленькое замечание: лучше сразу писать разработчика ядра / целевую плис. Вот по Xilinx как раз неделю назад делал, мог бы подсказать по FFT ядру. Ну а тут вероятно альтера.
Цитата(AVR @ Jun 21 2017, 12:54)
Маленькое замечание: лучше сразу писать разработчика ядра / целевую плис. Вот по Xilinx как раз неделю назад делал, мог бы подсказать по FFT ядру. Ну а тут вероятно альтера.
Принимается. Альтера, Аррия-5, Q16.0
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.