Добрый день, уважаемые ПЛИСоводы.
Столкнулся со следующей проблемой:
Fitter по-разному размещает межсоединения, хотя ячейки назначены одинаково.
Разница в двух проектах лишь в том, что левом - больше логики (расширен проект), а в правом - у ячейки больше выходов (Fan-out)
Нажмите для просмотра прикрепленного файла

Подскажите, пожалуйста, если кто-то встречался, как указать fitter'у использовать межсоединения для рядов, а не смежные?
Мне требуется максимально выровнять задержку (как на правом рисунке).
Возможно, есть другие способы?

Использую EP1C3T100C6.

PS. Прошу прощения - ошибся немного темой, нужно было в САПР...

Форумчане дорогие, ну неужели никто даже прокомментировать и на пути решения направить не может?

ИМХО не понятно зачем Вам это нужно. С данной конкретной ПЛИС не работал, но можно вроде только координату задать, а дальше квартус сам раскидывает из своих соображений межсоединения. Временной переход внутри одной ячейки, вроде как гораздо меньше нежели между разными и мне кажется что у Вас изначально каша именно с понятием выравнивания задержки. объясните конкретней - чего требуется? Те значения задержек, которые приведены на снимке гораздо меньше, нежели максимальная тактовая частота для триггеров.

Во-первых, я как раз и хочу понять из каких соображений Quartus раскидывает межсоединения?
Во-вторых, мне важно не минимальное время задержки между ячейками, а именно одинаковое.
Я пытаюсь сделать задержку асинхронного сигнала с точностью меньше периода тактовой, для этого я использую чертыре фазы частоты для оцифровки асинхронного сигнала и их же - для формирования задержанного импульса. Quartus не позволяет размещать ячейки тактичуемые частотыми с разными фазами в одном LAB'е(те 0 и 180 можно в одном, а 90 и 270 - в другом)

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

Просто в версии, где задержки равные, у меня все получилось. Чуть изменил проект и уже точность получилась меньше..

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

Могу ошибаться, но мне кажется, что вам нужно задать констрейны для критичных цепей и ква сам всё сделает за вас.
Про констрейны поищите в интернетах или на форумах, так же у des00 в блоге можно почитать.

Возможно я ошибаюсь, но как понимаю, констрейны и timequest analysis предназначены в основном для синхронных проектов (в общем то как и ПЛИС в целом). Их основная задача проследить, чтобы сигнал данных соотвествовал определенному клоку во избежание неправильной передачи данных (между регистрами или даже смежными чипами). Поэтому, как мне кажется, с помощью этих инструментов невозможно так точно ( 10 пс) задать время распространения сигнала. В основном таймквест отслеживает, чтобы данные приходили раньше периода тактовой частоты, так что точность получается в пределах 1нс.

Из статей des00 вижу только вариант использования set max/min delay, но пока не понимаю как, ведь ячейки у меня зафиксированы, а если убрать фиксацию, то как написал выше, вряд ли получится такая же точность.

Меня больше интересует, почему в почти одинаковых проектах квартус располагает межсоединения по разному?

Вы задали ограничения на межсоединения - нет, поэтому квартусу все равно. Ключевое слово здесь "почти", каждый раз разводится по разному, даже если поменяли настройки, а у Вас там fan-out другой.

Как правило не достаточно задать ограничения на тактовые частоты, требуется задавать еще на входные данные относительно в том числе и относительно тактовой (в некоторых случаях квартус сам будет вставлять логические болки для "выравнивания"). Стабильную точность в 10пс Вы никак не получите, не поверю я в это.
Честно говоря не осилил статью, а Ваше описание алгоритма мне лично не понятно.

Поподробнее бы описали, что за сигнал, как соотносится с тактовой (которая кстати тоже извне синхронно поступает?), с какой точностью.

Лектор нам говорил, что КВА каждый раз разводит один и тот-же проект по-разному сознательно. Он не воспроизводит его в точности... Даже внутри регионов!

QII проводит P&R синхронных дизайнов при одинаковых входных параметрах одинаково, вне зависимости от дня запуска и прочее.
На на моих асинхронных дизайнах и QII v7.2/v8 помнится было описываемое ТС

Посмотрите стр.9 - примерно то, что вам нужно.

Gate, огромное спасибо - в самую точку. Просто и понятно.

Что какается

Если вы не видели, то я как раз в своем первом сообщении и спрашивал как это сделать...


Точность в 10 пс - относится к внутренним сигналам (то что показано на рисунке).

Моя задача - задерживать внешний асинхронный импульс на Nое количество времени с максимальной точностью на ПЛИС. Исследую способы повышения точности. Пока добился джиттера выходного задержанного импульса, равного 80% периода внутернней тактовой частоты (от PLL).
Если кто-то встреячался с такими заданиями, какой вообще точности следует ожидать?

Кстати, кто-нибудь знает как создать генератор кореллированных импульсов, как на рисунке
Нажмите для просмотра прикрепленного файла,
но с помощью одного PLL?

2Egor-ka
Если вы делаете TDC, посмотрите еще xilinx xapp224.
Если вам не нужно иметь десяток каналов в одном устойстве, то рекомендую acam gpx: http://www.acam-usa.com/GPX.html

2Gate

Спасибо за документы, у меня как раз что-то похожее получается.

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

По поводу разводки межсоединений:
нашел, где Quartus это прописывает - файл .rcf - routing constraint file - но пока не понял, можно ли как-то его в этих целях использовать?
К тому же, этот файл создается при использовании back-annotation, а как с этим работать тоже пока не понял.