Верификация цифровых схем. Обзор

image


Я постараюсь в общем рассказать о верификации цифровых схем.


Верификация в данной области — это важный процесс, требующий привлечения опытных инженеров. Например, специалист по верификации, работающий над системами с ЦПУ, как правило должен владеть скриптовыми языками и языками командных оболочек (Tcl, bash, Makefile и т.п.), языками программирования (С, С++, ассемблер), HDL/HDVL (SystemVerilog [10, Appendix C — история языка][11], Verilog, VHDL), современными методологиями и framework’ами (UVM).


Доля времени, затраченного на верификацию, доходит до 70-80% от всего времени проекта. Одна из основных причин такого внимания в том, что к микросхеме нельзя выпустить “патч” после того, как ее отдали в производство, можно только выпустить “silicon errata” (это не касается проектов ПЛИС/FPGA).


Под цифровыми схемами я подразумеваю:


  • сложно-функциональные блоки/intellectual properties (СФБ/IP);
  • специализированные заказные микросхемы/application-specific integrated circuit (ASIC);
  • проекты программируемых логических интегральных схем/field-programmable gate array (ПЛИС/FPGA);
  • системы на кристалле/system-on-crystal (СнК/SoC);
  • и т.п.

Актуальные проблемы верификации


О текущем состояние и тенденциях в сфере верификации можно судить по следующим вызовам и проблемам, с которыми она сталкивается [6]:


  • размер объекта верификации (ОВ) постоянно растет. Даже небольшая ИМС типа “микроконтроллер” — это набор из десятков подмодулей, очень часто со сложным функционалом. Большие ИМС — это комплексы, в которых может насчитываться до десятков миллиардов транзисторов, и одна только схема управления электропитанием по сложности может превосходить некоторые процессоры [8];
  • невозможно составить спецификацию на ИМС в начале проекта и в дальнейшем только следовать ей, она постоянно изменяется на протяжении всего процесса разработки (заказчик изменяет требования, технические проблемы или обнаружение более оптимальных решений вынуждают пересматривать подходы и т.д.). Исходя из этого, все процессы должны в динамике воспринимать изменения спецификации и модифицироваться в соответствии с требованиями;
  • часто над верификацией проекта работает несколько удаленных друг от друга команд численность которых может достигать десятков человек;
  • количества отдельных тестов и их типов достигает огромного числа, результаты их надо собирать и анализировать;
  • моделирование даже цифровых систем требует массу машинного времени;
  • полнота установленных для проекта целевых показатели готовности во многом зависит от компетентности и интуиции специалистов по верификации;
  • несмотря на существование показателей охвата проекта тестами (метрик), единственный способ закончить верификацию — это принять решение о ее приостановке, основываясь в основном на следующих заключениях: деньги или время на этап проекта потрачены, необходимо запускать в производство, вроде как достигли покрытия кода в 100%, тестируем уже неделю и ошибок не обнаружили и т.п.

Типы верификации


Верификацию цифровых схем можно разделить на следующие основные типы:


  1. функциональная (functional verification) — название говорит само за себя, вы проверяете правильно ли выполняет свои функции ваша система;
  2. формальная (formal verification) — при такой верификации устанавливается эквивалентность представлений вашей системы на разных стадиях маршрута проектирования или выполнение утверждений, помещенных в исходный код:
    • Equivalence Checking (например, RTL-to-RTL, RTL-to-Gate, Gate-to-Gate);
    • Property Checking (Model Checking) (проверяет свойства(assertions), заданные в коде средствами SVA (например)).
  3. статический анализ кода (static code analysis) — проверка исходного кода по формальным критериям на соблюдения правил использования языка и его конструкций. Очень часто в настроенных правилах проверки идет отсылка на RMM [4]. Программы для такой проверки обычно обозначаются как lint или linter;
  4. физическая верификация — в основном подразумевается DRC, LVS, PERC и пр. проверки, физическое представление системы проверяется на соблюдение технологических норм и соответствия физического и логического представлений и т.д. Состав проверок сильно зависит от технологии. Обычно физическая верификация проводится инженером или командой топологического проектирования.
  5. прототипирование — использование FPGA для функциональной проверки [18].

Функциональная верификация в объеме всех работ наиболее значительна и требует непосредственного участия человека.


Статический анализ кода требуют только первоначальной настройки инструментов, которая соответствует внутренним правилам проектирования, принятым в компании, дальше инструмент занимается тем, что выдает “ценные указания” разработчикам и постоянного присмотра не требует.


Инструменты формальной верификации часто тоже весьма самостоятельны, требует только внимательного анализа отчетов, которые они генерируют. Они также подходят для реверс-инжиниринга, когда вам, по какой-то одному вам известной причине, приходится восстанавливать код из списка цепей.


Примеры инструментов верификации


Примеры инструментов верификации цифровых схем (маршрут digital-on-top):


  • инструменты управления верификацией
    • Mentor Graphics — Questa Verification Management
    • Cadence — vManager
    • Synopsys — Verdi, VC Execution Manager (“ExecMan”)
  • функциональная — как правило это симуляторы
    • Mentor Graphics — ModelSim, QuestaSim
    • Cadence — Incisive, Xcelium
    • Synopsys — VCS
    • свободное ПО независимых разработчиков — симуляторы Verilator, Icarus [5]
  • формальная
    • Mentor Graphics — Formal Pro, Questa Formal Verification
    • Cadence — JasperGold, Conformal LEC, Incisive Formal Verification Platform
    • Synopsys — Formality, VC Formal
  • статический анализ кода
    • Mentor Graphics — Questa AutoCheck
    • Cadence — HAL, JasperGold
    • Synopsys — SpyGlass Lint
  • физическая верификация
    • Mentor Graphics — Calibre
    • Cadence — Pegasus, Physical Verification System,
    • Synopsys — Hercules, IC Validator

Методы функциональной верификации


Функциональная верификация — представляет собой набор тестов, условно позволю себе разбить на три группы (это не догма, это из личного опыта):


  1. Положительные ветки — проверка поведения в штатных ситуациях, регламентируемых спецификацией на устройство или стандартом и т.п. Т.е. проверяем ситуации, когда все идет хорошо.
  2. Отрицательные ветки — проверка отклонений от штатных ситуаций, но в рамках спецификации или стандарта, например — несовпадение контрольной суммы, кол-ва принимаемых данных и т.п. Т.е. когда что-то идет не так, но мы знали, что такое может быть и знаем как в этой ситуации работать.
  3. Нестандартные ситуации — любые случайные ситуации от нарушений протоколов обмена, порядка следования данных, до физических коллизий в интерфейсах, случайных изменений состояний логических элементов и т.п. Т.е. это когда может произойти все, что угодно и надо убедиться, что ОВ выйдет после этого в рабочее состояние.

Первые две стадии поддаются автоматизации с помощью UVC/VIP(Universal Verification Component/Verification IP) и достаточно быстро там можно нарастить объем различных тестов, в том числе — генерируемых автоматически. Третья стадия — это «masterpiece» в верификации, эта стадия требует неординарного подхода и опыта, очень сложно автоматизируется, т.к. большинство ситуаций — это отдельный алгоритм, возможно скрипт для САПР или инструкции для «ручных» проверок.


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


Метрики — это показатели охвата проекта тестами. Они нужны для того, чтобы понять какие еще тесты необходимо разработать для проверки возможных ситуаций и сколько предположительно времени может занять верификация [16].


К сожалению, только один тип метрик оценивается на основании исходного кода проекта, определение критериев для остальных типов — это результат интеллектуального труда.


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


Типы метрик [3]:


  • функциональное покрытие. Показывает на сколько полно проверены функции ОВ. Критерии данного покрытия могут определяться планом тестирования и внедрением специальных конструкций (covergroup [1]) в тестовое окружение и/или ОВ, отслеживающих выполнялась или нет та или иная функция/действие, изменялись ли определенным образом данные и т.п. Информация от конструкций, внедренных в исходный код, может быть автоматически собрана средствами САПР.
  • покрытие кода — изменение состояния конструкций исходного кода в ходе тестов. Собирается автоматически средствами САПР, не требует внесения каких-либо конструкций в исходный код. Например:
    • переключение регистров (Toggle Coverage);
    • активность каждой строки кода (Line Coverage);
    • активность выражений (Statement Coverage), по сути — это Line Coverage, но может отслеживать выражения которые больше, чем одна строка в редакторе;
    • активность участка кода внутри условного оператора или процедуры (Block Coverage), разновидность Statement Coverage;
    • активность всех веток условных операторов таких как if, case, while, repeat, forever, for, loop (Branch Coverage);
    • изменение всех состояний(true, false) составляющих логических выражений (Expression Coverage);
    • состояния конечного автомата (Finite-State Machine Coverage).
  • покрытие утверждений. Утверждения — это специальные языковые конструкции, которые отслеживают различные события и последовательность, и по заданным критериям определяют правомерность их возникновения.

Методы функциональной верификации


Directed Tests Method (DTM)


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


Coverage-Driven Verification, Metric-Driven Verification (CDV, MDV) [17]


Концепция создания тестов, направленная на достижение определенного «тестового покрытия» ОВ. Опираются на метрики, чтобы понять какие тесты необходимо добавить в план верификации, чтобы достигнуть целевых показателей готовности проекта.
Необходимо использовать инструменты анализа покрытия, чтобы посмотреть, что еще добавить в план верификации. По-сути, если начать корректировать план верификации в DTM, опираясь хотя бы на “покрытие кода”, то уже можно считать, что от DTM плавно перешли к CDV.


Constrained Random Verification (CRV)


Верификация подачей случайных воздействий. Это действительно автоматические тесты с генерацией случайных воздействий на ОВ, только их трудно представить без симбиоза с ABV.
Метод очень затратный вначале, т.к. требуется длительное время на подготовку инструментов. После того как начальный этап подготовки пройден, то тестирование может запускаться автоматически, многократно с разными исходными данными. При выявлении несоответствия assertion, команда разработчиков и верификаторов приступает к анализу выявленной ошибки.
В реальном проекте нельзя ограничится только этим методом, т.к. этим методом можно собрать покрытие кода и покрытие утверждений, а они могут ничего не говорить о правильности работы ОВ, т.е. соответствии спецификации. Его необходимо дополнять функциональными тестами.
Для реализации данной методологии требуется:


  1. внедрить “утверждения”(assertion) во всех важных точках исходного кода ОВ и тестового окружения;
  2. разработать генераторы случайных воздействий и сценарии их работы, т.е. воздействия случайны, но имеют ограничения диапазона (все перебрать не успеем), порядок подачи и т.п..

Assertion Based Verification[9] (ABV)


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


Важным вопросом при ABV является как распределить assertions, какие из них лучше поместить в исходные код ОВ, какие нужно иметь в тестовое окружение.


Сразу стоит отметить, что язык Verilog не имеет assertions в своем стандарте (их можно создать с использованием основных конструкций языка, но необходимы директивы для синтезатора, чтобы он не занимался их преобразованием). Аssertions появляются только в стандарте SystemVerilog, а так же они изначально были в стандарте языка VHDL и e.


Предлагаю ознакомиться с рекомендациями специалистов, в том числе Clifford’а Cummings’а [12, статьи про SVA] о распределении работ по их написанию, а также с материалами по ABV на сайте Verification Academy [13].


Список литературы


  1. IEEE Std 1800TM-2012. IEEE Standard for SystemVerilog — Unified Hardware Design, Specification, and Verification Language
  2. Клайв Максфилд. Проектирование на ПЛИС. Архитектура, средства и методы. Курс молодого бойца. ISBN 978-5-94120-147-1 (RUS), ISBN 0-7506-7604-3 (ENG)
  3. Verification Academy. Coverage Cookbook. Про тестовое покрытие
  4. Michael Keating, Pierre Bricaud. Reuse methodology manual for system-on-a-chip designs. Print ISBN 1-4020-7141-8, eBook ISBN 0-306-47640-1
  5. Список лицензируемых и свободно распространяемых САПР
  6. Mentor Graphics. Пример статистики по современному состоянию и сферы верификации
  7. WikiChip. "Википедия" по микросхемам
  8. Wikipedia. Обобщенные данные по количеству транзисторов в ИМС
  9. Harry Foster, Adam Krolnik, David Lacey. Assertion-based design.Print ISBN 1-4020-8027-1, eBook ISBN 1-4020-8028-X
  10. Stuart Sutherland, Simon Davidmann, Peter Flake. SystemVerilog for Design. Print ISBN-10: 0-387-33399-1, eBook ISBN-10: 0-387-36495-1
  11. Chris Spear, Greg Tumbush. SystemVerilog for Verification. Print ISBN: 978-1-4614-0714-0, eBook ISBN: 978-1-4614-0715-7
  12. Sunburst Design. Papers
  13. Verification Academy. ABV course
  14. Doulos. Полезные материалы on-line и справочники
  15. Prakash Rashinkar, Peter Paterson, Leena Singh. System-on-a chip verification. methodology and techniques. Print ISBN: 0-792-37279-4, eBook ISBN: 0-306-46995-2
  16. Verification Academy. Metrics in SoC Verification
  17. Doulos. Coverage-Driven Verification Methodology
  18. Doug Amos, Austin Lesea, Rene Richter. FPGA-Based Prototyping Methodology Manual: Best practices in Design-for-Prototyping (FPMM). Print ISBN: 978-1617300042. Скачать бесплатно с сайта Synopsys

Комментарии 34

    +3
    Интересно было бы почитать, где в России есть компании, которым все это нужно.
      +3

      Описанные в посте технологии используются в российских компаниях Байкал Электроникс, НПО ЭЛВИС, Миландр, КМ211, НТЦ Модуль, НИИСИ, Syntacore, МЦСТ, НИИМА Прогресс, IVA Technologies и других.

        +3

        Ну в общем-то любому дизайн-центру связанному с цифровой разработкой. МЦСТ, Байкал, Элвис, Миландр, Iva tech, Текон и другие.


        Понятное дело используется не всё сразу и не во всех проектах. Но в целом — джентльменский набор.

          0
          По-хорошему, нужно всем, кто хоть как-то применяет «цифру» в проекте. Другой вопрос — какие инструменты применять. И тут уже начинаем балансировать между временем, ресурсами, затратами (стандартный набор как и везде). Цифровая схема хороша тем, что ее функционально можно проверить даже малейшие ее детали, но незначительная ошибка может привести к серьезным финансовым и временным затратам, а порой, к бессмысленности дальнейшего продолжения работ.
            +2
            В России, по разным оценкам, от 40-50 до 150-200 команд, занимающихся дизайном микросхем. И ещё как минимум не меньше команд, работающих с ПЛИС.
            Географически это Зеленоград, Москва, Воронеж, Нижний Новгород, Новосибирск, Питер, Брянск, Томск, Саратов.
              –1
              Интересно, где результат деятельности этих команд, кроме тех, что на слуху?
                +3
                А где результат деятельности 90% айтишных команд, кроме тех, которые Яндекс и Касперский? Кто пиарится сам — про тех слышно обывателю, а кто-то не пиарится, потому что ни для чего не нужно, чтобы было слышно обывателю.
                Я очень много результатов знаю, но я за этим специально слежу. Если вы не следите или, например, не посещаете регулярно отраслевые выставки, то действительно на слуху не очень много всего.
                Недавно мне, например, посчастливилось принять небольшое участие в создании ASIC для медицины, но я не думаю, что кто-то о ней будет много знать, кроме врачей и пациентов — и то, не о самой ASIC, а о приборе на ее основе. Типичная B2B история на всех уровнях, не требующая широкой рекламы ни для чего.
                  0
                  Я даже не про микросхемы, а про приборы, в которых они используются.
                    +2
                    Первое поколение упомянутого в моем предыдущем комментарии прибора, тоже с разработанной в России ASIC, давно и успешно производится серийно и спасает жизни людям.
                    Но не рекламируется для широкой публики — потому что в этом нет надобности. И подобных историй есть какое-то количество.
                  0
                  Есть команды, которые сидят на больших и не очень предприятиях, делают специально под свои нужды. Порой натыкаешься на коллег совершенно случайно, там где и не подозреваешь.
              +3

              Хороший текст для песочницы. Хорошо бы чтобы после обзора шли бы конкретные примеры верификации интерфейсов (шин AXI), типичных блоков (кэшей, сетевого свитча), с объяснением на пальцах как работает рандомизация, covergroups, concurrent assertions, причем так чтобы было не нудно.

                0
                Я для начала хотел сделать немного вводных статей, что бы потом с опорой на них можно было бы объяснять примеры. Про рандомизацию и пр. согласен, полагаю, имеет смыс объяснить «на пальцах» некоторые принципы и дать отсылку на существующие материалы, для «расширения сознания». Правда, они все на английском.
                  0
                  Я думаю, это даже «объяснить на пальцах» уже достаточно большая работа, которая уместится в достаточно большое количество статей. Хотя я очень «За!» такие статьи, иногда их нехватает даже на зарубежных источниках :(
                  0

                  ИМХО, по крайней мере в ПЛИСах, все эти методы верификации надо очень сильно пересматривать. Просто подход к проектированию firmware для ПЛИС за последнее время настолько изменился, что классические методы практически не дают результата.
                  Вот у меня сейчас сидит один, точнее одна верификаторша на проекте, везде пытается просунуть свою UVM и говорит, что без этого ну никак. В итоге самый бесполезный человек.

                    +1

                    В UVM для многих приложений много лишнего, что приводит к тому, что верификатора вместо верификации занимаются обхождением неудобств UVM. Например генерация последовательностей транзакций (sequences, virtual sequences) сделана громоздко и неполно: objections: программирование ради программирования: TLM2 порты не лучше mailbox-ов, автоматизация печати транзакций с помощью field macros — маразм, так как по умолчанию оно печатает нечитаемый лог; установка параметров через громоздкий API не особо лучше, чем серия простых присваиваний итд.


                    Я уже видел несколько компаний, которые внутри делают собственные самопальные библиотеки на SystemVerilog для верификации, и это оказывается проще для обучения работе новых инженеров, чем UVM.

                      0
                      UVM штука хорошая, но неободимо применять обдумано. Там порой куча способов сделать одно и то же. Есть несколько ресурсов, вендров, которые приводят исходные коды, там бывают сильно разные подходы.
                      Беда еще в том, что сам по себе он очень криво документирован, вернее, документация есть, а вот смысл и взаимосвязи понять — это просто превращается в кошмар. По опыту могу сказать, что бывают моменты, когда в нем можно забуксовать по абсолютно ерундовой причине именно в попытках найти взаимосвязи и идею, которая закладывалась в конструкции. Т.е. разбираешься не с проблемой по существу, а сражаешься с инструментом, безумно жалко время при этом.
                      Но с другой стороны, если его использовать, он превращается в некоторый «язык» команды верификации. Т.е. тут надо либо внутри создавать свои библиотеки/инструменты (тут нужен опыт и ресурсы), либо использовать готовое.
                      У себя мы вводим его постепенно (лет 6 уже), осваивая те или иные необходимые конструкции по необходимости и полностью осознавая зачем оно нам, хотя изначально знали практически все его возможности.
                        0
                        Кстати, если совсем мутит от UVM, то можно посмотреть вот эту книгу для начала: Chris Spear, Greg Tumbush. SystemVerilog for Verification, там про методы неплохо написано. UVM только взял это все и обернул в библиотеку (большую такую библиотеку).
                        0
                        А в такой верификации применяют фаззинг?
                        Думается, он может выявить некоторые ситуации (маловероятные, конечно, но на партии в 10 миллиардов устройств и вероятность в одну миллионную в день (попадание частицы в кристалл, например) превращается в десяток тысяч сбоев каждый день (если эти ошибки реально приводят к сбоям).
                          0
                          А что такое фаззинг по существу?
                          При функциональной верификации мы можем исказить любые сигналы. Тактовую частоту «покачать» по нестабильности фазы, частоты и пр. Это устройствам, которые с внешнего мира забирают сигналы в свой частотный домен, может помочь проверить блоки фильтрации и синхронизации.
                          Есть еще способы введения искажений в ОВ, т.е. можно случайным способом исказить состояние в модели и посмотреть как она «выкарабкается» из этого неловкого положения.
                            +1
                            Я имел в виду прежде всего случайные искажения в работе блоков.
                            То есть, условно, если по всем правилам блок должен выдать 0x00 а он всё же (несомненно ошибочно) выдаёт 0x11 — тестируется ли способность других блоков справиться с такой ошибкой и хотя бы выдать софту внятную ошибку (с которой софт сможет совладать), а не зависнуть намертво, и не скорраптиться.
                          0
                          Если имеется ввиду вариация фаз клоков в CDC, как и вообще методы проверки CDC на стрессоустойчивость — во время симуляции, то про такое было бы очень интересно почитать.
                          –1
                          Плохо, что об STA нет ни слова. Вообще временнОй аспект верификации не затронут. А между тем, симуляция нетлиста не дает полной гарантии работы схемы, особенно если в схеме есть CDC, и особенно, если библиотеки статистические. То же касается покрытия тестами — некоторые схемы, такие как большие блоки логики, не покрыть тестами — слишком много комбинаций требуется.
                            0
                            STA специально не упоминал, в маршрут проектирования он должен входит, конечно же. Но он ближе к back-end, с ним специалисты по синтезу и физической имплементации должны обниматься, как и с инструментами анализа ограничений (constraints). Ну, на данный момент, такая моя точка зрения.

                            Большие блоки логики тоже покрываются тестами практически полностью, при наличии времени. В составе системы это трудно сделать, но отдельно блок можно «вытрясти». Все декомпозируется. Сложные системы тоже по частям проверяются.
                              +2
                              Static timing analysis относится и к front-end, и к back-end. На front-end он делается вместе с logic synthesis, на back-end он уточняется после floorplanning, place & route. Писание RTL может и должно делаться параллельно с писанием testbench / verification environment, а писание RTL без периодического синтеза с sta — это непрактично и опасно, так как сильное нарушение тайминга в STA может потребовать пересмотр микроархитектуры.
                                0

                                Я согласен, особенно с тем, что это надо делать на самых ранних стадиях. Я пытался сказать, что STA в чистом виде к верификации я не знаю как приладить, хотя это тоже средство проверки.

                                  0
                                  А между тем, симуляция нетлиста с задержками (задержки получаются с помощью STA) является одной из главных задач верификатора. Полагаю, Вам просто не приходилось проектировать для ASIC
                                    0

                                    Задержки получаются синтезатором. STA — это средство анализа.

                            0
                            Задержки получаются синтезатором, STA — это средство анализа.
                              0
                              Задержки выписываются при участии STA. Сначала пускается rc-экстрактор паразитных задержек в проводах, затем запускается STA с учетом наложеных констрейнтов и настроек тула. И только потом полученные задержки сбрасываются в файл для симуляции. Соответственно, весь пессимизм (и ошибки — констрейнтов, настроек и т.д.), присутствующий в STA, попадает в симуляцию. В виде бонуса так же получаются критические пути, которые необходимо рассмотреть и при необходимости — просимулировать. Таким образом, получаем еще один аспект верификации — результатов STA и констрейнтов. Как выше написал YuriPanchul, часто это приводит к правкам в логической модели, а иногда и к изменениям в архитектуре.
                                0

                                Давайте разведем два понятия. STA — как инструмент анализа (типа Tempus, PrimeTime, TimeCraft) и утилиты и алгоритмы синтезатора, используемые для правильной сборки схемы.
                                Я говорил про STA как про инструмент анализа.

                                  0
                                  В таком случае правильнее было бы говорить о GLS(Gate level simulation) как этапе верификации, а не о STA.

                                  Плюс, imho, в вашем сообщении цифровой и аналоговый маршрут смешался — не совсем понятно как Вы связываете STA+констрейны(цифровой маршрут) и экстракцию паразитов(аналоговый маршрут).
                                    0
                                    STA необходим для проверки временных характеристик получающейся схемы. Если характеристики не вписываются в ТЗ, необходима правка кода/архитектуры. Рассматривайте это как часть флоу (фронтэнд) и/или как верификацию. Симуляция нетлиста подразумевается.

                                    Экстракция паразитов делается в цифровом флоу на каждом этапе, включая синтез. Исключение — синтез с wireload моделями, который перестал быть актуальным для технологий ниже 100нм. Во всех остальных случаях делается экстракция — если не из реальной топлогии металлов, то из их оценки (режимы -topo в синтезаторе, trialroute в p&r туле и т.д.). Экстракция паразитов делается и в аналоговом флоу, тут нет противоречий
                                +1
                                Таким статьям, мне кажется, не хватает своего профильного хаба. Впрочем и статьи на подобную тематику (разработка «цифры») пока довольно редки.

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое