Вы неправильно помните. Главный герой, получив образование врача, подался в солдаты удачи и большую часть своей жизни провел на войне. Врачом он стал за несколько лет до начала событий, описанных в книге.
В результате сохранятся все прелести существующей технологии и основные преимущества предложенного подхода. В частности скорость.
Может быть так уже и сделано? :)
Я не разработчик САПР, а их пользователь. Выше я описывал то, как выглядит процесс с точки зрения разработчика. Как работает сам САПР, какие в него там алгоритмы заложены неизвестно (коммерческая тайна).
У вас почему-то сложилось впечатление, что плэйсмент по кривой Гильберта требует бОльших вычислительных затрат, чем нынешняя технология.
Если крутить ячейки в разные стороны, не пользоваться заранее заданным допустимым местом расположения ячеек (рядами), разводить первый металл, то так и будет.
Плюс, если для применения такого метода, требуются нестандартные элементы, как то квадратные ячейки, ячейки разной ориентации и т.п., то это не просто дольше, но и гораздо дороже. Типовая библиотека состоит из порядка 300-500 элементов. Бывают больше. В проекте используются от 1 и до нескольких десятков библиотек.
Разработка библиотеки достаточно трудоёмкая задача, сложность и время на её решение растут с увеличением количества элементов примерно линейно.
Перечитал ещё раз. Хочу добавить, что у вас предпосылка неверная. Вы придумали метод, который позволит «минимизировать общую длину соединений». Этого не требуется.
Главное это, обычно, производительность/скорость, а не общая длина металлизации. Связь между ними есть, но не прямая.
У вас каждое соединение ячеек друг с другом должно удовлетворять заданным временным параметрам: грубо говоря, сигнал должен распространяться за время не более T и максимальный фронт должен быть не более S. В чипе существует огромное количество разных соединений. Какие-то должны обеспечивать минимальные T и S и такие ячейки надо ставить максимально близко друг к другу (иногда даже вручную задавать их месторасположение), а для некоторых предъявляются такие «расслабленные» ограничения, что их можно хоть в разных углах чипа ставить и вести между ними миллиметровые линии металлизации.
Современные САПРы это учитывают. Это 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%, поэтому можно добавить необходимой логики и поменять металлическую разводку.
Если фотошаблоны уже изготовлены, но вы заранее заложили «запчасти» в виде рассыпухи логических вентилей, то вы можете обойтись переделыванием нескольких фотошаблонов слоёв металлизации: просто по-другому связать то, что у вас было заложен в чипе.
В вашем подходе такое можно предусмотреть? И если такое предусмотреть, то как это повлияет не его эффективность?
Вы неправильно помните. Главный герой, получив образование врача, подался в солдаты удачи и большую часть своей жизни провел на войне. Врачом он стал за несколько лет до начала событий, описанных в книге.
Я не разработчик САПР, а их пользователь. Выше я описывал то, как выглядит процесс с точки зрения разработчика. Как работает сам САПР, какие в него там алгоритмы заложены неизвестно (коммерческая тайна).
Если крутить ячейки в разные стороны, не пользоваться заранее заданным допустимым местом расположения ячеек (рядами), разводить первый металл, то так и будет.
Плюс, если для применения такого метода, требуются нестандартные элементы, как то квадратные ячейки, ячейки разной ориентации и т.п., то это не просто дольше, но и гораздо дороже. Типовая библиотека состоит из порядка 300-500 элементов. Бывают больше. В проекте используются от 1 и до нескольких десятков библиотек.
Разработка библиотеки достаточно трудоёмкая задача, сложность и время на её решение растут с увеличением количества элементов примерно линейно.
Согласен с вами.
Главное это, обычно, производительность/скорость, а не общая длина металлизации. Связь между ними есть, но не прямая.
У вас каждое соединение ячеек друг с другом должно удовлетворять заданным временным параметрам: грубо говоря, сигнал должен распространяться за время не более T и максимальный фронт должен быть не более S. В чипе существует огромное количество разных соединений. Какие-то должны обеспечивать минимальные T и S и такие ячейки надо ставить максимально близко друг к другу (иногда даже вручную задавать их месторасположение), а для некоторых предъявляются такие «расслабленные» ограничения, что их можно хоть в разных углах чипа ставить и вести между ними миллиметровые линии металлизации.
Современные САПРы это учитывают. Это 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%, поэтому можно добавить необходимой логики и поменять металлическую разводку.
Если фотошаблоны уже изготовлены, но вы заранее заложили «запчасти» в виде рассыпухи логических вентилей, то вы можете обойтись переделыванием нескольких фотошаблонов слоёв металлизации: просто по-другому связать то, что у вас было заложен в чипе.
В вашем подходе такое можно предусмотреть? И если такое предусмотреть, то как это повлияет не его эффективность?