Такая коррекция адреса – бессмысленный расход логических ячеек и "проводов". Лучше сразу в управляющей логике формировать правильные адреса.

Но Вы, похоже, увлекшись адресами не заметили проблему. Из вашей схемы следует, что точки 0..511 Вы собираетесь сохранять в RAM0, точки 512...1023 в RAM1, точки 1024...1535 в RAM2 и точки 1536...2047 в RAM3. Пройдитесь мыссленно по схеме алгоритма и попробуйте увидеть что получится (точнее чего не получится) если распределить точки по блокам памяти таким образом. Очень важно не забывать, что мы должны вычитывать/сохранять по 4 точки одновременно.

Тогда вооще не понимаю в чем проблема, 4 памяти - пишем одновременно во все 4. WE только поставить и все.

Эх... Ленитесь...

Ну давайте разбираться. Заливаем память данными АЦП. В RAM0 точки 0..511, в RAM1 - 512...1023, в RAM2 - 1024...1535 и RAM3 - 1536...2047. Начинаем считать БПФ. В первую бабочку идут точки 0,512,1024 и 1536. Во вторую бабочку идут точки 1, 513, 1025 и 1537 и т.д. Каждая из 4-х точек идущих на одну и ту же бабочку лежит в своем отдельном банке памяти. После вычисления бабочки результаты складываются по тем же адресам и тем же номерам банков (только в другую память). Все замечательно. Но начинается след. этап и видим, что на первую бабочку нам надо подать данные из адресов 0, 128, 256 и 384. Спрашивается, где они лежат? Все до одного в RAM0. И как же Вы их собираетесь вычитывать все сразу за один такт из RAM0? Ведь любой блок RAMx за такт может вычитать/записать только одно данное. Так что уже на втором этапе мы имеем проблему т.к. любой бабочке нужны одновременно данные, которые лежат в одном и том же банке памяти. При этом, входы/выходы бабочки жестко связаны с банками памяти. Теперь, надеюсь, осознаете проблему и догадываетесь чего не хватает для ее разрешения?

Что-то ответа на этот вопрос от Вас не слышно... Времени нет или идей?

Честно говоря и того и другого нету. Я вообще не представляю как из памяти можно считать 4 отсчета сразу, при том, что она на это не рассчитана. Чувствую, что все кроется видимо в мультиплексировании, но как.

Да. Дело в мультиплексировании. Как именно напишу на днях - со временем сейчас тоже напряженно.

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

А прикольное Руко-водство! Давно такое искал. Ребята Молодцы! Sefo - просто Герой! Всё таки хочется чтоб до конца дошли!

Вот с recordом, только он не как шины распознает, а как отдельные сигналы: http://webfile.ru/3458200

Спасибо. Рад что это интересно не только ZEDу.

Т.к. текст с картинками, то решил загрузить его в pdf формате (fft.pdf). Читать его нужно одновременно имея перед глазами дополненную схему алгоритма (FFT_2048_a09_05_01.rar).

Задания будут следующие:
1) В качестве упражнения дополните, пожалуйста, схемы этапов 3,4,5 картой банков памяти как я это сделал для этапов 1 и 2.
2) Последний 6-й этап выбивается из общего алгоритма - объясните почему. Если с объяснением проблем не возникнет, то предложите решение проблемы.
3) Напишите, как бы Вы стали реализовывать генерацию адресов, управление миксерами и сами миксеры. Код пока не пишите, просто объясните и/или нарисуйте схему.

Код посмотрю вечером.

Можно тогда тоже поучаствовать? - У меня вопрос! - Была у вас такая тема - оптимизация суммы A + B + 1. Сразу оговарюсь что я использую Quartus 8. Так вот - если смотреть после синтеза RTL, то там действительно выдаётся 2 сумматора, но если проимплементировать весь проект и посмотреть что в итоге получится в Chip Planner-е - то результат для C <= A + B + 1 и sigTmp <= (A & '1') + (B & '1'); С <= sigTmp(8 downto 1); будет один и тот же. Причём с эти я сталкиваюсь не первый раз. Тут видимо есть какая-то недороботка, но на конечный результат похоже это не влияет!?

Полностью согласен Sefo - очень классный учитель, хорошо и толково объясняет!!! Дай Бог чтобы у них все получилось!!! ZED - не в обиду будет сказано, хороший ученик и видно, что хочет дойти до конца и во всем разобраться!
PS Надеюсь своим детищем поделяться

Спасибо, стараюсь!!!

Прикрепляю свои инсинуации, надеюсь нигде не напутал.

Это происходит потому, что сначала синтезатор из кода пытается выделить стандартные операторы: сумматоры, умножители, мультиплексоры, декодеры, регистры и т.д. Т.е. получается нечто среднее между языком описания аппаратуры высокого уровня и gate level. Далее полученные операторы "раскладываются" по технологическим ячейкам ПЛИС. Вот именно на этом уровне и происходит оптимизация и объединение, по возможности, нескольких операторов в одну техн. ячейку. Простой код не вызывает проблем у любого синтезатора, но вот в случае сложного кода результаты могут существенно отличаться от синтезатора к синтезатору. Например по своему опыту могу сказать, что Precision на сложном коде стабильно выигрывает у Quartus.

Что касается конкретно А+В+1, то просто полезно знать как можно "заставить" абсолютно любой синтезатор поставить 1 сумматор вместо двух, да и просто знать некоторые тонкости арифметической логики.

Precision, например, в отличие от Quartus, в конструкци A+B+1 сразу видит 1 полный сумматор вместо 2-х, что гарантирует, что при раскладке по технологическим ячейкам ПЛИС Precision очень постарается разложить его как полный сумматор.



Напутали С адресами напутали. Как бы мы не формировали адреса, но на каждом этапе из каждого банка должны быть прочитаны все 512 точек хранящиеся в каждом банке памяти и, соответственно, все без исключения 2048 вычисленых результатов должны быть записаны на свои индивидуальные места в банках памяти. У Вас получается, чем дальше, тем больше Вы читаете из одного и того же места и записываете разные результаты в одно и то же место, затирая предудущие. На 5-ом этапе у Вас и нумерация банков в последнем блоке, почему-то, неверная (на остальных правильно).

Поправил, ох уж этот Ctl+C Ctl+V

Вы не тот файл выложили - там нет ни одного отличия от того, что Вы выложили 4 мая. Причем файлы совпадают до бита