3.14 0 13 января, 2005 Опубликовано 13 января, 2005 · Жалоба Народу умного у нас тут порядком бродит, может совместными усилиями ... Из кожи вон лезу, стараюсь проект описывать так чтоб в конце глянул на отчет PAR и понял будет работать или нет. У ISE достаточное констрейнов, чтоб затянуть даже очень заковыристое устройство. Хотя "нужных" всего два : PERIOD да OFFSET (хотя я предпочитаю пользоваться MAXDELAY, смущает меня варнинг того что OFFSET только с пина можно). Все бы ничего, дык вот одной тактовой не отделаешса, а у меня еще тактовая как правило умножается, так что в Spartan2 больше двух глобальных тактовых не получить :(. Приходится тактовые обычными линиями делать, как то не прижилось у меня LOWSKEW. И тут начинается ... Разведеш, по отчету все ОК, в жизни такое творится :( ... Есть такой констрейн MAXSKEW - ограничивавет разбег тактовой. Только вот незадача, констрейн сделали а средство для его определения забыли. Пример: Счетчик имеет длительность путей от 2 до 5 нс, в отчете PAR фигурирует только 5, а для MAXSKEW надо 2. И как выковыривать эти минимальные значения, лазить в TimingAnalyzer и просматривать все от пути тактовой. Дак это смерти подобно на больших модулях. Что скажете? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
irum4 0 13 января, 2005 Опубликовано 13 января, 2005 · Жалоба Странно. Во втором Спартане вообще-то 4 глобальных буфера. И частоту я умножал и на 2 и на 4. И работало. Если умножаю частоту на 2, то в констрейнах достаточно указать только период на первой частоты, все производные ISE автоматически посчитает. Второй Спартан я разганял до 180 МГц и работало, вот только счетчики брал только из IP Core и некоторые тригера приходилось расставлять ручками. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
3.14 0 13 января, 2005 Опубликовано 13 января, 2005 · Жалоба Может я не ясно выразился ... С глобалом все ОК, но их не хватает, а когда тактовая не на глобале тогда :( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
svtsvt 0 17 января, 2005 Опубликовано 17 января, 2005 · Жалоба А какая проблема с MAXSKEW ? Задаешь свои значения, PAR разводит, в его отчете (файл с расширеним .par) смотришь, что получилось. Если тебя устраивает разбег в 2 нс, то в Sp2 между CLB (не к пинам) это достигается всегда и без проблем даже если твои клоки заведены и на логику. А разбег клоков между триггерами синхронных счетчиков или мышины состояний надо все-таки ограничивать 1 нс. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
3.14 0 17 января, 2005 Опубликовано 17 января, 2005 · Жалоба Извините, но я думаю надо вчитываться в вопрос ... < Только вот незадача, констрейн сделали а средство для его определения забыли> Перефразирую. Определение минимального пути для определенного клока влечет определенные сложности. Указав "на шару" (сейчас так и приходится делать), "перегнеш палку" - замучаеш PAR и ограничений не достигнеш (причем не только MAXSKEW), не догораничиш :(... Да даже хотя бы просто знать что у имеется "плюшечка" великое благо на пути к автоматизации пректирования. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
wintser 0 20 января, 2005 Опубликовано 20 января, 2005 · Жалоба Я честно говоря то же недолго вчитывался .. но лезу с вопросом :) Что то я не пойму, а почему нельзя клок посадить на линии с малым разбросом ? (типа атрибута USELOWSKEW). И задать period какой нужен, я насколько понимаю при задании period трассировщик сам контролирует разбросы ... А если уж тут ругнется , что данные раньше клока, ничего не попишешь.. перетрассируй. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
3.14 0 21 января, 2005 Опубликовано 21 января, 2005 · Жалоба Просто я слегка предвзято отношусь к LOWSKEW :( Наверное зря ;), похоже это единственное решение. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
wintser 0 25 января, 2005 Опубликовано 25 января, 2005 · Жалоба Вообщем то зря, я со Spartan не работал... но схожая проблема с буферами была в VertexE, приходилось сажать клок на LOWSKEW. Проблема решалась, причем нагрузок было приличное количество (кстати для лучшей трассировки в компонентах, на который заходит данный клок, лучше убрать атрибуты относительного размещения RLOC). В Vertex2 такой проблемы с количеством буферов глобальных уже нет .. и слава богу :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
3.14 0 25 января, 2005 Опубликовано 25 января, 2005 · Жалоба <Вообщем то зря, я со Spartan не работал... но схожая проблема с буферами была в VertexE, приходилось сажать клок на LOWSKEW. Проблема решалась, причем нагрузок было приличное количество (кстати для лучшей трассировки в компонентах, на который заходит данный клок, лучше убрать атрибуты относительного размещения RLOC). В Vertex2 такой проблемы с количеством буферов глобальных уже нет .. и слава богу > Вот только решение слегка специфичное получается (если не сказать корявое). Если RLOC прийдется выключать, это очень плохо :( Еще я заметил, что модули имеющие выходные регистры тактируемые от lowskew, отказываются разводится, PAR выдает варнинг, что не может развести эту тактовую и садит ее на local :( Еще заметил, что сам PAR, не брезгует для порстых цепей использовать lowskew линии. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
wintser 0 26 января, 2005 Опубликовано 26 января, 2005 · Жалоба <Вообщем то зря, я со Spartan не работал... но схожая проблема с буферами была в VertexE, приходилось сажать клок на LOWSKEW. Проблема решалась, причем нагрузок было приличное количество (кстати для лучшей трассировки в компонентах, на который заходит данный клок, лучше убрать атрибуты относительного размещения RLOC). В Vertex2 такой проблемы с количеством буферов глобальных уже нет .. и слава богу > Вот только решение слегка специфичное получается (если не сказать корявое). Если RLOC прийдется выключать, это очень плохо :( Еще я заметил, что модули имеющие выходные регистры тактируемые от lowskew, отказываются разводится, PAR выдает варнинг, что не может развести эту тактовую и садит ее на local :( Еще заметил, что сам PAR, не брезгует для порстых цепей использовать lowskew линии. <{POST_SNAPBACK}> Ничего специфического или корявого в данном случае нет, тем более что отключение RLOC это просто помощь трассировщику, которую можно ему и не предоставлять. И вообще я немного не понимаю , в чем проблема .. почему нас должно интересовать как и что делает PAR. Главное чтобы наши ограничения были выполнены (по периоду и по skew) , остальное не волнует , это и есть цель всех мероприятий. Отмечу по опыту, что если все ограничения заданы правильно, то железка работает .. .а если ограничения не выполнены или неверно или не доконца описаны, то не рабоает :). P.S. А насчет RLOC - эот совет его убрать, если в проекте очень много нагрузок, сидящих на этом клоке без глобального буфера, и ограничения при первой трассировке были не выплнены .. кстати, по-моемому сам трассировщик то же выдает этот совет, не помню надо посмотреть Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
3.14 0 26 января, 2005 Опубликовано 26 января, 2005 · Жалоба Как ни хотелось, но похоже разговор заходит в ... <Ничего специфического или корявого в данном случае нет, тем более что отключение RLOC> Ну, не знаю как Вы пришли к такому выводу. То что так просто на выходные регистры не завести, разве это не специфика. Ну а насчет удаления RLOC, я вообще возмущен. Вы что CoreGen не пользуетесь. Потом, имеется куча библиотечных примитивов, расозноваемых и подставляемых синтезатором, в которых взаимно-ориентированное размещение передается не посредством RLOC. <И вообще я немного не понимаю , в чем проблема .. > В смысле, основной вопрос описан в первом посте. <почему нас должно интересовать как и что делает PAR.> Ну если все "с легкостью" получается, задал констрейны, достиг и забыл. А если нет, вот и извращаешся. Извращения будут в меньшей степени "статистическими", если примерно прикидываете работу "черного ящика". А высказывания о работе PAR, в предидущем посте, из-за вывода который можно сделать на основании того, что PAR без "спроса" пользуется lowskew линиями: почему бы ему изначально локальный клок на lowskew не садить. Может в дальнейшем так и будет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
wintser 0 27 января, 2005 Опубликовано 27 января, 2005 · Жалоба Ладно, я так понял. что тема закрыта, т.к. вы нехотите даже вникать в СУТЬ того что я говорю... а переводите разговор в какое то кидание пальцев, значит Вам эта тема не так важна Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
3.14 0 27 января, 2005 Опубликовано 27 января, 2005 · Жалоба Ну это Вы зря, просто известное количество вытекающих нюансов использования lowskew, снова заставляют задуматься о поисках решения изначального вопроса. Ведь запросто может случится так, что PAR скажет "извини парниша, пользуйся локалом". Я так понимаю под "распальцовкой" Вы поняли мое возмущение по поводу отключения RLOC. Под фразой " Вы что CoreGen не пользуетесь" я не язвил, а хотел сказать - была нормальная корка, для которой производитель мог "гарантировать" размещение и разводку с определенными показателями, при отключении RLOC, мы просто лишаемся всех благ. P.S. Извините, а какую суть, в Ваших словах я пропустил? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
