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

Да, это так. Даже для одного клока фазы прихода на разные элементы (триггеры) будут разными. Однако этот разбег фаз учитывается самим ISE Place&Route, то есть логически синфазность не нарушается.
А Вы не преувеличиваете?

Одно дело учесть разбег при расчете полученых констрейнов.

А то получается что можно посадить тактовую на локальную линию, и пускай PAR разбег компенсирует :) (фантастика).

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


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

Да, это так. Даже для одного клока фазы прихода на разные элементы (триггеры) будут разными. Однако этот разбег фаз учитывается самим ISE Place&Route, то есть логически синфазность не нарушается.
А Вы не преувеличиваете?

Одно дело учесть разбег при расчете полученых констрейнов.

А то получается что можно посадить тактовую на локальную линию, и пускай PAR разбег компенсирует :) (фантастика).

 

Нет, не преувеличиваю :) Чтобы убедиться в этом, достаточно внимательно посмотреть временной отчет P&R, а именно, как проверяется выполнение временных ограничений, какие составляющие используются в расчете пути. Все средства P&R, с которыми мне приходилось работать, учитывают разбег фаз между элементами и не только его в процессе расположения и разводки соединений. :) Причем вне зависимости от того, глобальный ресурс используется под тактовую или нет.

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


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

Ну в любом случае, надеятся что разбег на глобальной линии систавит менее 0.7нс (для Spartan2) не стоит, а использовать локальную линию в качестве тактовой для хотя-бы мало-мальского синхронного автомата просто самоубийство (можно разбег и в 5нс получить).

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


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

Ну в любом случае, надеятся что разбег на глобальной линии систавит менее 0.7нс (для Spartan2) не стоит, а использовать локальную линию в качестве тактовой для хотя-бы мало-мальского синхронного автомата просто самоубийство (можно разбег и в 5нс получить).

 

Случалось, что по тем или иным причинам не было возможности использовать глобальные ресурсы для тактирования, использовали локальные. Таким образом тактировались и синхронные автоматы. То есть я хочу сказать, что ничего страшного в этом нет. При внимательном подходе все получается и работает :) Ведь никакого теоретического противоречия в этом нет. Главное, чтобы необходимые времена выполнялись.

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


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

Ну смотите, получили Вы разбег на локальной линии ~3нс, максимальный период для этой частоты период Вам выдаст PAR, а минимальный путь в этом частотном домене прийдется искать в ручную и смотреть не меньшне ли он этих самых 3нс (при желании можно задержку до тактового учитывать, но это уж черезчур геморойно). Повторять это при каждой итерации, занятие не для слабонервных.

Конечно ничего не поделаешь когда глобалов не осталось, но это уже игра в рулетку получается.

Или Вы знаете путь проще?

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


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

Ну смотите, получили Вы разбег на локальной линии ~3нс, максимальный период для этой частоты период Вам выдаст PAR, а минимальный путь в этом частотном домене прийдется искать в ручную и смотреть не меньшне ли он этих самых 3нс (при желании можно задержку до тактового учитывать, но это уж черезчур геморойно). Повторять это при каждой итерации, занятие не для слабонервных.

Конечно ничего не поделаешь когда глобалов не осталось, но это уже игра в рулетку получается.

Или Вы знаете путь проще?

 

Если я правильно понял, то здесь речь идет об анализе минимальных задержек. Если это так, то и этот процесс выполняется P&R автоматически, то есть вручную за этим следить также не требуется. P&R учтет все автоматически. То есть P&R всегда рассматривает как худший, так и лучший случай. Например, Actel Timing Analyzer предоставляет возможность анализа как максимальных задержек, так и минимальных. Кстати, например, для семейства Actel ProASICPlus разбег фазы тактового сигнала в 3-5 нс, даже при использовании глобальной цепи, совершенно нормальное явление :)

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


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

Если я правильно понял, то здесь речь идет об анализе минимальных задержек. Если это так, то и этот процесс выполняется P&R автоматически, то есть вручную за этим следить также не требуется. P&R учтет все автоматически.
Вот тут я с Вами не согласен, ничего он не учтет (по крайней мере для Xilinx), просто скажет какой разбег получился, а дальше думай сам ...

Ползание по отчетам Timing Analyzer требует тучу времени, хотя конечно имеется констрейн MAXSEW но его значение приходится ставить от балды (по описанным выше причинам).

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


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

Вот тут я с Вами не согласен, ничего он не учтет (по крайней мере для Xilinx), просто скажет какой разбег получился, а дальше думай сам ...

Ползание по отчетам Timing Analyzer требует тучу времени, хотя конечно имеется констрейн MAXSEW но его значение приходится ставить от балды (по описанным выше причинам).

 

То есть Вы хотите сказать, что P&R способен учесть заданные пользователем временные ограничения (констрейны), постараться выжать максимальную частоту работы схемы, но при этом совершенно не способен выполнить гораздо более элементарную задачу по учету разбега клока, да еще и со всеми известными параметрами. :) Странно как-то получается. Не находите?

 

Чем ситуация лучше (в отношении разбега фаз клока) при использовании глобальной цепи? Там разбег тоже не учитывается?

 

Вообщем, могу сказать только одно, работая с Xilinx, ошибок, связанных с разбегом фаз клока на разных элементах, не встречал ни разу, связанных с задержкой путей, сколько угодно. Встречал такое при работе с Actel, но это единичные случаи, да и P&R у Actel гораздо менее интеллектуальный.

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


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

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

Ситуация с глобалом лучше тем что разбег больше 1нс не будет (да и то на разных сторонах кристалла), у соседних слайсов он гораздо меньше будет, ну а в случае даже со сдвиговым регнистром минимальный путь по локальной линии между соседними слайсами будет ближе к 1нс.

Далее, откуда такая уверенность что у Вас не было проблем из-за разбега?

У меня на в разных проектах имелись модули у которых тактовая была на локале, это самые глючные модули в смысле непредсказуемости их работы при очередной итерации разводки проекта. Например, счетчики перестают считать и т.п. , при этом HDL модулей не меняется. Ситуация обостряется с ростом процента заполненности кристалла (приходилось постоянно мудрить с усилием и настройками PAR). При этом ест-но все констрейны выполняются, а вот MAXSKEW как правило меньше 2нс не выходит.

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


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

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

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

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

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

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

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

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

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