Нелья просто так взять, и выкинуть ресет ☺️ Код все равно считался бы измененным, и все равно потребовал бы проверки на SEC
Поймите, мы делаем SEC не потому что не умеем инферрить сдвиговые регистры, а потому что нам нужна абсолютная беспристрастная гарантия, что своими действиями мы не изменили поведение кода, что впоследствии может стоить очень-очень дорого
Наверное, поставить второй BUFGCTRL было бы более грамотным решением. Но наша проблема с времянками решилась и обычным BUFG. Идеально одинаковых задержек все равно не будет, потому что, кроме задержки на примивах, есть еще net delay
Или в базе компонентов лежит один и тот же примитив
BUFGCTRL, в зависимости от конфигурации, может быть BUFGCTRL, BUFGCE_1, BUFGMUX, UFGMUX_1 или BUFGMUX_CTRL.
А буфер BUFG - это вариация BUFGCE. Так что, это разные буферы
Ширина 32 и глубина 128 - это искуственный пример. В реальном дизайне параметры delay_n разные - есть блоки и поменьше объемом и побольше. Использовать блочную память везде - точно было бы расточительно.
К тому же, Виваде пришлось бы притягивать логику к определенным колонкам, в которых находится блочная память. Это могло создать дополнительные сложности при разводке дизайна.
Проблем с SRL32 не встречал. И даже писал когда-то проект, который забивает весь кристалл этими блоками. Вот код, строка 115. Можете попробовать
Давайте немного отвлечемся от ОС и начнем с другого:
Пускай ОС и версия IDE одна и та же. Берем два одинаковых проекта и собираем их с разными SEED. Логика раскладывается на чипе различным образом, и поэтому в отчетах тайминга видим различные Fmax. Логично?
Теперь собираем одинаковые проекты в разных версиях IDE на одной ОС, SEED не трогаем. Разные версии среды отличаются версиями библиотек, или, может, какими-то настройками, реализацией алгоритмов, наличием или отсутствием дополнительных шагов оптимизации. Снова получим различную разводку логики на кристалле и разные Fmax
Ну и возвращаемся к ОС. Снова берем два идентичных проекта. Как и в случае 2, на процесс сборки будут влиять внешние условия. Расстановка примитивов на кристалле снова будет отличаться, что повлияет на Fmax
В итоге, на Fmax во всех рассмотренных случаях влияет один фактор - физическое расположение примитивов и связей между ними. Механизм одинаковый во всех трех случаях. Считать, что расчеты временного анализатора в одной из ОС "подкручены" - это из разряда теорий заговора =)
Возможно, что 200 при сборке под Windows равно в железе 250 при сборке под Linux.
Вполне логичное рассуждение. В IDE встроен временной анализатор, который делает для нас расчеты слеков и Fmax. Полное знание о том, как делаются эти расчеты, и какой там уровень пессимизма заложен - есть только у производителя. Нам ничего не остается, кроме как доверять этим отчетам
Это означает, что среда будет использовать тем более сложные и времязатратные алгоритмы, чем более высокие таргеты по частоте мы задаем.
А если цели добиваться высоких частот нет - среда будет экономить время и завершит сборку. Хотя возможности дополнительной оптимизации дизайна у нее еще есть
В разных ОС вызовы системных функций реализованы по-разному. У Linux свой API, у винды - свой. Поэтому и разница. А если вы не меняете ОС и версию IDE - то производитель гарантирует детерминированность. То есть выходные файлы будут бит-в бит идентичными.
Information
Rating
163-rd
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Ваше предложение ничем не лучше, и ничем не хуже нашего. Дело вкуса, как организовать код.
Нелья просто так взять, и выкинуть ресет ☺️ Код все равно считался бы измененным, и все равно потребовал бы проверки на SEC
Поймите, мы делаем SEC не потому что не умеем инферрить сдвиговые регистры, а потому что нам нужна абсолютная беспристрастная гарантия, что своими действиями мы не изменили поведение кода, что впоследствии может стоить очень-очень дорого
Наверное, поставить второй BUFGCTRL было бы более грамотным решением. Но наша проблема с времянками решилась и обычным BUFG. Идеально одинаковых задержек все равно не будет, потому что, кроме задержки на примивах, есть еще net delay
BUFGCTRL, в зависимости от конфигурации, может быть BUFGCTRL, BUFGCE_1, BUFGMUX, UFGMUX_1 или BUFGMUX_CTRL.
А буфер BUFG - это вариация BUFGCE. Так что, это разные буферы
Вы правы, LUTRAM-ов должно быть в 4 раза больше 👍 Картинку исправил, текст остался актуальным
Ширина 32 и глубина 128 - это искуственный пример. В реальном дизайне параметры delay_n разные - есть блоки и поменьше объемом и побольше. Использовать блочную память везде - точно было бы расточительно.
К тому же, Виваде пришлось бы притягивать логику к определенным колонкам, в которых находится блочная память. Это могло создать дополнительные сложности при разводке дизайна.
Проблем с SRL32 не встречал. И даже писал когда-то проект, который забивает весь кристалл этими блоками. Вот код, строка 115. Можете попробовать
https://github.com/pConst/xilinx_max_power/blob/master/xilinx_max_power.srcs/sources_1/main.sv
Давайте немного отвлечемся от ОС и начнем с другого:
Пускай ОС и версия IDE одна и та же. Берем два одинаковых проекта и собираем их с разными SEED. Логика раскладывается на чипе различным образом, и поэтому в отчетах тайминга видим различные Fmax. Логично?
Теперь собираем одинаковые проекты в разных версиях IDE на одной ОС, SEED не трогаем. Разные версии среды отличаются версиями библиотек, или, может, какими-то настройками, реализацией алгоритмов, наличием или отсутствием дополнительных шагов оптимизации. Снова получим различную разводку логики на кристалле и разные Fmax
Ну и возвращаемся к ОС. Снова берем два идентичных проекта. Как и в случае 2, на процесс сборки будут влиять внешние условия. Расстановка примитивов на кристалле снова будет отличаться, что повлияет на Fmax
В итоге, на Fmax во всех рассмотренных случаях влияет один фактор - физическое расположение примитивов и связей между ними. Механизм одинаковый во всех трех случаях. Считать, что расчеты временного анализатора в одной из ОС "подкручены" - это из разряда теорий заговора =)
Как вы предлагаете проверить "действительную" производительность? Что и чем измерять? =)
Вполне логичное рассуждение. В IDE встроен временной анализатор, который делает для нас расчеты слеков и Fmax. Полное знание о том, как делаются эти расчеты, и какой там уровень пессимизма заложен - есть только у производителя. Нам ничего не остается, кроме как доверять этим отчетам
Далеко не всем нужна повторяемость сборки. Это просто один из нюансов, для кого-то важный, для кого-то - нет
В своих догадках мы можем опираться на документацию производителя. А производители говорят нам, что используют так называемый "timing driven" синтез и имплементацию. https://www.intel.com/content/www/us/en/programmable/quartushelp/17.0/logicops/logicops/def_synth_timing_driven_synthesis.htm
https://docs.amd.com/r/en-US/ug904-vivado-implementation/Routing
Это означает, что среда будет использовать тем более сложные и времязатратные алгоритмы, чем более высокие таргеты по частоте мы задаем.
А если цели добиваться высоких частот нет - среда будет экономить время и завершит сборку. Хотя возможности дополнительной оптимизации дизайна у нее еще есть
В разных ОС вызовы системных функций реализованы по-разному. У Linux свой API, у винды - свой. Поэтому и разница. А если вы не меняете ОС и версию IDE - то производитель гарантирует детерминированность. То есть выходные файлы будут бит-в бит идентичными.