alexadmin

Счетчик даст возможность контроля. Задержка вряд ли велика (негде данным там оседать надолго). В конце-концов можно откалибровать это время и добавить задержку формирования прерывания (с запасом). Вряд ли ведь от ARM'а требуется наносекундная реакция на прерывание.

А добавьте в данные счетчик!

Погодите. Либо у меня что-то с английским либо с головой. "Если валидные данные заканчиваются раньше запускающего фронта тактового сигнала, то min положительный." "Если валидные данные заканчиваются позже запускающего фронта тактового сигнала, то min отрицательный." Я считал, что наоборот. Картинка в цитируемом посте выше тоже наоборот. После чего там модертор написав эти слова соглашается, что картинка правильная.

Еще проще. Это удобно пока кривой софт не начнет падать при попытке сборке таких конструкций. Меня вивада, помню, так накормила. Написал все красиво, помоделировал. Запускаю сборку - падает синтезатор. Даже errata какая-то нашлась, но не устранена оказалась...

Никогда не имел дела. Но не конфликтуют, видимо, потому, что чип-селекты разные.

Да ладно! https://www.google.com/search?client=firefox-b-d&q=vivado+ila+free+running+clock

Как-то так и есть. Когда у меня не free-running клок и я не хочу плясать с бубном, я перевожу данные из одного тактового домена в тот, где клок стабильный и смотрю уже там.

Я понимаю, что это совсем не ответ на вопрос, но так ли уж нужны собственные ip-core в виваде? Этот ip packager сделан настолько не по людски, что как-то... После того, как появился режим Add RTL module, я забыл о них как о страшном сне.

Потому что сложно одной рукой пиратить, а другой сажать на 5 лет за контрафактный софт. Надо что-то одно выбрать.

Если бы потерянные. Они ведь наоборот, в Vivade излишне оптимистичные получились! То-то самолеты все в воду падают...

Открыл первый же пример: "проанализировали тайминги, получили столько-то. А вивада показывает с ошибкой на 30пс меньше". И как теперь с этим жить?

Если говорить про работу с гуи, то можно открыть список сгенерированных файлов ip-ядра, и запретить этот конкретный файл (disable file на нем). При перегенерации ядра запрет сохраняется, насколько я помню. Работает не на всех вивадах. Там же можно подсмотреть соответсву.щую tcl-команду для запрета файла.

Да, если АЦП всего один и/или не беспокоит детерминированная латентность, то можно вообще без sysref.

Все совершенно верно. Кратен частоте мультифрейма, чтобы регулярно приходящий sysref не сбивал счетчик мультифреймов. Про 5 МГц не помню, но если вас пугает 7, то сделайте 3,5МГц - сама частота не важна. В ряде случаев и вовсе подают sysref однократно, а потом выключают, чтобы не было лишнего шума на плате.

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