DENth

Но если передавать не выходные значения, а входные для автомата, то от автомата во второй ПЛИС не получится избавиться. Так? На то они и входные, чтобы по ним автомат формировал результат.

Почему-то мне кажется, что это нереально. К тому же от компиляции к компиляции задержки будут разниться, как их учесть? А вот кстати как быть при описании ограничений интерфейса с ПЛИСиной, если у всяких ЦАП, АЦП приведены значения tsu, th и tco, то где их брать в этом случае? Или есть какой-нибудь констрейн типа set_output_delay? Кстати, о таком решении я еще не думал. Если синхронизацию пытался сотворить, правда пока не особо удачно, то это - второй вариант решения, думаю более подходящий. Спасибо за идею! Состояний у атомата немного, пинов хватит.

Вот. Про контроль разбежки хотелось бы более подробно, если можно. Как просто пример, если в каждой ПЛИС есть PLL на одинаковую частоту, то эти частоты можно также считать синхронными в обеих ПЛИС? Или нет? А для моего случая все-таки как учесть взаимную разбежку клоков, если интерфейсные констрейны здесь не подходят? Передачи данных, кроме сигнала синхронизации ведь нет. Синхросигналу задаются констрейны только на приемной стороне, чтобы исключить на ней же метастабильное состояние.

Интересное решение. Спасибо. То есть например сигнал запуска автомата от контроллера пропускаю через два триггера одной ПЛИС и сразу вывожу наружу на вторую ПЛИС. Делаю fast output registr. Он должен на такт добежать до второй ПЛИС. Задаю ограничения чтобы не попасть на метастабильное состояние во второй. И уже здесь по фронту запускается автомат синхронно с автоматом в первой, задержанной после выхода на один такт?

Убрать ПЛИС не получается. Используем Cyclone II на 208 ног. Но пинов одной не хватает. До BGA пока не доросли. Не совсем понял про тактовую частоту и сигналы. Частота одна на обе ПЛИС. Значит они синхронны. И работать синхронно должны в данном случае, нет? Между ПЛИС заложены порядка 8 незадействованных пинов. Только что в моем случае с ними делать? А, если речь шла про тактовую для ОЗУ... ОЗУ в нашем случае статическая SRAM с доступом 10 нс.

Приветствую всех! Прошу помощи в следующем вопросе: Есть две ПЛИС. Тактируются от внешнего генератора на 40 МГц. В каждой есть автомат состояний. Задача получить синхронную работу этих автоматов на частоте 10 МГц. Запускает автоматы контроллер на этой же плате. Частота контроллера асинхронна для ПЛИС. Но данные от контроллера пропускаются через два триггера для исключения метастабильных состояний. Это, если кратко. Сложность в задании временных ограничений или иного, что необходимо в данном случае. Смущает то, что передачи данных между ПЛИС нет. То есть ни под одно описание интерфейса случай вроде бы не подходит. Если продолжить, то автоматы управляют внешней ОЗУ. Одна ПЛИС перебирает адреса и сидит на старшем байте шины данных, а также управляет ОЗУ. Вторая только на младшем байте шины данных ОЗУ. В соответствии с состоянием автомата, ПЛИСы либо пишут, либо читаю ОЗУ. Та которая "master" работает отлично, "slave" же периодически хандрит. Данные на чтение искажены. Запись еще не проверялась. Временных органичений на эти линии не задано.

Я конечно понимаю, что работаю с ПЛИСиной на грани ее возможностей. Но была необходимость использования корпуса с 208 выводами, а BGA технология для меня пока не совсем доступна. Выбор пал на Cyclone II. Самый большой по количеству вентелей в этом корпусе - EP2C8. С классом скорости "8". Его производительность из даташита: Надо думать про кристаллы с бОльшим количеством вентилей. Но хочется учесть это в будущем, а сейчас провести какие-нибудь работы по оптимизации. Но "черный ящик" такой черный ящик =)

Очень жаль, что не смог найти здесь ответа... Вопрос всё еще актуален. Давайте попробую спросить по другому. Многие из вас пользуются готовыми мегафункциями. Расскажите, если не сложно, ваши действия при наличии проблем с выполнением временных органичений с ними. Насколько я понимаю, вникать в устройство той или иной функции нет необходимости. В этом ее удобство применения. Но вот возникла ситуация - слаки именно в модуле, реализованном в мегафункции. И что делать? Для своего случая - ответа найти не смог. Лишь файл tcl-скрипта с ограничениями на проект. Вот он: proc add_fir_constraints {args} { package require ::quartus::project package require ::quartus::flow # Compiler Assignments remove set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -remove -entity "tdl_da_lc" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -remove -entity "lc_tdl_strat" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -remove -entity "lc_tdl_strat_cen" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -remove -entity "sadd_lpm" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -remove -entity "tsadd_lpm" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -remove -entity "sadd_lpm_cen" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -remove -entity "tsadd_lpm_cen" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -remove -entity "sadd_cen" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -remove -entity "tsadd_cen" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -remove -entity "lc_tdl_mr" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -remove -entity "lc_tdl_en" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -remove -entity "sadd_reg_top" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -remove -entity "sadd_lpm_cen" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -remove -entity "tsadd_reg_top_cen" set_global_assignment -name "DSP_BLOCK_BALANCING" -remove -entity "lp_filter_st" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -remove -entity "mlu_nd_lc" ########################################################################### ##################### # uncomment the following lines if you want to disable shift register recognition # ########################################################################### ##################### #set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -remove -entity "msft_data" #set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "msft_data" "OFF" #set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -remove -entity "msft_data_reseq" #set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "msft_data_reseq" "OFF" #set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -remove -entity "msft_data_reseq_mc" #set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "msft_data_reseq_mc" "OFF" #set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -remove -entity "msft_reseq_mc" #set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "msft_reseq_mc" "OFF" ########################################################################### ##################### set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "tdl_da_lc" "OFF" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "sadd_lpm" "OFF" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "tsadd_lpm" "OFF" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "sadd_lpm_cen" "OFF" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "tsadd_lpm_cen" "OFF" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "sadd" "OFF" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "tsadd" "OFF" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "lc_tdl_strat" "OFF" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "lc_tdl_mr" "OFF" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "lc_tdl_en" "OFF" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "lc_tdl_strat_cen" "OFF" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "sadd_reg_top_cen" "OFF" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "tsadd_reg_top_cen" "OFF" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "sadd_cen" "OFF" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "sadd_reg_top" "OFF" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "tsadd_reg_top" "OFF" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "tsadd_lpm_reg_top_cen" "OFF" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "sadd_lpm_reg_top_cen" "OFF" set_global_assignment -name "AUTO_SHIFT_REGISTER_RECOGNITION" -entity "mlu_nd_lc" "OFF" set_global_assignment -name "DSP_BLOCK_BALANCING" -entity "lp_filter_st" "DSP BLOCKS" } add_fir_constraints

Приветствую, коллеги! Задался вопросом - правильно ли у меня заданы временные ограничения на подпроект с фильтром, созданным в FIR Compiler'е. Дано: Cyclone 2. Фильтр реализован в структуре Multi-Cycle. Входные данные обрабатываются каждый третий клок фильтра. Выходные порождаются также на каждый третий клок. Данные поступают с частотой 40Mhz. Внутренняя частота фильтра, соответственно, 120 Мгц. Полностью проект занимает порядка 90% всех ресурсов ПЛИС. И если ранее временной анализатор не выдавал слаков по сетапу, то сейчас они начали появляться. Fmax упала до 118МГц. Слаки около 0,3 нс. И в реальной работе модуля визуально проявляются кратковременные выбросы на обрабатываемом сигнале. Вот я и задумался, а правильно ли у меня заданы ограничения? В руководстве на FIR Compiler нет ничего про временные ограничения. Есть только требования, касающиеся редактора назначений. Попытки разобраться в структуре фильтра толком ничего не дают, так как глубже основных блоков RTL Viewer не пускает. Да и там все равно не разобраться. Но ведь если задать мультицикл в ограничениях, возможно фиттеру полегчает и он сможет все развести без слаков? Ограничения сейчас следующие: set_multicycle_path 3 -from {ADCcontroller:ADCcnt|adc_*[*]~reg} -to {RadioFilter:RF*|filter:RadioFilter|filter_ast:filter_ast_inst|auk_dspip_avalon_streaming_sink_fir_91:sink|at_sink_data_int[*]} -setup set_multicycle_path 2 -from {ADCcontroller:ADCcnt|adc_*[*]~reg} -to {RadioFilter:RF*|filter:RadioFilter|filter_ast:filter_ast_inst|auk_dspip_avalon_streaming_sink_fir_91:sink|at_sink_data_int[*]} -hold Указывают на то, что данные из регистров, в которых хранятся данные с АЦП, до входных регистров Avalon интерфейса FIR Compiler'а - мультицикловые.

Очень странно, что при 25 МГц Вы получаете сплошной мусор. Вы уверены, что в сигнал тапе выбран правильный формат отображаемых даных? Вероятно, Вы должны были пробовать, но тем не менее скажу - в Bus Display Format выберите Unsigned или Signed Line Chart. Это даст наглядное представление об искажениях сигнала. Заодно можете приложить скриншот.

Вы имеете ввиду что данную задержку нужно задавать отрицательной? Или синтаксис команды? Не могли бы Вы пояснить свою точку зрения?

Русскоязычной литературы не много. Стандарт по этой теме - вот эти статьи: http://www.kit-e.ru/articles/plis/2010_9_51.php

Вы противоречите сами себе. 200 МГц как раз-таки очень даже используется. На весь сигнал тап. А он оперирует теми же блоками памяти, что и остальной проект. А имел я ввиду следующее: Отсюда видно, что предел - 274 МГц в вашем случае. Но это в теории. А из приведенного Вами отчета видно, что Вы не используете временной анализ. Компилятору неизвестно ничего о каких-либо ограничениях и о том, как должен работать проект. О чем он и пишет в первой приведенной строке. Задайте констрейны на указанные в варнингах клоки и посмотрите на отчет анализатора. Без использования временных ограничений проект будет жить своей жизнью =)

Всё. Разобрался. Спасибо alexadmin за наводку. Для всех, кому интересно, нужно было действительно сделать следующее: ##ADC #clock source to destination clock pin delay set clkA_delay_max [expr 22.0*0.010] set clkA_delay_min [expr 22.0*0.005] #source to destination data pins delay set bdA_delay_max [expr 22.0*0.010] set bdA_delay_min [expr 22.0*0.005] #ADC parameters set Tco_max 8 set Tco_min 3 set usedTsu [expr $clkA_delay_max + $Tco_max + $bdA_delay_max] set usedTh [expr $clkA_delay_min + $Tco_min + $bdA_delay_min] set_input_delay -clock adcclk -max $usedTsu [get_ports {adc[*]}] set_input_delay -clock adcclk -min $usedTh [get_ports {adc[*]}] set_input_delay -clock adcclk -clock_fall -add_delay -max $usedTsu [get_ports {adc[*]}] set_input_delay -clock adcclk -clock_fall -add_delay -min $usedTh [get_ports {adc[*]}] И в коде: adc_a[9..0]=adc[9..0]; adc_a[9..0].clk=!adcclk; adc_b[9..0]=adc[9..0]; adc_b[9..0].clk=adcclk; Необходимость этого явно видна, если посмостреть отчет по пути от adc к adc_a во временном анализаторе.

А какая ПЛИС Вами используется? Вы проверяли в документации, что внутреннее ОЗУ ПЛИС может работать на частоте 200 МГц?