Костян

Можно входной порт захватывать при данном генераторе и на 400МГц. Достаточно работать в DDR, а FSM запускать на более низкой частоте. Для этого необходимо сделать десериализатор, например 1:10. Тогда FSM будет работать на 40МГц.

Спасибо.

Поясните, пожалуйста, это момент. Как имея комплексное БПФ и действительные отчеты снизить количество точек БПФ?

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

Это слишком долго. Свет меряем при открытой диафрагме, вычисляем кол-во приходящего света, закрываем диаграмму на нужно число.

Как в ЦАП данные передаете ? Какая частота дискретизации ? Триггеры выходные в лапах ?

Хм , действительно: P ~ f*U2 Не понятно, почему у меня частота ассоциировалась с квадратом.

квадратичная зависимость от частоты. P ~ f^2

Ожидайте примерно в 100 раз.

Берете D триггер . Инверсный выход nQ подаете на вход D. На вход тактирования подаете импульсы. Выход будет Q. Вот вам T триггер из D. На И-НЕ собирать в плис нельзя - работать не будет.

ПЛИС, это не набор логики. Так триггер не получится. Делайте из D триггера. З,Ы Изучите любой язык HDL. Схематик - тупиковый путь.

первый и второй вариант подойдет.

Скорее всего нет. Вам прийдется еще давать сигнал старта. Синхронизировать платы лучше всего от одного источника, соединяя дальше платы цепочкой. Т.е PLLout одной платы идет на PLLin другой. Разность фаз иногда не нужно выравнивать. Зависит от задачи. Разность фаз можно компенсировать в цифре.

Возмите длину сигнала x и y равной 15. И рассчитайте fft-15. Дополните нулями x и y до длины 16 и рассчитайте fft-16. Сравните результат.

Это само собой. Цель этой темы выбрать оптимальный алгоритм. Пока я склоняюсь к БПФ, но предположил, что возможно есть что-то более оптимальное.

Спасибо. Догадывался. Посмотрю.

Так не получиться. Для линейной свертки бы подошло, а для циклической - нет. Спасибо. Интересная книжка. Блейхута знал по теории кодирования. Алгоритм Виноградова просматриваю, возможно он поможет. Но в остальной части главы речь идет только про короткие свертки. 255 - уже далеко не короткая. Пока лишь в голове держу вариант БПФ с разными основаниями. Например 255 хорошо разбивается на radix2,radix5 и radix17. 5 куда не шло, но 17 существенно увеличит время рассчета при таком кол-ве точек.

не в скорости дело, нужна циклическая свертка на такое кол-во отчетов.

Подскажите, существует ли ускоренный алгоритм преобразования фурье на 2**N - 1 точек (например 255 или 511 точек) ?

Спасибо.

Выводить клок нужно только по специальным клоковым линиям и на спец. пины. Обычные I/O для этого не предназначены. Altera в этом плане - не до плисы.

Подскажите ускоренный алгоритм рассчета преобразования Фурье для получения 0..N/8-1 спектральных отчетов от N входных временных. Можно было бы считать БПФ на N отчетов с прореживанием по времени, а затем брать только первые N/8 сперктальных отчетов. Но необходимо уменьшить время рассчета. Возможно ли ?

Похоже на ошибку разработчиков PLL Поясните подробнее, пожалуйста. Ничего не понятно, как инвертировать в данном случае клок, чем сдвигать частоты источника ?

Столкнулся с некорректным поведением синтезатора XST. Исходный код следующий: module test( input clk, input rst, input [7:0] dataIn, output reg [31:0] dataOut ); //------------------------------ reg [5:0] count; reg [31:0] dataRegTemp; always @(posedge clk) if(rst) {dataOut,count,dataRegTemp} <= 0; else begin count <= count + 1; //32 битный регистр заполняем входными 8-битными данными dataRegTemp[count*8+:8] <= dataIn; //Когда счетчик равен 15 выгружаеем внутренний 32-битный регистр на выходной порт if (count == 15) dataOut <= dataRegTemp; end endmodule Проблема заключается в частичном индексном присвоении: dataRegTemp[count*8+:8] <= dataIn; XST, в отличии от Synplify и Modelsim, трактует это как dataRegTemp[count[2:0]*8+:8] <= dataIn; т.е не проверяет, выходит ли счетчик count за размеры индексов dataRegTemp и берет младшую часть счетчика. Тогда как Synplify не присваивает, если count выходит за границы индексов dataRegTemp. Исходный код и тестбенч в аттаче. На выходе следующие данные: Behavioral simulation Modelsim - # data 0d0c0b0a Post translate simulation after Synplify # data 0d0c0b0a Post translate simulation after XST - # data 15141312 Что это, баг или не внятное толкование стандарта ? testBag.zip

Есть же специальные Clock MUX. C PLL вытягиваете 0 и 180 градусов clock и подаете на такой MUX