Почему один и тотже триггер реализуется по-разному?, как с этим бороться? Опции

[Viwon]

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

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



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

[o_khavin]

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

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

[dxp]

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

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

[Мур]

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

[spectr]

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

[alexadmin]

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

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

[Dmitriyspb]

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

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

[spectr]

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

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

[Viwon]

Полностью аналогичная тема была несколько дней назад.

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

У вас чисто академический интерес или что-то не получается?

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

[Dmitriyspb]

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

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

[SM]

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

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

[Viwon]

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

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

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

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

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

[Maverick]

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

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

[Dmitriyspb]

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

Халявщики

[Maverick]

Халявщики

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

[Dmitriyspb]

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

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

[SM]

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

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

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

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

[Viwon]

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

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

Код

#Вставляем LCELL между источником и триггером
set_instance_assignment -name LCELL_INSERTION 1 -from "VIRTUALPAL:inst4|LOCKPOSa~0" -to "POSCOUNTER:inst2|SYNCHRONIZER:m_lockpos_sync[0]|sync[0]"
#Фиксируем LCELL в LUTе LE
set_location_assignment LCCOMB_X14_Y6_N0 -to "inst4|LOCKPOSa~0user_cell0"
#Фиксируем регистр в LE
set_location_assignment LCFF_X14_Y6_N1 -to "POSCOUNTER:inst2|SYNCHRONIZER:m_lockpos_sync[0]|sync[0]"

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

Сообщение отредактировал Viwon - Mar 21 2014, 11:27

[SM]

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

[o_khavin]

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

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

Сообщение отредактировал o_khavin - Mar 21 2014, 13:44

[DASM]

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

[SM]

со случайных ячеек (ну грубо говоря).

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

[DASM]

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

[SM]

SEED нулевой будет всегда ?

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

[DASM]

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

[o_khavin]

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

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

[Viwon]

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

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

[FPGAz]

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

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

[Мур]

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

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

[Viwon]

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

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

CODE

module SYNCHRONIZER(SIGNALa, SIGNAL, CLK);
output SIGNAL;

input SIGNALa;// внешний асинхронный сигнал
input CLK;

reg [1:0] sync;
always @(posedge CLK)
sync[1:0] <= {sync[0], SIGNALa};

assign SIGNAL = sync[1];

endmodule

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

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

Сообщение отредактировал Viwon - Mar 25 2014, 09:10

[o_khavin]

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

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

[Мур]

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

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

[ViKo]

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

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

[Мур]

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

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

[ViKo]

Условия требований по констрейнам соблюдены, а на каком LUT это сделано физически,- все равно!

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

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

[alexadmin]

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

[ViKo]

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

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

[Мур]

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

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

[SM]

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

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

[ViKo]

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

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

[Мур]

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

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

[ViKo]

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

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

[SM]

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

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

[o_khavin]

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

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

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

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

Сообщение отредактировал o_khavin - Mar 26 2014, 15:24

[warrior-2001]

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

[SM]

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

[Viwon]

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

CODE

module TRIGGERS(DATA, SIGNALa, CLK);
output [3:0] DATA;
input SIGNALa;
input CLK;

reg [3:0] triggers;
always @(posedge CLK)
triggers <= {4{SIGNALa}};
assign DATA = triggers;
endmodule

В RTL Viewer’е он выглядит так:

В Technology Map Viewer(Post-Fitting):

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

Здесь один из триггеров реализуется по другому - без feeder’а, в связи, с чем длина пути к нему больше чем к остальным.
Мне нужно чтобы путь ко всем четырем триггерам был одинаковым, т.е. одинаковая реализация. Поэтому хочется знать, от чего она зависит.

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

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

[alexadmin]

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

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

[Viwon]

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

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

[Мур]

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


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

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

[ViKo]

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

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

Взял те же исходники, собрал новый проект с теми же параметрами.

Уверены на все 100%, что параметры идентичны? Там мно-о-о-го параметров.

[SM]

Там мно-о-о-го параметров.

Скорее даже не в параметрах дело (допустим, они по умолчанию), а в том, что порядок чтения исходников поменялся в проекте. От этого результат точно другой становится (проверял лично)!

[ViKo]

Скорее даже не в параметрах дело (допустим, они по умолчанию), а в том, что порядок чтения исходников поменялся в проекте. От этого результат точно другой становится (проверял лично)!

Проверил на вчерашнем. Сколько не перетрахивал порядок файлов, результат был неизменный.
Как только изменил SEED с 1 на 2, получил под 900 различий в sof файле.
Проектик простенький.

[SM]

Сколько не перетрахивал порядок файлов, результат был неизменный.

Возможно, это зависит от каких-то опций компиляции и оптимизации, связанных со сквозной оптимизацией через интерфейсы модулей. Или еще с чем то. У меня есть жирный проект из 43 файлов, который еле-еле лезет по таймингам, в нем это проявляется. А вот в другом проекте, там всего 3 файла, вроде не проявляется.

[o_khavin]

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

Скорее всего дело в порядке следования исходников. Файлы проекта сравнивали между собой?

[XVR]

Здесь один из триггеров реализуется по другому - без feeder’а, в связи, с чем длина пути к нему больше чем к остальным.
Мне нужно чтобы путь ко всем четырем триггерам был одинаковым, т.е. одинаковая реализация. Поэтому хочется знать, от чего она зависит.

От того, как показалось удобнее синтезатору. Хотите однозначности - описывайте этот кусок схемы в примитивах FPGA, запрещаете его оптимизацию в синтезаторе и вводите констрейны на физическое размещение элементов. Я не в курсе, как это делается в Quartus'е, сам работаю с Xilinx

Отмечу, что пути к этим регистрам исключены из временного анализа,

А зря, было бы неплохо на них тоже какие нибудь констрейны наложить. А так синтезатор имеет полное право сделать с этими путями все, что ему захочется. Даже провести их через весь кристалл (3 раза )

[o_khavin]

Как видно появились ячейки комбинаторной логики, выполняющие непонятную мне функцию, но бог с ними меня они не беспокоят.

Их функция совершенно понятная - фиттеру показалось, что так будет проще реализовать требуемую топологию.

Проблема в том, что при каких-то условиях (например после добавления нового кода), этот кусок может собраться так.
Здесь один из триггеров реализуется по другому - без feeder’а, в связи, с чем длина пути к нему больше чем к остальным.

Это тоже нормально, просто теперь фиттеру показалось по другому.

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

От того, как фиттеру покажется правильно.

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

То, что пути исключены из временного анализа, вовсе не говорит, что фиттер не будет их трогать. Во первых ему в любом случае нужно эти пути проложить, а во вторых эти пути должны не мешать другим путям. Единственный вариант принудить фиттер - захардкодить всё в один LAB.
Но IMHO, Вы пытаетесь достигнуть конечной цели каким-то не тем путём.

[Viwon]

to XVR, o_khavin
Исходный вопрос и его решение можно посмотреть здесь, буду рад, если есть что там добавить. В итоге мне удалось решить ту задачу на приемлемом уровне путем фиксации регистров в соседних LABах, но результат может быть улучшен решением проблемы обсуждаемой в этом топике.
Я понимаю, что фиттер разводит не от балды (или от балды? ), а потому что ему так «удобнее», вот и хочется создать ему комфортные условия для одинаковой разводки, но что это за условия?
Пока есть предположения

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

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

Не понятно что мешает, судя по Chip Planner’у в LABах куда назначены триггеры, нет ничего кроме них самих и их feeder’ов. Но мои знания архитектуры ПЛИС слабы, а Chip Planner могу только запускать , поэтому пока ни чего не утверждаю.

Сообщение отредактировал Viwon - Mar 27 2014, 07:43

[SM]

То, что пути исключены из временного анализа, как раз и приводит к тому, что оно как развелось, так и развелось, без какой либо оптимизации. Так что, как вариант, второй способ сделать время повторяемым, кроме ручного вставления LUT, может быть, задание жесткого set_max_delay на путь, чтобы он не давал возможностей втыкать эти feeder-ы, или жесткие set_max_delay и set_min_delay одновременно, чтобы он разводку делал в совсем жестких временных рамках...

[warrior-2001]

Тема весьма бурная и я не поспею ответить всем. Если брать одни и те же исходники и компилить их, не удаляя старую инфу о предыдущей компиляции, то результат будет гарантированно одинаков. С этим не поспоришь. Но если с одинаковыми исходниками собрать несолько ОДИНАКОВЫХ проектов, то результат может отличаться. И в чем тут проблема - разбираться можно долго, ибо исходников САПР нет.
Задача размещения элементов на кристалле весьма трудоёмка, и винить в неповторяемости трудно. Если все установки и тайминги выполняются(ну и логика верная), то с большой долей вероятности можно утверждать, что проект рабочий, а как там регистры лягли - дело второе. Если разводить два регистра - повторяемость будет много больше, чем у проекта со 100% загрузкой.
Я лишь делюсь своим скромным опытом, и не выдвигаю никаких гипотез.

[Viwon]

То, что пути исключены из временного анализа, как раз и приводит к тому, что оно как развелось, так и развелось, без какой либо оптимизации. Так что, как вариант, второй способ сделать время повторяемым, кроме ручного вставления LUT, может быть, задание жесткого set_max_delay на путь, чтобы он не давал возможностей втыкать эти feeder-ы, или жесткие set_max_delay и set_min_delay одновременно, чтобы он разводку делал в совсем жестких временных рамках...

Чтобы тут не флудить, ответил в здесь.