Всем доброго времени суток!

Кто-нибудь может объяснить, почему Quartus от компиляции к компиляции может реализовывать один и тот же триггер по-разному – с использованием LUT входящую в LE где находится регистр(1 вариант) и без (2 вариант). Причем задержка в 1 варианте (с использованием LUT) оказывается меньше.

Нажмите для просмотра прикрепленного файла

От чего зависит реализация, и как сказать Quarus’у чтобы определенные триггеры имели одинаковую реализацию?

Полностью аналогичная тема была несколько дней назад.
Общий ответ на вопрос - никак, кроме использования примитивов FPGA в явном виде (через пупер-визард, к примеру).
А если тайминг сходится, то можно и вовсе не обращать внимание на это.

Много факторов. Например, значение констрейна register packing. Пользователю главное, чтобы результат устраивал (как уже отметили выше), он может влиять на качество результата констрейнами. У вас чисто академический интерес или что-то не получается?

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

То есть Вы хотите сказать, что один и тот же код (не меняющийся), с одними и теми же констрейнами, настройками компиляции и seed, будет каждый раз разодиться по разному? Да ну, не может такого быть, ведь начальными условиями для синтеза и разводки как раз и являются настройки, констрейны, код, а они не меняются. А раз не меняются начальные условия, то и результат не должен меняться... По идее...

В теории нет разницы между теорией и практикой. А на практике - есть
Вообще говоря, Xilinx били себя в грудь пару лет назад и обещали что в Vivado результат сборки проекта будет абсолютно оптимален и детерменирован. Чем дело закончилось я не знаю, так и не успел приобщиться. Было бы интересно послушать тех, кто на практике с вивадой работает.

Все верно говорите!
Лезьте в настройки компилятора КВАКТУСА в районе разводчика (map и т.д.) Должны быть настройки которые запрещают переразводить топологию при перекомпиляции проекта. Синтезатор по идее в таком режиме работает с той топологией кристалла, которая вас устраивает по временным задержкам, и все изменения в проекте учитывает пользуясь свободными ресурсами кристалла. Т.о. Вы перекомпилите, а ваши драгоценные триггера стоят все на том же месте, и как следствие прежние задержки.
Осталось разобраться где то место которое нужно чесануть=)). Квактус мне не друг, поэтому не подскажу.... Тут наверняка есть гугу по альтере.. Ищите их и спрашивайте... Ваша задача имеет решение.

Да, такая технология у альтеры называется design partitions. Настраивается по-другому в отдельном окне, но смысл ее именно такой - защитить хорошо разведенные части проекта от переразводки.

А можно ссылочку? Сходу не нашел.


Мне нужно чтобы сигнал от одного источника к нескольким триггерам приходил одновременно. Если все триггеры реализуются одинаково, то разница в задержках получается около 0,005нс, а если по-разному то около 0,150нс.

Вооот.... так объясните нашему уважаемому автору топика, куда и как нажимать.

Поставьте примитив LCELL, и назначьте ему assignment в тот же LE, что и триггеру (триггер тоже вручную привязать в конкретный LE). Тогда, по идее, оно должно все такие триггеры сделать одинаковыми, с проходом сигнала через LUT. А вот как сделать обратное, заставить сигнал не идти через LUT, я не знаю. Возможно, chip editor может помочь, с ручным допиливанием того, что развелось.

А что это за примитив и куда его вставлять? Мой проект написан на Verilog'е.

Зачем вообще используется LUT если нету промежуточной логики?


Design Partition Planner, я нашел, но он работает только за деньги А у меня бесплатная версия Quartus, поэтому этот вариант не подходит.
Да и в целом меня беспокоит не то что каждый раз проект разводится по-разному, а то что такой примитив как триггер реализуется по разному внутри одной компиляции, в итоге получаются триггеры с разным быстродействием

могут использоваться для соединения входов триггеров

Халявщики

просто любопытство - у Вас ПО официально купленное?

Если webpack, я бы так не писал

Это примитив из альтерской библиотеки, такой же, как DFF, DFFE, и прочие физические сущности. Этот означает в контексте FPGA один LUT. От того, на каком языке написан проект, использование примитивов по сути не меняется. Смотрите хелп на него, там есть примеры на всех языках.


Видимо, ресурсы разводки так разлеглись, что надо было тут подключить через LUT, а напрямую не склалось у роутера.

Да, трюк с LCELL вроде работает, непонятные feeder’ы заменились user_cell’ами, и наверное эта картина теперь будет постоянна, понаблюдаю…

В Verilog-описание схемы LCELLы пока не вводил, удалось обойтись изменениями в qsf-файле:

Минус этого способа убогие автогенерируемые имена LCELLов

Кстати, к вопросу "почему". Вторая причина появления этих фидеров - нарушение hold time в пути, и разводчик вставляет их для исправления этого нарушения. Причем тут достаточно одной пикосекунды, чтобы в один путь его вставили, в другой - нет.

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

С чего Вы решили, что разводка будет одинаковой ? Я пруф не приведу сейчас, читал немного - они разводку начинают со случайных ячеек (ну грубо говоря). Плюс достоверно наши разводчики говорили - не совпадает разводка от раза к разу.

С псевдослучайных. Для этого SEED и задается...
А доказать в данном случае просто - собираем два раза один проект, и сравниваем битстрим - видим, что он одинаковый.

Ну а если ничего не задавать - SEED нулевой будет всегда ? Я более про Квартус

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

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

В софте Xilinx-а я уже много лет наблюдаю, что разводка на 100% воспроизводится при неизменных стартовых условиях.

Не подходит, пути к этим триггерам исключены из временного анализа с помощью set_false_path.

Картинки есть, а где HDL-код для триггера и для того, что рядом с ним?

Верно! Фиттер реализует вероятностный подход в своей работе. И только LLR (Logic Lock Regions) он не трогает. Оставляет прежним от старой компиляции. При инкрементной компиляции это неизбежно (и удобно!). Все что вы зафиксировали в проекте будет прежним, а вот остальное он будет разводить каждый раз по-разному. Единственный критерий,- требования констрейнов. Воспроизводимость проектов разная, но дизайн - рабочий!

В Verilog-коде нет ни чего мудреного и навряд ли даст какую-нибудь зацепку, тем не менее:

Это синхронизатор из двух последовательных триггеров. В 0ом посте приведена картинка для пути от внешней комбинаторной схемы до регистра sync[0]. Но уверяю Вас внутри этого модуля, путь от sync[0] к sync[1] подвержен тойже проблеме (регистр sync[1] реализуется, то с feeder’ом, то без), с той лишь разницей, что это синхронная схема и ее временные характеристики обеспечивает Quartus, мне до них нет дела.

Думаю, изучив триггеры в своем проекте с помощью Technology Map Viewer(Post-Fitting), также обнаружите, что они реализуются по-разному, в RTL Viewer они идентичны.

Т.е. Вы настаиваете, что в Квартусе используется внешний генератор случайных чисел? Пришлите мне пожалуйста проект, который разводится по разному от запуска к запуску при неизменных настройках, мне даже интересно.

Это нам рассказывалось на сертифицированных курсах подготовки по дизайну с Квартусом в Киеве.(Преподаватель был по фамилии Антонюк) Подчеркивалась именно эта мысль! Проекты не воспроизводимы из-за встроенного генератора случайных чисел... Если только явно не залочить зоны!

Если SEED один и тот же, то и результат должен быть одинаковым. Иначе... трудно представить, например, компилятор для ARM, который каждый раз выдает разный код. Так можно и в дурку загреметь.
Скорее всего, преподаватель "слышал звон...".

Нет такой аналогии разработки проекта под ARM и под FPGA!.. И не надо ничего представлять... Условия требований по констрейнам соблюдены, а на каком LUT это сделано физически,- все равно! И чем вас смущает факт попадания проекта в разные области ПЛИСины? Я не вижу противоречий!...

Вот именно. Первое же решение останавливает работу компилятора.
А если решение не найдено, вот тогда ищутся способы...

В Quartus-е запускаем Design Space Explorer, находится лучший вариант, определяемый конкретным SEED. А потом, что - все теряем, ибо ничто не предсказуемо? не гарантируется, что будет повторено? Разве не бред?

Ну на самом деле я тоже из тех кто "слышал звон", более того, щупал его сам. У меня есть твердая уверенность, что когда-то раньше тот же квартус мог по разному оттрассировать проект от случая к случаю, просто размещая элементы в различных областях кристалла. Но во прямо сегодня взял попробовал несложный проект, примерно на 1000 лутов. Версия квартуса 12.1 расположила его с точностью до бинарного совпадения битовых файлов. Так что не знаю что теперь думать...

Нашел первый попавшийся проектик (последний, по списку), и Quartus 9.1 выдал мне то же, что и 4 месяца назад.

А как вы проверяете?.. С точностью до бита?

тоже ради интереса пересобрал проект, который собирался последний раз аж в 2007 году. Совпадение битстрима 100%-ное.

Как проверяю совпадение - видимо, как все... cmp -l file1.rbf file2.rbf

Я проверяю в Total Commander, Файлы->Сравнить по содержимому.

Интересно...
Тогда как вы объясните проблему, описанную в старте топика?

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

ТС не писал, что проект при этом никак не менялся. Лично я понял так, что перекомпиляции происходили именно по причине каких-то изменений в проекте, а не просто так без причин к этому.

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


Не в одном из постов ТС-а нет утверждений, что разница возникает при полном сохранении исходных условий - настроек и кода.

Не холивара ради...
Взял простой проект в 13.1 версии Квартуса.
Собрал.
Взял те же исходники, собрал новый проект с теми же параметрами.
Собрал.
Результат разный, но полностью рабочий в комнатных условиях.
Как-то так...

А новый проект это не честно, никаких гарантий, что все параметры те же, и прядок компиляции файлов тот же. Честно - это пересобрать заново тот же проект.

Извиняюсь, что не совсем четко сформулировал суть проблемы, попробую исправиться
Есть следующий код:

В RTL Viewer’е он выглядит так:
Нажмите для просмотра прикрепленного файла
В Technology Map Viewer(Post-Fitting):
Нажмите для просмотра прикрепленного файла
Как видно появились ячейки комбинаторной логики, выполняющие непонятную мне функцию, но бог с ними меня они не беспокоят.
Проблема в том, что при каких-то условиях (например после добавления нового кода), этот кусок может собраться так(далее фотошоп):
Нажмите для просмотра прикрепленного файла
Здесь один из триггеров реализуется по другому - без feeder’а, в связи, с чем длина пути к нему больше чем к остальным.
Мне нужно чтобы путь ко всем четырем триггерам был одинаковым, т.е. одинаковая реализация. Поэтому хочется знать, от чего она зависит.

Отмечу, что пути к этим регистрам исключены из временного анализа, а значит реализация не связана с обеспечением setup/hold условий. Также, по наблюдению, внутри одного LABа триггеры реализуются одинаково.

Что касается возникшего здесь спора, результирующие файлы будут идентичны, при неизменном коде, параметрах компиляции, и версии Quartus(32bit и 64bit отличаются). Это из моего опыта, около 3х месяцев

Да забейте, никому ваш триггер не интересен. В этой теме теперь серьезные дядьки бьются ;-)

А вдруг Покрайне мере с подсказки SM одно из решений нашлось.

Ха! Я уже 4 года как на Xilinx-е сижу...
Скорее всего дело в настройках проекта...