[oratie 0]

>Топографикал это хорошо, но вот как мне ему блоки памяти, сделанные синтезатором, подсунуть?

А точно так же, как подсовываете библиотеку std cell. Есть .db файл, добавьте в link/target_library. Есть Milkyway - добавьте как reference.

 

> и вся разводка, по определению, поверх ячеек. Это не так?

Обычно этого не хватает. Там еще присутствует разводка земли/питания, клоковские деревья. Если std cell обычно использует внутри только первый метал, и разрешает разводку в остальных над собой, то память может использовать и 4 и 5 металлов. Да еще может запретить разводку сигнальных проводов над собой, чтобы избежать наводок (cross talk). Так, что , после синтеза (до размещения) суммарную площадь ячеек нужно умножить на два (это с запасом, потом при размещении, площадь ячеек вырастет, и core utilization будет меньше) - это и будет примерная площадь (core area). Chip area может определятся (как уже заметил SM) не только core area, но и периметром необходимым для размещения IO падов (это если Вы используете pad ring, а не flip chip pads).

 

> Каждая IO-cell должна включать контактную площадку, логику и ESD-защиту

Не всегда так. Если библиотека содержит так называемые staggered pads, то контактные площадки шире чем сам IO cell. В этом случае IO селы ставят впритык, а контактные площадки в шахматном порядке в два ряда. Это позволяет уменьшить периметр чипа. Если у вас обычная либа (inline pads), то приведена, скорее всего, суммарная площадь ячейки+площадки. Вам лучше посмотреть в топологическом редактора на эту площадку или повнимательнее почитать даташит, что это за площадь - ячейки с площадкой или без.

[SM 0]

Топографикал это хорошо, но вот как мне ему блоки памяти, сделанные синтезатором, подсунуть?

Сделанные кем? Синтезатором? Может мемори компилером? Так сделайте тем же компилером FRAM-ы, или LEF, или что он там делает для PAR.

А как можно узнать про то, какая именно разводка предполагается? Я так думал, что ежели технология поддерживает 6 слоев металла - так и вся разводка, по определению, поверх ячеек. Это не так?

Понятия не имею. Читать доку на либу. Смотреть глазами топологию ячеек. Других способов не знаю.

В ките у меня есть библиотека IO cells, каждая ячейка площадью 10000 мкм. Пока не могу понять, включает ли она в себя сам пад (кусок металла для соединения с корпусом).

Может включать, может не включать. читайте, блин, доки на либы. Или гляньте на топологию ячейки. У меня есть одна либа, где буфера отдельно, пады отдельно, и можно их собирать как и в staggered, так и в linear. А другая - только linear, и там все включено. А по хорошему - не надо считать IO-пады в area вообще. Они как не крути займут весь периметр чипа, даже если там не все будет забито падами, придется добивать филлерами. Или наоборот, падов может оказаться столько, что внутри периметра будет куча лишнего места. Ее, площадь этого периметра, проще посчитать на обычном калькуляторе. Или у вас там флипчип?

[starley 0]

Может включать, может не включать. читайте, блин, доки на либы.

Кабы там было написано нормальным английским языком, что включает, - не задавал бы лишних вопросов. Я думал, что спецы по площади смогут определить, включен пад или нет. Размер ячейки 245 на 40 мкм.

Из отсутствия отдельной ячейки для пада следует, что они включены?

Топологию бы посмотрел, но редактора нет, да и пользоваться им пока не умею :smile3046:

 

Или у вас там флипчип?

У нас разгильдяйство организации-исполнителя, которая полгода не может нормально посчитать площадь. :maniac: В результате приходится это за них делать, а это несколько не мой профиль. От этого и вопросов много, потому как результат надо быстрее, а разбираться во всем нужно время. Все же отдельная область знаний и далеко не самая простая.

А вообще мы на флипчип расcчитываем.

Изменено 2 февраля, 2009 пользователем starley

[SM 0]

Топология стандартной ячейки занимает не больше 2-3 слоев металла. Доступно 6. С какого бодуна разводка может идти не поверх ячеек? При чем тут библиотека и доки на нее?

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

Размер ячейки 245 на 40 мкм.

40 мкм... Это что, пад получается примерно 30 мкм сторона? Не маловато ли... Похоже, что не включены. Так как 2*40 получается 80, а это уже ближе к делу в случае staggered расположения. Таким образом два пада будут занимать примерно 325х80. Но может хватит гадать? Не верю, чтобы в доках на либы об этом не было.

Из отсутствия отдельной ячейки для пада следует, что они включены?

Да. Но как-то не сходится с 40 мкм...

[sleep 0]

предположу, что единственно верным ответом о конструкции падов будет просмотр их gds )

вьюверов gds-в достаточно много, некоторые ну очень простые.

плюс всё-таки имхо соотношение сторон абстракта указывает, что bonding pad уже включен...

похоже на 018 микрон как бы...

работал с 240*50 по 018 - это уже были staggered cо включенным bonding pad. 240*70 - inline.

если 013 - то может и без bonding-а. если так - сами bonding pads дорисовываются дизайнером "ручками".

можно создать конфигурацию хоть inline, хоть staggered; понятно, что расставляются они скриптами.

 

насчет доступности трассировки по падам - часто делают кольца внутри падов в нескольких металлах, и выводы питания/земли в сторону core выводят в нескольких доступных металлах.

следовательно, сигнальная трассировка над падами запрещается.

[SM 0]

работал с 240*50 по 018 - это уже были staggered cо включенным bonding pad.

А как это так может быть, стаггеред, и со включенным? Там же бонд-пады в шахматном порядке расставляются, и заранее их нельзя включить в IO-целл, потому как заранее не известно, какое будет расстояние от именно этого экземпляра буфера до пада.

[starley 0]

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

Если я правильно понимаю, то примерную площадь под ИО при линейном расположении надо считать так: (ширина пада + ширина выходного буфера)*периметр. Для staggered - (2*ширина пада + ширина выходного буфера)*периметр. Правильно?

 

 

суммарную площадь ячеек нужно умножить на два

А это не сильно круто? С чего ей в два раза вырасти, не из дерева же синхросигналов? Глобальная разводка земли и питания идет в первом слое металла?

[sleep 0]

А как это так может быть, стаггеред, и со включенным? Там же бонд-пады в шахматном порядке расставляются, и заранее их нельзя включить в IO-целл, потому как заранее не известно, какое будет расстояние от именно этого экземпляра буфера до пада.

очень просто, на каждый io cell есть его 2 варианта: обозначим их условно "S" и "T", то есть "короткий" и "длинный". bonding pads уже включены в габариты, но перекрытие или "двухрядность" получаются видны только при переходе lef-gds. на .lef-представлении просто стоящие плотно друг к другу более длинные и более тонкие по сравнению с inline пады.

при нормально сделанном .lef расставляем их на стороне по очереди: STSTS... получаются staggered io.

[oratie 0]

> (ширина пада + ширина выходного буфера)*периметр. Для staggered - (2*ширина пада + ширина выходного буфера)*периметр.

Это правильно.

 

> С чего ей в два раза вырасти

 

1. разводка земли и питания должна как минимуи идти в двух слоях (вертикальном и горизонтальном). Первый метал практически весь занят std cell. Если у вас длинный ряд из этих ячеек, а подключаете питание только по краям ряда, то будут помехи по питанию. Вдобавок, пин питания памяти памяти, я думаю, не в первом металле, к ним тоже надо подключится широкой шиной. И желательно не одной, а рингом или сеткой. Да и пады земли/питания тоже выдают не в первом металле. Например мы делаем сплошную сетку земли питания (очень частую) в двух верхних металлах (и запрещаем сигнальную трассировки в них), а дальше спускаемся до первого металла через более редкую сетку. Есть специальный тулы, которые помогают оценить, достаточно ли вы сделали шин земли питания (например Astro-Rail).

 

2. Хоть вы и используете DC -topo, реальное размещение (сделанное, например, в Astro) будет отличатся от первоначального. Соответственно, и ячейки будут умощнятся (расти в размерах) и дополнительные буфера будут вставляться. Это из личного опыта.

 

3. Потом, вам, наверняка, нужно будет вставлять специальные ячейки (tap-cell) для подклячения питания к карману (если, конечно, во всех std cell не сделано это).

 

4. А добавлять spare cells вы будете? (это чтобы, потом после изготовления, если выявится ошибка в логике, можно было бы изменением одной маски (перекомутацией пары ячеек) исправить ошибку)

 

5. А после трассировки могут появится проблемы с cross talk (хотя на 0.13 они невелики), следовательно, трассировщик будет раздвигать параллельные трассы, делать shielding или еще что.

 

6. Да мало ли что еще потом придется добавлять. По моему опыту, если проект новый и большой, то core utilization 0.5 после синтеза это нормально. А к детальной трассировке он повысится до 0.7. Я лично не встречал серьёзных дизайнов, которые бы развелись при utilization > 0.8

[SM 0]

Как в астро можно определить размеры этой ячейки?

Открыть FRAM или CEL view ячейки, и в астровском просмотрщике слева внизу есть жирная кнопка "Ruler". Далее интуитивно :)

 

но перекрытие или "двухрядность" получаются видны только при переходе lef-gds. на .lef-представлении просто стоящие плотно друг к другу более длинные и более тонкие по сравнению с inline пады.

Принцип понятен, просто не встречал такого. А в .lib указана площадь по lef/FRAM? Или по gds/CEL? А то как бы topo не начал орать, что одно с другим не сходится...

[starley 0]

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

Тогда получается, что разводка питания не увеличивает требуемую площадь.

 

3. Потом, вам, наверняка, нужно будет вставлять специальные ячейки (tap-cell) для подклячения питания к карману (если, конечно, во всех std cell не сделано это).

Я думал, что во всех нормальных библиотеках это сделано в ячейках.

 

4. А добавлять spare cells вы будете? (это чтобы, потом после изготовления, если выявится ошибка в логике, можно было бы изменением одной маски (перекомутацией пары ячеек) исправить ошибку)

Не будем. Во-первых, у нас еще две итерации, помимо этой, а, во-вторых, наши исполнители топологии не делают, ее буржуи делать будут.

 

5. А после трассировки могут появится проблемы с cross talk (хотя на 0.13 они невелики), следовательно, трассировщик будет раздвигать параллельные трассы, делать shielding или еще что.

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

 

6. Да мало ли что еще потом придется добавлять. По моему опыту, если проект новый и большой, то core utilization 0.5 после синтеза это нормально. А к детальной трассировке он повысится до 0.7. Я лично не встречал серьёзных дизайнов, которые бы развелись при utilization > 0.8

Ну 0.7 это все же не 0.5.

 

Открыть FRAM или CEL view ячейки, и в астровском просмотрщике слева внизу есть жирная кнопка "Ruler". Далее интуитивно :)

Спасибо, попробую.

[SM 0]

Тогда получается, что разводка питания не увеличивает требуемую площадь.

Еще как увеличивает. Не думайте, что если там есть куча слоев, то их всех не забъет трассировщик напрочь и ему их с легкостью хватит.

[starley 0]

Еще как увеличивает. Не думайте, что если там есть куча слоев, то их всех не забъет трассировщик напрочь и ему их с легкостью хватит.

А в процентах?

[SM 0]

А в процентах?

Я вот работаю с 4-мя металлами. Забивает в критических местах на все 100% только в путь, что приходится раздвигать. Вообще это очень сильно от проекта зависит.

[sleep 0]

А в .lib указана площадь по lef/FRAM? Или по gds/CEL? А то как бы topo не начал орать, что одно с другим не сходится...

в .lib на staggered пады площадь стратежно указана 0.000. в .lib и .lef на inline площадь, логично, указана и сходится.