Diploma_All
.pdfМинистерство образования и науки Российской Федерации
МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ ЭЛЕКТРОННОЙ ТЕХНИКИ (ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ)
Факультет ЭКТ Кафедра ПКИМС
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
к дипломному проекту на тему
«Разработка программы построения иерархического представления плоского нетлиста в формате SPICE с возможностью редактирования параметров элементов»
Дипломник |
|
Транченко Д. В. |
||||||||
|
|
|
|
|
|
(подпись) |
|
|||
Руководитель проекта |
|
Булах Д. А. |
||||||||
|
|
|
|
|
|
(подпись) |
|
|
|
|
Консультант |
|
Булах Д. А. |
||||||||
|
|
|
|
|
|
(подпись) |
|
|
|
|
Консультант по |
|
|
|
|
|
|||||
технологической части |
Кривсун Е. В. |
|||||||||
|
|
|
|
|
|
(подпись) |
|
|||
Консультант по |
|
|
|
|
|
|||||
организационно- |
Андрианова Н. А. |
|||||||||
экономической части |
||||||||||
|
|
|
|
|
|
(подпись) |
|
|
|
|
Консультант по |
|
|
|
|
|
|||||
производственной |
|
|
|
|
|
|||||
и экологической |
к.т.н. Рябышенков А. С. |
|||||||||
безопасности |
|
|||||||||
|
|
|
|
|
|
(подпись) |
|
|||
|
|
|
|
|
|
Москва, 2008 г. |
||||
1
Содержание |
|
Введение......................................................................................................................... |
4 |
Глава 1. Постановка задачи визуализации плоского нетлиста.................................. |
7 |
1.1 Проект схемы в современных САПР................................................................. |
8 |
1.2 Задача верификации топологии......................................................................... |
9 |
Глава 2. Построение иерархического представления плоского |
|
нетлиста в формате SPICE.......................................................................................... |
12 |
2.1 Введение............................................................................................................. |
13 |
2.2 Иерархия как ориентированное дерево........................................................... |
15 |
2.2.1 Математическое определение дерева....................................................... |
15 |
2.2.2 Ориентированные и упорядоченные деревья......................................... |
16 |
2.2.3 Представление деревьев в памяти компьютера...................................... |
18 |
2.3 Представление иерархии блоков SPICE-элементов в памяти компьютера. 19 |
|
2.3.1 Представление иерархии блоков во входном файле нетлиста............... |
19 |
2.3.2 Представление иерархии в виде объекта................................................. |
20 |
Выбор инструментальных средств для решения задачи построения |
|
иерархии SPICE-элементов........................................................................... |
20 |
Объект «элемент SPICE»............................................................................... |
21 |
Объект «узел»................................................................................................. |
21 |
Объект «дерево»............................................................................................. |
21 |
Алгоритм построения иерархии................................................................... |
23 |
Алгоритм построения «ствола» дерева........................................................ |
24 |
Алгоритм создания ветви из имен блоков.................................................... |
25 |
2.3.3 Представление иерархии в графическом виде........................................ |
26 |
Паттерн «Model — View — Controller» (MVC)........................................... |
26 |
Реализация принципа MVC в программе построения иерархии............... |
27 |
Геометрическое отображение иерархии блоков. Класс Renderer............... |
28 |
Текстовое представление............................................................................... |
32 |
2.3.4 Редактирование параметров элементов................................................... |
33 |
2.4 Анализ входного файла..................................................................................... |
34 |
2.4.1 Постановка задачи..................................................................................... |
34 |
2.4.2 Теория компиляторов................................................................................ |
34 |
2.4.3 Выбор инструментальных средств для решения |
|
задачи анализа входного файла......................................................................... |
36 |
2.4.4 Лексический анализ................................................................................... |
38 |
2.4.5 Синтаксический анализ............................................................................. |
41 |
2.5 Заключение........................................................................................................ |
45 |
Глава 3. Платформа .NET и генераторы лексических и |
|
синтаксических анализаторов.................................................................................... |
46 |
3.1 Платформа .NET................................................................................................ |
47 |
3.1.1 Каркас .NET Framework............................................................................ |
47 |
3.1.2 Общеязыковая среда выполнения CLR (Common Language Runtime). 49 |
|
3.1.3 Верифицируемый код................................................................................ |
50 |
3.1.4 Разработка приложений на разных языках.............................................. |
51 |
3.1.5 Инструментальные средства разработки................................................. |
52 |
3.2 Генератор лексических |
|
анализаторов GPLEX.............................................................................................. |
55 |
2
3.2.1 Описание..................................................................................................... |
55 |
|
3.2.2 Использование............................................................................................ |
56 |
|
3.2.3 Интерфейсы................................................................................................ |
57 |
|
|
Интерфейс синтаксического анализатора.................................................... |
58 |
|
ВнутреннийAPI лексического анализатора................................................. |
60 |
3.3 |
Генератор синтаксических анализаторов GPPG............................................. |
61 |
3.3.1 Описание..................................................................................................... |
61 |
|
3.3.2 Использование............................................................................................ |
62 |
|
3.3.3 Производимый файл.................................................................................. |
62 |
|
3.3.4 Интерфейсы................................................................................................ |
63 |
|
|
Использование синтаксических анализаторов GPPG с |
|
|
не LEX-подобными лексическими анализаторами..................................... |
64 |
Глава 4. Определение затрат на разработку программного продукта.................... |
66 |
|
4.1 |
Введение............................................................................................................. |
67 |
4.2 |
Теоретическая часть: «Себестоимость программного продукта»................ |
68 |
4.2.1 Понятие себестоимости продукции......................................................... |
68 |
|
4.2.2 Виды затрат при производстве ПО.......................................................... |
71 |
|
4.2.3 Методы калькуляции себестоимости продукции.................................... |
73 |
|
4.2.4 Специфика производства программного обеспечения........................... |
74 |
|
4.2.5 Выбор метода калькуляции затрат........................................................... |
74 |
|
4.3 |
Практическая часть: «Оценка себестоимости программного продукта |
|
методом калькуляции по статьям»......................................................................... |
76 |
|
4.3.1 Калькуляция прямых затрат на материалы.............................................. |
76 |
|
4.3.2 Калькуляция прямых затрат на труд........................................................ |
76 |
|
4.3.3 Калькуляция затрат на содержание и эксплуатацию ЭВМ.................... |
77 |
|
4.3.4 Калькуляция накладных затрат................................................................ |
78 |
|
4.3.5 Калькуляция полной себестоимости разработки программного |
|
|
продукта............................................................................................................... |
79 |
|
4.4 |
Заключение........................................................................................................ |
80 |
Глава 5. Анализ основных вредностей на рабочем месте оператора ЭВМ........... |
81 |
|
5.1 |
Введение............................................................................................................. |
82 |
5.2 |
Анализ опасных и вредных факторов при работе с персональным |
|
компьютером............................................................................................................ |
84 |
|
5.2.1 Электромагнитное излучение................................................................... |
84 |
|
5.2.2 Шумовое воздействие................................................................................ |
86 |
|
5.2.3 Опасность поражения электрическим током.......................................... |
87 |
|
5.2.4 Защита от статического электричества.................................................... |
89 |
|
5.2.5 Освещенность............................................................................................ |
90 |
|
5.2.6 Микроклимат.............................................................................................. |
92 |
|
5.3 |
Инженерный расчет электромагнитного излучения от ЭВМ....................... |
93 |
5.4 |
Нормирование метеорологических условий в машинном зале.................... |
95 |
5.5 |
Требования по пожарной безопасности.......................................................... |
97 |
5.6 |
Экологическая безопасность............................................................................ |
97 |
5.6.1 Проблема утилизации компьютерной техники....................................... |
97 |
|
5.7 |
Заключение........................................................................................................ |
98 |
Список литературы..................................................................................................... |
99 |
|
Приложение............................................................................................................... |
100 |
|
3
0 Введение
4
С ростом уровня современных вычислительных систем растет и уровень задач, которые решаются с их использованием. В современных проектах электронных устройств количество блоков достигает тысяч, а количество активных элементов - сотен миллионов (современный процессор Pentium D 900 содержит 376 · 106 транзисторов). Чтобы производить моделирование подобных схем, размещение и трассировку элементов, требуются колоссальные вычислительные мощности и время.
На этапе верификации топологии возникает задача сравнения двух нетлистов: нетлиста, полученного из схемотехнического представления и нетлиста, полученного в результате экстракции из топологии (называемый еще «плоским» (flat netlist), потому что не содержит вложенных иерархических блоков, в языке SPICE, например, определяемых директивами .SUBCKT или .MACRO). Эта зада-
ча также известна как LVS (Layout versus Schematics).
Время получения второго нетлиста значительно больше времени получения первого, так как требует прохождения этапа синтеза топологии и дальнейшей ее экстракции. Однако перед разработчиками может встать задача просмотра именно плоского нетлиста, полученного из топологии, для того чтобы визуально оценить на сколько схема, восстановленная из топологии, соответствует исходной схеме в схемотехническом представлении, и редактирования параметров элементов, чтобы сразу увидеть результат параметрической оптимизации, передав исправленный нетлист в программу моделирования.
Разработанная в ходе выполнения дипломного проекта программа призвана визуализировать плоский нетлист в формате SPICE в интуитивно понятное иерархическое представление с возможностью редактирования параметров выбранного элемента.
Пояснительная записка структурирована следующим образом.
В первой главе кратко описывается типичный маршрут проектирования ИМС с использованием современной САПР, ставится задача визуализации плоского нетлиста и редактирования параметров выбранных элементов.
Вторая глава (специальный раздел) посвящена процессу разработки программы: описываются форматы входных и выходных данных, приводятся схемы
5
алгоритмов работы программы, раскрываются использованные в разработке проектные решения.
Втехнологическом разделе (глава 3) приводится описание основных программных средств, которые были использованы при реализации программы: платформа .NET и средства лексического и синтаксического анализа — библио-
теки GPLEX и GPPG.
Ворганизационно-экономическом разделе при помощи метода калькуляции по статьям рассчитывается полная себестоимость разработанного программного продукта.
И, наконец, в главе 5 (производственная и экологическая безопасность) даются рекомендации по режиму работы и организации рабочего места оператора ЭВМ.
6
1 Глава 1
Постановка задачи визуализации плоского нетлиста
Дипломант: Транченко Д. В. Консультант: Булах Д. А.
7
1 . 1 Проект схемы в современных САПР
Современные средства проектирования поддерживают проектирование схем с использованием иерархических блоков, что упрощает и ускоряет процесс проектирования. Часто используемый элемент можно поместить в иерархический блок, который затем можно использовать в любом месте проекта, как отдельный элемент без необходимости дублирования его содержания. В итоге схема может быть сколь угодно сложной, но с использованием иерархии блоков, ее представление будет вполне понятным и удобочитаемым.
Графический интерфейс пользователя САПР представляет такую иерархию в виде графических элементов — блоков с входными и выходными контактами с возможностью свободного перемещения по уровням иерархии, вызывая контекстное меню выбранного блока.
Текстовое представление проектируемой схемы, то есть нетлист, также может содержать специальные конструкции для описания иерархии внутри проектов. Рассмотрим такие описания на примере языка SPICE. В этом языке конструкциями, реализующими «подсхемы» (subcircuits), являются конструкции .SUBCKT и .MACRO. Можно объявить сколь угодно много подсхем со сколь угодно глубокой вложенностью других подсхем и элементов. Нетлист, содержащий такие описания, называется иерархическим. Он удобен для чтения и понимания. Пример использования подсхем в нетлисте приведен ниже:
.SUBCKT SUB1 1 2 P4=4
R1 |
1 0 |
P4 |
R2 |
2 0 |
P5 |
X1 |
1 2 |
SUB2 P6=7 |
X2 |
1 2 |
SUB2 |
.ENDS |
|
|
*
.MACRO SUB2 1 2 P6=11
R1 |
1 |
2 |
P6 |
R2 |
2 |
0 |
P2 |
.EOM |
|
|
|
* |
1 |
2 |
SUB1 P4 =6 |
X1 |
|||
X2 |
3 |
4 |
SUB1 P6=15 |
X3 |
3 |
4 |
SUB2 |
* |
|
|
|
8
Несмотря на то, что спецификация SPICE содержит определение базовой подсхемы (.SUBCKT), она не определяет совместимый формат именования узлов. Однако многие современные программы моделирования, такие как StarHspice предоставляют возможность обращения к вложенным элементам через оператор «точка»:
.PRINT I (X1.MP),
где X1 — имя блока, а MP — имя транзистора, содержащегося в этом блоке.
1 . 2 Задач а верификации топологии
На этапе верификации топологии помимо проверки DRC (Design Rules Check) на соответствие синтезированной топологии установленным промышленным ограничениям возникает задача проверки соответствия полученной топологии исходной схеме в схемотехническом представлении. Эта задача также из-
вестна как LVS (Layout versus Schematics).
Решение задачи LVS состоит из трех этапов:
1.Экстракция. На этом этапе соответствующее программное обеспечение (ПО) сопоставляет элементы топологии с полупроводниковыми элементами, взятыми из библиотеки, а также по металлизированным дорожкам определяет, как эти элементы связаны между собой.
2.Преобразование. Во время этапа преобразования информация об экстрагированных компонентах записывается в нетлист. Полученный нетлист не содержит вложенных подсхем — он содержит только конечные схемотехнические элементы: транзисторы, конденсаторы, резисторы; и таким образом не содержит иерархического представления элементов. Поэтому для того, чтобы подчеркнуть его отличие от иерархического нетлиста, такой нетлист получил название «плоский нетлист» (flat netlist).
3.Сравнение. На данном этапе сравниваются плоский нетлист, полученный на этапе преобразования с нетлистом, полученным на этапе схемотехнического проектирования. Если эти два нетлиста совпадают, то говорят, что «схема прошла проверку LVS».
9
Вслучае, если схема не проходит проверку LVS, причинами этого являются обычно следующие ошибки:
●короткие замыкания,
●разрывы цепей,
●несоответствие компонентов,
●отсутствие компонентов,
●неверные параметры компонентов.
Впроцессе анализа и исправления ошибок, найденных при проверке LVS, разработчику может потребоваться просмотр и редактирование плоского нетлиста, полученного из топологии. Иерархическое представление такого нетлиста выявит несоответствие или отсутствие каких-либо компонентов, а возможность редактирования параметров элементов позволит провести параметрическую оптимизацию и сразу увидеть результат моделирования, передав исправленный нетлист в программу моделирования, минуя этап синтеза и экстракции топологии.
Как уже было сказано, плоский нетлист не содержит иерархического представления элементов. Однако программа, производящая экстракцию и преобразование топологии в плоский нетлист, генерирует имена элементов таким образом, что по ним можно узнать их иерархическую принадлежность, заложенную еще на этапе схемотехнического проектирования. Выглядит такое описание следующим образом:
m_I1|I127|I5|I6|MmM1 I1|I127|I5|C I1|I127|X3 vdd vdd
+p l=0.18u w=0.9u ad=0.4725p as=0.440727p pd=2.85u ps=3.6u
m_I1|I127|I5|I1|MmM0 I1|I127|I5|N_2 I1|I127|X3 vdd vdd
+p l=0.18u w=0.9u ad=0.24525p as=0.544828p pd=1.445u
+ps=2.71416u
m_I1|I106|I85|I4|MmM1 I1|I106|I85|N_5 I1|I106|I85|C vdd
+vdd p l=0.18u w=0.9u ad=0.24525p as=0.544828p
+pd=1.445u ps=2.71416u
m_I1|I106|I84|I4|MmM1 I1|I106|I84|N_5 I1|I106|I84|C vdd
+vdd p l=0.18u w=0.9u ad=0.24525p as=0.544828p
+pd=1.445u ps=2.71416u
На примере имени транзистора «m_I1|I127|I5|I6|MmM1» можно проследить, что изначально это был транзистор MmM1, который находился в блоке I6, кото-
10