Комментарии 14
Базовые ячейки имеют очень разную длину. Вот, например, несложный триггер:
У сложного триггера (с сетами-ресетами, входным мультиплексором для скан-цепи) длина будет ещё больше.
Для того, чтобы удобно вписать в кривую Гилберта множество ячеек с различающимися больше, чем на порядок длинами, надо очень постараться. Или иметь много вариантов топологии каждой ячейки.
И ещё есть мнение, что в топологии с кривой Гилберта у вас будут намного более серьезные проблемы с просадкой питания из-за намного большего сопротивления линий земли и питания.
И, кажется, ничего не мешает в технологии, где у вас достаточно металлов, располагать ячейки в каком угодно порядке поверх прямолинейной сетки земель и питаний.
У сложного триггера (с сетами-ресетами, входным мультиплексором для скан-цепи) длина будет ещё больше.
Для того, чтобы удобно вписать в кривую Гилберта множество ячеек с различающимися больше, чем на порядок длинами, надо очень постараться. Или иметь много вариантов топологии каждой ячейки.
И ещё есть мнение, что в топологии с кривой Гилберта у вас будут намного более серьезные проблемы с просадкой питания из-за намного большего сопротивления линий земли и питания.
И, кажется, ничего не мешает в технологии, где у вас достаточно металлов, располагать ячейки в каком угодно порядке поверх прямолинейной сетки земель и питаний.
Это всего-лишь идея, а не законченное решение.
Про питание: сейчас, насколько я понял, есть два варианта — условно, прогрессивное и чересстрочное
В данном случае придётся делать что-то вроде H-tree аналогично подводу синхроимпульса.
Повернуть стандартную ячейку или обернуть её через ось, насколько я понимаю, не проблема. Если это будет полезно, появятся и «угловые» ячейки.
Сложный триггер тянет на функциональный блок, который, впрочем можно «с'инлайнить», разбив на элементарные ячейки. Либо на следующем уровне иерархии можно использовать функциональные блоки в качестве элементов для размещения по высокоуровневой кривой Гильберта.
Здесь, похоже, есть где разгуляться пытливым умам.
Про питание: сейчас, насколько я понял, есть два варианта — условно, прогрессивное и чересстрочное
В данном случае придётся делать что-то вроде H-tree аналогично подводу синхроимпульса.
Повернуть стандартную ячейку или обернуть её через ось, насколько я понимаю, не проблема. Если это будет полезно, появятся и «угловые» ячейки.
Сложный триггер тянет на функциональный блок, который, впрочем можно «с'инлайнить», разбив на элементарные ячейки. Либо на следующем уровне иерархии можно использовать функциональные блоки в качестве элементов для размещения по высокоуровневой кривой Гильберта.
Здесь, похоже, есть где разгуляться пытливым умам.
Повернуть стандартную ячейку или обернуть её через ось, насколько я понимаю, не проблема.Повернуть стандартную ячейку на 90 градусов в технологии 28 нм и ниже нельзя. Все затворы всех транзисторов должны быть ориентированы одинаково.
Ну и повторяю, никто не захочет делать линии питания длиннее — это куча проблем, в том числе связанных с тем, что просадка питания зависит от расположения ячейки на кристалле. С нормальной сеткой (она кстати обычно именно сетка в двух металлах, а не набор линий) эта разница предсказуема и легко считается. С вашим подходом вы предлагаете взять одну из самых сложных задач — построение дерева тактовых сигналов — и усложнить ее ещё больше.
Опять же, что мешает расставить находящиеся в сетке питания ячейки вдоль линии Гилберта, чтобы получить минимальную сумму длин сигнальных линий, а не силовых?
P.S. Делать много вариантов топологии для библиотечных элементов — дорого и ещё больше запутает плейсер. А если разбивать большие ячейки на прямо маленькие примитивы, то накладные расходы площади на соединения мини-ячеек между собой сожрут всю выгоду от более продвинутого плейсмента.
Если вы считаете, что для питания проще использовать решетку, нежели дерево,
значит так и есть.
Большие библиотечные элементы можно делать квадратными а не линейными.
В этом случае они на общих основаниях встроятся в кривую Гильберта (вместо узда 2Х2, 4Х4, ...), дискретность только появится. И/или разрывы, если таких элементов несколько.
значит так и есть.
Большие библиотечные элементы можно делать квадратными а не линейными.
В этом случае они на общих основаниях встроятся в кривую Гильберта (вместо узда 2Х2, 4Х4, ...), дискретность только появится. И/или разрывы, если таких элементов несколько.
Если вы считаете, что для питания проще использовать решетку, нежели дерево, значит так и есть.Я не претендую на то, что мое мнение — истина в последней инстанции. Я даже не профессионал в разработке САПР, я профессионал только в его применении) Ваша статья заставляет немного задуматься о том, почему некоторые вещи делаются тем или иным образом (а это всегда полезно — проговорить наконец вслух некоторые соглашения по умолчанию, чтобы лучше их осмыслить), но пока что я не вижу, где конкретно будет выигрыш от вашего предложения, зато вижу кучу маленьких и больших проблем, которые вызовет его внедрение.
Большие библиотечные элементы можно делать квадратными а не линейными.
Делать много вариантов топологии для библиотечных элементов — дорого и ещё больше запутает плейсер.
Библиотечные элементы делают фиксированной высоты для того, чтобы максимально упростить работу плейсера, потому что она и так крайне ресурсозатратна, даже на маленьких проектах.
А есть еще, например, timing-driven placement, где задача стоит не «оптимизировать», а «сделать достаточно хорошо для того, чтобы удовлетворить ТЗ». и, СЮРПРИЗ, в процессе итерационной разводки соединений в проекте могут появляться новые элементы, предназначенные для коррекции поехавших в разные стороны задержек.
Большие библиотечные элементы можно делать квадратными а не линейными.… дискретность только появится. И/или разрывы, если таких элементов несколько.Таких элементов примерно половина проекта.
Вы видите результат, то есть стандартные ячейки, расставленные в ряды, и хотите это улучшить, используя те инструменты, которыми вы сами владеете. Но вы, похоже, смутно представляете как было сделано то, что вы видите, и почему именно так. Поэтому ваше предложение для специалистов в этой области выглядит странно. Хотя идея и интересная.
Смотрите. Плейсинг начинается с того, что в САПР создаются границы проекта, создаются ряды заданной высоты, доступные для расстановки стандартных ячеек, между рядами прокладываются линии земли и питания по первому металлу и ещё ряд действий, которые в рамках данного обсуждения неважны. Это называется создание Floorplan'а.
Все стандартные ячейки в рамках одной библиотеки имеют фиксированную высоту и фиксированный шаг ширины. В проекте может быть несколько библиотек с разной высотой и тогда потребуется создание рядов с разной высотой, но это мы сейчас тоже опустим.
Ряды делаются так, что в ряде номер N ячейки стоят так, что шина земли проходит снизу, а шина питания сверху; в ряде номер (N+1) — наоборот. То есть ячейки стыкуются друг с другом.
Короче говоря, плейсер может ставить ячейки только в фиксированные места (ряды). Единственная степень свободы, которая у него есть помимо выбора ряда — это поворот на 180 градусов.
При этом есть ещё один немаловажный момент. Большинство ячеек в современных и не очень технологиях типа 65 нм, 28 нм и ниже не имеют контактов к подложке и карману. Для обеспечения такого контакта используются специальные ячейки (tap'ы), которые разработчик расставляет с заданным шагом на этапе проектирования Floorplan в рядах, в соответствии с требованием технологии. Грубо говоря, у вас в каждом ряду должны стоять tap'ы с шагом 20 мкм или меньше.
Шины земли и питания существенно шире, чем сигнальные линии, поэтому разводить их будет сложно, если они уже не разведены способом описанным выше.
К тому же, границы проекта выбираются так, чтобы у вас после плейсинга утилизация была ~75%. Реально можно сделать как меньше, так и больше. Зависит от конкретного проекта. Утилизация — это сколько площади у вас занято. То есть на этапе плейсинга реально занимается порядка 3/4 площади. А зачем так делают? Так затем, что плейсинг — это только начало маршрута!
Дальше будет построение деревьев тактовых сигналов. Строится оно добавлением инверторов, буферов и, возможно, других элементов типа gate'ов. Это «съест» ещё площадь.
Дальше будет правка setup'ов и hold'ов (времена предустановки и удержания) с помощью добавления буферов уже в пути данных.
Потом будет этап разводки, после которого скорее всего будет опять правка setup'ов и hold'ов тем же способом. Возможно будет ещё «починка» деревьев тактовых сигналов после разводки.
Это то, что с ходу в голову приходит. Вероятно, есть ещё проблемы, которые на первый взгляд неочевидны, но которые тоже ставят крест на том, что вы предлагаете.
Это было длинное лирическое отступление. Теперь к сути.
Суть в том, что необходимость изменения плейсинга из-за добавления элементов на более поздних стадиях проектирования ставит крест на предлагаемом методе.
Теоретически, можно заложить «запчасти» ещё на этапе плейсинга (так, кстати, делают, но для других целей) и часть из них потом не использовать, но какова будет эффективность этого?
Ну, и скорость, конечно. Крупный проект на современном железе с применением современных САПР может собираться несколько недель. Боюсь, что таким методом он будет собираться пару лет.
Кстати, насчёт запчастей. Есть такой подход — ECO (Engineering Change Order). Это когда вам на поздних этапах проектирования, когда уже всё почти готово к отправке на фабрику, или даже уже отправлено, нужно провести какую-то корректировку.
Если фотошаблоны ещё не готовы, то всё вообще просто: у вас же утилизация не 100%, поэтому можно добавить необходимой логики и поменять металлическую разводку.
Если фотошаблоны уже изготовлены, но вы заранее заложили «запчасти» в виде рассыпухи логических вентилей, то вы можете обойтись переделыванием нескольких фотошаблонов слоёв металлизации: просто по-другому связать то, что у вас было заложен в чипе.
В вашем подходе такое можно предусмотреть? И если такое предусмотреть, то как это повлияет не его эффективность?
Смотрите. Плейсинг начинается с того, что в САПР создаются границы проекта, создаются ряды заданной высоты, доступные для расстановки стандартных ячеек, между рядами прокладываются линии земли и питания по первому металлу и ещё ряд действий, которые в рамках данного обсуждения неважны. Это называется создание Floorplan'а.
Все стандартные ячейки в рамках одной библиотеки имеют фиксированную высоту и фиксированный шаг ширины. В проекте может быть несколько библиотек с разной высотой и тогда потребуется создание рядов с разной высотой, но это мы сейчас тоже опустим.
Ряды делаются так, что в ряде номер N ячейки стоят так, что шина земли проходит снизу, а шина питания сверху; в ряде номер (N+1) — наоборот. То есть ячейки стыкуются друг с другом.
Короче говоря, плейсер может ставить ячейки только в фиксированные места (ряды). Единственная степень свободы, которая у него есть помимо выбора ряда — это поворот на 180 градусов.
При этом есть ещё один немаловажный момент. Большинство ячеек в современных и не очень технологиях типа 65 нм, 28 нм и ниже не имеют контактов к подложке и карману. Для обеспечения такого контакта используются специальные ячейки (tap'ы), которые разработчик расставляет с заданным шагом на этапе проектирования Floorplan в рядах, в соответствии с требованием технологии. Грубо говоря, у вас в каждом ряду должны стоять tap'ы с шагом 20 мкм или меньше.
Шины земли и питания существенно шире, чем сигнальные линии, поэтому разводить их будет сложно, если они уже не разведены способом описанным выше.
К тому же, границы проекта выбираются так, чтобы у вас после плейсинга утилизация была ~75%. Реально можно сделать как меньше, так и больше. Зависит от конкретного проекта. Утилизация — это сколько площади у вас занято. То есть на этапе плейсинга реально занимается порядка 3/4 площади. А зачем так делают? Так затем, что плейсинг — это только начало маршрута!
Дальше будет построение деревьев тактовых сигналов. Строится оно добавлением инверторов, буферов и, возможно, других элементов типа gate'ов. Это «съест» ещё площадь.
Дальше будет правка setup'ов и hold'ов (времена предустановки и удержания) с помощью добавления буферов уже в пути данных.
Потом будет этап разводки, после которого скорее всего будет опять правка setup'ов и hold'ов тем же способом. Возможно будет ещё «починка» деревьев тактовых сигналов после разводки.
Это то, что с ходу в голову приходит. Вероятно, есть ещё проблемы, которые на первый взгляд неочевидны, но которые тоже ставят крест на том, что вы предлагаете.
Это было длинное лирическое отступление. Теперь к сути.
Суть в том, что необходимость изменения плейсинга из-за добавления элементов на более поздних стадиях проектирования ставит крест на предлагаемом методе.
Теоретически, можно заложить «запчасти» ещё на этапе плейсинга (так, кстати, делают, но для других целей) и часть из них потом не использовать, но какова будет эффективность этого?
Ну, и скорость, конечно. Крупный проект на современном железе с применением современных САПР может собираться несколько недель. Боюсь, что таким методом он будет собираться пару лет.
Кстати, насчёт запчастей. Есть такой подход — ECO (Engineering Change Order). Это когда вам на поздних этапах проектирования, когда уже всё почти готово к отправке на фабрику, или даже уже отправлено, нужно провести какую-то корректировку.
Если фотошаблоны ещё не готовы, то всё вообще просто: у вас же утилизация не 100%, поэтому можно добавить необходимой логики и поменять металлическую разводку.
Если фотошаблоны уже изготовлены, но вы заранее заложили «запчасти» в виде рассыпухи логических вентилей, то вы можете обойтись переделыванием нескольких фотошаблонов слоёв металлизации: просто по-другому связать то, что у вас было заложен в чипе.
В вашем подходе такое можно предусмотреть? И если такое предусмотреть, то как это повлияет не его эффективность?
Спасибо за развёрнутый ответ.
Положение, которое вы описали, сложилось за десятки лет совместной эволюции технологии и САПР. И конечно, здесь всё явно и неявно пронизано этими рядами ячеек.
Просто отбросить их равносильно прохождению всего пути заново, что может быть и неплохо при определенных обстоятельствах.
Можно ли как-то встроить предложенный подход в существующую технологию?
А что если… :)
Давайте отбросим вертикальные отрезки кривой Гильберта, не будем их заполнять ячейками. Горизонтальные участки сдвинем, чтобы убрать промежутки (это нетривиальное дело).
Но заполнять их станем, как если бы они по-прежнему были на кривой Гильберта ( с учетом tap-ов, если требуется).
В результате сохранятся все прелести существующей технологии и основные преимущества предложенного подхода. В частности скорость.
У вас почему-то сложилось впечатление, что плэйсмент по кривой Гильберта требует бОльших вычислительных затрат, чем нынешняя технология.
Считаю что это не так. Впрочем, опыт критерий истины.
Положение, которое вы описали, сложилось за десятки лет совместной эволюции технологии и САПР. И конечно, здесь всё явно и неявно пронизано этими рядами ячеек.
Просто отбросить их равносильно прохождению всего пути заново, что может быть и неплохо при определенных обстоятельствах.
Можно ли как-то встроить предложенный подход в существующую технологию?
А что если… :)
Давайте отбросим вертикальные отрезки кривой Гильберта, не будем их заполнять ячейками. Горизонтальные участки сдвинем, чтобы убрать промежутки (это нетривиальное дело).
Но заполнять их станем, как если бы они по-прежнему были на кривой Гильберта ( с учетом tap-ов, если требуется).
В результате сохранятся все прелести существующей технологии и основные преимущества предложенного подхода. В частности скорость.
У вас почему-то сложилось впечатление, что плэйсмент по кривой Гильберта требует бОльших вычислительных затрат, чем нынешняя технология.
Считаю что это не так. Впрочем, опыт критерий истины.
В результате сохранятся все прелести существующей технологии и основные преимущества предложенного подхода. В частности скорость.Может быть так уже и сделано? :)
Я не разработчик САПР, а их пользователь. Выше я описывал то, как выглядит процесс с точки зрения разработчика. Как работает сам САПР, какие в него там алгоритмы заложены неизвестно (коммерческая тайна).
У вас почему-то сложилось впечатление, что плэйсмент по кривой Гильберта требует бОльших вычислительных затрат, чем нынешняя технология.Если крутить ячейки в разные стороны, не пользоваться заранее заданным допустимым местом расположения ячеек (рядами), разводить первый металл, то так и будет.
Плюс, если для применения такого метода, требуются нестандартные элементы, как то квадратные ячейки, ячейки разной ориентации и т.п., то это не просто дольше, но и гораздо дороже. Типовая библиотека состоит из порядка 300-500 элементов. Бывают больше. В проекте используются от 1 и до нескольких десятков библиотек.
Разработка библиотеки достаточно трудоёмкая задача, сложность и время на её решение растут с увеличением количества элементов примерно линейно.
Впрочем, опыт критерий истины.Согласен с вами.
Добавил вырожденный случай, когда стандартные ячейки просто располагаются
в узлах кривой Гильберта, т.е. в прямоугольной решетке, естественным образом формируя ряды.
>> Может быть так уже и сделано? :)
>> Я не разработчик САПР, а их пользователь. Выше я описывал то,
>> как выглядит процесс с точки зрения разработчика.
>> Как работает сам САПР, какие в него там алгоритмы
>> заложены неизвестно (коммерческая тайна).
Есть такое мнение (andy_p):
«Вообще алгоритмов размещения достаточно много. Насколько мне известно, обычно делают так — размещают грубо ячейки по силовому алгоритму, а затем с помощью какого- либо другого алгоритма убирают получившиеся пересечения. Насчет заметающих кривых — не встречал такого, но, наверное, тоже может иметь место.
Силовой алгоритм — это просто размещение, при котором потенциальная энергия минимальна, если считать, что связь между парами ячеек является пружиной или чем-то типа того с жесткостью, зависящей от количества соединений (ряды при этом не учитываются). А в какой ряд ячейка встанет определяется близостью к этому ряду.»
в узлах кривой Гильберта, т.е. в прямоугольной решетке, естественным образом формируя ряды.
>> Может быть так уже и сделано? :)
>> Я не разработчик САПР, а их пользователь. Выше я описывал то,
>> как выглядит процесс с точки зрения разработчика.
>> Как работает сам САПР, какие в него там алгоритмы
>> заложены неизвестно (коммерческая тайна).
Есть такое мнение (andy_p):
«Вообще алгоритмов размещения достаточно много. Насколько мне известно, обычно делают так — размещают грубо ячейки по силовому алгоритму, а затем с помощью какого- либо другого алгоритма убирают получившиеся пересечения. Насчет заметающих кривых — не встречал такого, но, наверное, тоже может иметь место.
Силовой алгоритм — это просто размещение, при котором потенциальная энергия минимальна, если считать, что связь между парами ячеек является пружиной или чем-то типа того с жесткостью, зависящей от количества соединений (ряды при этом не учитываются). А в какой ряд ячейка встанет определяется близостью к этому ряду.»
Я ещё на всякий случай замечу, что пользователь имеет довольно много возможностей повлиять на результаты трассировки, например, вручную проставив минимальные или максимальные необходимые расстояния между отдельными блоками. Поэтому может иметь смысл применение максимально простых алгоритмов, чтобы учёт пожеланий пользователя не приводил к сильному усложнению расчетов.
В случае с кривой Гилберта все выглядит так, как будто дополнение алгоритма всеми разумными практическими ограничениями (не 100% заполнения, запасные части, отсутствие поворотов на 90 градусов и т.д.) в итоге приведет к тому, что решение получится очень сильно вырожденным и не имеющим больших преимуществ над более простыми алгоритмами.
В случае с кривой Гилберта все выглядит так, как будто дополнение алгоритма всеми разумными практическими ограничениями (не 100% заполнения, запасные части, отсутствие поворотов на 90 градусов и т.д.) в итоге приведет к тому, что решение получится очень сильно вырожденным и не имеющим больших преимуществ над более простыми алгоритмами.
«Силовой» алгоритм имеет большое число степеней свободы и его еще надо суметь аккуратно "отжечь". Из-за локальных минимумов делать это надо многократно.
И даже найденное расположение пытаются улучшить перестановками ячеек с целью уменьшить число пересечений, насколько я понял.
В предложенной же конструкции одна степень свободы и глобальный минимум находится перебором всех вариантов. При этом «силовая» функция может быть той же самой. Это не гарантирует оптимальности решения, но это точно будет быстрее.
И даже найденное расположение пытаются улучшить перестановками ячеек с целью уменьшить число пересечений, насколько я понял.
В предложенной же конструкции одна степень свободы и глобальный минимум находится перебором всех вариантов. При этом «силовая» функция может быть той же самой. Это не гарантирует оптимальности решения, но это точно будет быстрее.
Перечитал ещё раз. Хочу добавить, что у вас предпосылка неверная. Вы придумали метод, который позволит «минимизировать общую длину соединений». Этого не требуется.
Главное это, обычно, производительность/скорость, а не общая длина металлизации. Связь между ними есть, но не прямая.
У вас каждое соединение ячеек друг с другом должно удовлетворять заданным временным параметрам: грубо говоря, сигнал должен распространяться за время не более T и максимальный фронт должен быть не более S. В чипе существует огромное количество разных соединений. Какие-то должны обеспечивать минимальные T и S и такие ячейки надо ставить максимально близко друг к другу (иногда даже вручную задавать их месторасположение), а для некоторых предъявляются такие «расслабленные» ограничения, что их можно хоть в разных углах чипа ставить и вести между ними миллиметровые линии металлизации.
Современные САПРы это учитывают. Это timing-driven placement, о котором вам говорили в комментатариях выше.
Главное это, обычно, производительность/скорость, а не общая длина металлизации. Связь между ними есть, но не прямая.
У вас каждое соединение ячеек друг с другом должно удовлетворять заданным временным параметрам: грубо говоря, сигнал должен распространяться за время не более T и максимальный фронт должен быть не более S. В чипе существует огромное количество разных соединений. Какие-то должны обеспечивать минимальные T и S и такие ячейки надо ставить максимально близко друг к другу (иногда даже вручную задавать их месторасположение), а для некоторых предъявляются такие «расслабленные» ограничения, что их можно хоть в разных углах чипа ставить и вести между ними миллиметровые линии металлизации.
Современные САПРы это учитывают. Это timing-driven placement, о котором вам говорили в комментатариях выше.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Расставляем стандартные ячейки (заметки постороннего)