Это простой вопрос с очень сложным ответом.
Прежде всего, немного предыстории.
Реальный дизайн СБИС - это чрезвычайно техническая область, в которой постоянно меняется баланс компромиссов. Время, которое требуется схеме для расчета ответа, редко является единственным важным фактором. Также есть потребляемая мощность и физическая площадь, а также множество факторов, которые показывают, что разрабатываемые вами схемы на самом деле являются аналоговыми (например, сопротивление проводов, паразитная емкость). Все это важно в реальной схеме и может повлиять на то, какой дизайн выбран.
Во-вторых, вы должны рассмотреть весь жизненный цикл проекта. Сумматор, который подходит для реализации VLSI, может не подходить для реализации FPGA. Если дизайн будет проходить этап тестирования на FPGA ... вы получите картину.
В-третьих, не каждый сумматор сделан равным. На типичном процессоре имеется множество сумматоров, которые выполняют разные задачи; вероятно, есть несколько целочисленных ALU, сумматор мантиссы с плавающей запятой, сумматор, который выполняет вычисление адресов, сумматор, который вычисляет целевые значения для филиалов, и так далее. Это не считая сумматоров с сохранением переноса, которые вы найдете в современных единицах умножения. У каждого есть свои особенности и ограничения.
Например, вычисление целевого значения ветвления обычно включает добавление небольшой константы к полному слову, что предполагает другой дизайн сумматора, чем тот, который добавляет два полных слова вместе. Точно так же для сложения с плавающей запятой требуется шаг округления после сложения, который может занять меньше цикла, поэтому нет причин, по которым вы не могли украсть оставшуюся часть цикла, чтобы завершить сложение.
И, наконец, и, возможно, самое главное, крупные игроки (например, Intel, AMD, NVIDIA) довольно недоверчиво относятся к деталям низкоуровневой реализации по очевидным причинам, если только они не думают, что могут получить документ и / или патент из него. Даже тогда вы часто не можете быть уверены, что они на самом деле сделали без реинжиниринга.
Сказав это, есть несколько вещей, которые мы знаем.
Главное, что вам нужно осознать, - это то, что методы переноса в будущее являются строительными блоками, а не обязательно самими методами. Здесь может быть аналогия.
Если вы думаете о классах алгоритмов, вы, вероятно, изучили кучу алгоритмов сортировки, таких как быстрая сортировка, сортировка слиянием, сортировка вставками и так далее. В реальном мире, если сортировка является узким местом в производительности, любой порядочный инженер мог бы думать о них как о примитивных строительных блоках, из которых можно построить «реальный» вид.
Например, алгоритм сортировки из стандартной библиотеки GNU C ++ использует быструю сортировку, используя сортировку вставкой, когда интервалы становятся достаточно малыми. Однако, если после нескольких проходов кажется, что разделение быстрой сортировки имеет патологическое поведение, оно возвращается к сортировке в куче. Это три разных алгоритма сортировки для создания одного промышленного класса.
То же самое относится и к схемам сумматора. Например, известно, что в целочисленном устройстве Pentium 4 использовался сумматор Хана-Карлсона, представляющий собой смесь Kogge-Stone и Brent-Kung. (Хан-Карлсон особенно интересен, потому что это «сладкое пятно» в компромиссе между задержкой распространения и площадью кристалла, которая также является достаточно энергоэффективной.) Часто бывает полезно использовать сочетание нескольких методов.
«Чистые» сумматоры-переносчики по-прежнему остаются нормой в синтезированных цепях (например, если вы передаете оператор Verilog «+» в Cadence или Synopsys), когда речь идет о ручном проектировании, современных высокопроизводительных ЦП с их суперскалярными выходами. Похоже, что механизмы исполнения заказов движутся к несколько иному дизайну для своих целочисленных единиц.
Спекулятивные сумматоры - это схемы, которые имеют чрезвычайно низкую задержку распространения, но работают корректно только в течение некоторого времени (95% времени является типичным), и можно с очень небольшой логикой сказать, возвращает ли умозрительный сумматор правильный результат или нет. Таким образом, идея состоит в том, чтобы сделать умозрительное сложение и половину сложного переноса параллельно, за один цикл. Если умозрительный сумматор вернул правильный ответ, инструкция выполнена. В противном случае остановите конвейер и сделайте вторую половину точного сложения.
Поскольку вы знаете, что медленный путь займет два цикла, разработчики могут использовать более компактный и энергоэффективный метод, даже если он будет слишком медленным для общего использования.