Pull to refresh
20
Karma
0
Rating
Alex Surkov @Khort

Пользователь

Заметки дилетанта, или Сказ о том, как Scala-разработчик ПЛИС конфигурировал

Я писал про разработку микросхем, это несколько другой уровень нежели ПЛИС (с которым Вы скорее всего и имеете дело). Две большие, огромные разницы.

Это, скажем, как сравнить радиолюбителя и главного инженера: один лабает себе на коленке в свое удовольствие, а другой собаку съел в своем деле и гонит качественный продукт четко по графику. Если посмотреть вакансии крупнейших мировых дизайн центров, то в 99% случаев будут требования верилог/сверилог и для скриптинга тикль+питон/перл. Но не чизел. И совсем другое дело хайповая университетская или любительская среда, где микросхему могут разве что для диссера разработать, а в 99% случаев дальше ПЛИС дело не идет.

Можно ли тренировать чиподелов на 3 нанометра упражнениями с 130 нм? А упражнениями с 20000 нм?

Здесь нет противоречий с тем, что я писал. Действительно PTPX/Voltus на входе берет нетлист, экстракцию, и - файл переключательной активности элементов. А вот уже как делать этот файл переключательной активности - возможны варианты. Я писал о том, что не обязательно симулировать тот же нетлист, что грузится в PTPX, можно обойтись и RTL.

Можно ли тренировать чиподелов на 3 нанометра упражнениями с 130 нм? А упражнениями с 20000 нм?

Для оценки потребления не обязательно симулировать нетлист с задержками, да и вообще симулировать нетлист - достаточно и симуляции RTL. Второй вариант более универсален, но требует переноса полученной переключательной активности RTL на нетлист, а для этого нужно иметь таблицу соответствия имен регистров и цепей, которые меняются во время синтеза. В целом, проблем нет, но нужно писать транслятор (или покупать готовый). Знаю, поскольку раньше занимался дизайном, и приходилось такое делать.

В моем понимании, везде где есть симуляция (того же нетлиста, или для оценки потребления) - это еще фронтенд. Но уже почти на стыке с другими дисциплинами, согласен.

Можно ли тренировать чиподелов на 3 нанометра упражнениями с 130 нм? А упражнениями с 20000 нм?

Раньше симулировать надо было, ведь только так можно протестировать исключения (иначе - отловить баги) в констрейнтах, которые STA не видит. Но, это вы дизайном занимаетесь, не я. Раз сказали не симулируют, значит стали как то по другому проверки делать. Спасибо за ответ.

А что касается STA в P&R, то его гоняют на всех этапах: до и после плейса, после CTS, route, и конечно в конце, в специализированном signoff туле после сделанной полноценой экстракции паразитов из GDS. Это я уже как специалист говорю.

Можно ли тренировать чиподелов на 3 нанометра упражнениями с 130 нм? А упражнениями с 20000 нм?

Юрий, вот вы интересно заголовок написали, про 3нм и 130нм. Да, понятно, что для цифрового дизайнера (RTL) разницы нет, под какой процесс писать код. Или, все таки, есть разница?

Начну издалека. Напомню, что частю работы по разработке эсика является верификация, в т.ч. симуляция пост-лейаут нетлиста. С задержками. Проверить те вещи, которые не видит STA. Далее, задержки (SDF) выписываются с помощью STA-тула. А в чем разница в STA на 3нм и 130нм? Разница - статистический STA на тонких процессах. В котором при расчете задержки пути, задержки складываются квадратически, а не линейно. Может так RTL симулятор считать задержки статистическими формулами? Нет, не может. Да и SDF не поддерживает статистические данные. Так как же быть, как симулируют нетлист с задержками на 3нм? Поделитесь опытом. Раз уже упомянули 3нм

Алгоритмы на кристалле. Глава 1 (продолжение): Быстродействие элементарных схем

  1. Ответ -наверное да, можно так считать, хотя в общем случае это вовсе не обязательно. Суть в другом - анализ на установку и анализ на удержание - разные, не зависимые и не связанные между собой задачи. Но для каждого из этих анализов производится расчет верхней и нижней границы задержек, просто для анализа по установке: путь данных должен быть Макс, и путь клока Мин. А для анализа удержания - путь данных Мин, а путь клока -Макс.

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

Но в целом соглашусь с вами - для фундаментальной публикации по математике, алгоритмы вычисления минимальной и максимальной задержки - минимальный и достаточный инструментарий. А как его использовать - уже вопрос практики. Точнее, можно добавить сюда всю ту физику, которая используется в реальных программах STA, и получится тоже очень даже фундаментальная публикация. Только, это уже будет иметь отношение не столько к математике, сколько к физике, алгоритмам, и численным методам. Я не уверен, что такой труд есть даже на английском. Только отдельные научные публикации, и все. Это та область знаний, на которой зарабатывают огромные деньги, к примеру одна лицензия синтезатора схем из их описания (Design Compiler) стоит $50к в год. Синтезатор работает, как не трудно догадаться, не просто как синтезатор и оптимизатор булевых функций (задача в общем то простая), а с упором на статический временной анализ во время синтеза. Алгоритмы работы подобных инструментов - охраняемая коммерческая тайна. Я так понимаю, в Зеленограде пытались что то свое создать, судя по публикациям. Но чем закончилось, не известно

Алгоритмы на кристалле. Глава 1 (продолжение): Быстродействие элементарных схем

Дело в том, что без этого никак. Задержки в одной лишь комбинационной логике интересны, но не практичны. На практике орграф потому и ацикличен, что один конец отрезка всегда входной клоковый порт схемы, а вторая точка всегда место разыва - пин данных триггерного элемента, у которого внутрення арка ( вершина графа) от пина данных рвется, и на графе заменяется контрольным ребром между этим пином данных и пином клока. Таким образом мы получаем два пути, которые можно сравнить по величине задержек - от клокового порта до пина данных триггера, и от клокового порта до пина клока этого триггера. А дальше эти два пути просто анализируются на предмет нижней и верхней грани разброса задержек (поиск максимума и минимума). Полученный результат сравнивается с контрольным ребром, который суть - характеристика триггера в виде допуска по этой верхней и нижней грани. Если результат удовлетворяет - схема работоспособна. В этом суть статического временного анализа, на пальцах. Как вы понимаете, на фоне изложенного, ваши выкладки выглядят очень не полно. Об этом я и писал

Алгоритмы на кристалле. Глава 1 (продолжение): Быстродействие элементарных схем

Повторюсь:
Поскольку оценка всегда делается для обоих граней "окна" переходных процессов - верхней и нижней. Зачем - это уже надо вводить такие понятия как Setup, Hold, и метастабильность. И контрольные ребра графа, о которых я писал выше.

Алгоритмы на кристалле. Глава 1 (продолжение): Быстродействие элементарных схем

Хорошо. Значит не совсем верно понял, мои извинения.
Еще одно замечание. Важно считать не только кратчайший путь, но и самый длинный. Поскольку оценка всегда делается для обоих граней "окна" переходных процессов - верхней и нижней. Зачем - это уже надо вводить такие понятия как Setup, Hold, и метастабильность. И контрольные ребра графа, о которых я писал выше.

Иии.. и еще одно совсем маленькое замечание. Дело в том, что в индустрии последние лет 10 используют статистические величины задержек. В простейшем случае для модели задержки используется распределение Гаусса - т.е. mean и sigma (для расчетов обычно используют 3 сигма), в некоторых случаях это распределение складывается из двух разных "половинок колокола" (почему - можно написать много текста), в еще более продвинутом случае ось колокола имеет наклон (тут скрыто еще больше текста). Соответственно все формулы расчета задержек превращаются в статистические, обычный "+" уже не работает. Надеюсь, кто нибудь когда нибудь запилит об этом пост .. для будущих инженеров. Что до вашей книги - наверное об этом стоит просто упомянуть вскользь.

Алгоритмы на кристалле. Глава 1 (продолжение): Быстродействие элементарных схем

Ок, тогда наверное мне нужно уточнить. Поясню, что я имел ввиду под "физикой". Задержки ребер графа (банально RC проводов). Зависимость задержки вершин графа (элементов) от полярности сигнала: рассматриваем мы передний или задний фронт. Тип вершины (выхода элемента): инвертирующий или нет. Вот и все. Хотя это малое может сильно повлиять на выводы в ваше публикации. К примеру, кратчайший путь - вовсе не тот где меньше вершин в графе, а тот, где суммарные задержки (с учетом задержек ребер, полярностей сигнала на отрезках, и т.д.) меньше.
Ну и надо пояснить про дополнительные ребра графа, которые я выше обозвал как [setup/hold/recovery/removal check]. По русски их можно назвать контрольными ребрами, поскольку на них фактически сравниваются задержки прохождения графа разными путями (я об этом подробно писал по ссылке выше).

Алгоритмы на кристалле. Глава 1 (продолжение): Быстродействие элементарных схем

Я так понимаю, представленный материал есть не что иное как глубинная основа STA - static timing analysis. Проблема в том, что даже для основ изложено слишком математизированно. Конечно, если абстрагироваться от физики проводников и полупроводников, то выглядит вполне. Но вот если рассматривать вопрос более практично, то у DAG (directed acyclic graph или по русски направленный ацикличный орграф) появляются дополнительные ребра в виде setup/hold/recovery/removal check, прохождение по графу учитывает полярность сигнала и возможность его инверсии при прохождении вершин .. и т.д. - куча усложнений, притягивающих всю изложенную математику к практике. Материала на русском по этой тематике действительно мало. Лет 10 назад было много научных публикаций и даже диссеры в Зеленограде ... но до написания софта так дело и не дошло. Я в свое время учил это все (практическую часть STA, т.к. нужно было для работы) по скачанным лекциям MIT. И даже сделал небольшой пост здесь https://habr.com/ru/post/273849/ Собственно, именно по прикладной STA очень и очень не хватает публикаций, а в идеале учебника на русском. На уровне лекций MIT и даже глубже - языком математики, как вы и запостили. Для будущих инженеров, если страна все же сможет выбраться из под санкций.

Разглядывая JTAG: что внутри?

Загуглите строку "BSDL" boundary scan description language book Получите первой же ссылкой книгу 2003 года. Тогда, 20 лет назад, это было еще актуально

https://link.springer.com/chapter/10.1007/978-1-4615-0367-5_2

Если нужны айпи, добро пожаловать в мир Синопсиса. У них эти ядра лежат уже лет 15 как минимум в каждом дистрибутиве DC. С описанием, все разжевано, все что есть в вашей статье и еще сверху раз в 10 больше. Синтезатор DC автоматически (по подготовленному скрипту) вставит Tap контроллер в ваш код, соединит все IO цепочками boundary scan и выпишет получившийся BSDL. А до кучи сгенерит тестбенч, который дергает интерфейс, читает и пишет, да еще и проверяет. Лет 15 это все там есть как минимум, отлажено настолько что никто уже давно в этот код и не лезет внутрь. Нет, можно конечно и самому все написать, но я бы клеил шилдик "РЕТРО" к такому материалу.

Разглядывая JTAG: что внутри?

Как я уже писал на электрониксе - стандарту JTAG почти 40 лет, его жевали-разжевали уже все кто только мог. RTL на него весь давно написан, BSDL много кем разжеван, даже книги есть. Хотя картинки у вас конечно красивые, респект.

Дам совет. Если хотите сбацать пиар-бомбу в стиле Панчула, вида: как проектируются супер-современные микропроцессоры, то есть очень интересный потомок житага - стандарт ieee 1500. Это уже не про граничное сканирование, а про сканирование логики. И не просто контроллер, а целая архитектура, на порядок более сложная и развитая. Но в целом, это развитие житага. Так вот, без этого (ieee 1500) стандарта действительно ни один современный SoC не обходится, а между тем в РФ это знает (и использует) очень мало кто. Такая статья была бы интересна и профессионалам, а не только начинающим.

Алгоритмы на кристалле (анонс книги)

Клюнул на название, и честно говоря слегка "прифигел". Потому что 20 лет занимаюсь пректированием чипов, но после первого прочтения "вскользь" не понял вообще ничего. После второго, подробного прочтения, уже понял, что это алгоритмика, никаких кристаллов здесь нет и в помине, но материал вполне попадает под классификацию чипостроения в качестве логического дизайна. Причем дизайна весьма специфического, поскольку, как я понимаю, для имплементации рассматриваемых алгоритмов предлагается не использование процессора с ограниченным числом инструкций, а имплементация "в лоб" путем построения автомата (поправьте, если не прав). И вот здесь я оказался в тупике, поскольку сходу не смог придумать, для чего это может быть нужно. Т.е. автору я бы посоветовал включить в книгу и практические примеры, где эти алгоритмы могут быть использованы.

Еще небольшой комментарий по вводной части. В логическом дизайне время различают на физическое и логическое. Логическое время измеряется в шагах алгоритма, и может течь как с той же скоростью, что и физическое время (синхронная работа от внешних "часов"), так и без привязки к физическому времени (асинхронная работа). Соотвественно, автомат может проектироваться как для синхронной работы по шагам state <= next_state (Мур, Мили), так и с использованием параллельных процессов (модель Хаффмана). Это более широкая классификация, чем просто "дискретное время". Полагаю, автор предлагает проектирование именно синхронных автоматов.

Ни на что не претендую, просто высказал свое мнение человека - не из целевой аудиотрии, т.е. случайно заглянувшего.

Будущее российской микроэлектроники

Как только вы обеспечиваете нормальную себестоимость и рыночные цены, вы можете быть востребованы. У Байкал Электроникс гораздо больше шансов, чем у МЦСТ в силу того, что они совместимы с огромным количеством доступного на рынке софта.

Аргумент интересный и правильный, но вывод странный. Под совместимостью понимается преимущество использования архитектуры АРМ, полагаю. Но вот вопрос в том, а как Байкал будет покупать ядра АРМ следующих поколений (в условиях санкций). На мой взгляд, у АРМ в РФ нет будущего, надо искать другие ниши/архитектуры.

Асинхронная обработка данных (асинхронные вычисления). Анализ поведения

По x-talk/noise и защелкивание асинхронных схем напишу чуть подробнее.

Любая асинхронная схема так или иначе содержит RS защелки: в явном виде, либо в виде С-элемента, либо в составе NCL элементов. RS защелка это бистабильный триггер, для переключения которого нужен импульс с некоторой минимальной энергией. Для простоты будем считать что амплитуда сигнала фиксирована, и тогда вместо энергии можно говорить просто о длительности импульса, а однократное переключение будем считать импульсом с бесконечной энергией/длительностью. Так вот, если длительность импульса слишком мала, то переключения не произойдет, а если длительность чуть выше, но все равно недостаточна, то получим бистабильное состояние, выражающееся биениями/генерацией на выходе. У меня есть хорошая статья, поясняющая этот эффект. В нашем контексте, импульс это наведенное паразитное переключение.

А теперь представьте, что в Вашей NCL-подобной схеме какой то элемент сработал неверно за счет наведенного импульса. Сработал, и защелкнул неверное состояние. Вот об этой проблеме я и писал выше. Есть еще проблема защелкивания управления, но если его проектировать как и в синхронных схемах, т.е. с экранированием, то проблем быть не должно. В любом случае, нужны исследования.

Асинхронная обработка данных (асинхронные вычисления). Анализ поведения

Согласен со всем, и в частности с недостатком классического dual rail в виде орфанов и повсеместного нарушения DI. Но тут важно понимать, чего мы хотим добиться, и какой ценой. Поясню:

Наиболее серьезный недостаток асинхронных схем, это защелкивание (когда схема просто встает). Причем на практике стоит опасаться не эффектов вида SEU в где то в транзисторах (хотя и это случается тоже), а куда более распостраненного эффекта X-talk/ noise, который как Вы верно написали, в синхронных схемах маскируется клоком, а вот асинхронную схему просто убьет. Причем современные тулы проектирования топологии кристалла помогают снизить этот эффект до приемлемого (для синхронных схем) уровня, но полностью от этого избавиться может и не получится (для синхронных схем это не требуется). И я подозреваю, что данный аспект проектирования асинхронных схем пока вообще никто не изучал. Были пара американских патентов с троированием, и схемой watchdog, которая при срабатывании делала сброс, но .. это какие то убогие костыли, а не системное решение проблемы.

Получается, что на фоне борьбы с защелкиванием, проблеммы с чистотой DI смотрятся уже более чем бледно. И возникает вопрос - а может и вовсе не делать индикацию в логике? Ведь избавившись от индикации (в логике, но не в регистрах) кроме очевидного бенефита в виде скорости/площади/потребления мы получаем еще хоть и небольшую, но защиту от x-talk/noise - случись это где то в середине комбинационной схемы, отголоски такого сбоя могут и не докатиться до выходов. А могут и докатиться, тут как повезет. Скажем, если электромагнитный импульс был наведен снаружи, а не изнутри схемы, то ничего уже не спасет от защелкивания.

Итого, все зависит от задач и имплементации. Но если расставлять приоритеты, то может оказаться, что DI в комбинационной логике не нужно и даже вредно. Причем проблема x-talk/noise - электрическая, т.е. можно сменить CMOS на что то еще, но провода то останутся. Нужны исследования, не хватает практики. По борьбе с защелкиванием в асинхронных схемах практически ничего нет.

Асинхронная обработка данных (асинхронные вычисления). Анализ поведения

У NCL реализации комбинационных схем есть два серьезных недостатка:

Первое - в NCL каждый логический элемент ожидает окончание переходных процессов(ПП). Таким образом вычисление функции и ожидание окончания ПП происходит последовательно. В классическом же dual-rail подходе индикация окончания ПП производится параллельно с вычислением функции, а значит работает быстрее.

Воторое - NCL это проприетарная (!!!) библиотека элементов. Практически в каждом элементе сожержится защелка (С-элемент) для хранения состояния. И если сравнить реализации на NCL и классический dual rail с параллельной схемой индикации ПП, то во втором случае общее число таких защелок получится меньше, т.к. они используются более еффективно. По крайней мере, так получалось у меня в экспериментах, когда я занимался данной тематикой.

Итого, причины не использовать NCL более чем весомые. Да и сам метод dual rail (перекрестная реализация по Варшавскому) мне кажется сильно проще, особенно тем что можно использовать коммерческие синтезаторы синхронных схем DC / Genus. Т.е. приведенный в статье новый (?) метод синтеза - хорошо, но польза от него сомнительна.

В дополнение, и это уже много раз обсуждалось, в том числе и здесь, непонятно где вообще имеет смысл использовать dual rail кодирование для реализации асинхронных комбинационных схем. Не асинхронных схем вообще, а именно комбинационных, т.е. где требуются вычисления. Потому что автоматы (FSM) прекрасно синтезируются и без dual rail.

Новости импортозамещения в пересечении тактового домена

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

Кстати, по явлению метастабильности плохо написано, мне кажется, автор не до конца понимает материал. В часности, в западных лекциях обязательно рассказывается о MTBF, и чем специальные селлы-синхронизаторы отличаются от просто цепочки из защелок или флопов.

Темное искусство функциональной верификации цифровых микросхем

Есть еще китайские фабы. К примеру Ядро заявляло чип по тех. процессу, доступному на нескольких фабах, включая SMIC. Я не знаю, что будет с лицензиями на тулы, но китайцы врят ли запретят у них выпускаться. А может, и с лицензиями помогут. Мне кажется, тут есть еще место для маневра.

Information

Rating
Does not participate
Location
Россия
Registered
Activity