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

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

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

В Technology Map Viewer(Post-Fitting):

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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


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


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

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


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

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

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

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