attaboy

reg some_sig; reg some_sig_dly; always @ (posedge clk) some_sig_dly <= some_sig; some sig_dly задерживается на один такт. Время задержки определяется частотой clk.

Триггером.

Нужно смотреть, какой пункт калибровки не проходит. Не скажу про Intel, но у Xilinx через отладчик можно посмотреть подробно отчет по калибровке. Там несколько десятков пунктов, и в случае непрохождения калибровки видно, на каком пункте остановился процесс. Если остановился на первом пункте - скорее всего в цепях DDR-FPGA где-то плохой контакт,непропай и т.д. Менять микросхемы между платами не нужно. Для начала можно просто прогреть память, ПЛИС. Если не помогло - поменять память на новую, и т.д. Если где-то посередине (типа DQS-to-DQ deskew) - можно уменьшить частоту контроллера памяти. Но судя по тому, что часть плат проходит калибровку с хорошим результатом, предположу первый вариант.

Асинхронную логику можно легко реализовать на ПЛИС. Но проблема здесь в другом - асинхронная логика может быть быстрее при выполнении единичных операций. А при поточной обработке информации синхронная логика будет намного быстрее. Допустим, есть некоторая операция, которая на асинхронной логике работает на частоте 100 МГц. А на синхронной разбивается на 4 такта и работает на частоте 200 МГц. Кажется, что асинхронная быстрее в два раза. Но если в схеме на синхронной логике организовать конвейер и подавать данные каждый такт, то да, первый результат будет позже по сравнению с асинхронной логикой (выше латентность), но потом результат будет получаться каждый такт. И это уже на частоте 200 МГц, то есть синхронная логика в этом случае будет в два раза быстрее.

К сожалению я тоже прихожу к такому выводу. По крайней мере в трансиверах Xilinx я не нашел сигнала, обозначающего текущий диспаритет на передачу. Но это же получается такой колхоз - при наличии встроенного кодера делать свой, чтобы просто контролировать текущий диспаритет.

Вопрос по IDLE-сетам. В IEEE802.3-2015 Clause 36 определено два IDLE - Correcting /I1/ и Preserving /I2/. В описании говорится, что первый /I/ выбирается в зависимости от текущего диспаритета, а все последующие должны быть /I2/. Но, допустим я реализую некоторую логику на ПЛИС с использованием трансивера. В трансивере как правило есть свой декодер 8/10. При использовании встроенного декодера я ему подаю на вход 8-ми битные данные и ничего о текущем диспаритете не знаю. Я могу только разделить простые и спецсимволы сигналом char_is_k. Как в этом случае выбрать, какой будет первый символ - /I1/ или /I2/ ?

Это при "full duplex". А как быть, когда линк только в одну сторону, например Aurora Simplex Rx-only (или Tx-only) Тоже линк надо как-то настроить, а канала для обратной связи нет.

У каждого IP-ядра есть набор параметров. Часть из них можно увидеть в графическом интерфейсе, но значительно больше параметров отображается при помощи команды типа: report_property -all [get_ips ddr4_0] Если есть необходимость изменить какой-либо параметр, это можно сделать с помощью команды типа: set_property -dict [list CONFIG.C0.DDR4_OutputDriveImpedanceControl RZQ/6] [get_ips ddr4_0] Но иногда при таком способе установки параметров Vivado выдает ошибку: "Value is out range. Valid values are ..." Возник вопрос: есть ли в Vivado команда, с помощью которой можно посмотреть диапазон допустимых значений параметра?

В xdc обязательно нужно указывать PACKAGE_PIN и IOSTANDARD.

Похоже что нет, по крайней мере в открытых источниках.

Друзья, появился такой вопрос. Проект запускается в Vivado скриптом в project_mode. На разных этапах выполнения формируются отчеты и складываются в специальную папку. В том числе собирается статистика по времени выполнения. В Vivado определено два времени - elapsed time и cpu time. Для получения elapsed time использую команду: get_property STATS.ELAPSED [get_runs ${CurrentSynth}] А вот cpu time похоже в свойствах объектов нет, по крайней мере команда: list_property [get_runs ${CurrentSynth}] не выдает никаких свойств, похожих на cpu time Вопрос: где/какой командой можно получить cpu time?

Необязательно target. Может быть и в каком-нибудь другом xdc или даже в tcl. Думаю лучший вариант ручного поиска - в рабочей директории проекта запустить что-то типа: grep -r "create_debug_core" . И по результату поиска уже посмотреть, какие ila создаются.

Запрет на ввоз компонентов может мешать развитию. Допустим, вы освоили все тонкости программирования последних моделей процессоров Intel и как эсперт ждете поставок нового поколения для совершенствования своих навыков. Запрет на их ввоз может остановить ваше развитие. Если вы используете осциллограф как инструмент для каких-либо исследований, то запрет на ввоз осциллографа тоже может остановить развитие.

Например ограничения на поставку определенных электронных компонентов в Россию, на поставки оборудования для нефтегазового комплекса. Достаточно?

Что странного? Я привел конкретный пример международной кооперации, и её результаты. А так да, провал любого проекта можно обосновать. Была международная кооперация, но место не то, или что-то ещё. Все очень просто - те самые "западные технологии" предоставляются в объёме, достаточном для работы, но не для развития. Ну а если вдруг начинается развитие, то выявляются нарушения и вводятся ограничения. В принципе это наблюдается уже длительное время, и не только в России.