Всем привет.

Пытаюсь отладить работу устройства. Мозг ус-ва - Циклон ep1c3. Отлаживаю с помощью Сигнал Таб.
Клок, подаваемый на ПЛИС достигает 165 МГц.

Времянки не очень радостные все криво. Может это быть связано с невозможностью работать Сигнал Табом на такой частоте?
Если да, то как отлаживаться?

Спасибо

В симуляторе.

Ну по идее частота анализатора работы должна ограничиваться максмимальной частотой работы памяти. Для циклона в даташите пишут 250 МГц.
Но вдруг я ошибаюсь

Есть еще логика триггера.
Фраза про времянки напрягает. Чтобы была хоть какая-то польза от процесса, все времянки должны быть в норме, что отлаживаемой схемы, что самого signal tap.

Чего такого неведомого, быстро меняющегося, хочется узнать про работу схемы или её окружения, чего нет в неподвижной документации?

Ну ладно расскажу.

Сопрягаю приемник dvi tfp401 и циклон ep1c3.

Приемник должен генерить импульсы синхронизации vsync и hsync, валидность данных подсвечивается сигналом de.
Поставил на прием этих сигналов по триггеру и снимаю с этих триггеров сигналы с помощью Сигнал Тап.
Но эти сигналы "пляшут" - устанавливаются как хотят.
Вот я и спрашиваю - какое ограничение частоты у Сигнал Тап

Полистал datasheet на приемник, ничего не понял, но кажется, что на вашей частоте данные наверняка валидны лишь 1.2nS и чтобы попасть, может понадобится сдвинуть клок.
Почему все дрыгается вы увидите в отчетах анализатора таймингов, когда запишите аккуратно все констрейны для входных сигналов (set_input_delay, set_clock_uncertainty и т.д). Детально и полно не подскажу, не силен в этом вопросе, всякий раз обязательно что-то неизвестное для себя обнаруживаю.

Посмотрите в TimingAnaliser(или TimeQuest) какая максимальная частота клока в Вашем проекте, если она выше требуемой то всё ок.

А Вы входные сигналы в Fast тригерах защёлкиваете?

TimingAnaliser говорит, что максимальная частота 153 МГц - ниже того, что требуется. Но вроде относительно TimingAnaliser имеется "запас" в железе - аля показания TimingAnaliser + процентов 10% должно работать.

У меня требование 165 МГц

А что такое Fast триггеры и с чем их едят?

Так раз должно, значит и работает! (сарказм)
Взглянув на некоторые схемы можно с уверенностью сказать "работать не будет", но заявить обратное трудно.
Для меня отчет анализатора таймингов с нарушениями таймингов на любую величина (хоть на долю пикосекунды) означает негодную схему, которую нужно переделать, которой доверять нельзя. Что работать будет скорее всего понятно, но как запрашивать support или объяснять сбои в рабочем экземпляре? "Я прикинул, должно заработать..." ?

Без размещения входных регистров в том, что называется "input registers" надежно захватить данные не получится, как мне кажется.

Я бы не стал заниматься шаманством с анализатором, а полез изучать констрейны для входных сигналов и клоков, на возможности PLL, input registers.

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

Fast тригеры это тригеры расположенные в ножках ПЛИС, если их не использовать, то различные разряды шины данных будут иметь раличную задержку на пути от входой ножки до первого тригера. Думаю, у вас именно это проблема

а как эти триггеры задействовать?

Способов применить регистры подключенные напрямую к ножкам несколько, все они спорные.
Один из них - применять соответствующие примитивы, в данном случае altddio_in.
Генерируется MegaWizard-ом. Потом можно воткнуть в исходник и использовать без всякого визарда.
Другой путь - использовать атрибуты и констрейны, но он менее надежный.

Вы в схематике рисуете или на языке пишете?
Я пишу отдельные блоки на языке, но файл верхнего уровня всегда делаю в схематике.
Для использования FastInput тригеров в схематике подключаете к входной ножке тригер, кликаете правой кнопкой , в контекстном меню выбираете locate in Assigment Editor и там задаёте этому тригеру FastInput - On. После компиляции может посмотреть на этот тригер в ChipEditor (при помощи того же меню Locate...) чтобы убедится, что ваш тригер попал именно туда, куда вы хотели. Советую такие тригеры выделять другим цветом, чтобы не забывать делать назначение при переносе части схемы в другой проект.
Если у Вас в проекте файл верхнего уровня написан на языке, то попробуйте назначить входному сигналу атрибут FastInput (сам не пробовал), результат можете проверить в том же ChipEditor.

подрубил осциллограф к выходу HSYNC микросхемы tfp401. Импульсы синхронизации идут как надо - четко и красиво (ПЛИС не прошита).


Однако заметил такую штуку, что после прошивки Циклона, на экране осциллографа между импульсами HSYNC наблюдается как будто шум.

Запускаю Сигнал Тап и вижу, что иногда HSYNC устанавливается как надо, а иногда в произвольные моменты времени. Может быть это причина "шума"?
Тогда как прошивание ПЛИС на это влияет?

Спасибо





Всем спасибо - вроде сам разобрался.
Поставил не используемые выводы ПЛИС делать Z-состоянием, а не подтягивать к земле.

Зря. Альтера ведь не зря по умолчанию все неиспользованные ноги как выход с gnd делает. Z обычно делают на EZ_KIT (там ноги проекта жестко к перефирии привязаны), когда хочется что то свое в кристалл запихнуть и проверить на готовом, не спалив при этом соседей.
Так что в реальности, если в проекте ввели входные резервные пины, по идее с каждым пином надо работать индивидуально
(Раз поставили все неиспользованные пины в Z, посмотрите в рапорте *.pin, какие требования при этом предъявляет Квартус к окружению плисины)

у меня на вход плисины заведены 3 воcьмибитных шины данных, сигналы синхронизации hsync и vsync.
Я в тестовом проекте "обстреливаю" только одну восьмибитную шину данных и сигналы синхронизации.

неиспользуемые пины в Z поставил - получше картинка стала вроде