Michael358

А, т.к. входные данные представляются числом < 1, то в результате умножения модуль числа будет только уменьшаться. Оставляем нужное количество разрядов после точки. Поэтому переполнения не будет. Верно понимаю? Тогда почему не хватит 12 бит, если после умножения/сложения оставлять нужное количество разрядов ? Мне надо сделать эхокомпенсацию. Её можно реализовать на БПФ ?

А можно поподробнее для нуба: Разве не проще в ПЛИС реализовывать целочисленную арифметику? Полная разрядность - это: входные данные (х) с АЦП - 12-разрядов; под коэффициенты отводится тоже 12-разрядов; выход фильтра y = сумм(х * w) = 12 + 12 + log2(512) = 34 разряда, из них в выходные данные брать старшие 12 разрядов? Далее ошибка е = d - y = 13 разрядов. Брать старшие 12 ? Затем обновление коэффициентов w(k +1) = μ e(k) x(k)+ w(k). e(k)=12 разрядов, x(k) = 12 разрядов, μ - ? (не знаю, сколько). Получается w(k +1) = ? + 12 + 12 + 1 >= 26 разрядов ? Как масштабировать до 12 разрядов? Что есть усиление в цифровом фильтре?

При реализации адаптивного фильтра (lms-алгоритм) на ПЛИС как работать (выбирать, маштабировать и т.п.) с разрядностью промежуточных вычислений и результата? Например, длина фильтра 512, входные данные 12-разрядные, выходные данные тоже должны быть 12-разрядные. Если в КИХ-фильтре коэффициенты постоянные, то можно вычислить разрядность максимально возможного значения выхода фильтра и взять нужное количество старших разрядов. Как действовать с переменными коэффициентами?

Спасибо. Заполненность 80%. Мне как раз нужно 200 МГц и выше

Подскажите: В проекте системная частота подбирается к 200МГц. Если выставить настройку speed, то Timing Analyzer выдает Fmax=185МГц. Если Balanced - Fmax=192МГц. Получается, оптимизация по speed не всегда приводит к повышению Fmax относительно balanced? И каждый раз нужно пробовать оба варианта(если цель - увеличение Fmax)?

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

Как я понял из хендбука, в Quartus Prime надо использовать что-то из dont_merge, Preserve, Noprune или syn_keep. Keep_hierarchy - это в Xilinx ISE

А, дошло. Спасибо.

А можете объяснить, в каких случаях и как надо использовать PIPLINE. Вот я выставляю PIPLINE = 0 ( системная тактовая частота 160 МГц , разрядность портов = 48), и прописать set_multicycle_path = 48, то получаю: Fmax = 329 МГц Logic utilization (in ALMs) 1,583 / 32,070 ( 5 % ) Total registers 192 Total block memory bits 0 / 4,065,280 ( 0 % ) Total DSP Blocks 0 / 87 ( 0 % ) Если PIPLINE = 48, то: Fmax = 156 МГц Logic utilization (in ALMs) 2,098 / 32,070 ( 7 % ) Total registers 4935 Total pins 195 / 457 ( 43 % ) Total virtual pins 0 Total block memory bits 2,014 / 4,065,280 (< 1 % ) Total DSP Blocks 0 / 87 ( 0 % ) Задержка одинаковая(если в первом случае добавить логику, считывающую результат через 48 тактов), а расход ресурсов увеличивается и снижается макс. частота.

Не подскажите, эта настройка есть только в платных версиях quartus? В Lite Edition не нашёл.

А где это задаётся? "Allow Shift Registers Merging across Hierarchies" ? Balanced Циклон 5. Timing Driven Synthesis стоит в ON. Она разрешает объединять регистры из разных иерархий?

Его можно описать кодом? Или придётся использовать ip-компонент? П.С. В "Assigments->Settings->Analysis & Synthesis Settings" выставил Optimization Technique = speed. Пересобрал проект - слак пропал.

Спасибо. У меня память описана так: Вроде в RTL-Viewer регистры есть на выходе: А Technology Map Viewer уже нет:

Значит, slack убирается только уменьшением data delay ?

Здравствуйте. В проекте частота на входном порту ПЛИС CLOCK_50 = 50МГц. Далее на PLL она повышается до 160МГц, и полученная clk = 160МГц используется как системная частота. В sdc файле описал так: create_clock -name {clock_50} -period 20.000ns [get_ports {CLOCK_50}] derive_pll_clocks -create_base_clocks derive_clock_uncertainty set clk {\Rate_160:pll_160_inst|pll_160_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divclk} set_clock_groups -exclusive -group [list $clk clock_50_0] В Timing Analayzer получаю: Правильно я понимаю, что анализируется clock, начиная от входного порта CLOCK_50 и через PLL? Этот путь же не нужно учитывать?