Доброго времени суток,

Собственно - $subj. Изучаю вопрос проектирования чипа с использованием асинхронных пайплайнов. I.E. Sutherland, ‘‘Micropipelines’’ неплохо описывает концепцию и дает понимание о том, как работают вычислители при таком подходе, однако как делать управляющие стейт-машины в этой работе не рассматривается. Подход, предложенный в ASYNCHRONOUS FINITE STATE MACHINE DESIGN: A LOST ART? Christopher Carroll, University of Minnesota-Duluth мне не понравился. Другие книги, которые я просмотрел по теме, учат вариациям на тему той-же методологии, однако кардинально ничего не улучшают. В результате асинхронные стейт-машины представляют собой диких паучков из нандов и норов с обратными связями, крайне тяжело модифицируются, плохо верифицируются, короче - обладают целым рядом недостатков, делающих их реальное применение неоправданно дорогим и сложным.

Есть ли у кого мысли как упростить этот процесс и сделать его более простым и контролируемым?

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

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

Нашел еще одну книгу по дизайну асинхронных систем: PRINCIPLES OF ASYNCHRONOUS CIRCUIT DESIGN – A Systems Perspective. Написана STEVE FURBER в 2001 году. Очень интересный труд, всем советую.

Уточните, если не трудно, это на нескольких примерах.

Если книга уже найдена, то прикрепите ее в приложении, она будет интересна многим.

Есть книга Asynchronous Circuit Design.Chris J. Myers Copyright 2001 by John Wiley & Sons, Inc и И.Б.Бурдонов, А.С.Косачев, В.В.Кулямин.
АСИНХРОННЫЕ АВТОМАТЫ: КЛАССИФИКАЦИЯ И ТЕСТИРОВАНИЕ. Труды Института системного программирования РАН. No. 4. 2003. стр. 7-84.

если нужны выложу

Выкладывайте все с небольшой аннотацией или своим мнением.
Интересует, в частности, адаптация этих методов к ПЛИС.

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

Если используется completion detector, то асинхронная схема оказывается значительно быстрее синхронного аналога. Спайс говорит, что мой пайплайн из 4 последовательных MAC юнитов работает на частоте порядка 3.5GHz на 55nm. Если же подходить к вопросу с синхронными мерками, то пришлось бы посчитать частоту по worst case delay, что ограничило бы рабочую частоту на уровне 2.7GHz.

Если использовать dual-rail data encoding, то в системе полностью отсутствует паразитный свитчинг. В качестве эксперимента я оценивал потребляемую мощность 32 рязрядного сумматора с префиксным деревом деревом Когга-Стоуна в dual-rail и single-rail реализации. Так вот потребляемая мощность dual-rail реализации была в 2 раза ниже, чем потребляемая мощность single-rail реализации. Правда, в начале она занимала в 2 раза больше места, но эту проблему удалось "полечить" переходом на домино реализацию

Асинхронные пайплайны очень удачно сочетаются с домино реализациями. В моем случае я управляю precharge и evaluate транзисторами раздельно, таким образом получилось выкинуть "лишние" латчи и бополнительно сэкономить порядка 15% места.

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



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

Документы не читал, поэтому аннотаций дать не могу. Вторую книгу выложу позже, там 41 МБ

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

А что если остаться в рамках методологии синтеза синхронных FSM, но сделать асинхронным его тактирование. То есть для длинных по времени микрокоманд удлинять время такта, а для коротких уменьшать. При этом менять длительность такта дискретно, или как-то иначе, в зависимости от типа текущей микрокоманды.

Залил кое-что по асинхронщине
/upload/BOOKS/Asynchronous_Circuit

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

По асинхронным схемам (и особенно по преобразованию синхронных в асинхронные) есть серия патентов фирмы Achronix. Это контора, которая сейчас и Интелом сотрудничает. Когда выходила первая серия их ПЛИС, так там характеристики по быстродействию, температурному диапазону и напряжению были такие сумасшедшие, что косвенно это указывало на асинхронную реализацию ядра, что и коррелировало с патентами. Так что можно их еще почитать.
Лично я не вникал, но отметил для себя, что тема перспективная. Одна из ключевых нерешенных проблем в этой области - это определение окончания расчета какого-то блока. Как правило делается эталонная цепь, переключение которой гарантированно произойдет позже чем худший случай для конвейера. Для ПЛИС такие решения проще чем для произвольной логики.

Отвечу сразу на вопрос. Есть два хороших проверенных тула, с ними работают, их используют. Первый и основной, это Petrify. Позволяет синтезировать асинхронный автомат из графа. Ограничение на число вершин - в районе 50. Что особенно ценно, Petrify позволяет сразу делать мэппинг в базисе standard cells. Второй тул, Workcraft - графический интерфейс для рисования и что важно - моделирования сетей Петри. Хорош еще тем, что автоматически генерит входной файл для Petrify.

Далее, что касается Сазерленда и микропайплайнов. Сазерленд предложил десинхронизацию, т.е. переделку синхронных схем путем убирания клока и заменой его на хендшейки. Это почти не имеет отношения к сетям сетям Петри и построению асинхронных автоматов из графов. Строго говоря, пайплайны по типа Сазерлендовских сейчас называют BD - Bundled delay. Построение полностью асинхронных автоматов (не переделка синхронных схем) - это отдельная методика, имеющая в своей основе теорию графов, теорию автоматов и сети Петри, а в качестве объединяющей надстройки эксплуатирует идеи Варшавского. Есть еще отдельное направление, развившееся в америке -NCL. Схемы Варшавского обычно называют SI - speed independend, а NCL - DI - delay insensitive. Впрочем, у Варшавского тоже были DI схемы, ими потом стал заниматься Стародубцев - можете погуглить. Так что, все асинхронные схемы условно можно разделить на три направления: BD, SI и DI. Схемы Dual rail и Burst Mode - это подклассы SI. Сравнивать эти схемы смысла нет, они все имеют свои плюсы и минусы. И каждая имеет свою область применения, где другие будут работать хуже.

Специалистов в РФ по этой тематике - считайте что и не осталось, хотя львиная доля теории разработана в СССР в 70-80х, под руководством В.И. Варшавского.

Вопрос - а с какой целью интересуетесь? Праздный интерес, или серьезные разработки?


По поводу верификации. Если речь идет только об FSM, с числом вершин в графе не более 50, то проверку делает Petrify и еще ряд менее известных тулов. Это самая точная верификация, она покажет что схема полумодулярна.
Если же речь идет о большой схеме с сотнями тысяч и даже миллионами элементов, то верификацию не сделать. Единственное, можно использовать обычные средства моделирования, при условии что схема - нетлист, и подключаются реальные задержки (SDF). Так можно защититься от совсем уж глупых ошибок.
В ПЛИС асинхронные автоматы вообще не получится проверить. Я в начале лета поднимал тему - не нашлось ни одной ПЛИС/ПАЛ, где можно было бы хорошо уложить все эти тысячи мелких обратных связей. Но, можете поискать еще. Если найдете что то подходящее, напишите обязательно.

книжки переехали сюда?
/pub/BOOKS/IC_Design/_Asynchronous_Circuit_/

а про ПЛИС для экспериментов - лучше актеловских проазиков, имхо, сейчас нет - у них локальный интерконнект развит. но тул отсутствует - нужно что-то писать самостоятельно, какие-то скрипты поверх libero designer-а не сильно помогают

книжки переехали сюда?
/pub/BOOKS/IC_Design/_Asynchronous_Circuit_/

а про ПЛИС для экспериментов - лучше актеловских проазиков, имхо, сейчас нет - у них локальный интерконнект развит. но тул отсутствует - нужно что-то писать самостоятельно, какие-то скрипты поверх libero designer-а не сильно помогают - что ставит на затее крест



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

если у Вас в конвеере есть задержка на 2.7GHz, то и весь конвеер будет работать 2.7GHz, те части которые 3.5 будут ждать completion (как я понимаю это можно назвать хэндшейк) от той, которая 2.7
то есть выигрыша тут не получится, по сравнению с синхронной схемой
понятно, что не worst case для самосинхронной схемы поднимет автоматом (by design) производительность при низкой температуре и хорошем питании (best case) - но и для синхронной в не worst case можно тактовую разогнать

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

---------------------------

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

Совершенно не правильный вывод. Сумматор сам по себе имеет очень разную задержку в зависимости от чисел, которые отправляются ему на вход. Даже сумматоры с префиксными деревьями подвержены этому недостатку, хотя для них разница между самым быстрым временем вычисления и самым медленным существенно меньше. Несложно посчитать, что при суммировании двух случайных чисел 98% случаев содержат переносы с максимальной длинной 6 бит. Синхронная схема обязана быть рассчитана на распространение сигнала переноса через все 32 бита в случае 32-разрядного сумматора, тогда как асинхронная схема с комплишен детектором закончит вычисление тогда, когда будут вычислены все биты результата и не будет ожидать следующего фронта клока для начала следующего вычисления. Вот здесь и получается ускорение работы схемы в среднем до 3.5GHz против 2.7GHz в синхронном случае. Другой вопрос, что за подобное ускорение пришлось заплатить несколько большей площадью, но в моем случае это был приемлемый обмен. Сделать более быструю синхронную схему тоже возможно, но в этом случае пришлось бы часто-часто порезать сумматор регистрами, а это может быть не всегда удобно. Да и потребление такой синхронной схемы было бы сильно выше.

Заблуждаетесь. Если речь идет о dual rail схемах (а вариантов может быть много - читайте мой прошлый пост в этой теме), то имеет место 1) увеличение площади в 4-6 раз, и 2) замедление работы от десятков процентов, до нескольких раз - в зависимости от того, как сделана индикация. Объясню подробнее.
1) По площади. На каждый элемент логики требуется вставить парный + двувходовой тестер. Это в среднем троекратное увеличение площади. Далее, как вы хотите строить схему индикации (СD)? Если на С-элементах, то более-менее реально использовать 3-х входовые и иметь увеличение площади 3.5-4х, а если делать сжатие на стандартных элементах (на библиотеках 65нм и ниже обычно число входов не более 3-х), то площадь увеличивается уже в 5-6 раз. Очень много зависит от разрядности шин и слоев логики внутри схемы.
2) По скорости. Здесь определяющей является как раз размерность логики в слоях. Единственное, где dual rail имеет преимущество перед синхронной схемой, это преобразование инверторов, которое заменяется на перекрестье проводов. Да и то это преимущества является мнимым, поскольку инверторы в синхронных схемах, в большинстве своем, не являются элементом логики, а служат больше для выравнивания transition в нагруженных цепях. Т.е. по большому счету, инверторы лучше оставлять, чем заменять на перекрестья. Все остальное - сплошное замедление схемы по сравнению с синхронной. Посудите сами - входы индикации, это выходы логики. Т.е. dual rail априори медленнее синхронной схемы. А с ростом разрядности логики в слоях это замедление становится сопоставимо с периодом в синхронной схеме. И напоследок самый важный аргумент. Dual rail использует 2-х фазную передачу данных (4-х фазная в западной терминологии). Отсюда следует, что dual rail работает минимум в два раза медленнее синхронной схемы, поскольку фазу данных сменяет фаза спейсера.
Как я уже писал в предыдущем посте, у каждого вида асинхронных схем есть свое применение. Dual rail с полной индикацией не годится для high perfomance. Можно делать квази схемы и они с некоторой натяжкой могут потягаться с синхронными. Но в целом во всем мире для производительности используют bundled delay схемы (пайплайны сазерленда).

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

Я как-бы стандартных библиотек в высокопроизводительной части схемы не использую. Вся вычислительная система построена на dual-rail domino, потому четырех-фазный протокол туда встроен по умолчанию. Схемы индикации CD сделаны на основании внутренних сигналов сумматора и не вносят дополнительной задержки в вычисления. Теперь совсем немного о площади. CMOS 32 bit префиксный сумматор на тактовую частоту больше 3GHz у меня сделать не получилось. Может опыта было мало, может руки кривые, но максимум, чего удалось достичь - это 2.5GHz с деревом Когга-Стоуна. При этом внутри сумматора во время спайс-моделирования были видны множественные паразитные переключения. Попытки регулирования мощности отдельных узлов к успеху не привели, поскольку в зависимости от входных данных значения напряжений в разных точках дерева требовались в разное время. Таким образом паразитный свитчинг увеличивал потребление сумматора в 1.5-2 раза по сравнению с расчетным потреблением. Такое вот г... получалось. Теперь картина для префиксного сумматора с деревом моего изобретения, выполненного на dual-rail domino. Паразитный свитчинг внутри отсутствует как факт. Потребление четко совпадает с расчетным. Время пречарджа составляет ~30ps, задержка для самых медленных данных - 150ps, самых быстрых <100ps, средняя задержка - 120-130ps. Итого, имеем более чем в 2 раза быстрый сумматор, занимающий в 1.5 раза больше площади, чем single-rail CMOS. Лейаут не выложу, уж извините При необходимости, можно было бы разогнать сумматор и до 10GHz, но дальше я уже не вписывался в тепловой пакет. На основании вот этого опыта могу сказать, что задача проектирования супер-быстрых схем иначе как на dual-rail domino не решается. Может быть их можно построить, но потом на них не реально подать питание. Еще можно обсудить требуемую площадь москапов для single-rail и dual-rail с учетом двойного потребления мощности single-rail схем из-за паразитного свитчинга.


В соей системе я использовал совсем даже не пайплайн Сазерденда. В случае классического пайплайна Сазерденда мне не понравилось количество регистров, которые пришлось вставить по ходу. По факту у меня мой собственный пайплайн с немного хитрым управлением, выполненным на асинхронных one-hot burst-mode стейт машинах. На пост-лейаут симуляции увидел, что немного ошибся с задержками в стейт-машинах, а потому пречарджи немного "торчат", уменьшая эффективную скорость вычисления. Переделывать уже не хочется, поскольку в требуемую производительность вписались, а переделывать в кастоме все надо руками.

По моей оценке, процессор на dual-rail domino уровня Intel Core i7 в кастоме занимал бы немного больше, или столько же площади в кремнии, но при этом мог бы потреблять сильно меньше мощности. Единственное почему асинхронные системы не получили очень широкого распространения - это неготовность production тулзов. Кастом - это очень хорошо, но действительно большой проект силами небольшой группы людей не выпилить.

Еще плохо, что специалистов в асинхронном дизайне практически нет. К вам, господин Shivers, последнее утверждение не относится Все, с кем я говорил, имеют за плечами теоретические знания, но практического опыта работы нет. У людей стойкие стереотипы, что асинхронная схема сложнее, хуже верифицируется и медленнее синхронного аналога. Исходя из моего опыта, правильным является только первое утверждение.

Домино - любопытно. Я правильно понимаю, что у вас логику делает матрица на nmos, один pmos используется как precharge, а на выходе схемы стоит элемент CD? Такие схемы я видел в статьях Таубина.

К сожалению, насколько мне известно, эти схемы так и не пошли, уж не знаю почему. У меня в фирме домино логику пытались использовать (в синхронных проектах), но решили что она слишком медленна, и предали анафеме. Чтобы кто то использовал домино в обычной цифре ниже 180нм я тоже не слышал. А для dual rail на мой взгляд, домино вообще логика не безопасна ; вы ведь понимаете, что при сбое асинхронная схема защелкивается, и тогда все элементы домино могут стать в КЗ. Что до меня, то я работаю только со стандартными элементами. Из кастома необходимый минимум - элементы С2, С3 и RS-защелки.
Еще я сомневаюсь, что домино-элементы с n-матрицей полностью индицируются по выходу. Надо подумать.

До лейаута я асинхронные схемы не доводил ни разу, пока отлаживаю синтез в DC, и хочу добиться того чтобы начал работать STA. Пока же я сужу по скорости получаемых схем моделированием нетлиста с sdf в incisive. Но если заработает STA, то станет доступен и автоматический P&R в энкаунтере. С кастомом я связываться вообще не хочу, поскольку не владею тулами (я вообще очень мало работал с ВЕ). В общем, я пытаюсь запустить стандартный маршрут для синхронных схем.

Теперь я по крайней мере понял, почему у Вас получается малая площадь и высокая скорость.

Укажите, пожалуйста, еще тех. процесс, по которому работаете. 120-130пс для 32-х битного сумматора это очень быстро.

p.s.

Я все же останусь при своем мнении: видов асинхронных схем много. То, о чем пишите Вы, я бы назвал fine grain SI, с использованием домино. Этим занимался Таубин, последняя его работа вышла почти 10 лет назад. Но есть и другие виды асинхронных схем. Самыми быстрыми, на мой взгляд, являются BD схемы, которые абсолютно точно быстрее синхронных (просто потому что из синхронных и делаются). Повторюсь, но у каждого вида асинхронных схем есть свои плюсы и минусы. К сожалению именно о fine grain домино я ничего не знаю, поскольку в расчет их никогда не брал.
В общем, по стереотипам, готов с Вами поспорить. Схемы на стандартных элементах действительно и медленные, и большие по площади, но они чрезвычайно живучи: могут работать на около пороговых напряжениях, и в совершенно экстремальных температурах. Но high perfomance это точно не про них. В то же время BD быстры, но работают только в пределах тех углов, на которые охарактеризованы. При выходе параметра за предел, BD схема собьется. Полагаю, у домино тоже есть свои пределы работы. Итого, нельзя делать однозначных утверждений по всему классу асинхронных схем.

Есть ещё одна альтернатива - CML.
На высоких частотах (единицы ГГц и выше) фиксированный микроток потребления дифф. каскада суммарно оказывается на порядок и более выгоден по сравнению и с синхронными, и с асинхронными решениями, работающими в полный размах.
К сожалению, реальных заказчиков на что-то значительное на основе CML сейчас в РФ нет.
Поэтому полноценно попробовать в реале пока не получилось, только небольшие узлы по 180 нм.

Рассматриваемый вопрос мне представляется, вообще, несколько далёким от реала.
Ибо использовать синтез асинхронных СБИС, основываясь на каком-то автоматическом инструменте, - пагубно. Примерно также, как пытаться синтезировать, например, RAM на SCL. Можно, конечно. Но не стоит. В жизни же всё сочиняется по блочному принципу. Внутри каждого блока вылизывается в полуручном режиме. Если этим заниматься серьёзно, конечно. А не только примочками типа прерывания распространения сигнала двухвходовками.
И да, без Спайса тут нельзя, если хочется приблизиться к идеалу.

Хотя, может, я и не совсем прав с точки зрения научных изысканий и протаптывания тропинки в светлое будущее.

Альтернатива в чем? в high perfomance? Или речь о выборе базиса для dual rail асинхронных схем?


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

На самом деле, что касается синтеза dual rail SI, то ни один синхронный САПР не годится, имхо. Я использую dc_shell просто как среду программирования, в которой из синхронной схемы получаю dual rail с индикацией. Далее DC можно использовать только для исправления DR/transition (если он оказался нарушен), и (если заработает STA) для подкручивания мощностей SC с целью ускорить схему. Что касается P&R то думаю никто спорить не будет в очевидности преимуществ автоматизации перед ручным проектированием - при автоматизации скорость проектирования увеличивается на порядки. При этом никто не мешает делать отдельные макроблоки вручную.

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


Не скажу ничего нового, но спайс годится для небольших блоков. Вы же не будете моделировать процессор на спайсе? Поэтому, обычное моделирование тоже необходимо. по возможности. С использованием SC такая возможность есть. Кстати, характеризация нестандартных элементов - отдельная проблема. Мне кое как удалось охарактеризовать С-элементы, но не представляю как это сделать с элементами на базе домино. Т.е. как то охарактеризовать всегда можно, вопрос в том - будет ли работать потом STA в primetime? Т.е. надо получить все необходимые timing arc, и при этом не допустить ни одного loop. Но пока работоспособсность всего этого под вопросом, разумеется что и моделирование на спайсе -уже очень неплохо.

Может, и я не прав. Все написанное - imho

спасибо, понял.

но обычно, с точки зрения _всей_ системы нужно расчитывать на худший случай (тоесть 32'b0-1 и т.п), а не на среднюю длину переноса.

я не спорю, что самосинхронные схемы интересно и все-такое, но для какой-то проф. деятельности [пока] не подходят.

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

Да, самый хай. При весьма умеренном потреблении, слабо растущем с частотой. Не ради ли этого жаждут асинхронности в конечном счёте?
"Хай" заключается ещё и в том, что для того же техпроцесса можно задрать частоту в 1.5-2 раза выше относительно КМОП.
Есть, конечно, и ограничения. Но, они больше "снизу". Так, например, теряется смысл использовать CML для коротких путей. И надо делать преобразователи CML-CMOS и обратно.

Пардон, что я тут встрял. Только лишь с целью расширения взглядов. Завязываю.
Самый писк был бы асинхронный CML, с отключением питания неиспользуемых ячеек.
Круче пока ничего не просматривается ни по скорости, ни по потреблению для ВЧ схем.
ПС. Кстати, такие ячейки не сложно формализовать. Почти как стандартные. И использовать синтезаторы, заточенные для синхронных схем.

Если работает статический временной анализ, то САПР сам рассчитывает все возможные комбинации входных сигналов, и выбирает worst-case. Учитывается даже наклон фронтов (передний/задний). Это еще один аргументв пользу того, что моделирования на спайсе недостаточно - наихудший случай может оказаться не очевидным, и в результате не проверенным.


Пока основные аппликейшны асинхронных схем - лоу пауер (150-200мВ питание), секьюрные чипы (ровное потребление), аэроспейс (работа на -200 .. +200С). High perfomance тоже есть в списке, но это только для BD схем, но судя по публикациям ничего особенно волшебного получить не удалось.

По CML .. сталкивался с ним, подключая лазеры волоконной оптики к ПЛИС, но не думал что и внутри логики можно такое использовать. А не будет так же как и в ЭСЛ - в два раза выше скорость, но и в десять раз выше - потребление?


Погуглил, и действительно - народ и в асинхронной логике CML использует. Есть даже схема С-элемента на CML. Любопытно конечно. Но я занимаюсь схемами исключительно на SC, мне кастом не доступен. Будь у меня команда .. а так - в одиночку копаю.

Это вы описываете footless domino. Хорошая штука, более быстрая, чем footed domino, однако имеет свои недостатки. В моем случае у меня микс из footed и footless domino co схемами CD по выходу. Все же 120-130ps просто так не получаются.


Поверьте, все получается, индицируется и работает очень надежно. В первом проекте мы тоже немного переживали с динамической логикой, однако после всестороннего моделирования в спайсе отдельных блоков и более крупных сборок таки отправили на производство. Как оказалось, нижняя частота работы динамической логики на bulk 55nm составляет немногим более 100MHz для ff корнера. В наших проектах 10ns - это почти вечность. Где-то год назад читал на этом форуме утверждение, что в мире есть не так много компаний, которые могли бы спроектировать чип с рабочей частотой порядка 1GHz. Сегодня я могу утверждать, что если не стоит задача втиснуться в определенный тепловой пакет, то быстродействие в гигагерц для процессов от 110nm и тоньше является тривиальной задачей. Если говорить о кастоме, то и пара гигагерц не является сверх-сложной задачей.

Если говорить о применении динамической логики и домино в частности в синхронных системах, то хорошим примером может быть один из Intel Pentium 4. Я в Сети встречал описание его архитектуры с точки зрения микроэлектроники. Так вот все его сумматоры и умножители выполнены с использованием footless domino. Как-бы синхронный процессор и домино, а потому не понимаю почему вы отказались от этого весьма много обещающего симбиоза у вас на фирме



Один мой гениальный знакомый сумел построить 32 разрядный рипл-керри сумматор на CML логике по bulk 55nm техпроцессу с задержкой "всего" 50ps. Когда мне нужен был очень быстродействующий сумматор я повторять не взялся - по его отзывам топология сумматора сильно зависит от его нагрузок. Еще очень сложно гарантировать работоспособность во всем диапазоне PVT вариаций. Исходя из этого от CML логики я отказался. Еще не мой класс задач.


Всю асинхру с burst-mode стейт машинами очень просто формализовать. Я даже думаю, что производители кадов делают с нами такую же шутку, как владельцы патентов на конный трамвай в 30-x годах прошлого столетия. Когда был изобретен электрический трамвай, они купили все патенты и положили их под сукно. Дальше они эксплуатировали свои конные трамвайные линии до тех пор, пока они не окупились и не заработали им денег на модернизацию. И только потом конные трамваи были заменены электрическими. Вот и производители софта ждут...

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

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

Предположим, вы сделали домино-элемент. Существует ограничение на число последовательно включенных транзисторов - на 65нм это число равно 3. Если включить больше, резко падает скорость работы. Поэтому и в SC нет однокаскадных элементов с числом входов больше 3х. Многокаскадные элементы нельзя индицировать по выходу, как известно. Итого, какую функцию можно сделать на домино, с числом входов не более 3х? Да в общем то и смысла нет связываться. Это означает, что нужно вводить большее число каскадов транзисторов, и тогда можно делать более сложные функции. При этом CD надо ставить в каждом транзисторном каскаде и выводить наружу. Если же CD ставить только в самом конце, схема становится не полностью индицированная, а значит потенциально может привести к состязаниям. Т.е. схема становится квази индицируемой.
Еще момент - все же, как вы делали схему сжатия индикаторов? Варианта известно всего два - на мажоритарных однокаскадных элементах, и на С-элементах. Какие параметры у Вашего С-элемента, сколько задержка переключения?
И последнее. Вы учитываете, что строя дерево для распределения нагрузки, нужно ставить CD на все его листья? Ведь каждый внутренний элемент логики - это фактически новая переменная в графе, и эту каждую переменную надо индицировать. В дереве каждая новая ветвь - новая переменная.

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

Ну, с тремя транзисторами в пулл-даун цепи я не согласен. В моем случае некоторое количество элементов имеет до 5 транзисторов. Другой вопрос, что все транзисторы для таких элементов имеют очень разную ширину канала. Скажу так, в некоторых элементах нижние транзисторы имели ширину канала в микрон и более. Еще такие элементы представляли собой целый комплекс компромисов с точки зрения площадь/задержка/потребление. Скажу так, что один из таких элементов потребовал около 30 часов рабочего времени от человека, который работал со мной - нарисовать, просимулировать, поменять, снова просимулировать и так до полного удовлетворения. При этом скажу, что без спайс-моделирования эта затея была бы обречена на провал - простые инженерные расчеты врали в полтора-два раза.

Теперь немного о индикации. Для dual-rail domino индикация промежуточных состояний вычислительной функции не требуется. Это не очевидно в начале. Мне на старте работы с этой технологией казалось, что разные по скорости пути должны конфликтовать и разряжать высокоомные точки в процессе вычислений. Однако спайс-моделирование рипл-керри сумматора полностью развеяло мои сомнения. Десяток включенных последовательно рипл-керри сумматоров давали верный ответ для любых входных данных при этом не порождали ни единого глитча ни на одном из проводов. Так вот, всю цепочку из десяти сумматоров можно было индицировать по 31 биту последнего сумматора. В моем случае индикация более сложная, поскольку сумматор у меня префиксный, но принцип тот же.

Еще можно вдвигать CD внутрь префиксного дерева, поскольку с момента "дифференциальности" некоторого набора промежуточных сигналов задержка до полного установления всех выходов в истинное состояние будет уже константой. Такая себе машина времени

Дело вот в чем. Индикация сигнализирует об окончании всех переходных процессов. В BD схемах это делается в лоб: рассчитывается максимально возможная задержка с учетом PVT разброса, и с ее выхода берется как бы сигнал завершения. В Вашем случае - Вы просто симулировали, убеждались что глитчей нет, и делали вывод о правильности выбранной точки для индикации. Неплохо, но не совсем правильно. Согласно теории, Вы должны построить граф, соответствующей Вашей логической схеме, и уже анализируя каждое ребро и каждую вершину графа, делать вывод - куда нужно ставить индикатор, а куда нет. Отсюда и вывод, что Вы сделали не полную индикацию. Возможно, я и не прав.

Тем не менее, я считаю, что в Вашем случае и не нужно делать полную индикацию, поскольку вся схема целиком должна работать в обычных для синхронных схем PVT corners. Т.е. от нее не требуют работы при питании 150мВ, и не нужно охлаждать до -100С. Т.е. никакого экстрима. Если Вы гарантируете работу схемы в заданных диапазонах - это самое главное. Но основных достоинств SI схем со строгой индикацией, вы лишаетесь.

По крайне мере, теперь мне стало ясно, над чем Вы работаете.
Возвращаясь к главному вопросу этого топика. Я занимаюсь немного другими асинхронными схемами (это уже и так уже стало понятно). Поэтому могу только посоветовать почитать об т.н. Elastic circuits. Это разработка Кишиневского, который изначально работал с Варшавским, а потом слинял в Америку, и уже лет 20 работает в Интел. Он в свое время приложил руку к открытию Российского отделения Интел, и он же придумал Elastic - некое подобие самосинхронных схем, которое интел по некоторой информации активно использует в своих разработках. Информации по этим схемам очень мало, как и вообще по технологиям интела. Но какие то статьи Кишиневского есть в интернете. Возможно, это окажется Вам полезным, именно в ключе разработки кастома под high prefomance. По работам Таубина, которые я упоминал ранее в ключе связки домино+dual rail, я не слышал о практической реализации. Так что возможно, Вы первый, кто это использует на практике.

Ну даже не знаю. Расчетный пайплайн в Монте-Карло симуляции с sigma=6 работал при напряжении питания 0.6 вольта. Разброс по температуре до -100С - не знаю, думаю, что модели, которые есть у меня, такой диапазон не поддерживают. Однако и симуляции от 0 до 125С никаких аномалий не выявили. Реальный кремний в таком режиме работать не сможет, поскольку небольшая часть проекта была собрана с использованием стандартных библиотек, а они не характеризовались для низких напряжений и широкого диапазона температур.


Спасибо за информацию - попробую поискать.

Разумеется! Таких моделей нет ни у кого, если это не специализированное производство.

В этом вся и прелесть схем DI и SI со строгой индикацией - они гарантируют работоспособность при любых PVT параметрах и не только. Единственное условие работоспособности - транзисторы должны физически переключаться. Т.е. моделировать такие схемы имеет смысл не более чем для оценки производительности в какой то конкретной точке, все остальное гарантирует математическая модель. Пока переходы открываются, схема будет работать.

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

Баловался в свое время с такими вещами. Этакий "ECL-like MOS", или "гигагерц на старых процессах".
У таких структур есть несколько особенностей, которые, если доступен некоторый тюнинг техпроцесса (использование полуизолирующей подложки с отказом от "вытягивания" пороговых напряжений), потенциально позволяют прилично выиграть в удельном потреблении (работе переключения) за счет введения большого запирающего смещения на подложку (снижение емкостей). До серьезных проектов дело не дошло ввиду отсутствия реальной потребности.


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