v_mirgorodsky

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

Shivers А вот тут и возникает вопрос - а как сделать характеризацию хотя-бы одной целы и как после этого получить готовый .LIB файл, годный к употреблению? Я очень хорошо знаю что есть симуляции и фулл-кастом, однако не знаю что ожидает увидеть DC и ICC. Можете показать пример на одном нанде, если не сильно сложно?

Доброго времени суток, Раньше пользовался готовыми библиотеками с ФАБа, а теперь вот назрела необходимость разработать свою специализированную библиотеку для ICC и охарактеризовать ее. Есть у меня некий список целов, для каждой есть СПАЙС-нетлист, сделан лейаут, извлечены паразиты. Требуется получить LIB-файл, который можно скормить DC и ICC в качестве библиотечного. В Инете встречал упоминание о магической тулзе SiliconSmart. По отзывам, сильно упрощает и облегчает процесс. Однако сразу приручить ее как-то не получилось. Да и не совсем понятно что она берет на вход и что выдаст на выходе. Может кто-то сможет подсказать приблизительный маршпут, или сможет показать пример характеризации одной ассинхронной и одной синхронной целы? Думаю, что многим здесь это было бы интересно.

С ошибками DRC по антеннам ни один ФАБ к изготовлению микросхему не примет. С точки зрения пробоя диэлектрика - да, процесс вероятностный, однако чем Вам лично будет хороша микросхема с выгоревшим каскадом ? И как Вам ФАБ будет гарантировать йилд ? По опыту многие ошибки по DRC обсуждаемы в том, или ином виде, однако антенные ошибки считаются одними из наиболее критических. Однако с антеннами не все так плохо. Если гейты одних транзисторов когда-то подключаются к диффузиям других, то этого уже в большинстве случаев достаточно. В Вашем случае я бы посоветовал в местах, где DRC ругается на площади попытаться сделать минимальную дублирующую разводку на более нижних слоях. Речь не идет о сколь-нибудь значащих токах. Важно чтобы между гейтом и любой диффузией достаточного размера был контакт.

Из моей практики NMOS и PMOS - названия транзисторов в CAD-ах по умолчанию. Потому как ФАБ дополнительно кодирует в названии модели тип транзистораи, версию модели и область применения - I/O, core, SRAM, etc.

Я своими глазами видел две TSMC либы под advanced nodes. По своему собственному личному опыту могу сказать следующее - стандартные либы TSMC выполнены неоптимально с точки зрения плотности. В моем случае практически каждую целу можно было "ужать" на 1-2 поли без ущерба для функциональности. Простая переразводка/перехарактеризация либов могла бы дать уже 5-10% экономии площади. Так что я думаю, что экономия за счет несколько более сильных транзисторов и чуть более прямых рук.

Самой логичной причиной деления клоков может быть часть дизайна, которая не успевает работать на основном клоке :) Я так думаю. Ну и перевод сколь-нибудь значительной части дизайна на более низкий клок очень положительно сказывается на потреблении. Теперь-то я уже знаю, что клоковое дерево может потреблять до 15-20% мощности и эту цифру практически нельзя уменьшить. З.Ы. Ну и в моем случае - неоптимально, это и есть неправильно. Потому как это значит, что дизайн мог бы потреблять меньше, или работать быстрее. Потому для меня и организаций, с которыми я сотрудничал, неоптимально и неправильно - синонимы. Хотя, строго говоря, неоптимально и неправильно действительно разные вещи.

Даже не знаю, возможно за последнее время Квартус вместе с ИСЕ серьезно добавили в интеллекте, или проект в котором возможна такая манипуляция клоками крайне далек от предела возможностей выбранного кристала. На сколько помню, при заполнении кристалла под 90% и на максимум по частоте одновременно у меня провернуть такой финт уже не получилось - проект просто перестал компилироваться на заданную частоту и сильно "распух" в размере. Теперь я уже понимаю, что тулза начинала фиксить холды в корнерах, но много лет назад ответа на тот вопрос я так и не нашел - пришлось переделать пару блоков и вставить синхронизаторы.

Сделал ма-а-а-ленький эксперимент в качестве тренировки. Взял свой кастомный DFF на UMC 28HLP, извлек из него паразиты почти без редукции, также обработал несколько "боевых" топологий своих инверторов. Прикинул клоковое дерево, в каждый клоковый домен поставил по одному DFF и соединил их в виде сдвигового регистра. Соединил все в спайсе. Тут уж извините, делать полный эксперимент в лейауте было лениво, да и результаты бы это не изменило. Как критерий успешности выбранной топологии использовалась локальная MC-симуляция со свипом в 1000 ранов. Если на 0.6V у моих триггеров в TT Tco составляет в районе 150ps, то при 0.8V Tco уменьшается до 60ps, а при 1.0V - до 30ps. Итого - разница в TT всего по одному параметру в моем диапазоне рабочих напряжений составила 120ps, а это надо как-то компенсировать. Как результат, систему можно сравнительно просто настроить на конкретное рабочее напряжение и локальные вариации в пределах одного корнера. Линия SS-TT-FF тербует почти 50% увеличения количества инверторов в "клоковом дереве" и пары последовательных буферов с выхода одного триггера до входа другого для фикса холдов. Расширение зоны работоспособности до SF и FS потребовало очень много усилий и до конца я его не довел. В глобальных корнерах работало, в тотальных - нет, в монте-карло ошибались 3 эксперимента в SF и 7 экспериментов в FS из 1000. Потом уменьшил рабочее напряжение с 0.8 вольт до 0.6 вольт и повторил эксперимент без изменения топологии. Как результат получил больше 1000 фейлов из 5000 ранов. Выводы. 1. Если делить клоки простыми триггерами, то нужно позаботиться о разнице фаз между активными фронтами клоков больше, чем Tco самого медленного триггера в системе во всем PVT диапазоне. Как самый простой вариант - поиграться с инверсиями клоков триггеров делителей. Если активные эджи клоков фиксированы на границахи все переходы известны, то решение найти, думаю, можно. 2. Если выполнить (1) не получается, то домены следует считать асинхронными и делать переходы между ними на синхронизаторах. 3. Если выполнять (1) и (2) не хочется, то лучше всего использовать триггера с клок-енейблами и отказаться от деления клоков в принципе. 4. Если все (1-3) выполнить не получилось, то следует быть готовым к абсолютно безобразному количеству инверторов в проекте и неэффективному использованию площади кремния. Безусловно, я не IC Compiler :) У него эта задача возможно получилась бы несколько лучше - все же он больше параметров учитывает и задачи оптимимизации топологии решает не перебором ;) Однако даже IC Compiler не в силах обойти физику процессов в кремнии.

Давно не заходил, а потому отвечу немного позже. Если коротко, то делить так клоки принципиально нельзя. Ни в ASIC, ни в FPGA. Эта система сильно подвержена нарушению холдов при переходе из одного клокового домена в другой. Можно, конечно, попытаться скомпенсировать холды путем удлиннения ассинхронных путей между триггерами (IC Compiler, к примеру, начинает на такие пути гадить инверторами), но работать это будет только в сравнительно узких диапазонах изменения температур и напряжений и, обычно, только в симметричных корнерах. Хорошим признаком такого рода ошибок является финальный репорт тулзы. Если количество инверторов или буферов в дизайне неоправданно большое, то где-то есть проблемы с клоком.

Для 28нм HKMG затворы исключительно прямые, с постоянным шагом и длинной транзисторов. Для поликремниевых затворов в зависимости от ФАБа затворы разрешается гнуть, или делать из них букву L. Практически все остальное в технологиях тоньше 40нм запрещено. Помню, что в проекте на 65нм мы использовали поликремний почти как металл для роутинга внутри целов, то в процессах тоньше 40нм о таких вольностях надо забыть. Еще в технологиях тоньше 40нм сильно проявляется влияние позиции транзистора на его максимальный ток. Отличие на низких напряжениях может достигать 30%. На напряжениях, близких к номиналу все получается не так печально, но это уже инженерная задача каждого конкретного места в лейауте. Т.е., одиноко стоящий транзистор приходится делать на 30% и больше процентов шире, чем такой же транзистор, выполняющий аналогичные функции но в группе транзисторов. Таким образом единственный более-менее подходящий подход к лейауту на технологиях ниже 40нм - это длинная непрерывная полоса диффузии, на ней много транзисторов с одинаковыой длинной канала с постоянным шагом. Если транзистор в этом конкретном месте не нужен, то его затвор просто сажается на соответствующий рейл питания, или, если чип большой и с ESD проблемы, то на близ лежащий tie-off или tie-on. Транзисторы могут иметь разную ширину канала, но и тут есть ограничения. В зависимости от ФАБа может сильно варьироваться конфигурация и требования к "выступающим", или утопленным частям диффузии. Короче, надо смотреть по ПДК - однозначного рецепта здесь нет. Еще огромную проблему на 28 и ниже представляет собой активное сопротивление металлов. 28 в этом смысле самый сложный процесс. Потребление схемы все еще высокое, геометрически транзисторы большие и получить значительный IR-drop на рейле питания сравнительно просто. Это приходится учитывать, делать более широкие рейлы питания, или выделять два металла на разводку питания. Особенностей в тонких техпроцессах много. Спрашивайте, что вспомню - расскажу, если не будет противоречить всяким NDA ;) Shivers, может этот вопрос будет уже неактуальным, но играться с длинной канала на тонких процессах будет совсем напряжно по площади. Посмотрите в сторону такого элемента, как мажорити. Если коротнуть ему выход на один из входов получается очень даже хороший C-элемент. На 28 нм у меня такая штука заняла "всего" 7 полосок поли на два входа.

Не проводите чемпионат по рисованию на технологических нормах ниже 28 нанометров :) Правильный виртуозовод даст вам 100 очков вперед на плотных целах среднего и большого размера. Практически гарантированно. Рисует не тул, а человек. Тул только помогает. Однако для некоторых тонких процессов наличие тула за лям становится обязательным. Я тоже некоторое время назад считал, что все можно нарисовать в бесплатном электрике. Теперь знаю - хороший тул для тонкого процесса увеличивает производительность лейаут-инженера на порядки. Одно время я недоумевал - почему у моих подрядчиков не получается решать эфффективно проблемы с дабл-паттернингом. Там ведь все просто - красная дорожка, зеленая дорожка, просты понятные технологические правила и ограничения. А оказалось, что работают они в Lakers, а Lakers не поддерживает дабл-паттернинг, потому и лейаут у них получается "рыхлый". Единственное, что могут они сделать с ошибками дабл-паттернинга - это раздвинуть дорожки более чем на 81нм, потому как раздебажить кольцо из 30-40 геометрий в уме уже очень сложно. Еще скажу из собственного опыта - все дело в рефлексахи мотороной памяти. Действительно, в каденсе рисовать немного медленее, чем в электрике, или пайксисе, но только в начале. Дальше руки привыкают нажимать нужные связанные клавиши автоматически и процесс значительно ускоряется. Все дело в прямых руках и желании сделать свою работу качественно и быстро. А тул может быть более подходящим, или менее подходящим под конкретную задачу.

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

Доброго времени суток, Вопрос простой - есть ли у кого опыт использования Спектры и APS из командной строки? На сетап простого теста уходитт минут 10-15. Результаты симуляций смотрятся местной тулзой VIVA, которая не умеет как WaveView от Синопсиса сохранять настройки текущей сессии, вернее умеет, но с привязкой к абсолютным путям, если захотеть этой же сессией воспользоваться еще раз, то надо поменять кучу путей в XML файлике, что несколько раздражает. Каждая новая симуляция создает свой новый огромной длинны путь. Так, на вскидку, уровней 10-12 вложений - может оно и оправдано для систематизации результатов, но ходить по этому пути за файлами очень напрягает. Как-то нашел минут 30 свободного времени и изучил структуру того, что создает ГУИ перед запуском. Выглядит так, что это хозяйство можно переместить в более приемлемое место с более коротким путем и потом перезапускать по необходимости. Однако остается большой вопрос с перегенерацией cdl-нетлиста перед запуском и опоисанием того, что хотелось бы получить от симулятора - какие напряжения дампить, какие источники и куда подключены, параметы моделей ну и все остальные приятные мелочи. Для HSPICE прямо в дереве инсталла есть примеры и валом документации. Доков на спектру и APS я в дереве не нашел - может просто плохо искал. Вопрос в том, что Каденс я использую для работы всего три месяца. Со мной работают очень неплохие IC дизайнеры, но многие мои вопросы ставят их в тупик. Основная отговорка - тулза слишком большая, чтобы знать ее досконально во всех аспектах. Официальная поддержка умеет ходить только по менюшкам в ГУИ, а любые варианты нестандартного использования отметает даже без рассмотрения. Много информации есть в хелпах, но учить тул по хелпам удовольствие не быстрое и сильно ниже среднего. Может у кого-то есть опыт более прогрессивного использования тулзов из командной строки? А может кто знает где заныкана документация на все это хозяйство?

На eetop.cn говорят, что CustmSIm - это и есть XA. Самая новая версия XA доступная от Синопсис всего на один релиз младше той, что есть в закромах. Еще ко-симуляцию умеет FineSim Pro двухлетней давности - тоже лежит в закромах. Однако у него серьезные проблемы с лицензиями. Как бы во всех случаях смущают сравнительно старые версии продуктов, а новых как-то не появляется.

Был у меня опыт использования Наносим для динамических гейтов на UMC 65нм. Наносим симулировал быстро и неправильно. По какой-то причине он разряжал динамические ноды намного быстрее, чем это предполагалось. Пришлось выбросить в топку. HSPICE, XA, HSIM симулировали нормально, результаты немного отличались между собой, но не критично. Как показала практика, ближе всего к правильному ответу был HSPICE, дальше всех лежали результаты XA, HSIM довольно точно повторял поведение HSPICE с некоторыми особенностями. Ну и как не странно, HSPICE практически без проблем поднял post-layout extracted нетлист на 200000 транзисторов и выдал результаты симуляции часов через 20, тогда как HSIM просто "упал" с ошибкой по памяти. Симуляция проводилась на 48 процессорном сервере с 384GB памяти. Сейчас надо симулировать "всего" тысяч 50 транзисторов, но техпроцесс сильно тоньше. Фактически, производительно рисовать full-custom под этот тех-процесс можно только в честно купленном Каденсе. Все остальное, что имеется на рынке или плохо поддерживает дабл-паттернинг, или никак его не поддерживает. Вместе с рисовалкой были честно куплены очень ограниченное количество лицензий под Спектру и APS. Там и получилось запустить миксед моде симуляцию с Верилогом, однако меня не устраивает гибкость полученного решения, его точность и скорость. Вот и ищу варианты "улучшения" ситуации. На сайте Synopsis новостей об обновлении XA я не нашел. В закромах есть версия за 2013 год. Если правильно помню, то для проекта с 65нм использовал все же что-то более ранее. Можно попытаться запустить эту связку. А у вас нет какого-нибудь простого примера на эту тему? Все же очень хотелось бы научиться использовать HSPICE в связке с VCS, потому как оба продукта регулярно обновляются в закромах и дают необходимую точность и скорость работы. По идее, VCS-AMS предоставляет необходимые возможности. Потому ищется этот подукт, или другое решение, позволяющее организовать ко-симуляцию любого из доступных Верилогов с HSPICE.

Доброго времени суток, Ищется простое решение для симуляции спайс-нетлиста совместно с тест-бенчем на Верилог. Точно знаю, что подобная штука есть в Каденсе. Там Verilog-NC запускается совместно со Спектрой и получается автоматический тестовый стенд с очень хорошим покрытием. Верилог генерирует входные вейв-формы и проверяет результаты из Спайса. Получается очень приличное покрытие, практически неограниченная гибкость, авоматические тесты и много других полезностей. Недостатком этого всего является большой прицеп в виде самого Каденса и его слабо вменяемых настроечных файлов. Еще знаю, что подобное решение запускалось с Наносимом, однако он уж сильно устарел и для "свежих" библиотек его использовать как-то сильно рисковано. Был вариант, когда Наносим был интегратором, а в качестве спайс-симулятора предлагались на выбор xa & hsim. Однако этот маршрут выглядит тоже немного рискованным по причине отсутствия "свежих" версий вышеупомянутых симуляторов. Недавно прочитал, что есть подобное решение от Синопсиса - VCS-AMS. Сразу пошел искать его в закрома, однако ничего похожего на аббревиатуру VCS-AMS там не нашел. Соответственно, вопрос. Использовал ли кто-то в работе связки Верилог-Спайс? Если да, то какие програмные продукты использовались, получалось ли у кого в качестве Спайс-симулятора запускать HSPICE? Есть ли у кого опыт использования VCS-AMS? На сколько сложно увязать нетлисты? И знает ли кто как скоро он может появиться в закромах?

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

Ну, с тремя транзисторами в пулл-даун цепи я не согласен. В моем случае некоторое количество элементов имеет до 5 транзисторов. Другой вопрос, что все транзисторы для таких элементов имеют очень разную ширину канала. Скажу так, в некоторых элементах нижние транзисторы имели ширину канала в микрон и более. Еще такие элементы представляли собой целый комплекс компромисов с точки зрения площадь/задержка/потребление. Скажу так, что один из таких элементов потребовал около 30 часов рабочего времени от человека, который работал со мной - нарисовать, просимулировать, поменять, снова просимулировать и так до полного удовлетворения. При этом скажу, что без спайс-моделирования эта затея была бы обречена на провал - простые инженерные расчеты врали в полтора-два раза. Теперь немного о индикации. Для dual-rail domino индикация промежуточных состояний вычислительной функции не требуется. Это не очевидно в начале. Мне на старте работы с этой технологией казалось, что разные по скорости пути должны конфликтовать и разряжать высокоомные точки в процессе вычислений. Однако спайс-моделирование рипл-керри сумматора полностью развеяло мои сомнения. Десяток включенных последовательно рипл-керри сумматоров давали верный ответ для любых входных данных при этом не порождали ни единого глитча ни на одном из проводов. Так вот, всю цепочку из десяти сумматоров можно было индицировать по 31 биту последнего сумматора. В моем случае индикация более сложная, поскольку сумматор у меня префиксный, но принцип тот же. Еще можно вдвигать CD внутрь префиксного дерева, поскольку с момента "дифференциальности" некоторого набора промежуточных сигналов задержка до полного установления всех выходов в истинное состояние будет уже константой. Такая себе машина времени :)

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

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

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

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

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

Что же, придется, вероятно, таки смещаться в сторону каденса. Может удастся с ним как-то подружиться.