[doom13 0]

Поменял опцию Fitter-a Fitter Initial Placement Seed на 2 (было 1), пересобрало и ошибок по таймингам не выдает, максимальную частоту показывает 410МГц, кто может пояснить, как он допер, что можно разбросать элементы правильно? И что мешает сделать это при Seed 1? И как же тогда временные ограничения, если сработалo только в комплексе с конкретной настройкой Fitter-a?

[ViKo 1]

Кроме Auto Fit и Fast Fit есть еще Standard Fit.

[doom13 0]

Кроме Auto Fit и Fast Fit есть еще Standard Fit.

да, оно даёт результат лучше фаста, но хуже авто (количество фалс пасов)

[ViKo 1]

да, оно даёт результат лучше фаста, но хуже авто (количество фалс пасов)

Это странно.

А что у вас стоит в поле Desired worst case slack для AutoFit?

[doom13 0]

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

Если изменить Optimization mode c Balanced (Normal flow) на Performance (High effort - increases runtime), то это даёт пинок QII развести всё без ошибок, но на опции Fitter_effort и optimization_technique это не влияет. Fmax в этом случае может выдержать 443 MHz.

 

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

[bogaev_roman 0]

Если изменить Optimization mode c Balanced (Normal flow) на Performance (High effort - increases runtime), то это даёт пинок QII развести всё без ошибок, но на опции Fitter_effort и optimization_technique это не влияет. Fmax в этом случае может выдержать 443 MHz.

 

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

Это уже шаманство, также как и смена seed. Такими вещами занимаются при сложных объемных проектах, а у Вас сумматор 8 разрядный, хоть и на высокой частоте. Может глюк квартуса этой версии, я с подобным сталкивался последний раз в 9 версии - в 17, 13, 14 такого не встречал. Можно еще попробовать перед полной компиляцией удалить содержимое файлов db и incremental_db - там вся информация сохраняется с предыдущих разводок, иногда перед новой полной разводкой сохраняется и используется предыдущий результат.

[doom13 0]

Это уже шаманство, также как и смена seed. Такими вещами занимаются при сложных объемных проектах, а у Вас сумматор 8 разрядный, хоть и на высокой частоте. Может глюк квартуса этой версии, я с подобным сталкивался последний раз в 9 версии - в 17, 13, 14 такого не встречал. Можно еще попробовать перед полной компиляцией удалить содержимое файлов db и incremental_db - там вся информация сохраняется с предыдущих разводок, иногда перед новой полной разводкой сохраняется и используется предыдущий результат.

Ок, установлен еще и 14.0 и 13.0, сейчас опробую, базы чистить я пробовал.

 

14 версия с настройками по умолчанию всё собрала, писец.

 

Спасибо, буду двигать дальше.

[warrior-2001 0]

Много глюков ловил в новых версиях квартуса из-за прав доступа! Только рут/админ и никак иначе!

[bogaev_roman 0]

Много глюков ловил в новых версиях квартуса из-за прав доступа! Только рут/админ и никак иначе!

:bb-offtopic: Я очень неохотно перехожу на новые версии - только когда они проверены временем и людьми. Сейчас это версия 17.0.2 (все 16 прошли мимо), но и в ней я нашел для себя одну неприятную вещь, хотя жалоб вроде и не было.

[doom13 0]

del

[doom13 0]

Это уже шаманство, также как и смена seed. Такими вещами занимаются при сложных объемных проектах, а у Вас сумматор 8 разрядный, хоть и на высокой частоте. Может глюк квартуса этой версии, я с подобным сталкивался последний раз в 9 версии - в 17, 13, 14 такого не встречал. Можно еще попробовать перед полной компиляцией удалить содержимое файлов db и incremental_db - там вся информация сохраняется с предыдущих разводок, иногда перед новой полной разводкой сохраняется и используется предыдущий результат.

Версия 17.1 с настройками по умолчанию собирает всё с таким же косяком как и 16.1. Руками разводку можно подправить.

:laughing:

[Kluwer 0]

Входные/выходные порты идут на ножки FPGA. Ругается на путь от reg_B[7] до sum1[7], смотрю как разбросал все в ChipPlanner-e. Если в Chip Planner-e подвинуть reg_B[7] максимально близко к sum1[7] и применить изменения в нетлисте, то все тайминги соблюдаются. Вопрос - почему автоматом не хочет поставить ячейки в нужные места (куча свободных ресурсов), чтоб все тайминги соблюдались.

Это - не такое "очевидное" решение. Потому что он тупо боится ставить reg_B[7] далеко от остальных, справедливо опасаясь, что у вас может шина "разбежится" (400МГц, так между прочим, не хухры мухры!).

А вы ещё зачем-то прилепили никому не нужный промежуточный регистр reg_sum, который явно назначили на выход sum. А компилятор Квартуса совсем не такой интеллектуальный, как вы могли подумать и он достаточно тупо выполнил ваши указания, повесив reg_sum чуть ли не на ногу sum. Была б его воля он бы его ещё на двухфазный выходной триггер (altddio) залепил, но права не имеет.

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

[doom13 0]

Это - не такое "очевидное" решение. Потому что он тупо боится ставить reg_B[7] далеко от остальных, справедливо опасаясь, что у вас может шина "разбежится" (400МГц, так между прочим, не хухры мухры!).

А вы ещё зачем-то прилепили никому не нужный промежуточный регистр reg_sum, который явно назначили на выход sum. А компилятор Квартуса совсем не такой интеллектуальный, как вы могли подумать и он достаточно тупо выполнил ваши указания, повесив reg_sum чуть ли не на ногу sum. Была б его воля он бы его ещё на двухфазный выходной триггер (altddio) залепил, но права не имеет.

Это "учебный" пример, и частота такая задана, чтобы посмотреть, когда ошибки появляются и как с ними бороться, и reg_sum добавлен для этих же целей.

 

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

Может и так, но две версии Квартуса результат дают разный. Версия 14 собрала всё правильно, для 16 приходится допиливать ручками.

И главный вопрос - как можно полагаться на все эти временные ограничения, если реально вижу, что возможность развести "правильно" (с учетом тех ограничений, которые заданы) есть, но разводит "криво"?!