[yes 5]

книжки переехали сюда?

/pub/BOOKS/IC_Design/_Asynchronous_Circuit_/

 

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

 

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

 

....

 

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

 

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

 

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

то есть выигрыша тут не получится, по сравнению с синхронной схемой

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

 

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

 

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

 

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

[v_mirgorodsky 0]

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

 

если у Вас в конвеере есть задержка на 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 в синхронном случае. Другой вопрос, что за подобное ускорение пришлось заплатить несколько большей площадью, но в моем случае это был приемлемый обмен. Сделать более быструю синхронную схему тоже возможно, но в этом случае пришлось бы часто-часто порезать сумматор регистрами, а это может быть не всегда удобно. Да и потребление такой синхронной схемы было бы сильно выше.

[Shivers 0]

Синхронная схема обязана быть рассчитана на распространение сигнала переноса через все 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 схемы (пайплайны сазерленда).

 

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

[v_mirgorodsky 0]

Заблуждаетесь. Если речь идет о dual rail схемах (а вариантов может быть много - читайте мой прошлый пост в этой теме), то имеет место 1) увеличение площади в 4-6 раз, и 2) замедление работы от десятков процентов, до нескольких раз - в зависимости от того, как сделана индикация. Объясню подробнее.

1) По площади. На каждый элемент логики требуется вставить парный + двувходовой тестер. Это в среднем троекратное увеличение площади. Далее, как вы хотите строить схему индикации (СD)? Если на С-элементах, то более-менее реально использовать 3-х входовые и иметь увеличение площади 3.5-4х, а если делать сжатие на стандартных элементах (на библиотеках 65нм и ниже обычно число входов не более 3-х), то площадь увеличивается уже в 5-6 раз. Очень много зависит от разрядности шин и слоев логики внутри схемы.

Я как-бы стандартных библиотек в высокопроизводительной части схемы не использую. Вся вычислительная система построена на 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 схем из-за паразитного свитчинга.

 

2) По скорости. Здесь определяющей является как раз размерность логики в слоях. Единственное, где dual rail имеет преимущество перед синхронной схемой, это преобразование инверторов, которое заменяется на перекрестье проводов. Да и то это преимущества является мнимым, поскольку инверторы в синхронных схемах, в большинстве своем, не являются элементом логики, а служат больше для выравнивания transition в нагруженных цепях. Т.е. по большому счету, инверторы лучше оставлять, чем заменять на перекрестья. Все остальное - сплошное замедление схемы по сравнению с синхронной. Посудите сами - входы индикации, это выходы логики. Т.е. dual rail априори медленнее синхронной схемы. А с ростом разрядности логики в слоях это замедление становится сопоставимо с периодом в синхронной схеме. И напоследок самый важный аргумент. Dual rail использует 2-х фазную передачу данных (4-х фазная в западной терминологии). Отсюда следует, что dual rail работает минимум в два раза медленнее синхронной схемы, поскольку фазу данных сменяет фаза спейсера.

Как я уже писал в предыдущем посте, у каждого вида асинхронных схем есть свое применение. Dual rail с полной индикацией не годится для high perfomance. Можно делать квази схемы и они с некоторой натяжкой могут потягаться с синхронными. Но в целом во всем мире для производительности используют bundled delay схемы (пайплайны сазерленда).

 

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

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

 

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

 

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

 

[Shivers 0]

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

 

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

Еще я сомневаюсь, что домино-элементы с n-матрицей полностью индицируются по выходу. Надо подумать.

 

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

 

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

 

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

[Shivers 0]

p.s.

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

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

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

[zzzzzzzz 0]

Есть ещё одна альтернатива - CML.

На высоких частотах (единицы ГГц и выше) фиксированный микроток потребления дифф. каскада суммарно оказывается на порядок и более выгоден по сравнению и с синхронными, и с асинхронными решениями, работающими в полный размах.

К сожалению, реальных заказчиков на что-то значительное на основе CML сейчас в РФ нет.

Поэтому полноценно попробовать в реале пока не получилось, только небольшие узлы по 180 нм.

 

Рассматриваемый вопрос мне представляется, вообще, несколько далёким от реала.

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

И да, без Спайса тут нельзя, если хочется приблизиться к идеалу.

 

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

[Shivers 0]

Есть ещё одна альтернатива - CML.

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

 

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

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

 

На самом деле, что касается синтеза 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 ;)

[yes 5]

Совершенно не правильный вывод.

...

 

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

 

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

 

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

 

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

 

 

[zzzzzzzz 0]

Альтернатива в чем? в high perfomance? ...

Да, самый хай. При весьма умеренном потреблении, слабо растущем с частотой. Не ради ли этого жаждут асинхронности в конечном счёте?

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

Есть, конечно, и ограничения. Но, они больше "снизу". Так, например, теряется смысл использовать CML для коротких путей. И надо делать преобразователи CML-CMOS и обратно.

 

Пардон, что я тут встрял. Только лишь с целью расширения взглядов. Завязываю.

Самый писк был бы асинхронный CML, с отключением питания неиспользуемых ячеек. :)

Круче пока ничего не просматривается ни по скорости, ни по потреблению для ВЧ схем.

ПС. Кстати, такие ячейки не сложно формализовать. Почти как стандартные. И использовать синтезаторы, заточенные для синхронных схем.

[Shivers 0]

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

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

 

Да, самый хай. При весьма умеренном потреблении, слабо растущем с частотой. Не ради ли этого жаждут асинхронности в конечном счёте?

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

 

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

 

Самый писк был бы асинхронный CML, с отключением питания неиспользуемых ячеек. :)

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

[v_mirgorodsky 0]

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

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

 

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

Еще я сомневаюсь, что домино-элементы с n-матрицей полностью индицируются по выходу. Надо подумать.

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

 

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

 

 

Да, самый хай. При весьма умеренном потреблении, слабо растущем с частотой. Не ради ли этого жаждут асинхронности в конечном счёте?

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

Есть, конечно, и ограничения. Но, они больше "снизу". Так, например, теряется смысл использовать CML для коротких путей. И надо делать преобразователи CML-CMOS и обратно.

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

 

Пардон, что я тут встрял. Только лишь с целью расширения взглядов. Завязываю.

Самый писк был бы асинхронный CML, с отключением питания неиспользуемых ячеек. :)

Круче пока ничего не просматривается ни по скорости, ни по потреблению для ВЧ схем.

ПС. Кстати, такие ячейки не сложно формализовать. Почти как стандартные. И использовать синтезаторы, заточенные для синхронных схем.

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

[zzzzzzzz 0]

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

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

Приходится лаптем щи хлебать. :)

[Shivers 0]

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

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

 

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

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

И последнее. Вы учитываете, что строя дерево для распределения нагрузки, нужно ставить CD на все его листья? Ведь каждый внутренний элемент логики - это фактически новая переменная в графе, и эту каждую переменную надо индицировать. В дереве каждая новая ветвь - новая переменная.

 

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

 

[v_mirgorodsky 0]

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

 

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

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

И последнее. Вы учитываете, что строя дерево для распределения нагрузки, нужно ставить CD на все его листья? Ведь каждый внутренний элемент логики - это фактически новая переменная в графе, и эту каждую переменную надо индицировать. В дереве каждая новая ветвь - новая переменная.

 

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

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

 

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

 

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