tocha

Надо для 32-bit fixed point, коеффициенты - в табличке. Вопросы масштабирования пока не волнуют. Будем искать....Вам спасибо за ответ, Ксения.

Именно так и сделал. А теперь хочу сделать это (IRFFT), то есть irfft симметричного комплексного сигнала у которого будет реальный выход. Макимально эффективно с точки зрения вычислительных затрат. Если можете ткнуть в готовый код, буду благодарен (в пятницу навскидку не нашёл - может плохо искал...). То есть, если я правильно понял, вы такое (IRFFT) делали: обратное преобразование симметричного сигнала длиной 2*N с помощью N-point ICFFT плюс немного вычислений и этим самым экономили ресурсы? Если скажете да, буду тоже благодарен.

Делая FFT для реального сигнала длиной 2*N, мы получаем комплексный результат, причём выход имеет complex-conjugate симметрию. И реализовать его можно через комплексное FFT длиной N + небольшие манипуляции и на этом сэкономить вычислительные ресурсы. Нужно сделать обратное преобразовние IFFT для комплексного входа длиной 2*N, который имеет свойство complex-conjugate симметрии. Соответствено результат будет реальным. Правильно то, шо если мы сделали RFFT длиной 2*N упрощённым методом(CFFT длиной N), то и complex conjugate IFFT длиной 2*N мы можем вычислить через FFT длиной N?

Есть такие

Передают на уровне IP, так и называется tdm over ip http://en.wikipedia.org/wiki/TDMoIP

Открываю mVision3 v3.62с - Смотрю описание PerformanceAnalyze и вижу сноску что команда не доступна в arm симуляторе. Я правильно понимаю, что в симуляторе (без железа) кол-во тактов ядра на выполнение куска кода подсчитать невозможно или я не прав? Если неправ, ткните где написано, как это сделать.

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

Думаю больше и подробнее чем в ГОСТе, врядли где будет описано. Да и изучать там вроде немного.

Думаю, что нет. Хотя всё возможно. В принципе, Зелакс - это готовое решение, осталось найти того, кто им поделится.)

Небольшой плис с буфером должно хватить шоб построить фапч для С1, выделить синхронизацию и данные -> в буфер -> из буфера в передатчик для UART. Найти контроллер с приёмником для С1 думаю врядли удастся.

Я говорю, что если у нас есть массив x0,x1,x2,x3 и мы хотим посчитать его ДПФ, для этого представляем его в виде: x0 x1 x2 x3, то такая последовательность действий: ДПФ(x0,x1)+ДПФ(x2,x3)+умножение на матрицу поворачивающих коеффициентов+ДПФ(x0,x2)+ДПФ(x1,x3) правильного результата не даст. Исходников есстественно нет, т.к. не смог это сделать. П.с. это не двумерное ДПФ, а вычисление одномерного большого ДПФ через комбинацию малых. Только частично. )

Вроде разобрались... Нельзя. Если данные расположены в виде: x_0 x1 ... x_n-1 x_n x_n+1 ... x_2n-1 то вначале нужно делать ДПФ-столбцов, потом умножение на матрицу, потом ДПФ-строк. Если в обратном порядке (ДПФ-строк, потом умножение на матрицу, потом ДПФ-столбцов), то надо делать не одно умножение на матрицу (для вычисления каждого элемента вертикального ДПФ матрица разная), то есть два. Шо и выходит из формулы в Рабинере и Голде. А формула, как это ни удивительно, правильная. Только объём вычислений возрастает, а они это не учитывают и ничего не говорят об этом. Так шо немного, но обманули. И к типам прореживания это не имеет отношения, и по-времени и по-частоте вначале считают ДПФ-столбцов, просто разбиение, как выше сказали, разное (2xN или Nx2) Тут переставляют данные в хитром порядке. Можна как хочешь расставить, и построкам начинать, и по столбцам. Смысл был в том, чтоб без переставления начать с ДПФ-последовательного блока данных(x0,x1,...,xN-1) как написано в книге, а нельзя. Вот так.

Главу 6 читал. Порядок перемножения соблюдаю. В таком порядке вычисленния "умножение на поворачивающие коэфф. - ДПФ строк - ДПФ столбцов" не могу получить результаты идентичные методу "ДПФ столбцов - умножение на поворачивающие коэфф. - ДПФ строк". Не могу понять кто виноват. Или так в принципе нельзя посчитать?

Хочу посчитать FFT используя Cooley-Tukey алгоритм. Представляю отсчёты в виде квадратной матрицы, считаю дпф столбцов, умножаю на коэффициенты, потом дпф строк - получаю спектр. Хочу поменять порядок расчёта (сначала дпф строк, потом столбцов) - не могу получить спектр. Кто-то реализовывал расчёт иммено в таком порядке (сначала дпф строк, потом столбцов)?

...

Вы обещали: a = a+b*c, а описали: Ai = Ai-1 + Bi*Ci, то есть конвеер, который даст осмысленный результат минимум после второго такта. Я так понял, вопрос был: как реализовать a = a+b*c за один такт. Может был неправ.

в любом, vhdl подойдёт

Не понял, решение чего? Если того, как сделать мак за один такт, то приведите здесь, если не сложно. ЗЫ. По поводу гугла, если вам интересно, то и ищите сами. Я не говорю, что умножение и сложение - некомбинацинная логика, и не говорю, что умножение должно быть за один такт. Я говорю, что один МАК за один такт не делается. Если можете, покажите, если не сложно, как за один такт сделать следующую операцию a = a + b*c.

А как по-другому? За один такт МАК никак не сделать, значит - последовательная схема. Походу ваш товарищ прав. Вся сила в конвеере.

А слово "pipeline" слышали?

Прекращайте спешить и сдуру писать в форум :)

А вы не добавляйте :), а если сильно хочется, то в отдельный процесс. У нас схемой управляет strob, который синхронизирован с clk, так шо усё как надо. Xilinx-XST может и позволит, но лучше так не делать, если нет очень острой необходимости. Схему лучше сделать синхронной, управляемой одним клоком, если это возможно. Так легче.

Для начала разбить на несколько процессов, а не сваливать всё в кучу в один (будет наляднее). Затем для всех процессов использовать только ОДИН тактовый сигнал, например clk, а strob подавать на вход enable триггера. Например так: process(clk) begin --Проверяем на знакоперемену if rising_edge(clk) then if we='1' and ch='0' then --Если we стал = "1" - держим strob в "1" strob<='1'; else strob<='0'; end if; end if; end process; process(clk) begin if rising_edge(clk) then if (strob='1') then cnt:=cnt+1; Reg<=Reg[158..0] & in; end if;--strob end if; end process;

Каких два оператора? Всё однозначно. Переменная отличается от сигнала тем, что апдэйтится новой величиной сразу после оператора присваивания и может использоваться в этом же процессе ниже по тексту. Сигнал апдэйтится в конце выполнения процесса, хотя присваивание может стоять в середине или вначале, новое значение доступно только при следующем запуске процесса. Всё. Тут сделано лишнее присваивание: in_data_rs232<=RS232_IN; получение в переменную in_data_rs232 байта из UARTа получился сдвиговый регистр и задержка на такт. Строка с переменной command := in_data_rs232(7 downto 5); здесь вводит ещё одно имя "command" для "in_data_rs232(7 downto 5)". Всё. Больше она на ни на что не влияет. П.С. Переменные юзать можна, иногда помогают. Присваиваний делать столько, сколько нужно. В данном случае можна ниодного. Как в последнем варианте case RS232_IN(7 downto 5) is

Может и так. Отстал от жизни на :)