DuHast

Приветствую. А дампы вы чем писали? Плисиной или wireshark'ом. Если последнее, то поделитесь, каквы pcap симулятору скармливали.

А Вы посмотрите на их видеоролики в интернете. Сплошная реклама матлаба. Hdl презрительно называют "олдскулом". Каждый год проводят конференцию, где собирают приличную толпу инженеров и пытаются убедить всех, что кодегенерация не только быстрее, но и не уступает по оптимальности ручному кодингу. Так, что если там и есть hdl, то в публичном пространстве они в этом не признаются. А так, ребята молодцы.

А зачем Вам именно pci? Если задача обмена между двумя плис, то можно через те же разъёмы не меняя разводку плат сделать что-нибудь попроще. 10G ethernet, или вообще, что-то своё запилить.

Вот и я о том же. И констрейны здесь ни при чём. Поэтому надо симулировать, тем более у автора топика есть тестовый генератор.

Попробую задать правильный вопрос: Вы новые фильтры параллельно ставили или последовательно?

С нуля и всё? Выбор компонентов, разводка платы, написание firmware, драйвера и пользовательского ПО. Или что-то уже есть/будете делать сами?

А в чём смысл? Константы и на бумаге можно обсчитать :) А если серьёзно, то при подаче константы синтезатор упростит схему(так сказать "обсчитает на бумаге") и по результатам синтеза не будет понятно ни сколько ресурсов займёт схема, ни максимальная частота её работы. Поэтому лучше, переделать тестбетч, который у вас уже есть, так, чтобы он синтезировался в ПЛИС и сделать его верхним файлом проекта ПЛИС.

Вы где эти X и Y брать собираетесь? Хотите просто задать константой в проекте, откомпилировать и чипскопом/сигналтапом посмотреть результат?

Странный вопрос. ПЛИС - это микросхема, которая стоит на какой-то плате. С внешним миром ПЛИС взаимодействует через какие-то интерфейсы, которые реализованы на этой плате. Через эти интерфейсы в ПЛИС и далее на ваш модуль и надо подавать X и Y. Но чтобы разработать и протестировать этот ваш модуль используется симулятор и тестбенч.

Это не выбор между количеством сорок описывающих одну и ту же схему , это две разных схемы. В первой входные пины заведены на логический элемент без триггеров, что обеспечит вам много головной боли. Во второй они завезены сперва на триггеры, а уже затем на логику.

Давайте уточним. Проект где вы стоите SignalTap на входе ФИФО и проект, когда вы видите ошибки - это один и тот же проект? Или вы увидели ошибки, собрали новый проект с SignalTap и увидели, что на входе ФИФО всё ок? И ещё, было бы не плохо посмотреть временные диаграммы на входе и выходе ФИФО при переходе через FF

В процессе, тактируемом клоком: In1 <= inpit_1; In2 <= input_2; a <= In1 and In2; Сигналы input, сперва попадут на триггеры(которые квартус, скорее всего, сделает fast), а уже потом на логику.

ТС писал, что у него входной сигнал заведён прямиком на ФИФО, т.е. между входным пином и входным триггером ФИФО ничего нет. В такой ситуации Fast Input Pin задействованы не будут, а время задержки входного сигнала будет сильно зависеть от того, где будет расположена в ФИФО внутри ПЛИС. Конечно, правильно расставленные констрейны помогут квартусу сделать всё корректно, но защёлкивание входной шины в Fast триггерах помогут ему гораздо больше. Хуже ситуация, когда по неопытности пишут код типа a <= input_1 and input_2 т.е. входные пины сперва идут на логику.

Выходные fast триггеры выравнивают сигналы на шине данных по фронту тактового сигнала перед выходом из плис. Если у вас в схеме есть триггеры то квартус, скорее всего сам разместится их в пинах, т.е. в фаст тригерах. Но если выход вашей схемы логика, то квартус просто может не справиться с вашими констрейнами. С входами ситуация аналогичная.

Все входные и выходные сигналы крайне желательно пропускать через fast input/output trigger'ы, расположенные в пинах ПЛИС