Может ли дизайн FPGA быть в основном (или полностью) асинхронным?

У нас был очень короткий курс FPGA/Verilog в университете (5 лет назад), и мы всегда везде использовали часы.

Теперь я снова начинаю работать с ПЛИС в качестве хобби, и я не могу не задаться вопросом об этих часах. Являются ли они абсолютно необходимыми, или конструкция на основе ПЛИС может быть полностью асинхронной? Можно ли построить сложную связку логики и заставить ее работать так быстро, как только возможно?

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

На мой взгляд новичка кажется, что единственной конструкцией, которая абсолютно требует часов, является reg, и я понимаю, что типичная FPGA (скажем, Cyclone II) будет иметь свои триггеры, предварительно подключенные к определенным тактовым сигналам. Это правильно? Существуют ли какие-либо другие неявные часы, подобные этому, и могут ли они обычно управляться вручную в соответствии с дизайном?

Я знаю, что Саймон Мур из Кембриджского университета провел много исследований в области асинхронного проектирования, в том числе изготовил тестовый чип. Он требует совершенно нового набора инструментов проектирования и имеет странные побочные эффекты: например, скорость выполнения обратно пропорциональна температуре.

Ответы (9)

Короткий ответ: да; более длинный ответ был бы: это не стоит вашего времени.

Сама FPGA может без проблем запускать полностью асинхронную конструкцию. Результат, который вы получаете, является проблемой, поскольку синхронизация через любую FPGA не очень предсказуема. Более серьезная проблема заключается в том, что ваше время и итоговый дизайн почти наверняка будут различаться в зависимости от места и маршрута. Вы можете наложить ограничения на отдельные асинхронные пути, чтобы они не занимали слишком много времени, но я не совсем уверен, что вы можете указать минимальную задержку.

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

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

Надеюсь, это немного прояснит ситуацию.

Мне пришлось использовать некоторые устройства с асинхронными конструкциями FPGA. С ними было тяжело работать. Пожалуйста, по крайней мере, используйте временные ограничения
Хотя действительно возможно реализовать асинхронные проекты с помощью FPGA, большинство FPGA созданы для поддержки именно синхронных проектов. У них есть много ресурсов (PLL, схемы распределения тактовых импульсов и огромное количество триггеров), которые будут потрачены впустую в асинхронной схеме.
Этот ответ не дает особенно хороших советов. Вы можете создать FPGA без тактов, и это на самом деле упрощает размещение и маршрутизацию, устраняет массу проблем, связанных с требованиями к времени, и благодаря мелкозернистой конвейерной обработке может иметь значительно более высокую пропускную способность. Настоящая проблема возникает, когда вы пытаетесь сопоставить схему с тактовой частотой с ПЛИС без тактовой частоты, потому что они имеют очень разные временные характеристики. Это можно сделать, просто для преобразования требуется немного больше предварительной обработки. vlsi.cornell.edu/~rajit/ps/rc_overview.pdf
Вы МОЖЕТЕ сделать дизайн, нечувствительный к задержке. Я разработал небольшую схему, которая хранит бит в триггере и формирует сигнал, когда обнаруживает, что бит был сохранен. Он также определяет, действительно ли бит был получен (в отличие от появления нуля из-за задержки отправки 1), и невосприимчив к сбоям. Схемы должны обмениваться данными через рукопожатие и использовать такие компоненты для взаимодействия; сами схемы просто ждут завершения своего вывода, а затем выполняют все коммуникации. Нет часов.

«Можно ли построить сложную связку логики и заставить ее работать так быстро, как только возможно?» Да. Были построены целые ЦП, полностью асинхронные — по крайней мере, один из них был самым быстрым ЦП в мире. http://en.wikipedia.org/wiki/Асинхронная_схема#Асинхронный_ЦП

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

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

К счастью, некоторые из преимуществ асинхронного проектирования можно получить, используя в основном методы синхронного проектирования, используя глобальный асинхронный локальный синхронный (GALS) проект.

Точно так же я отношусь к современной тенденции разводки печатных плат по квадратной сетке , хотя преимущества миграции гораздо менее значительны.
@romkyns - Это больше связано с тем, что писать программное обеспечение для печатных плат, использующее непрямолинейные сетки, сложно .
Я только что наткнулся на этот ваш ответ на более ранний вопрос. GALS, по-видимому, является термином для конструкций, которые берут несколько синхронных блоков и соединяют их между собой, даже если они асинхронны друг с другом. Существует ли термин для устройств, которые тактируются разными тактовыми генераторами, которые имеют известное временное соотношение (например, нарастающий фронт тактового сигнала X (X+) будет не позднее нарастающего фронта Y (Y+) и произойдет значительно раньше спадающего фронта Y? (Y-); X+ может использоваться для синхронизации данных, полученных из данных, синхронизированных Y+, но не наоборот; Y- синхронизирует данные, полученные из X+).
@supercat: я подозреваю, что вы имеете в виду четырехфазную логику . Это один из многофазных тактовых сигналов , о котором, похоже, забыли.
Я не думал о динамической логике. Я просто думал о том, как обеспечить правильную причинно-следственную связь с тактовыми сигналами, которые могут быть слегка искажены. Если нарастающий фронт тактового сигнала № 2 получается путем объединения тактового сигнала № 1 с какой-либо другой логикой, так что он возникает после нарастающего фронта тактового сигнала № 1, используя нарастающий фронт тактового сигнала № 1 для фиксации сигнала, который изменяется на нарастающий фронт тактового сигнала № 2 вызовет состояние гонки. Вместо этого использование заднего фронта часов № 2 должно быть безопасным.
@supercat: Верно. Возможно, вы думаете о системах с двухфазными часами или о какой-либо другой многофазной системе часов. Дайте мне знать, если вы найдете лучший термин для этих систем.
@davidcary: Вроде того, за исключением обеих «фаз» на одном проводе - одна фаза контролируется нарастающим фронтом, а другая - падающим фронтом. По сути, я бы разделил защелкивающиеся часы на четыре категории: чистый подъем, чистый спад, поздний подъем, поздний спад. Защелки, тактируемые (L/CB) чистым нарастающим или спадающим фронтом, могут получать данные с любого нарастающего или спадающего фронта. L/CB поздний передний фронт может брать данные из L/CB чистый передний фронт любого заднего фронта. L/CB по позднему спаду может брать данные с L/CB на чистое падение или любой рост.
@davidcary: при условии, что самое быстрое время распространения для любой защелки превышает самое длительное время удержания, и при условии, что самый длинный путь сигнала от фронта тактового сигнала через логику стробирования тактового сигнала и «поздние» защелки, запускаемые этим фронтом, к любой защелке, запускаемой следующий фронт, не превышает минимального времени между фронтами тактового сигнала, я думаю, что такая конструкция должна быть полностью надежной и свободной от внутренне генерируемой метастабильности при любой комбинации задержек распространения.
@supercat - интересно, я недавно разработал процессор, который использует такой подход: у меня есть один тактовый вход, который выполняет несколько фаз, чтобы (1) разрешить несколько обновлений регистров за цикл при использовании конструкции файла регистров, который имеет только один вход порту и (2) иметь двухэтапный конвейер, полный от чтения инструкции до обратной записи регистра за 1,5 цикла, так что опасности конвейера сохраняются только в течение одной длины инструкции. Здесь есть обзор , а более подробная статья здесь, в этой ветке форума .
Я работаю над макетом печатной платы для него, когда нахожу время (пока это только моделируется), но я использую инвертор с емкостью, добавленной к его выходу, чтобы обеспечить небольшую задержку на часах записи регистрового файла, чтобы чтобы дать время для завершения всего остального до того, как результат будет фактически записан. В симуляции все выглядит хорошо... посмотрим, что произойдет, когда у меня будет настоящая плата. :)
@Jules: Спасибо. Этот дизайн процессора выглядит завораживающе.

Еще не упомянутый фактор - метастабильность. Если в схему фиксации попадает последовательность входов/переходов, так что результирующее состояние будет зависеть от задержек распространения или других непредсказуемых факторов, нет гарантии, что результирующее состояние будет чистым «высоким» или «низким». Рассмотрим, например, триггер, запускаемый фронтом, который в настоящее время выдает «низкий уровень», а его входной сигнал меняется с низкого на высокий почти одновременно с приходом фронта тактового сигнала. Если фронт тактового сигнала происходит достаточно долго до изменения входа, выход просто будет оставаться на низком уровне до следующего фронта тактового сигнала. Если фронт тактового сигнала происходит достаточно долго после изменения входа, выход быстро переключится один раз с низкого на высокий и останется там до следующего фронта тактового сигнала. Если ни одно из этих условий не применимо,. Он может оставаться низким или быстро переключаться один раз и оставаться высоким, но он может оставаться низким некоторое время, а затем переключаться, или переключаться, а затем некоторое время спустя переключаться обратно, или переключаться туда и обратно несколько раз и т. д.

Если конструкция полностью синхронна и все входы синхронизированы дважды, очень маловероятно, что синхронизирующий импульс ударит по первой защелке синхронизатора таким образом, что заставит ее переключиться в нужное время, чтобы сбить с толку вторую защелку. защелка. В общем, можно с уверенностью относиться к таким вещам как к «просто не будет». Однако в асинхронном дизайне часто гораздо сложнее рассуждать о таких вещах. Если ограничение по времени для схемы фиксации (не только триггеров, но и любой комбинации логики, которая будет действовать как защелка) нарушается, невозможно сказать, что будет делать выход, пока в следующий раз не появится допустимое входное условие, которое вызывает защелку. до известного состояния. Вполне возможно, что задержанные выходные данные приведут к нарушению временных ограничений нисходящих входных данных, что приведет к непредвиденным ситуациям.

Самый безопасный способ смоделировать асинхронную схему состоит в том, чтобы почти каждая выходная схема на некоторое время выдавала выход «X» всякий раз, когда она переключается между «0» и «1». К сожалению, этот подход часто приводит к тому, что почти все узлы показывают «X», даже в случаях, которые в действительности почти наверняка привели бы к стабильному поведению. Если система может работать при моделировании, когда все выходы становятся «X» сразу после изменения входа и остаются «X» до тех пор, пока входы не стабилизируются, это хороший признак того, что схема будет работать, но заставить асинхронные схемы работать при таких ограничениях. часто трудно.

На самом деле существует ТРИ типа конструкций.

  1. Комбинаторный. Нет ни часов, ни обратных связей, и у системы нет «памяти». Когда один или несколько входных данных изменяются, изменения распространяются по логике. Через некоторое время выход переходит в новое состояние, в котором он остается до тех пор, пока снова не изменятся входы.
  2. Синхронный последовательный. Система строится из регистров и блоков комбинаторной логики, регистры тактируются небольшим количеством (часто 1) тактов. Если имеется несколько часов, то могут потребоваться специальные меры предосторожности для сигналов, которые проходят из одного домена часов в другой.
  3. Асинхронный последовательный. Существуют пути обратной связи, защелки, регистры или другие элементы, которые обеспечивают память проекта о прошлых событиях и которые не синхронизируются легко анализируемыми линиями синхронизации.

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

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

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

В асинхронной последовательной системе эти предположения не учитываются. Глюки могут иметь значение, порядок изменений вывода может иметь значение. И инструменты, и сами ПЛИС были разработаны для синхронных проектов. Было много дискуссий (погуглите дизайн асинхронных FPGA, если хотите узнать больше) о возможности реализации асинхронных систем либо на стандартных FPGA, либо на специально разработанных, но это все еще выходит за рамки общепринятой практики проектирования.

Конечно, если ваши требования к дизайну достаточно медленные, и многие внутренние задержки по-прежнему на несколько порядков больше, чем время, которое вас волнует, то это не проблема, и вы можете посмотреть отчет о времени, чтобы следить за этим, но есть предел тому, что вы можете с пользой делать без информации о внутреннем состоянии. Если вы просто хотите сделать что-то вроде мультиплексора на 100 входов, тогда все в порядке, просто помните, что каждый вход будет иметь разную задержку распространения. На самом деле вы можете получить некоторые интересные и хаотичные эффекты с большим количеством колеблющихся петель обратной связи с непредсказуемой задержкой - возможно, полностью асинхронный синтезатор на основе FPGA может стать следующим «аналогом».

Да, ты можешь. Вы можете полностью игнорировать триггеры и построить все это из LUT. И/или вы можете использовать элементы состояния большинства Xilinx FPGA в качестве (управляемых уровнем) защелок вместо (управляемых фронтом) триггеров.

Опасность заключается в том, что если не ограничить компилятор логики, он может создать логику с отрицательным временем распространения для некоторых вентилей. Например, если указать X=(someComplexFormula)и Y=X & D, и если компилятор подставит эту формулу вместо X и определит, что X & Dона эквивалентна A & D, компилятор может заменить вычисление Y в терминах A и D, а не в терминах X, что позволит вычислить Y выполняться быстрее, чем в X. Такие замены допустимы для комбинаторной логики, но наносят ущерб асинхронной последовательной логике.
@supercat - я никогда не работал с инструментами Xilinx, но когда я работал с FPGA Altera, у вас всегда была возможность указать любые критические пути как подключенные модули вентилей, а не в RTL, после чего любые такие оптимизации Отключено.
@Jules: Во всех моих проектах с программируемой логикой использовался Abel, который является несколько глупым языком, но позволяет указывать вещи способами, которые могут реализовать некоторые CPLD, но которые могут создать трудности для инструмента синтеза VHDL или Verilog. Например, в одном из моих проектов я использовал тот факт, что части Xilinx имеют часы, асинхронную установку и асинхронный сброс, для реализации асинхронно загружаемого сдвигового регистра. Если мне нужно делать такие вещи в FPGA, никогда не используя Verilog или VHDL, как я должен узнать, что нужно для этого? Кстати, если мне не изменяет память, я использовал Т-флопс для переключателя, и...
... время было таким, что асинхронная запись могла происходить только в те моменты, когда вход T был бы низким, предполагая, что если тактовый сигнал отсутствует около начала импульса записи, асинхронная запись будет простираться достаточно далеко за его пределы, поскольку для обеспечения стабильного значения, а если бы нерабочие часы произошли ближе к концу, это просто зафиксировало бы все еще стабильное значение. Я не уверен, как можно эффективно обрабатывать такие случаи в VHDL или Verilog.
@supercat - рассматривая аналогичную проблему, глядя на Справочник по устройствам Cyclone IV, я вижу, что лучшим подходом к той же проблеме было бы использование опции «синхронная нагрузка для всей лаборатории» («ЛАБ» — это группа из 16 логических элементов). , поэтому, если размер такого регистра не кратен 16 битам, то некоторые биты будут потрачены впустую, но в любом случае это кажется наиболее полезным вариантом). Теперь у меня есть два варианта: я могу написать функциональный verilog, который потребует, чтобы инструмент синтеза выбрал способ реализации требуемого регистра (что обычно было бы лучшим вариантом), или, если у меня есть строгие сроки...
... требования Я могу заставить его жестко подключить это: просмотр списка доступных низкоуровневых модулей на устройстве, которое я нахожу lpm_ff, может реализовать триггер d- или t-типа с синхронной нагрузкой. Используя этот модуль, я могу быть уверен, что эти функции будут точно сопоставлены с низкоуровневыми функциями устройства без возможности их оптимизации.

Как отметил @Andrey, это не стоит вашего времени. В частности, инструменты этого не делают, поэтому вы будете полностью предоставлены сами себе. Кроме того, поскольку у них есть встроенные регистры, вы ничего не сэкономите, не используя их.

Да. Если у вас нет конструкций типа процесса, он не должен делать такие вещи, как вывод регистров. Будут такие вещи, как встроенная память, для которых требуются часы, хотя, если вы действительно хотите, вы, вероятно, могли бы генерировать их асинхронно.

Вы хотели сделать это одним ответом?

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

Эти глобальные часы/PLL/буферы сжигают много джоулей.

По мере того, как решения FPGA переходят на арены с батарейным питанием (например, Lattice Icestick), этому аспекту будет уделяться гораздо больше внимания.

Это хороший момент, хотя стоит учитывать, что плохо спроектированная комбинаторная схема, выполняющая ту же операцию, что и последовательная схема, может в некоторых случаях делать много переходных процессов, поскольку частичные результаты вычисляются, а окончательный вывод обновляется с их учетом. а в схемах CMOS (как и в большинстве FPGA) энергопотребление примерно пропорционально количеству переходов. Тактовые импульсы могут вызвать ненужные переходы, но вы также можете значительно снизить мощность, отключив тактовые импульсы в тех частях схемы, которые в данный момент не нужны.
Может ли дизайн FPGA быть в основном (или полностью) асинхронным?
СпросиСетьПолитика конфиденциальности1y, 0v