Нестабильность работы плис. Нестабильность проектов ПЛИС. Марсоходмарсоходopen Source Hardware ProjectOpen Source Hardware Project
 Скачать 242.86 Kb.
|
МАРСОХОД МАРСОХОД Open Source Hardware Project Open Source Hardware Project Нестабильность проектов ПЛИС Бывает, что есть проект, который вроде бы работает. Как только начинаешь добавлять в него новые модули или какие-то казалось бы небольшие изменения — перестает работать. В чем тут может быть дело? Каким правилам нужно следовать, чтобы получить стабильный проект? На мой взгляд правило есть только одно — проект не должен содержать асинхронной логики, все процессы должны быть только строго синхронными. Что такое синхронный дизайн? В синхронном проекте для ПЛИС есть один дирижер для всех музыкантов, для всей логики - это сигнал тактовой частоты. По каждому активному фронту тактовой частоты все регистры проекта одновременно фиксируют сигналы на своих входах и передают их на свои выходы. Подключенные к выходам регистров логические функции начинают свое вычисление и у них, как правило, есть только один период тактовой частоты для этих вычислений. Новые вычисленные значения из логических функций подаются на входы регистров и должны быть готовы к очередному активному фронту тактовой частоты. Логические функции — это сумматоры, вычитатели, умножители, мультиплексоры, дешифраторы и всякое другое. Выход логической функции зависит только от сигналов на входах. Внутри логической функции нет запоминающих элементов. Вычисление логической функции занимает время — чем сложнее логическая функция, тем дольше может считаться отклик. Например, сумматор 32х битных чисел является более сложной функцией, чем сумматор 4х битных чисел. Значит он будет вычислять дольше. Подробности Подробности Категория: Категория: Разное Разное Создано Создано 22 Апрель 2015 22 Апрель 2015 Автор: Автор: Николай Николай … … Осталось: 1000 символов Menu Menu Посмотрите на рисунок выше. Здесь изображены несколько регистров и в овалах — логика. Например, есть блок логики который выполняется дольше всего, целых 18 наносекунд. Именно этот критический путь будет определять максимально возможную частоту на которой сможет работать проект. В данном случае: Fmax = 1/ max(t1,t2,t3...tn) = 1/18нс 55МГц. Данные на входах регистров должны быть стабильны в момент фронта тактовой частоты. Еще правильней сказать, что данные должны быть стабильны как минимум «setup time» (t su ) до фронта и «hold time» (t h ) после фронта тактового сигнала. t su и t h – это параметры конкретной ПЛИС. В принципе, компоновщик (fitter) компилятора старается расположить элементы и логику в ПЛИС так, чтобы пути сигналов были короткими, чтобы задержка распространения сигнала была минимальной. Однако, к сожалению, это не всегда удается. Если проект сложный, если рабочая частота проекта оказывается равной или большей, чем рассчитанная во время компиляции F max , то проект работает на грани возможного. В состав пакета Quartus II входит временной анализатор TimeQuest. Эта программа рассчитывает и показывает критические пути и F max проекта после компиляции. Однажды компилятор смог удачно расположить логику и рассчитанная F max оказывается равной или выше реальной частоты проекта. В этом случае проект еще работает. Даже небольшое изменение в проекте заставляет компилятор располагать логику и регистры в ПЛИС несколько иначе, чем в прошлый раз. Критические пути меняются и расчетная F max может оказаться ниже реальной. Проект перестает работать. В этом случает требуется пересмотреть логические функции, насколько их можно упростить. Если упростить логические функции в Вот как на этом рисунке: в результате перекомпиляции fitter разместил регистры на удалении друг от друга, пути прохождения сигналов к отдельным регистрам стали разной длины. Время распространения сигнала до каждого конкретного регистра становится неодинаковым. Вероятность правильной передачи данных падает. Проект, кажется, перестает работать правильно. На самом деле он и раньше не очень хорошо работал, просто вероятность ошибки передачи между разными clock domain была довольно низкой и мы ее толком не замечали. Как же быть в этом случае? Неужели нельзя в проекте использовать несколько разных частот одновременно? На самом деле использовать несколько частот можно, но нужно понимать, как ими пользоваться. Будет правильно использовать для передачи данных из одного клокового домена в другой мегафункцию FIFO или двухпортовое ОЗУ. Например, альтеровский Megafunction Wizard позволяет создавать FIFO с двумя разными тактовыми входами для передающей и принимающей стороны. Альтеровское FIFO уже содержит в себе схему синхронизации, движение указателей на данные в ФИФО передается с помощью специальных кодов Грея. Что еще можно сказать по поводу стабильности проектов. Есть документ Альтеры https://www.altera.com/content/dam/altera- www/global/en_US/pdfs/literature/quartus2/qts_qii51006.pdf Recommended Design Practices. В этом документе написано, какие методы проектирования приветствуются, а каких лучше избегать. Вот краткий перечень, чего лучше не делать: 1) не используйте асинхронный сброс или установку регистров для логической обратной связи, вообще старайтесь избегать использование асинхронных сбросов и установки. Асинхронные сброс и установка нужны только для начальной инициализации проектов и для симуляции. 2) не используйте защелки данных по управляющему уровню (latch), для запоминания и хранения данных есть регистры, используйте регистры 3) не используйте задержки сигнала на логических элементах 4) не создавайте импульсов или мультивибраторов принцип действия которых основан на задержках в элементах 5) не используйте выход логической функции как сигнал тактовой частоты, вместо этого, используйте выход регистра как сигнал тактовой частоты 6) не используйте последовательных счетчиков 7) не используйте переключение тактовой частоты во время работы проекта 8) не используйте подавление тактовой частоты с помощью логики, вместо этого используйте синхронные схемы разрешения записи. Возможно я что-то упустил из вида, но кажется, что про основные возможные проблемы с проектами ПЛИС я рассказал. Тем не менее, на нашем сайте мы уже кое-что писали по поводу стабильности: 1) Передача группы сигналов в другой клоковый домен 0 0 0 2) Синхронизатор сигнала для CDC на Verilog 3) Еще о метастабильности. 4) Пример цифровой системы с несколькими тактовыми частотами. 5) Счетчик в коде Грея 6) Базовые принципы построения FIFO. Tags: стабильность FIFO clock domain FPGA Altera Quartus II Комментарии #6 Alex_M 02.07.2018 12:08 подскажите, есть ли способ создать задержку сигнала без использования тактового сигнала (то есть стандартная линия задержки не подходит), при этом без костылей в виде логических элементов? "3) не используйте задержки сигнала на логических элементах 4) не создавайте импульсов или мультивибраторов принцип действия которых основан на задержках в элементах" #5 LAS 11.04.2017 12:41 Цитирую nckm: например анализатор TimeQuest говорит про критические пути прохождения сигналов. Многое может сказать про проект. Планируется ли написание статьи о TimeQuest и о написании констрейнов? После прочтения статьи http://o53xo.nnuxillffzzhk.cmle.ru/articles/plis/2010_9_51.php появилась масса вопросов. #4 nckm 29.06.2015 05:04 Цитирую ehot29: Подскажите, можно ли заранее увидеть, что проект нестабилен используя инструменты altera? А еще лучше в каких именно местах. например анализатор TimeQuest говорит про критические пути прохождения сигналов. Многое может сказать про проект. +1 0 0 #3 ehot29 26.06.2015 07:32 Подскажите, можно ли заранее увидеть, что проект нестабилен используя инструменты altera? А еще лучше в каких именно местах. #2 umarsohod 28.04.2015 07:01 Цитирую alman: Как же быть, как же быть.? Не могли бы дать расширенный комментарий на "8) не используйте подавление тактовой частоты с помощью логики, вместо этого используйте синхронные схемы разрешения записи." Это вообще нельзя делать или иногда можно? Возлагаю большие надежды на "Clock Gating" - собираюсь подавлять тактовую частоту всего устройства, за исключением одного счётчика. Неужели меня поджидают проблемы и сюрпризы? В моём случае принципиально именно отрезание тактовой частоты. У вас какой чип? В циклонах3 (и старше) есть такая деталь - "ALTCLKCTRL" - https://www.altera.com/en_US/pdfs/literature/ug/ug_altclock.pdf возможно вам подойдет. #1 alman 27.04.2015 16:01 Как же быть, как же быть.? Не могли бы дать расширенный комментарий на "8) не используйте подавление тактовой частоты с помощью логики, вместо этого используйте синхронные схемы разрешения записи." Это вообще нельзя делать или иногда можно? Возлагаю большие надежды на "Clock Gating" - собираюсь подавлять тактовую частоту всего устройства, за исключением одного счётчика. Неужели меня поджидают проблемы и сюрпризы? В моём случае принципиально именно отрезание тактовой частоты. Обновить список комментариев Добавить комментарий Имя (обязательное) E-Mail (обязательное) Отправить JComments Подписаться на уведомления о новых комментариях I'm not a robot reCAPTCHA Privacy - Terms Desktop Version Desktop Version Top Top Вы здесь: Вы здесь: Начало Начало Статьи о разном Статьи о разном Нестабильность проектов ПЛИС Нестабильность проектов ПЛИС |
делать pipeline.
Рассмотрим еще более тяжелый случай.
Рассмотрим неудачный дизайн, с несколькими тактовыми частотами, где данные пересекают клоковый домен без должной синхронизации.
Посмотрите. Здесь данные фиксируются в четырехбитном регистре с частотой CLK1, а затем данные передаются другой группе регистров работающих на частоте CLK2.
В общем случае, когда CLK1 и CLK2 – это несвязанные частоты, время между фронтами двух частот может быть каким угодно (t1, t2, t3, t4 ...) — может быть достаточным для распространения сигналов от первой группы регистров, а может быть и весьма малым,
таким, что сигналы просто не успевают распространяться одновременно от первых регистров ко вторым. В этом случае появляется некоторая вероятностная составляющая.
Пока проект маленький, регистры расположены близко друг к другу и с большой вероятностью данные из одного клокового домена будут успешно (почти всегда) переданы во второй клоковый домен. Когда же проект растет, компилятор уже не может расположить регистры достаточно близко друг к другу.