Перейти к содержанию
    

неустойчивость P&R ISE к констрейнам,как бороться?

собственно вопрос может и бестолковый, но может...

 

у меня бывает, что поставишь какой-нибудь временной констрейн на 9.9 нс - не может уложится P&R в это время, критический путь по этому констрейну получается 10.2 нс

 

а потом поставишь на этот же констрейн 10.4 нс - а P&R сгенерит так, что критический путь 9.8 нс ...

 

и еще - проект, который синтезировался на одном компе с одним набором констрейнов - никак не разводится на другом,

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

что сильно мешает распределенной работе.

 

может есть какие-то "народные средства" для этих проблем?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

<у меня бывает, что поставишь какой-нибудь временной констрейн на 9.9 нс - не может уложится P&R в это время, критический путь по этому констрейну получается 10.2 нс

 

а потом поставишь на этот же констрейн 10.4 нс - а P&R сгенерит так, что критический путь 9.8 нс ...>

 

Давно подмеченная особенность....

В таких случаях я обычно "шаманил" с Starting Placer Cost Table, что имеют значение от 1 до 100. Запускаешь одновременно несколько переложений одного и того же проекта с разными значениями (обычно рядом стоящими) этого шаманского лекарства - и смотришь, кто шустрее разводит. Остальные прерываешь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

По моим наблюдениям, если P&R не может "вписаться" в констрейн, он перестает оптимизировать данную цепь в пользу остальных.

Способ борьбы - не делать констрейны на пределе возможностей P&R. В данном случае, когда речь идет о единицах процентов периода можно лишь предложить по другому реализовать критические места проекта.

Что до разного результата на разных компах - не наблюдал такого никогда. Проверял на Athlon/Pentium-4/Celeron/Pentium-M/C3.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Проверял на Athlon/Pentium-4/Celeron/Pentium-M/C3.

 

про констрейны согласен, хотя знаю коллегу, который выжимает из синтеза перекруткой всех констрейнов - его проекты трогать потом вообще нельзя :)

 

сам еще наблюдал влияние констрейна который заведомо выполняется на какой-то критический, то есть есть например путь, который заведомо укладывается в 50нс законстрейнить 50нс - то может развалиться по другим ограничениям, а если его законстрейнить 60нс - то остальной проект улучшится

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Пропустите отPARенный проект с выдержанным констрейном через FPGA Editor и сделайте директ роутинг для критичной цепи. Сгенеренную последовательность вставьте в UCF. Можно еще так: В FPGA Editor делаете unrout all затем rout для критичной цепи и опять директ роутинг. Мне помогает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А вы не замечали,что выдавая разное время в тайминг аналайзере, разводика по разному и размещала проект в плисе?Я такое замечал.

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

Вот пример.тайминг аналайзер уверял,что микроблейз в нашем кристале минимум чем на 40 Мгц не заведётся.Однако подцепили генератор,и оказалось,что и на 50 он себя прекрасно чувствует.Правда это всё было при нормальном питании и температуре :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Мое субъективное мнение.

Не надо сосбо грузится по поводу всех этих "мистических" свойств PAR. В "светлом"(уже чувствую ваше раздражение) будующем влияние этого будет минимум. А сейчвс, даже если не вписывется на %20, да и хер с ним, главное работает платах на пяти и в темперетурном диапазоне! Опять всех с новым годом!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я обычно смотрю в Timing Analizer-e самый большой путь, и изменяю в этом месте исходник (добавляю триггеры и т.д.)

После 3х- 4х таких итераций все хорошо разводится.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Хотя здесь люди просто высказыватся, хочется подметить.

<Я обычно смотрю в Timing Analizer-e самый большой путь, и изменяю в этом месте исходник (добавляю триггеры и т.д.)

После 3х- 4х таких итераций все хорошо разводится. >

Не всегда возможно расконвейерить цепь. Да и анализ отчета Timing Analizer - занятие для отважных (на "больших" проектах).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

А вообще я согласен, что небольшое превышение никак не влияет на работу схемы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А сейчвс, даже если не вписывется на %20, да и хер с ним, главное работает платах на пяти и в темперетурном диапазоне! Опять всех с новым годом!

 

И на разных партиях кристаллов. Хе-хе...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

<И на разных партиях кристаллов. Хе-хе...>

Хе-хе не хе-хе, но так уж получается что работает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

<И на разных партиях кристаллов. Хе-хе...>

Хе-хе не хе-хе, но так уж получается что работает.

 

Повбивав би! Недавно как раз полностью переписал такой проект, который "работал" на столе у автора, но глючил в партии.

 

Как вообще можно вообще говорить о том, что разработанная система работает, не имея объективных данных по расстоянию до границы, за которой система перестанет работать? Как можно получить такие данные для достаточно сложной системы, кроме как пытаясь смоделировать систему с учетом разброса параметров, декларированного производителем компонентов и заложенного им в модели, и убедившись, что еще остается достаточный запас на всякий случай?

 

Фи...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Мда, ну у Вас и манеры :( ...

 

<Недавно как раз полностью переписал такой проект, который "работал" на столе у автора, но глючил в партии.>

Ну, авторы разные бывают. Тем более я не говорил про еденичный экземпляр. Всегда при создании/изменении в проекте обкатываю это на всех имеющихся платах (обычно штук по 5), и обязательно "морожу" и "грею" в меру возможности.

 

Получаемые задержки считаются для наихудшего случая - наименьшее напряжение + наибольшая температура.

Наши блоки работают примерно в условиях от -10 до +50, да и за напряжением питания слежу строго.

 

Еще, в нашей конторе, 5 разработчиков, 4 из них имеют крайне размытое представление о констрейнах, после размещения обычно не обращают никакого внимания на времяной отчет PAR. Тем не менее жизнь на этом не заканчивается и с каждой новой микросерией изделий (обычно по 5 штук) за ново свои проекты не ковыряют. Уверен, что такая же картина с %80 разработчиков FPGA.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...