Универзитет “Св.

Кирил и Методи” - Скопје

Факултет за електротехника и информациски технологии – Скопје

Процесни компјутери

Семинарска работа

Внатрешност на OpenSPARC – втор дел

Ментор : Изработил :

Проф. Д-р Аристотел Тентов Тримчевски Игор инд.446/2004

Скопје, Јуни 2017

Contents

8. ОПЕРАТИВНИ СИСТЕМИ ЗА OPENSPARC T1....................................................................................5

8.1. Виртуелизација.............................................................................................................................5
8.2. sun4v архитектура.........................................................................................................................6
8.3. Додатоци на SPARC процесорот...................................................................................................6
8.4. Портирање на оперативни системи............................................................................................8
9. Tools for Developers..........................................................................................................................8
9.1. Компајлирачки код.......................................................................................................................8
9.1.1. Компајлирање апликации со Sun Studio..............................................................................9
9.1.2. Компајлирање аплиакции со GCC за SPARC системи.........................................................11
9.1.3. Подобрување на брзината со профилна повратна информација....................................13
9.1.4. Вградување оптимизација низ фајл....................................................................................15
9.1.5. Избор на големина на TLB страница...................................................................................16
9.2. Испитување на извршувањето на програмот...........................................................................17
9.2.1. Профилирање со анализатор на брзината.........................................................................17
9.2.2. Собирање броења на инструкции со BIT............................................................................23
9.2.3. Проценка на квалитетот на податоците од тренингот......................................................28
9.2.4. Профилирање со SPOT.........................................................................................................32
9.2.5. Дебагирање со dbx...............................................................................................................35
9.2.6. Употреба на Discover за лоцирање на грешки во меморискиот пристап........................38
9.3 Пресметување пропусност..........................................................................................................39
9.3.1. Мерење на искористеност на процесорот.........................................................................40
9.3.2. Употреба на бројачи на брзина за пресметка на употребата на инструкцискиот буџет и
буџетот за чекање..........................................................................................................................44
9.3.3. Собирање на податоци за броење инструкации...............................................................48
9.3.4. Стратегии за паралелизам...................................................................................................48
9.3.5. Паралализам на апликации со POSIX канали.....................................................................50
9.3.6. Паралелизам на апликации со OpenMP.............................................................................51
9.3.7. Употреба на автопаралелизам за добивање на паралелни апликации..........................54
9.3.8. Детекција на податочни трки со анализатор на канали....................................................55
9.3.9. Избегнување на податочни трки.........................................................................................58

2
 9.3.10. Преглед на микропаралелизација....................................................................................63
9.3.11. Програмирање за пропусност...........................................................................................67
10. Симулација, верификација и подигнување на системот...........................................................68
10.1. Модел на SPARC архитектура...................................................................................................69
10.1.1. SPARC CPU модел...............................................................................................................71
10.1.2. VCPU интерфејс..................................................................................................................71
10.1.2.1. Контролен интерфејс......................................................................................................72
10.1.2.2. Системски интерфејс.......................................................................................................73
10.1.2.3. Интерфејс за следење.....................................................................................................73
10.1.3. ММI.....................................................................................................................................74
10.1.3.1. SAM конфигурациски фајл..............................................................................................75
10.1.3.2. Вчитување и (вадење) бришење на модул...................................................................75
10.1.3.3. Подигнување на модул...................................................................................................76
10.2. Системски конфигурациски фајл..............................................................................................77
10.2.1. Формат на sysconf наредбата............................................................................................77
10.2.2. Примери.............................................................................................................................79
10.2.3. Симулирано време во SAM...............................................................................................80
10.3. SAM Huron Sim архитектура.....................................................................................................82
10.3.1. Пример за конфигурациски фајл за T2 Huron на SAM...................................................83
10.3.2. Модул за сериски уред......................................................................................................86
10.3.4. PIU модул...........................................................................................................................90
10.3.5. IORAM модул....................................................................................................................92
10.3.6. Модул за време од денот...................................................................................................94
10.3.7. PCI-E Bus модул.................................................................................................................95
10.3.8. PCIE-PCI Bridge модул......................................................................................................97
10.3.9. PCIE-PCIE Bridge модул...................................................................................................99
10.3.10. Сериски прикачен SCSI модул.....................................................................................101
10.3.11 LLFS модул.......................................................................................................................103
10.5. Дебагирање со SAM................................................................................................................106
10.5.1. Пристап до симулирани состојби...................................................................................108
10.5.2. Информација за симболи................................................................................................110
10.5.3. Точки на прекин...............................................................................................................112

3
 10.5.4. Следење на дебагирање.................................................................................................113
10.5.5. Сонди................................................................................................................................114
10.6. Симулација со точни циклуси................................................................................................115
10.6.1. Пристап со следење.........................................................................................................115
10.6.2. Пристап базиран на извршување...................................................................................116
10.6.3. Пристап со подмодули....................................................................................................117
10.6.4. Заклучок............................................................................................................................117
10.7. Верификација со косимулација.............................................................................................117
10.7.1. RTL косимулација.............................................................................................................118
10.7.1.1. TLB-Sync модел............................................................................................................120
10.7.1.2. LdSt-Sync модел............................................................................................................122
10.7.1.3. Follow-Me модел...........................................................................................................125
10.7.2. RTL-SAM косимулација....................................................................................................126

4
8. ОПЕРАТИВНИ СИСТЕМИ ЗА OPENSPARC T1
Со зајакнувањето на евтините хардверски системи, употребата на хардверскиот
систем стана проблем кај некои апликации. Виртуелизациската технологија дозволува
консолидација на апликации кои работат на повеќе неискористени хардверски системи
во еден хардверски систем. Повеќето хардверски системи со се консолидирани треба
да работат со различни верзии на ист оперативен систем или на различни оперативни
системи. Виртуелизациската технологија го оддвојува оперативниот систем од
хардверскиот систем и дозволува повеќе OS околини (Solaris, Linux, Windows, etc.) да
работат на еден хардверски систем.
Оваа точка дава детали за виртуелизацијата на OpenSPARC T1 OS преку
следните потточки:
• Виртуелизација
• sun4v архитектура
• Додатоци на SPARC процесорот
• Портирање на оперативни системи

8.1. Виртуелизација

Танок слој на софтвер кој работи на хардверскиот систем претставува

виртуелен систем за секој гостински OS кој работи на хардверскиот систем домаќин.
Софтверот кој нуди поглед на виртуелен систем на гостинскиот OS се нарекува
Hypervisor. Виртуелниот систем е дефиниран од хардверски регистри и софтверски
API за да пристапи до услуги понудени од хипервизорот. Хипервизорот користи
хардверска виртуелизација за да овозможи заштита помеѓу виртуелните системи.
Хардверските ресурси во системот како што се меморија, CPU, и I/O се поделени и
алоцирани до виртуелните системи.

5
8.2. sun4v архитектура

OpenSPARC T1 е првиот SPARC процесор кој имплементира хардверски

додатоци за поддршка на хипервизор. Виртуелниот системски модел прикажан на
гостинскиот OS се нарекува sun4v архитектура. Хардверските ресурси на виртуелниот
систем се одредени со податочна структура наречена машински опис.

8.3. Додатоци на SPARC процесорот

OpenSPARC, покрај привилегиран режим и кориснички режим,

поддржува хиперпривилегиран режим. Само софтверот кој работи во
хипепривилегиран режим може да пристапи до регистри кои управуваат со харверски
ресурси како меморија, CPU, и I/O уреди. Hypervisor софтверот работи во
хиперпривилегиран режим. OS работи во привилегиран режим и управува со
хардверски ресурси во својот виртуелен систем со изведување на Hypervisor API
повици. OS не може директно да управува со хардверските ресурси заобиколувајќи го
хипевизорот.
OpenSPARC има проширена инструкција за Тсс стапица за да овозможи
броеви на софтверска стапица од 8016 па нагоре. Слично на процесите во кориснички
режим кои поставуваат стапица на OS за барање на OS услуги, OS која работи во
привилегиран режим праќа стапица во хипервизорот за да направи Hypervisor API
повици користејќи извршување на инструкција за Тсс стапица. Само софтверот кој
работи во привилегиран режим може да изврши нова инструкција на Тсс стапица.
Процесите кои работат највисоко на OS не може да направат стапица во хипервизорот
од кориснички режим.
Секој виртуелен систем е одреден со вредност за одредување на партиција
(PID). Секој CPU со системот има 30битен регистер за партициски идентификатор и
хипервизорот го иницијализира овој регисрат на CPU со PID на виртуелен систем кој
припаѓа на тој CPU. Притоа, најмногу 8 виртуелни системи може да бидат поддржани.

6
 OpenSPARC, покрај поддршката за виртуелни адреси (VA) и физички
адреси (PA), поддржува и реални адреси (RA). MMU поддржува RA-во-RA
поместување покрај VA-to-PA поместувае. MMU не поддржува VA-to-RA хардверски
поместување.
Физичката меморија во виртуелниот систем е опишана со реална адреса.
Гостинскиот OS пристапува до меморијата или директно со реални адреси или преку
виртуелни адреси мапрани за реални адреси. Кога гостинскиот OS бара од
хипервизорот да постави VA-to-RA MMU мапирање (преку Hypervisor API повик ),
хипервизорот ја преведува RA во физичка адреса на меморијата алоцирана за
виртуелниот систем. Потоа хипервизорот поставува VA-to-PA MMU мапирање. MMU
чува PID на виртуелниот систем во TLB влез заедно со VA, PA и други информации.
Овој TLB влез не е придружен за виртуелен систем кој го внесил мапирањето. Кога
софтверот кој работи на виртуелен систем прави мемориски операции, MMU
поместувањата се совпаѓаат само на оние TLB влезови кои имаат ист PID како и PID
зачуван во регистерот за партициски идентификатор на CPU. Притоа, виртуелен
систем не може да пристапи до ресурси (меморија, мемориски мапирани I/O регистри
итн) мапирани од TLB влезови на друг виртуелен систем. Кога виртуелен систем е
активен, еден од CPUата алоциран на виртуелниот систем е препознаен како CPU за
подигнување и започнува со покревање на гостинскиот OS.
Најверојатно гостинскиот OS го чита описот на машината на својот
виртуелен систем и почнува друг CPU во виртуелниот систем. Гостинскиот OS има
барање за хипервизор преку Hypervisor API повици за стартување на CPU алоциран за
неговиот виртуелен систем. Пред CPU да започне со софтверот за извршување во
виртуелниот систем, хипервизорот иницијализира PID регистер на CPU до PID на
виртуелниот систем. Hypervisor API исто така поддржува повик за испраќање на
прекин од еден CPU до друг во рамки на виртуелниот систем.
OS може да пристапи до I/O регистри преку барање на хипервизор за сетирање
на MMU мапирање од виртуелна адреса на гостински OS на физичка адреса на I/O
уред. Двигател на уред запишан на DDI/DDK интерфејс не треба да се менува за да
работи на OpenSPARC систем.

7
8.4. Портирање на оперативни системи

Портирањето на OS кој веќе работи на не-sun4v SPARC системи бара

промени на софтверот на ниско ниво кој ја чита хардверската системска
конфигурација, пристапува до MMU регистри за подесување на VA-to-PA поместувања
и овозможува и оневозможува CPUa. Моментално, Solaris, OpenSolaris, Linux, и
FreeBSD оперативните системи се портирани на OpenSPARC системите.

9. Tools for Developers

Ова подглавје прикажува преглед на некои од алатките кои се достапни за развој на
апликации на SPARC платформи. Подглавјето открива како да се користат овие алатки
за да се нагоди брзината и да се дебагираат апликации. Ова подглавје завршува со
дискусија за тоа како CMT го менува работењето на девелоперите.
Овие идеи се содржани со следните подточки:
• Компајлирачки код
• Испитување на извршување на програм
• Пропустно пресметување

9.1. Компајлирачки код

Во овој дел ќе научиме за следното:

• Компајлирање на апликации со Sun Studio
• Компајлирање на апликации со GCC за SPARC системи
• Подобрување на брзина со Profile Feedback
• Порамнување за отпимизиација низ фајл
• Избор на големина за ТLB страница

8
9.1.1. Компајлирање апликации со Sun Studio

Пектот Sun Studio е бесплатен за преземање и вклучува компајлери за C,

C++, и Fortran. Исто така вклучува и дебагер и анализатор на брзината, како и различни
библиотеки (како што се оптимизирани математички модели).
Sun Studio компајлерот поддржува широк опсег на карактеристики и
оптимизација. Во овој текст се фокусираме на мало множество на најчесто користени
опции. Постојат три основни сценарија за програмерите: компајлирање на апликација
за максимално дебагирање, компајлирање на апликација со мала оптимизација и
компајлирање на апликација со агресивна оптимизација. Знаменцата ги претставуваат
овие три опции како што е прикажано на табела 9-1.

ТАБЕЛА 9-1 Знаменца на компајлер за трите сценарија

Прва работа која ќе ја разгледаме се знаменцата кои овозможуваат генерирање

на информација за дебагирање. Информацијата за дебагирање се користи и кога се
дебагира апликацијата и кога се профилира истата. Информацијата за дебагирање
овозможува алатките да додадат реално време на индивидуалните линии на изборниот
код.
Се препорачува информацијата за дебагирање секогаш да се генерира.
Знаменцето кое условува компајлерот да генерира информација за дебагирање е –g.
Ова знаменце дава само мала разлика во генерираниот код, освен во две ситуации. За
код компајлиран со –g и без знаменце за оптимизација, компајлерот ќе направи код кој
има максимална количина на информации за дебагирање; ова ќе оневозможи некои
оптимизации па така резултантниот код е почист. Друга ситуација каде –g може да
доведе до значителна разлика на генерираниот код е за С++ апликации. За изворни

9
фајлови во С++, -g знаменцето ќе оневозможи функциско порамнување. За С++
кодови, се препорачува да се користи –g0 наместо –g; ова знаменце генерира
информација за дебагирање, но исто така овозможува порамнувачки оптимизации.
Кога не е специфицирано знаменце за оптимизација, компајлерот не
изведува оптимизација; ова обично резултира во код кој работи поспоро од
очекуваното. –О оптимизациското знаменце обично претставува добар компромис
помеѓу времето на компајлирање и брзината на новиот код, па обично е добар почетен
чекор за оптимизација.
Макро знаменцето –fast овозможува опсег на компајлерски оптимизации кои
обезбедуваат добра брзина кај повеќето апликации. Меѓутоа, ова знаменце не е добро
за сите апликации бидејќи прави одредени претпоставки за однесувањето на
апликацијата:

• Компајлерот може да користи спецификација за подвижна запикра. Знаменцата кои

го овозможуваат тоа се -fsimple=2, кое дозволува компајлерот да
преуредува искази со подвижна запирка и -fns, кое дозволува
апликацијата да ги прочисти поднормалните броеви на 0. Знаменцето
исто така ќе услови генерираниот код да не ги сетира errno и matherr
променливите за некои повици на математички функции; обично, ова
се случува кога компајлерот заменува функциски повик или со
еквивалента инструкција (пример, замена на повикот sqrt со SPARC
fsqrt инструкцијата) или со повик до оптимизирана верзија на
библиотека. Некои апликации се чуствителни на оптимизации на
подвижна запирка, и затоа –fast компајлерското знаменце може да не е
добро.
• -fast знаменцето за С код вклучува знаменце -xalias_level=basic, кое
дозволува компајлерот да претпостави дека покажувачите до разни
типови на променливи (пример, покажувачи до ints и до флоати) не
покажуваат до иста локација во меморијата. Кодот кој се совпаѓа со С
стандардот исто така ќе го потврди ваквото креирање, но ќе постои
одреден код за кој ова нема да виде вистинито.
• Макро знаменцето – fast вклучува знаменце -xtarget=native, кое му

10
 кажува на компајлерот да претпостави дека системот кој ја прави
апликацијата исто така е систем на кој апликацијата работи. Во некои
случаи, оваа претпоставка може да доведе до извршувања кои ќе
работат споро (или воопшто нема) на други системи. Ова однесување е
причина за следење на – fast со знаменце -xtarget=generic, кое прави
враќање назад и му кажува на компајлерот на изгради код кои ќе
работи на широк опсег од платформи. Компајлерот оценува знаменца
од лево на десно, па така знаменцата поставени подоцна во наредбата
ќе надвладеат на оние поставени порано.

Еден начин на употреба на –fast знаменцето е да се пресмета

добиената брзина која може да се добие од агресивната оптимизација, и
потоа да се избери од опциите овозможени од –fast, односно само оние
кои се добри за кодот и кои учествуваат во подобрувањето на брзината.
За повеќе информации за компајлерски знамнца може да се прегледа
страницата
http://developers.sun.com/solaris/articles/options.html.

9.1.2. Компајлирање аплиакции со GCC за SPARC системи

GCC за SPARC системи е достапна за преземање од

http://cooltools.sunsource.net/gcc/. Таа нуди GCC компајлерот да користи генератор на
код од компајлерот Sun Studio. Оваа карактеристика овозможува програмерите да
користат GCC екстензии во нивниот код додека истовремено ги задржуваат
карактеристиките и брзината на Sun Studio компјалерот. Табела 9-2 прикажува
еквивалентни знаменца за GCC за SPARC системи.

ТАБЕЛА 9-2 GCC компајлерски знаменца за три сценарија на програмирање

11
 GCC за SPARC поддржува оптимизациски карактеристики на компајлерот Sun
Studio како што се повратна информација за профилот, оптимизација помеѓу
фајловите, автоматска паралелизација, бинарна оптимизација, детекција на податочни
трки и друго. Овие карактеристики се дискутирани подоцна.

12
9.1.3. Подобрување на брзината со профилна повратна информација

Една од техниките кои ја подобрува брзината на апликацијата е

профилната информација. Оваа техника е особено згодна за кодови кои имаат сложена
контрола на проток. Кога компајлрот наиде на изворен код кој има гранки по кои може
да се движи или не, компајлерот или претпоставува дека гранката ќе биде изврпена или
не со еднаква веројатност, или во некои случаи може да користи информација за изјава
за гранката за да пресмета дали таа ќе се изврши или не со поголема зачестеност. Ако
компајлерот може точно да го одреди однесувањето на гранката, тогаш можно е да се
намали бројот на инструкции и изведат други оптимизации кои резултираат со
зголемена брзина.
Друга ситуација во која познавањето на контролниот тек на апликацијата
му помага на компајлерот е во одлуката за порамнување на рутини. Предноста на овие
рутини е тоа што тие го намалуваат трошокот за повикување на кодот; во некои случаи
дури може да и внесе дополнителна можност за оптимизации. Меѓутоа, негативност е
тоа што тие можат да го зголемат кодот во големина и притоа да ја намалат количината
на код го го собира во кешот.
Компајлирањето со информација за профилот овозможува компајлерот да
собере податоци за типични патеки на код кои ги извршува апликацијата и притоа да
му даде информација на компајлерот која помага за негово оптимално распоредување
во кодот.
Употребата на профилна информација е тростепен процес. Првиот чекор е
да се произведе инструментирана верзија на апликација. Инструментираната верзија
тогаш се пушта под оптоварување кое претставува реално оптоварување под кое
обично работат апликациите. Ваквата работа собира множество на податоци кое се
користи во третиот чекот, крајна пресметка за добивање верзија на апликацијата.
Пример е прикажан во примерот 9-1.

ПРИМЕР ЗА КОД 9-1 Процес на изградба на апликација со информација за профилот

$ cc -O -xprofile=collect:./profile -o test test.c $ test training-workload

$ cc -O -xprofile=use:./profile -o test test.c

13
 Профилната информација бара некои компајлерски знаменца (со исклучок на
знаменцето -xprofile) да се користат и за инструментирани и за крајни верзии на
апликацијата. –xprofile знаменцето исто така како параметар ја зема
локацијата на фајлот каде се чуваат податоците од тестното
оптоварување. Се препорачува овој фајл да биде специфициран;
спротивно, компајлерот може да не биде во состојба да го лоцира
податочниот фајл.
Неколку проблеми околу употребата на профилната информација
треба да се спомнат:

• Процесот на компајлитање со профилна информација значи две изминувања низ

компајлерот плус работа на апликацијата со податоци за учење. Ова може да додаде
сложеност и потребно време за изработка на апликацијата. Најдобро е да се
емулира трошокот наспроти брзината добиена низ процесот. Неопходно е да се
користи профилна информација на крајна наместо на рана верзија од апликацијата.
• Понекогаш се поставува прашање за тоа дали употребените податоци за учење на
апликацијата навистина претставуваат работа која апликацијата вообичаено ја
изведува. Овој наслов е податално опишан во понатамошните потточки.
• Слична загриженост за тоа дали учењето на апликацијата ќе резултира со код кој
подобро се извршува на едно оптоварување за смета на различно оптоварување. И
овој проблем е адерсиран во наредните потточки.
• Повеќе информации за профилната повратна информација може да се добијат на
http://developers.sun.com/solaris/articles/profeedback.html.

14
9.1.4. Вградување оптимизација низ фајл

Оптимизацијата низ фајлот е процедура со која рутините од еден изворен

фајл се вградени во рутини кои се лоцирани на различен изворен фајл. Оваа
оптимизација е контролирана со компајлерското знаменце -xipo. Знаменцето треба да
се користи и за почетна компилација на изворни фајлови како и при времето на
поврзување со цел компајлерот да направи оптимизација низ фајлот.
Ваквата оптимизација има потенцијал да влијае на добиените брзини на
три начини:

• Вградувањето го отфрла трошокот за повик до вградени рутини, отстранувајќи

инструкција за контрола на пренос и резултира со појасен код
• Компајлерот завршува со поголем блок на инструкции и можно е да се побори
распоредот на овие инструкции
• Кога рутината е вградена таа дава можност за дополнителна оптимизација. На
пример, еден од параметрите пратен во рутината може да е константен на местото
на повик, што резултира со поедноставување на вградениот код

Постојат и проблеми:
• Големината на кодот кој се распоредува е зголемена, што може да резултира со
голем број на активни регистри, што пак може да доведе регистрите да се отфрлени
од меморијата.
• Влијанието на меморијата врз рутината ќе се зголеми и ова може да доведе до
поголем притисок на кешовите. Ако се покаже дека вградениот код не бил
неопходен, рутината која еднаш ја собирало во кешот веќе нема да може да ја
собере.

Оптимизацијата низ фајлот е во природен спој со профилната информација

бидејќи податоците од учењето ќе му помогнат на компајлерот да одреди рутини кои
често се извршуваат и може добро да се вградат.

15
9.1.5. Избор на големина на TLB страница

Компајлерот има опции кои дозволуваат избор на големина на page за

апликацијата во време на компајлирањето. Ако овие опции не се користат Solaris
избира големина која смета дека е соодветна. Големината на страницата за стек и heap
може да се постави со знаменцето - xpagesize=value, каде value е од 8K, 64K,
512K, или 4M.
Правилата за одредување на соодветна големина на страница се релативно
едноставни:
- Поголема страница го намалува бројот на TLB промаршувања бидејќи ќе
биде мапирана поголема меморија од страна на единечно внесување во TLB
- Меѓутоа, на Solaris му е тешко да најде доволно меморија неопходна за
алоцирање на голема страница. Така иако апликација бара големи стрници,
оперативниот систем може да не ги обезбеди

Наредбата cputrack може да се користи за да изброи колку TLB

промаршувања се случуваат за дадена апликација. Оваа инфмркација
може да се користи за да се види дали промената на големината на
страницата има влијание. Пример за броење на инвршените инструкции и
бројот на TLB промаршувања е прикажан во примерот за код 9-2. Во овој
пример вкупно 115 TLB промаршувања се случиле во над 100 милиони
инструкции.

ПРИМЕР ЗА КОД 9-2 Броење на промаршувања на податочен TLB со cputrack

Наредбата pmap -xs pid може да се користи за испитување на процес и

проверка дали тој добил говолно голема страница или не. Примерот за код 9-3

16
прикажува излез од оваа наредба при извршување на a.out.

ПРИМЕР ЗА КОД 9-3 Излез од pmap кој покажива големини на страници за

процесот

9.2. Испитување на извршувањето на програмот

Следните потточки ги испитуваат аспектите на извршување на програм:

• Профилирање со анализатор на брзината
• Собирање на инструкциски броења со BIT
• Проценка на квалитетот на податоците од учењето (тренингот)
• Профилирање со SPOT
• Дебагирање со dbx
• Користење на трагач за лоцирање на грепки во мемориски пристап

9.2.1. Профилирање со анализатор на брзината

Една од најважните алатки за програмерите е анализаторот на брзината,

вклучен во Sun Studio, кој генерира профили на апликациите кои покажуваат каде е
потрошено времето. Да го разгледаме примерот во 9-4.

ПРИМЕР ЗА КОД 9-4 Програм за пример

17
 Алатката која собира профилни информации се нарекува collect. Ова алатка
може да биде прикажан на процес кој работи преку collect -P pid или може
да го следи целосното работење на апликацијата со собирање на апликациски
параметри. Податоците за профилот се собираат во директориум на кој му е
преддефинирано име test.l.er. Двете алатки може да прикажат собрани
податоци: алатката за наредбата наречена er_print или GUI алатка
наречена анализатор. Двете алатки треба да се подигнати со името на
експериментот кој е вчитан. Верзијата на алатката со наредба исто така
може да биде вклучена преку команди кои се извршуваат или со скрипта.
Чекорите неопходни за градење, работа и преглед на профилот во
GUI од кодот во 9-4 се прикажани во примерот за код 9-5.

ПРИМЕР ЗА КОД 9-5 Пример за апликација за компајлирање и профилирање

18
 Првичниот преглед на профилот е прикажан на слика 9-1.

СЛИКА 9-1 Профил од анализаторот на брзина

Првите две колони во профилот прикажуваат ексклузивно и инклузивно

корисничко време. Ексклузивното време за функција е времето поминато само за таа
функција. Инклузивното време за функција е времето потрошено за таа функција плус
функциите кои таа ги повикува. На пример, функцијата main има 0 ексклузивно време
– што значи дека времето потребно за таа функција е незначително, но има 11 секунди
на инклузивно време, што значи дека тоа време е потрошено во рутини повикани ов
главната функција. Рутината sum акомулира 5.3 секунди од ексклузивното време, или
времето потребно за таа рутина. Инклузивното време за таа рутина е исто со
ексклузивното време бидејќи рутината на повикува други рутини.
Алатката исто така собира информации за повици до стек. Оваа информација
дозволува алатката да пресмета инклузивно време. Слика 9-2 прикажува повик на стек
за рутина main. Главната рутина е наречена routine _start и повикува рутини clear
и sum.

19
СЛИКА 9-2 Информација за повик на стек

Графикот повикувач-повикан вклучува мерка наречена својствено време, кое го

разделува времето потрошено на одредена рутина на рутините кои ја повикуваат. Ова
време, покажано во првата колона, претставува количина на време својствено за
одредена рутина кога избраната рутина е во повикувачкиот стек. Појасно е да се
објасни овој концепт користејќи податоци од слика 9-2. Својственото време за routine
_start е 11 секунди, што значи дека сите 11 секунди на инклузивно време
за главната рутина се својствени нејзините повици повикани од _start.
Својственото време за рутината clear е 5.7 секунди, што е количина на време
својствено за оваа рутина од нејзиното повикување од страна на главната рутина. Ако
програмот е посложен и рутината clear е повикана од неколку локации, инклузивното и
ексклузивното време за clear би се зголемило но времето својствено на нејзино
повикува од главната рутина ќе остане исто.
Можно е да се опише својственото време како формула – сума од својствените
времиња за повикување рутини е еднакво на инклузивното време за избраната рутина,
но и на сумата на својственото време за избрана рутина и рутините кои таа ги
повикува.
На хардвер кој го поддржува, анализаторот на брзина може да профилира
апликација за да покаже каде се случуваат настани на грепка на хардверскиот бројач.
На пример, може да покаже на точка во кодот каде се случува најголемиот број на
промаршувања на кеш. Оваа карактеристика не е поддржана на UltraSPARC T1 но е
достапна на UltraSPARC T2. Опцијата е поддржана преку дозволата за собирање на

20
знаменцето –h, заедно со листа на бројачи кои го користат. Примерот за код 9-6
прикажува инструкции потребни за профил на апликацијата да лоцира места во кодот
каде постојат промаршувања на податочниот кеш; промаршувањата на податочниот
кеш се снимани од бројачот DC_miss.

ПРИМЕР ЗА КОД 9-6 Профилирање со бројачи за брзина на хардверот

Слика 9-3 прикажува резултати од профилирање на промаршувања на

податочен кеш на UltraSPARC T2 систем. Сите промаршувања на податочен кеш се
случуваат во рутината sum; ова не е изненадување бидејќи рутината sum тече низ
меморијата, читајќи податоци. Рутината clear ги сместува податоците во меморија, па
нема потреба да прави читања и предизвикува промаршувања на податочен кеш.

СЛИКА 9-3 Апликација профилирана по локација на промаршувањата на податочниот

кеш

Изворните и расклопувачките табови на апликацијата покажуваат својствено

време на ниво на изворен код (ако кодот бил компајлиран со -g) и на расклопувачко
ниво. Слика 9-4 покажува преглед на изворно ниво на времето својствено за рутините

21
sum и main. Пак двете колони колони покажуваат инклузивно и ексклузивно
корисничко време. Рутината main има два повици до други рутини и овие повици
имаат инклузивно време својствено за нив, но немаат ексклузивно време (бидејќи
инструкцискиот повик има време 0).

СЛИКА 9-4 Профил на ниво на изворен код

Профилот може да биде прегледан на пасклопувачко ниво, како што е прикано

на слика 9-5. За да се одреди каде е потрошено времето, анализаторот на брзина
проверува адреса на следната инструкција кој треба да се изврши. Фреквенцијата со
која тоа се прави може да се примени од корисникот но предодредена е инспекција од
100 пати во секунда. Секогаш кога ова ќе се случи, алатката снима додполнителен дел
од времето за таа локација, па PC кое се следи 100 пати со фреквенција од 100
примероци во секунда ќе заврши со 1 секунда време својствено за него.
За секоја инструкција компајлерот снима број на линија и изворен фајл за
изворниот код кој направил генерирање на инструкцијата. Бројот на изворната линија е
прикажан во квадратче на слика 9-5 веднаш до расклопената инструкција. За да се
одреди колку време треба биде обезбедено за одредена линија на изворен код, алатката

22
го собира времето својствено за сите расклопувачки инструкции кои се генерирани од
таа изворна линија.

СЛИКА 9-5 Профил на расклопувачко ниво

UltraSPARC T2 има точни стапици за префрлувања кај хардверски бројач, кои

се механизам кој одредува каде во кодот се случиле настани избројани од хардверскиот
бројач. Точната стапица значи дека алатките може да одредат точна инструкција која
довела до настанот. На слика 9-5, промаршувањата на податочниот кеш се одредени
заради читање на 0x10c54. Навистина, ова читање е соодветно на читање на вредноста
a[i] во изворниот код.

9.2.2. Собирање броења на инструкции со BIT

Алатката BIT (http://cooltools.sunsource.net/bit) овозможува корисникот да

собере податоци за тоа колкав број на пати се извршила инструкцијата, број на пати на

23
повикување на рутина, веројатност на извршување на гранка и други корисни мерки.
По инсталацијата на BIT, тој може да се покрене директно, или уште подобро,
преку вклучување на collect –с. За BIT да работи, апликацијата мора да се компајлира
со оптимизација и компајлира и поврзе со компајлерско знаменце -xbinopt=prepare
за компајлерот да ги снима потребните анотации. Примерот за код 9-7
покажува пример за компајлирање и собирање на броења на извршувања
за пример во програм.

ПРИМЕР ЗА КОД 9-7 Собирање на инструкциски броења со BIT

Кога ќе се подигне со collect, BIT дава излез на резултати како анализирачка

опрема како што е прикажано на слика 9-6.

СЛИКА 9-6 Анализаторот прикажува изброени податоци од BIT

Првата од трите колони на податоци прикажува колку пати секоја функција

била внесена: рутината main била внесена еднаш, рутините sum и clear двете биле
внесени 10 пати. Втората колона покажува вкупен број на инструкции кои се извршени
низ работата на кодот, во овој случај околу 600 милиони динамички инструкции.

24
Последната колона на податоци покажува анулирани инструкции. Анулираните
инструкции се инструкции кои биле поставени во местото за доцнење на гранката. Тие
се извршуваат доколку се тргне по гранката, но доколку не се тргне по неа,
инструкциите се анулирани.
Податоците за броење на инструкции исто така се постапени на расклопувачко
ниво, како што е прикажано на слика 9-7. Може да се види дека јамката на адресите
0x10cd0 до 0c10d00 е внесена 10 пати и има средно броење на пат од 2 и пол милиони
итерации секогаш кога е внесена. Бидејќи кодот е компајлиран со оптимизација,
компајлерот има одмотано јамка 4 пати, како што може да се види од четирите faddd
во јамката.

СЛИКА 9-7 Податоци за броење инструкции во расклопувачко ниво

Бидејќи алатката има податоци за фреквенцијата на извршување за секоја РС,

исто така е можно да се пресмета фреквенција на извршување на секоја различен тип
на асемблерска инструкција. Овие податоци се прикажани на одделен таб во Analyzer
GUI, како што е прикажано на слика 9-8. Сумираните податоци прикажуваат дека
околу 1/3 од вкупно избројаните инструкции се читања и сместувања и сите тие се
однесуваат на подвижна запирка. Над половина од вкупниот број на инструкции е
концентриран на манипулација со податоци со подвижна запирка.

25
СЛИКА 9-8 Информација за фреквенција на инструкциски типови за BIT

BIT исто така дава извештаи кои покажуваат на веројатност и фреквенција со

која гранките се извршени како и извршување на броења за основни блокови. За да се
добијат овие податоци, се повикува BIT во линијата за наредби, како што е прикажано
на примерот 9-8.

ПРИМЕР ЗА КОД 9-8 Повикување BIT преку командана линија за генерирање на

извршување на броење на основни блокови

26
 Како што се гледа на примерот 9-8, BIT прво се вклучува за да генерира
инструментирана верзија од апликацијата. BIT користи анотации за снимање под
-xbinopt=prepare за да ја расклопи апликацијата и да генерира нова
верзија од бинарностите кои содржат инструментиран код. Оваа
инструментирана апликација е таа со која мора да се работи. На крајот на
циклусот на инструментираните бинарност, податочен фајл е креиран кој
содржи резултати од инструментацијата. Потоа BIT се вклучува за да го
анализира овој податочен фајл.
BIT може да инструментира само делови од кодот кој е компајлиран
со -xbinopt=prepare . Ако апликацијата има повеќе фајлови со и без оваа
опција, тогаш известувањата за податоците од страна на BIT се собрани
само од инструментираниот делови. Ако инструментиран код повикува во
неинструментирани библиотеки, тогаш овие библиотеки исто така се
исклучени од анализата.
BIT исто така може да генерира извештај за покриеност кој
покажува на код кој бил извршен. Исто така може да генерира извештај
наречен извештај на непокриеност. Идеата на непокриеност е да испита
повикувачки стек на рутини како и да одреди дали тие се извршени или
не. Алатката може да одреди некоја рутина, која доколку е извршена,
исто така доведува други неизвршени рутини да се користат. Со оваа

27
анализа, може брзо да се развијат тестови кои ќе погодат одредени
делови од кодот, знаејќи дека овие тестови сигурно ќе ги извршат
непокриените рутини. Извештајот за покриеност може да се генерира од
BIT, како што е прикажано на примерот 9-9. Анализирачката опрема, која
содржи и репорти на покриеност и непокриеност, исто така се генерира.

ПРИМЕР ЗА КОД 9-9 Генерирање на извештај за покриеност од BIT

9.2.3. Проценка на квалитетот на податоците од тренингот

Кога апликацијата е компајлирана со профилна информација, компајлерот

собира информации за веројатност на гранки и фреквенции на извршување од тренинг
податоците кои се користеле. Притоа, важно е овие податоци да го претставуваат
оптоварувањето кои обично се пушта. BIT алатката може да генерира извештаи за
фреквенциите на извршување на основни блокови на код како и на веројатностите на
извршување и неизвршување на некоја инструкција за гранење.
Извештаите од тренингот и реалните оптоварувања може да се споредат за да се
види дали одредена инструкција за гранење се извршила со иста зачестеност и дали
некои основни блокови се важни. Gove and Spracklen (2006, 2007)1 за употребиле
анализата на SPEC CPU2006 платформата за проверка. Една важна обсервација од тој
труд е дека повеќето тренинг оптоварувања веќе се претставници на реалните
оптоварувања.
1 ACM SIGARCH Computer Architecture News, Vol. 35, No. 1 - March 2007
http://www.spec.org/cpu2006/publications/SIGARCH-2007-03/ 10_cpu2006_training.pdf
http://www.spec.org/workshops/2006/papers/10_Darryl_Gove.pdf

28
 Најслабата точка е воочена кога тренинг оптоварувањето беше од друг тип на
проблем а не поради оптоварување употребено при работа на тест платформата.
Методологијата е детално објаснета на ://developers. sun.com/
solaris/articles/coverage.html. Прегледот е следен. Бинарностите се компајлирани со
знаменце -xbinopt=prepare. Компајлираните бинарностите се инструментирани со BIT,
и потоа се генерирани извештаи за тренинг оптоварување и за реалното оптоварување.
Едноставна програма е прикажано како што е наведено во примерот 9-10.

ПРИМЕР ЗА КОД 9-10 Пример за програм кој прикажува квалитет на тренинг

оптоварување

Неопходните чекори за генерирање на извештај кој покажува веројатности на

гранки се прикажани во примерот 9-11, заедно со пример за излези од извештајот.

ПРИМЕР ЗА КОД 9-11 Веројатности на гранки

Неопходните чекори неопходни за генерирање на извештај за фреквенција на

извршување на основни блокови се прикажани на примерот 9-12, заедно со примерок
од излез од извештајот. Извештајот вклучува борења на број на пати на извршување на
секој основен блок.

29
ПРИМЕР ЗА КОД 9-12 Броење на основни блокови

Следно, тест кодот е извршен со неколку параметри од команданта линија.

Извештаите за гранки и блокови за ова се прикажани на примерот 9-13.

ПРИМЕР ЗА КОД 9-13 Податоци за гранка и блок за реално оптоварување

Податоците за веројатност на гранење може да се искористат за да одредат дали

постои совпаѓање помеѓу тренинг и реалните оптоварувања. Секоја гранка може да се
класифицира како извршена или неизвршена. Ако гранката има иста веројатност и за
тренинг и за реални оптоварувања, тогаш гранката точно се предвидела. Ако гранката
има различно однесување, тогаш гранката се предвидела погрешно.
За единечни мерења кои опишуваат квалитет на тренинг оптоварувањето,
броењето на динамичко извршување на точно предвидени гранки за време на реално
оптоварување е поделено на борења на динамичко извршување за сите гранки за време
на реалното оптоварување. Овој резултат е вредност помеѓу 0 и 1. Вредноста во
близина на 1 значи дека сите често извршувани гранки се точно предвидени; вредност

30
блиску 0 значи дека ниту една од често извршуваните гранки не е точно предвидена.
За примерот, постојат две гранки. Првата гранка е предвидено да не се изврши
од тренинг оптоварувањето и не е извршена од референтното оптоварување; таа се
извршува еднаш од референтнното оптоварување. Втората гранка исто така е
предвидено да не се изврши од тренинг оптоварувањето но е извршена од
референтното оптоварување. Втората гранка е сретната 4 пати од регерентното
оптоварување. Така пресметката кажува дека една точно предвидена гранка извршена
еднаш од референтното оптоварување и 4 неточно предвидени гранки изврпени до
референтното оптоварување, па согласно квалитетот на предвидувањето е (1 x 1 + 0x4)
+ 5 = 0.2. Така тренинг оптоварувањето е со слаба совпадливост за однесувањето на
гранката на реалното оптоварување.
Пресметката за договор помеѓу фреквенцијата на динамичко извршување на
основни блокови е малку различна. Веројатноста за гранка која е извршена има опсег
од 0 до 1, но не постои еквивалентна горна граница на фреквенција за извршување на
основен блок.
Меѓутоа, една мерка која може да јасно да се дефинира за основен блок е тоа
дали тренинг оптоварувањето ги покрива сите блокови кои се важни за реалното
оптоварување; пред се, доколку оптоварувањето не изврши блок, тогаш компајлерот
може да не добие информација за однесувањето на блокот. Блокот се смета за покриен
се додека тренинг оптоварувањето го извршило блокот барем еднаш. Ако блокот
никогаш не се изврши од тренинг оптоварувањето, тогаш блокот се смета на
напокриен.
Вредност помеѓу 0 и 1 може да се пресмета преку сумирање на бројката за
динамичко извршување на оние основни блокови во реално оптоварување кои се
покриени со тренинг оптоварувањето и делење на тоа со бројот на динамички
извршувања на сите основни блокови во реално оптоварување. Вредност блиску до 1
значи дека сите често извршени основни блокови во реално оптоварување се исто така
извршени барем еднаш од тренинг оптоварувањето. Вредност блиску 0 значи дека ниту
еден блок кој е често извршуван во реално оптоварување не е покриен со треминг
оптоварувањето. Во примерот, тренинг оптоварувањето ги извршува сите основни
блокови во референтно оптоварување, па така се добива квалитет на покриеност на
основни блокови од (1 + 1+ 4 + 1) + 7=1.0. Тренинг оптоварувањето добро се

31
совпаѓа со референтното оптоварување.
Добро е да се воочи дека иако овие мерки се приближни за квалитет
на тренинг оптоварување, исто така е можно да се направи компромис
помеѓу тренинг и реалните оптоварувања на график. Примери за графици
со скрипти кои процесираат резултати од BIT се достапни на:
http://developers.sun.com/solaris/articles/coverage.html.

9.2.4. Профилирање со SPOT

SPOT (http://cooltools.sunsource.net/spot/) е алатка која го олеснува процесот на

лоцирање и одредување на проблеми со брзината. Алатката вклучува апликација која
подлежи на повеќе проверки и генерира HTML извештај кој покажува резултати од
овие проверки плус профил на апликацијата. Проверките кои се достапни зависат од
карактеристиката на хардверот и оперативниот систем, па така не сите проверки ќе
бидат достапни на сите машини. Следуваат описи на овие проверки кои ги користи
SPOT:

• Системските информации се снимаат, што го олеснува следењето на конфигурација

во системот на кој работи апликацијата
• Компајлерските знаменца се добиени од апликацијата доколку оваа информација се
снима.
• Информации за настани на броење на брзината на кои наишла апликацијата се
собираат од ripc и се користат за одредување на количина на време изгубено кај
состојби на чекање за различни процесори. Оваа информација може да се користи
од SPOT за профил на апликација под оние бројачи на хардверска брзина кои
најмногу учествуваат во вкупното време на чекање.
• Профилната информација која прикажува каде се троши време во апликацијата е
собрана од анализаторот на брзина
• Податоците за инструкциско броење се собираат од BIT доколку апликацијата е
компајлирана со соодветни знаменца
• Податоците за искористувањето на системскиот опсег и податоци за системски
стапици се собираат при работата на апликацијата. Собирањето на овие

32
 информации бара привилегии на супер корисник.

Извештајот генериран од SPOT има неколку предности над пуштањето на различни

самостојни алатки. Извештајот заштедува значителна количина на контекстни
информации, па така може да се навраќаме на извештајот и да ги најдеме знаменцата
кои се користеле, името на системот, како и изворот и расчленувањето на деловите од
апликацијата кои трошат време. Друга значајна предност при користење на SPOT е тоа
дека тој може да ги гледа HTML извештаите преку пребарувач. Освен тоа, важно е да
се споделува URL која покажува на важни податоци или точки од изворниот код со
колеги па и тие може да ги погледнат податоците кои се пред нас.
Апликацијата може да работи под SPOT во исто време кога апликацијата работи
и под collect, како што е прикажано на примерот 9-14. Алтернативно, SPOT може да се
прикаче на работниот процес со spot -P pid, иако овој пристап не се препорачува за
производни системи бидејќи може да воведи стопирање на процесот неколку пати.
SPOT е наменет за собирање на кратки извештаи за брзината на апликацијата; за
ситуации во кои постои повеќе време, може да собере подолги извештаи со опцијата на
наредбата –X како што е прикажано во примерот 9-14.

ПРИМЕР ЗА КОД 9-14 Собрирање проширени продатоци за a. out со SPOT

$ spot -X a.out

Профилната информација која ја собира SPOT веќе ќе биди слична со

претходните резултати од ова подглавје. Еден дел од извештајот кој може да биде
помалку познат е податокот за хардверски бројач наведен од ripc. Дел од овие
податоци за апликација која работи кратко е прикажана на примерот 9-15.

ПРИМЕР ЗА КОД 9-15 ripc излез прикажан од SPOT

33
 Делот на почетокот на ripc излезот пресметува број на иагубени циклуси на
секој тип на процесорски настан. За овој код, околу 1/3 од работата е изгубена во
настани на промаршување на податочен кеш. Околу 40% од вкупната работа се троши
во циклуси на чекање. Ripc исто така следи вкупни времиња, броења инструкции и
операции со подвижна запирка. Тој исто така следи и број на стапици за подвижна
запирка низ целиот систем кои се случуваат додека апликацијата работи. Овие стапици
се направени кога процесорот има потреба операциите со подвижна запирка да се
извршат во софтверот. Оваа алатка исто така следи и големина на меморија и го чита
искористувањето на опсегот.

34
9.2.5. Дебагирање со dbx

Дебагерот Sun Studio, наречен dbx, како и повеќето дебагери поддржува

испитување на изворни фајлови како и работа со апликации. Употребата на dbx за
испитување на фајлови е прикажана во примерот 9-16. Изворниот фајл обично го
снима името на извршувањето кое го генерирало, па така dbx може да се вклучи кога
со знакот – на името на извршувањето. Ако тоа не е случај, когаш извршувачот може
да се одреди на командната линија.

ПРИМЕР ЗА КОД 9-16 Употреба на dbx за испитување на изворен фајл

$ dbx application core $ dbx - core

Да го разгледаме кодот од пример 9-17. Овој код има грешка на меморијата која
се користи без да биде алоцирана.

ПРИМЕР ЗА КОД 9-17 Програм со грешка во меморискиот пристап

Компајлерското знаменце –g условува компајлерот да генерира информација за

дебагирање. Во Sun Studio 12, и поновите верзии, оваа информација за дебагирање е
снимена во извршувачот. Претходните верзии на Sun Studio ги снимаат овие
информации во објектни фајлови но небинарни. Програмот во кодот од пример 9-17
генерира јадрен фајл кога работи, и dbx може да се користи за да одреди што се
случило, како што е прикажано на примерот 9-18. Апликацијата е комплајлирана со
оптимизација со цел да добие повеќе информации за дебагирањето. Dbx точно
одредува апликација од јадредниот фајл и известува за грешка која довела генерирање

35
на овој фајл.

ПРИМЕР ЗА КОД 9-18 Употреба на dbx на изворен фајл

Првичниот приказ покажува изворна линија на која се случила грепката.

Наредбата која покажува на повикувачки стек на точката на грешка, известува дека
рутината f била повикана од рутината main. Исто така покажува параметри пуштени во
рутината f. Може да се покаже и вредност на параметрите користејќи изјава print.
Ако кодот бил компајлиран со оптимизација, дебагерот ќе може да прикаже
помалку информации и може да биде наопходно да се погледа кодот за расклопување
за да се одреди што се случило. Процесот е доста триковит како што е прикажано на
пример 9-19.

ПРИМЕР ЗА КОД 9-19 Употреба на dbx за да се испита јадран фајл од

оптимизиран код

36
 Во овој случај, компајлерот не може да одреди точна линија на изворен код кој
довела до проблемот. Тој ја одредува рутината точно. Со поглед кон расклопувањето
на рутината со dis наредбата се покажува дека проблематичната инструкција е clr
(clear) инструкција на 0x10ba8.
Бидејќи рутината е кратка, важно е да се погледне дека %o0 содржи вредност на
а која била пратена во рутината и дека %o5 содржи индекс во тоа поле. Наредбата regs
ги печати тековните вредности на регистрите и покажува дека %o1 содржи вредност 1,
%o5 содржи 8 (што е 1 помножено со големината на елемент на полето, и секоја двојка
зема 8 бајти) и %o0 содржи 0x1070c— исто вредност како и неоптимизараната
ситуација.
Исто така е можно да работи програмот под dbx. Во тој случај, dbx мора да
прати име на извршувач како параметар на командната линија, како што е прикажано
на неоптимизиран код во примерот 9-20. Ако апликацијата бара некакви параметри на
командната линија, тие може да се постават со runargs наредбата во dbx.

ПРИМЕР ЗА КОД 9-20 Работа на апликација со проблем под dbx

37
9.2.6. Употреба на Discover за лоцирање на грешки во меморискиот пристап

Грешките кај меморискиот пристап се грешки условени кога до

меморијата се пристапува, откако била ослободена, пред да била иницијализирана, итн.
Грешките од овој вид е доста тешеко да се лоцираат бидејќи резултатот од грешката
често се манифестира после долго време откако извршувањето на кодот кој содржи
проблем. Алатката Discover (http ://cooltools.sunsource.net/discover/) е дизајнирана за да
детектира вакви проблеми. За да се користи Discover, апликацијата мора да биде
направена со оптимизација и компајлерска опција xbinopt=prepare. Тогаш алатката
discover прави инструментирана верзија од апликацијата, која се пушта да работи.
Примерот 9-21 прикажува пример за работа на алатката. Discover исто така може да
генерира резултати како HTML извештај. Ова се овозможува со подесување на
променливата DISCOVER_HTML пред да се започне со инструментирање.

ПРИМЕР ЗА КОД 9-21 Употреба на Discover за лоцирање грешки во мемориски

пристап

38
9.3 Пресметување пропусност
OpenSPARC T1 и OpenSPARC T2 процесорите имаат повеќе канали кои делат
јадро, и како такви се дизајнирани за оптоварувања кои бараат поголема пропусност
наместо кратко време на одзив. Најчест начин на илустрирање зошто повеќето канали
може да делат јадро покажуваат јазовите кои се јавуваат во протокот на инструкции од
настани како промаршувања на кеш и демонстрираат дека овие јазови треба да се
користат од други канали за да направат прогрес. Ова може да биде изразено со сите
канали ќе имаат циклуси на чекање, и овие циклуси се доволни да обезбедат промена
на различни канали. Следните подточки прават преглед на развојот на апликации кои
користат повеќе канали:

• Мерење на искористеност на процесото

• Употреба на бројачи на брзина за пресметка на употребата на инструкциите и
чекањата
• Собирање податоци за избројани инструкции
• Стратегии за паралелизација
• Паралелизам на апликации со POSIX канали
• Паралелизам на апликации со OpenMP
• Употреба на автоматска паралализација за добивање паралелни апликации
• Детекција на трки на податоци со анализатор на канал
• Избегнување на податочни трки
• Преглед на микропаралелизација
• Програмирање за пропусност

39
9.3.1. Мерење на искористеност на процесорот

Со секое јадро кое работи со повеќе канали, максималната пропусност која

може да се постигне е една инструкција по јадро за OpenSPARC T1 и две инструкции
по јадро за OpenSPARC T2. Во оваа ситуација, секое јадро ќе достигнува максимален
број на инструкции кои се достапни. Очигледно, не сите оптоварувања ќе управуваат
со овој проблем на брзина на инструкции. Проблемот со брзината на инструкција не е
видлива низ обичните алатки на Solaris како што е prstat (која покажува за колку време
оперативниот систем распоредил канал на виртуелниот процесор).
Проблемот со брзината на инструкцијата може да се мери за индивидуален
процес, користејќи cputrack за читање на бројачите на брзина, или може да се мери на
целиот систем со cpustat. Добар начин на преглед на проблемот со брзината за целиот
чип е corestat (http://cooltools.sunsource.net/corestat/), која дава извештај за
искористеност на целобројните и каналоводите за подвижна запирка на процесорскиот
јадра.
Corestat работи со извештаи за бројот на проблематични инструкции кој е
изваден од максималниот можен број на инструкции кои се пратени. Ова дава вредност
која покажува колкав дек од „инструкцискиор буџет“ за процесорско јадро е
искористен. Пример од излезите покажува запрен систем базиран на UltraSPARC T2
даден во примерот 9-22. Само каналоводот 0 на јадро 2 покажува доволна активност.

ПРИМЕР ЗА КОД 9-22 Искористеност на целоброен каналовод кај UltraSPARC T2

од corestat

40
 Corestat добро го опфаќа и cpustat, која следи процесорски настани на целиот
систем. Може да се бројат разни хардверски настани и добро е да се прегледаат
информациите кои ги нудат тие настани. Примерот 9-23 покажува повеќеканален
програм кој може да се користи за испитување на брзината на инструкциски проблеми.

ПРИМЕР ЗА КОД 9-23 Пример за повеќеканално јадро

Кодот користи OpenMP за да паралелизира едноставна јамка; OpenMP се

поајавува во следните потточки. Променливата OMP_NUM_THREADS го поставува
бројот на канали кои ќе ги користи апликацијата во паралелниот регион. Примерот 9-
24 покажува компајлирање и работа на програм на UltraSPARC T1 систем.

41
Компајлерското знаменце –xopenmp прави компајлерот да препознае OpenMP наредба
во кодот. Знаменцата -xloopinfo и –xvpara прават компајлерот да даде повеќе
информации за паралелизмот на кодот.

ПРИМЕР ЗА КОД 9-24 Компајлирање и работа на OpenMP паралелизиран код

Додека кодот работи, cpustat може да се користи за следење на бројот на

инструкции пратени од секој канал, како што е прикажано на примеро 9-25. Наредбата
бара да се земе број на инструкции секоја секунда во време од 10 секунди. Колоните
покажуваат време за кое е земен примерок, вирутелен CPU, тип на текст кој е во
извештај (во овој случај “tick”) и број од бројачот на хардверска брзина.

ПРИМЕР ЗА КОД 9-25 Употреба на cpustat за добивање на брзината на

инструкциски проблеми

42
 Излезот покажува дека секоја канал извршил околу 188М инструкции во
секунда. UltraSPARC T1 системот кој ги генерира овие податоци има 4 канали на
секое јадро. Со земање на ID 0, 1, 2, i 3, на виртуелен CPU , кои лежат на првото
јадро, вкупниот број на извршени инструкции од тоа јадро е 750М; за 1.2 GHz
процесор ова е 750 + 1200 = 65% искористеност.

И за двата процеори Т1 и Т1, во иделен случај еден од 4те канали дава

инструкција при секој циклус. Другите 3 канали или чекаат да дадат инструкција или
се закочени на некој процесорски настан. Под еднаква распределба на можности за
издавање инструкција, секој канал ќе има три циклуси за време не кои не може да
прати инструкција за секој циклус при кој тоа може да се направи.

За време на овие 3 циклуси не е важно дали каналот е закочен на настан или

подготвен за извршување, бидејќи другите канали ќе ја искористат можноста за
праќање инструкција пред тековниот канал да добие друга можност за праќање.

43
Согласно, секој канал поседува т.н. „буџет за чекање“ кое е три пати од
„инструкцискиот буџет“. Се додека бројот на циклуси за кој каналот е закочен не го
надмине овој буџет, каналот ќе продолжи со праќање инструкции со најголема брзина.

9.3.2. Употреба на бројачи на брзина за пресметка на употребата на

инструкцискиот буџет и буџетот за чекање

Хардверските бројачи на брзина на Т1 и Т2 може да се користат за

собирање информации за тоа кои настани на чекање ги има каналот. Интересни
бројачи на брзина на двата процесори се дадени на табла 9-3.

ТАБЕЛА 9-3UltraSPARC T1 и UltraSPARC T2 бројачи на брзина

UltraSPARC T1 UltraSPARC T2
Performance Performance
Event Counter Counter
Cycles store buffer full SB_full Not available
Floating-point instructions FP_instr_cnt Instr_FGU_
issued arithmetic
Instruction cache misses IC_miss IC_miss
Data cache misses DC_miss DC_miss
Instruction TLB misses ITLB_miss ITLB_miss
Data TLB misses DTLB_miss DTLB_miss
Instruction cache misses that
L2_imiss L2_imiss
also miss L2 cache
Data cache load misses that also L2_dmiss_ld L2_dmiss_ld
miss the L2 cache
Instructions issued Instr_cnt Instr_cnt

Со исклучок на бројач за баферот за чување на Т1, бројачите собираат податоци

за бројот на настани, а не за бројот на циклуси кои се потребни за настан. На пример,
промаршување на податочен кеш кое е задоволено за податоци од L2 кеш одзема 18
циклуси за да се изврши. Начин на пресметка на бројот на изгубени циклуси по

44
состојба е да се помножи бројот на настани на со трошокот на тој тип на настан.
Доста е лесно да се користат cpustat или cputrack за да се соберат фреквенции на
разни настани за време на работата на апликацијата. Потоа ова може да се комбинира
за да се добие пресметка на вкупниот број на потрошени циклуси во состојби на
чекање. Податоците се сумирани за кодот во примерот, кој работи на 1.2 GHz
UltraSPARC T1 систем, во табела 9-4. Важно е да се увиди дека пресметките за
трошоците на разни настани се само пресметки а не се точни мерења. Меѓутоа, ова не
му штети на пресметката на трошоци за разни настани – јачината на пресметките се
користи и за точни вредности.

ТАБЕЛА 9-4 Вкупно циклуси потрошени во настани на чекање

Est. Cost
UltraSPARC in Est.
T1 Cycles Cost
Performance Per in
Event Counter Event Events Sec
Cycles store buffer
SB_full 1 185,264 0
full
Floating-point 30
FP_instr_cnt 0 0
instructions issued
Instruction cache
IC_miss 20 0
misses 1,683,889
5,059,778,32
Data cache misses DC_miss 20 84
9
Instruction TLB
ITLB_miss 100 217 0
misses
Data TLB misses DTLB_miss 100 686,278 0
Est. Cost
UltraSPARC in Est.
T1 Cycles Cost
Performance Per in
Event Counter Event Events Sec
Instruction cache L2_imiss 100 1,262,433 0
misses that also

45
miss L2 cache
Data cache load L2_dmiss_ld 1,015,218,197 84
misses that also 100
miss L2 cache
65,284,655,74
Instruction count Instr_cnt 4 7 217s

За даден број на настани, трошокот за секоја настан и брзината на тактот, може

да се пресмета бројот на секунди потребен за секој тип на настан.
Кога се работи со 32 канали, кодот користи околу 320 секунди од корисничкото
време и околу 15 секунди од реалното време. Од овие 320 секунди, пресметано е дека
84 секунди се потрошени чекајќи податоци од L2 кеш и исто толкав дел на време за
податоци од меморија. Па така околу половина од вкупното корисничко време се
користи на чекање на меморијата. Во 320 секунди еден канал кој извршува инструкција
на секои 4 циклуси ќе има извршено 96 милијарди инструкции. Пресметаното време на
кодот за изведување на 65 милијарди инструкции е 217 секунди. Кодот употребува
околу 68% од достапниот инструкциски буџет. Еден канал кој работи 320 секунди ќе
има 3 циклуси за секои 4 потрошени во чекање бидејќи три други канали го користат
јадрото. Ова претставува 288 милијарди циклуси на можно чекање, или 240 секунди.
Кодот има околу 170 секунди вкупно време на чекање поради промаршувања на кеш,
што е еднакво на искористеност од 71% на буџетот за чекање.
Заклучокот за овој код е тоа дека тој не изведува многу инструкции колку што
би можел, но исто така ниту пак страда премногу поради мемориско чекање. Со други
зборови, бројот на циклуси за чекање може да се зголеми пред да има влијание на
работата на апликацијата. Во поглед на оптимизацијата, намалување на циклусите за
чекање на еден канал ќе доведе до тоа каналот да се извршува побрзо. Каналот почесто
ќе биде подготвен за да зафати инструкциско место. Меѓутоа, каналот ќе може да ги
постави неговите инструкции само ако другите канали не ги користат. Така каналот
нема да го искористи доволно ваквото намалување на циклусите за чекање.
Веројатно најважна мерка за испитување е вкупниот број на извршени
инструкции од сите канали во еден циклус. Тоа би ја подобрило пропусноста со
избегнување на настани на чекање само ако има достапни инструкциски места. Ако
нема достапни места, тогаш сите подобрувања на брзината мора да дојдат од

46
намалување на бројот на инструкции.

47
9.3.3. Собирање на податоци за броење инструкации

Бидејќи бројот на инструкции најверојатно е главна мерка која одредува

пропусност на апликацијата, важно е да се дозволи мерење на инструкциски
фреквенции за сите делови на апликацијата. Постојат повеќе начини за тоа:
- Употреба на анализатор на брзината за да профилира бројач на брзината со
хардверско броење. Оваа опција лесно се изведува но подлежи на
хардверски бројач на брзина кој генерира префрлувачки настан. Овај
механизам е достапен на Т2 но не на Т1.
- Употреба на алатката BIT за проширување на анализаторот на брзина со цел
да се соберат податоци за бројот на инструкции. Ова е опфатено во
претходните точки.
- Употреба на алатката ifreq која е доставена од емулирачката библиотека
SHADE (http://cooltools.sunsource.net/shade/). Оваа алатка исто така може да
снима инструкциска фреквенција, но моментално не е можно да се префрлат
излезите од алатката во анализаторот на брзина
- Употреба на cpustat и cputrack за добивање информација за бројот на
инструкции. Corestat алатката користи бројачи на инструкции за да извести
за искористеноста на виртуелните јадра.

9.3.4. Стратегии за паралелизам

Апликација може да се распределена на повеќе јадра на повеќе начини:

- Мултипроцес. Мултипроцесна апликација има бројни одделни извршувања
кои работат истовремено за да формираат една апликација. Извршувањата
обично комуницираат преку механизми како сигнали и пораки, или преку
мрежен стек. Предност на употребата на повеќе процеси е тоа што секој
процес е независен и може да се рестартира доколку падне, па така една
грешка не ја паѓа цела апликација.

48
- Повеќе канали. Повеќеканалната апликација е единечно извршување кое се
бројни канали кои ја извршуваат работата. На веб сервер, секој канал може
да е задолжен за работа со новите барања за страници кои доаѓаат. Во
посложен систем, на секој канал може да му се даде одделна задача. Кај
појаки оптоварувања, секој канал може да пресметува дел од проблемот.
Бидејќи сите канали делат иста меморија, постои загриженост дека грешка
кај едно од овие канали може да доведе до пад на цела апликација. Постојат
два можни начини на кодирање на повеќеканални апликации, PThreads и
OpenMP, и двете се опишани подоцна.
- Повеќе системи. Можно е да се распредели апликацијата помеѓу
повеќе системи. Во некои ситуации ова може да се постигне со
реплицирање на еден извршувач и инсталирање на повеќе системи,
потоа поставување на овие системи зад некаков тип на механизам на
контролирано читање – ова е типично за хостирање на големи веб
страни – со бројни системи кои работат на идентичен софтверски
стек.

Друг тип на употреба на повеќе системи е проширување на

мултипроцеси, со процеси кои се поставуваат на различни машини. Ова
обично се постигнува со TCP/IP. Во сметачки домен со голема брзина,
обично се користи интерфејс за праќање пораки (MPI) кој нуди
апликација која ја дели работата на повеќе системи. MPI е вон опсегот на
овој труд. Sun производите кои го поддржуваат се нарекуваат
ClusterTools. (http://www.sun.com/software/products/clustertools/).

49
9.3.5. Паралализам на апликации со POSIX канали

POSIX каналите, или PThreads, често се користат за добивање на

повеќеканални апликации. Тие имаат богати API и за контрола на канали и
механизами за различна синхронизација (како што се mutex заклучувања) кои
се неопходни со цел да се развијат апликации кои нудат точни резултати.
Едноставен пример за PThread апликација е прикажан на примерот 9-26.

ПРИМЕР ЗА КОД 9-26 Едноставен PThread пример

Во апликацијата, секој повик на pthread_create креира нов канал. Новиот канал

извршува do_work рутина. Единечен параметар е пуштен во рутината. Овој параметар
содржи вредност на променлива i кога каналот е креиран. Иако е пожелно да се прати
адреса на променлива i, за жал тоа не работи бидејќи променливата може да има
променета вредност пред каналот да започне.
Единствена работа која секој канал ја прави е печатење идентификатор. После
тоа канлот постои. Главниот канал повикува pthread_join за да чека се додека секоја
канал не ја заврши работата. Откако сите канали се комплетирани, главниот канал
принта порака пред да излезе.
За да се компајлира апликацијата мора да се вклучат компајлерски знаменца –mt
и –lpthread за верзии на Solaris пред верзија 10. Со верзија 10, каналната библиотека е

50
комбинирана со libc, па така не треба да се поврзува во libpthread. Чекорите за
компајлирање и работа на апликацијата на Solaris 10 платформа се покажани во
примерот 9-27.

ПРИМЕР ЗА КОД 9-27 Пример за компајлирање и работа на PThread

Кога апликацијата работи, каналите нема да работат во детерминистички

редослед. Во прикажаниот случај, јасно е дека каналите не работат во редослед на
нивното креирање.

9.3.6. Паралелизам на апликации со OpenMP

OpenMP е начин на паралелизација на апликација, користејќи директиви кои се

внесени во изворниот код на апликацијата. OpenMP пристапот има бројни предности:

- Директивите се релативно лесни за користење и ја сокриваат сложеноста за

управување до канали која е неопходна за паралелизам
- Компајлерот ќе ги препознае директивите само кога одредено знаменце (-
xopenmp) е специфицирано. Ако знаменцето не е присутно, се задржува
оригиналниот код, па така едно јадро може да доведе до сериски и
паралелни верзии на апликацијата. Ова олеснување е доста добро за
одредување на тоа дали грешката е поради сериската логика на апликацијата
или заради нешто во паралелизмот.
- Директивите треба да се употребат само на делови од кодот кои се
паралелизираат, па така остатокот од кодот може да се остави ист. На тој
начин, програмерите може да ја зголемуваат паралелноста на апликацијата,

51
 избирајќи само делови на апликацијата кои ќе го подобрат паралелизмот и
ќе го остават остатокот од апликацијата недопрен.

Едно ограничување при употреба на OpenMP за паралелизација на апликации е тоа

што таа е најефикасна кога се користи за паралелизам на код кој содржи јамки.
Меѓутоа, најновата OpenMP 3.0 верзија нуди и пристап базиран на задачи.
Пример за употреба на OpenMP наредба за паралелизација на едноставна
спликација е прикажан на примерот 9-28.

ПРИМЕР ЗА КОД 9-28 Пример за OpenMP код

OpenMP наредбата му кажува на компајлерот да даде паралелна верзија од

ледната јамка. Секој канал зема одделен дел од јамката; бројот на канали е
контролиран преку променливата OMP_NUM_THREADS, иако постои API функција
за програмот да одреди или да го промени бројот на канали при работата. За да се
компајлира апликацијата, мора да се користи знаменце -xopenmp. Знаменцата flags
-xvpara и –xloopinfo може да се користат за барање со компајлерот да извади
информации за паралализацијата која била постигната. Низата од компајлирање и
работа со пример за код е дадена во примерот 9-29.

ПРИМЕР ЗА КОД 9-29 Компајлирање и работа со едноставен OpenMP пример

Посложен пример е прикажан во кодот од 9-30. Овој код содржи две паралелни

52
области; првата е јамка која поставува содржина од вредности на поле; втората
паралелна област е намалена.

ПРИМЕР ЗА КОД 9-30 Пример за намаување со OpenMP

Редукцијата е ситуација во кодот кога множество на вредности е намалено на

една вредност. Собирањето и одземањето се примери за тоа, но други операции како
што е наоѓање на максимална вредност исто така претставуваат редукции. Проблемот
со редукциите како собирање и одземање и тоа што редоследот по кој се извршува
пресметувањето во паралелен случај може да биде различно со редоследот по кој се
пресметува со сериски случај.
На пример, да замислиме дека програмот додава листа од броеви со подвижна
запирка кои се сортирани во редослед од најголем кон најмал. Кај пресметување на
подвижна запирка, многу мал број се додава на другиот број кој е доста поголем, што
резултира со број кој може да е идентичен со првиот голем број. Па кога низа од
броеви се сумира, резултатот може да не ги рефлектира вредностите на малите броеви.
Сега, да замислиме паралелен случај каде еден канал додава големи броеви на друг
канал кој додава мали броеви. Кога сите мали броеви се соберат меѓусебе, тие
стануваат доволно голем број кој ќе има влијание во собирањето на сите големи
броеви. Иако овој пример е хипотетички, слично сценарио може да доведе со мали
разлики во резултатите.

53
9.3.7. Употреба на автопаралелизам за добивање на паралелни апликации

Еден пристап за паралелизација е да се дозволи компајлерот да ја паралелизаира

апликацијата. Знаменцето –xautopar овозможува автоматска паралелизација. Под ова
знаменце, компајлерот се обидува да одреди блокови на код кој се паралелизира.
Компајлерот исто така паралелизира код кој содржи редукции. Како што е дискутирано
претходно, редукциите може да ги применат резултатите кај некои пресметки на
подвижна запирка. Согласно, компајлерот бара точни пермисии од корисникот за да
генерира редуцирачки код. Корисникот ги дава пермисиите до знаменце - xreduction.
Пример за код кој содржи редукција е даден на 9-31.

ПРИМЕР ЗА КОД 9-31 Пример за код кој содржи редукција

Низата на компајлирање е прикажана на примерот 9-32.

ПРИМЕР ЗА КОД 9-32 Компајлирање со автомстска паралелизација

Бројот на канали кој се користи од апликација која автоматски се паралелизира

е поставен на ист начин како кај OpenMP апликација, преку променлива
OMP_NUM_THREAD S .

54
9.3.8. Детекција на податочни трки со анализатор на канали

Податочна трка се случува кога два (или повеќе) канали се обидат да пристапат до
иста мемориска локација во исто време и едниот или повеќе од овие пристапи е
запишување. Како едноставен пример, да разгледаме два канали. Двата канали ќе
читаат, инкрементираат и запишат иста вкупна променлива total. Низата на операции е
прикажана на кодот од примерот 9-33. Се забележува дека променливата total е
декларирана како погрешна, што го стопира компајлерот од задржување на
променливата во регистар и гарантира дека променливата е вчитана од меморија пред
да се инкрементира и зачува назад.

ПРИМЕР ЗА КОД 9-33 Пример за код кој содржи податочна трка

Резултатите од компајлирањето и работата на програм два пати се покажани на

примерот 9-34. Првиот пат програмата работи, известува резултати за 53, 164, но
вториот пат истиот код известува за резултати 132, 400. Точен одговор на секој канал
би бил да ја инкрементира променливата 100000 пати, што би дало вредност 200,200.

ПРИМЕР ЗА КОД 9-34 Компајлирање и работа со код кој содржи трка на податоци

55
 Иако двата канали се обиделе да инкрементираат вредност, само еден од
инкрементите всушност е сниман. Најчесто со многу грешки во меморијата, овој
проблем е тешко да се детектира бидејќи резултатот на грешката најверојатно ќе се
детектира далеку од локацијата на грешка во кодот.
За среќа, Sun Studio 12 вклучува анализатор на канал, кој детектира и известува
за грешки во повеќеканалниот код. За употреба на алатката, мора да се компајлира
кодот со компајлерско знаменце flag -xinstrument = datarace, кое кажува компајлерот да
вклучи неопходни инструменти за снимање на грешки. Се препорачува исто така да се
вклучи знаменце –g. Кодот потоа се пушта под collect со опција –r вклучена. Овие
чекори се прикажани на примерот 9-35.

ПРИМЕР ЗА КОД 9-35 Компајлирање за детекција на податочна трка

Откако работата заврши, експериментите може да се испитаат на GUI на

анализаторот на канал, како што е прикажано на слика 9-9. Првиот екран е листа на
потенцијални податочни трки во кодот.

56
СЛИКА 9-9 Податочни трки прикажани во Thread Analyzer GUI

Корисникот може да избере некоја од податочните трки за да биди која линија

од изворот доведува до проблемот како што е прикажано на слика 9-10. Двоен дисплеј
прикажува изворен код од две места каде се пристапува до истата мемориска локација.
Во овој пример, двата пристапи од иста линија на изворот се извршени на два различни
канали.

СЛИКА 9-10 Линии на изворен код кој содржат податочни трки

Постојат две можни решенија за податочните трки: заклучување или

реархитектура. Очигледно решение би било заклучувањето околу проблематичниот
код така што само еден канал може да ја обнови меморијата истовремено. Во кодот
паралелизиран со PThreads најчеста форма на заклучување е mutex заклучување. За
OpenMP постои критична наредба која обезбедува дека само еден канал извршува дел
од код во исто време.
Алтернатива за mutexes е употреба на атомски операции. Атомска операција е

57
онаа која се завршува како да била единечна операција; тоа значи, никој друг канал не
може да ја интерпретира или расипе операцијата. Solaris 10 има код за голем број на
атомски операции вклучени во libc. Опсегот на поддржани операции може да се најде
под man atomic_ops.
Следната точка ги испитува трошоците од различните методи на делење на
податоци помеѓу каналите.
Второто решение да податочните трки е да се реархитекурира кодот така што
податоците не се делат помеѓу каналите. Предност на овој пристап е тоа што избегнува
синхронизациски кодови, но ова избегнување не е секогаш можно да се достигне во
пракса.

9.3.9. Избегнување на податочни трки

Најочигледен начин за избегнување на податочни трки е прикажан на

примерот 9-33 и вклучува поставување на mutex заклучување и обновување на
променливата. Оваа структура гарнатира дека само еден канал ја обновива
променливата во исто време. Бидејќи повеќето од работата која ја извршуваат каналите
е обновување на променлива заштитена од mutex заклучување, брзината ќе биде
помала од онаа во сериски случај. Променетиот код е прикажан во примерот 9-36.

ПРИМЕР ЗА КОД 9-36 Избегнување на податочни трки со употреба на Mutex

Заклучувања

58
 Низата на компајлирање и работа на кодот е прикажана на примерот 9-37. Кодот
дава точен одговор од 200000.

ПРИМЕР ЗА КОД 9-37 Compiling and Running Code Containing a Mutex Lock

Интересно е да се спореди брзината на SMP и CMT систем со горниот код. Ако

кодот е уреден така што е креиран само еден канал, времето на 900 MHz V880 и на 1.2
GHz T2000 е скоро исто. Меѓутоа, кога се креирани два канали, брзината е доста
различна прикажано на табела 9-5.

ТАБЕЛА 9-5 Споредба на едно и повеќеканален пристап до Mutex

Platform Single Thread Two Threads, Twice the Work

900 MHz
V880 1.8 s 10.0 s
1.2 GHz2.5 s 6.2 s

59
T2000

Во двата случаи, кога mutex е задоволен прави апликацијата да работи поспоро

од случајот кога тој не е задоволен. Меѓутоа, V880 работи 5 пати поспоро кога имаме
два канали од ситуацијата кога имаме еден канал, споредено со CMT T2000 на кој му е
потребно скоро двојно време – тоа значи дека треба дупло време да да изврши дупла
работа.
Причината за оваа разлика во брзината е тоа што кај V880 повеќето канали го
делат mutex низ меморијата. За овој систем, доцнењето на меморијата е неколку
стотици циклуси. Кај Т2000 пак, може да се споредли mutex низ L2 кешот или пат дури
и на L1 кешот. Доцнењето на кешот е значително помало од она на меморијата.
Алтернативен начин за промена на кодот е да се користи атомска операција.
Атомските операции се вклучени во libs на Solaris 10 (man atomic_ops). Тоа обично се
кратки рутини кои се однесуваат како операцијата да е атомска (што знали, не може да
се преземе од друг канал). Променетиот код е прикажана на примерот 9-38.

ПРИМЕР ЗА КОД 9-38 Употреба на атомски операции

60
 Разликата во брзината кај Т2000 е импресивна. Двоканалната верзија на кодот
завршува за околу 0.8s. Интересно, двоканалната верзија изведува двојно повеќе
работа за исто време, но користи двојно подолго корисничко време. Атомските
операции се поисплатливи отколку добивање и пуштање на mutex, што води кон многу
подобро скалирање. Секако, SMP систем ќе нема доволно брзина од употребата на
атомски операции бидејќи нивното делење треба да се направи низ меморијата. Две
директиви во OpenMP се справуваат со истата ситуација. Кодот од примерот 9-39
прикажува OpenMP код кој содржи податочна трка. Овој код има две јамки кои се
паралелни за OpenMP. Првата јамка поставува поле а втората пресметува сума на сите
вредности во полето.

ПРИМЕР ЗА КОД 9-39 OpenMP код кој содржи податочна трка

Процесот на компајлирање и работа на кодот со еден или два канали е

прикажан во примерот 9-40. Компајлерското знаменце –xvpara условува
компајлерот да прати известување за потенцијалната податочна трка во втората јамка.
Компајлерското знаменце –xloopinfo условува компајлерот да емитува информација за
јамките кои се паралелни. Не е изненадување тоа што кодот дава погрешни резултати
кога работи со повеќе од еден канал.

ПРИМЕР ЗА КОД 9-40 Компајлирање и работа на OpenMP програм кој доржи

податочна трка

61
 Двете директиви може да се користат за избегнување на ситуација на податочна
трка. Првата е наредба на критичен дел. Оваа наредба одредува дел од кодот кој треба
да се изврши на само еден канал истовремено. Променетиот код е прикажан на 9-41.

ПРИМЕР ЗА КОД 9-41 Избегнување на податочна трка со OpenMP наредба на

критичен дел

Кога кодот работи, тој дава точен одговор и во сериски и во паралелен случај.
Овој код е аналоген на употребата на mutex заклучување за заштита на пристап до
променливата total. Меѓутоа, поефикасна наредба може да се користи во оваа
ситуација. Тоа е атомска наредба, која одредува дека следната операција е иаведена
автоматски. Кодот кој ја користи оваа наредба е прикажан на 9-42.

ПРИМЕР ЗА КОД 9-42 Избегнување податочни трки со OpenMP атомска наредба

62
9.3.10. Преглед на микропаралелизација

CMT процесорите имаат две доста значајни предности над

традиционалните пристапи. Прва предност е што имаат голем број на канали. Втора
предност е што овие канали обично имаат исплатлива синхронизација –
синхронизацијата се прави на ниво на кеш кој е многу блиску до јадрото.
Комбинацијата на овие две предности води кон идеа дека е можно да се
паралелизираат делови од кодот на CMT процесорите каде трошокот за
синхронизација на традиционалните процесори надтежнува над брзината поради
употребата на повеќе канали. Микропаралелизацијата е пристап каде мал дел од
работата е разделена на повеќе канали; можноста за тоа лежи во синхронизацискиот
трошок кој се одржува низок.
Главна рамка за микропаралализација кодот е опишана подолу:
- Секој канал треба да одреди следен дел од работата која ќе ја извршува
- Секоја канал проверува дали е безбедно ја го изврши делот од работата
- Откако работата ќе се изврши, каналот го обновува статусот и дозволува
зависните канали за започнат

Предноста на оваа рамка е тоа што може да се справи со ограничувања каде

некој дел од работата не може да започне се додека друг дел не заврши.
Флексибилноста значително го зголемува бројот на ситуации во кои
микропаралелизмот може да се употреби. Примерот 9-43 покажува код со
потенцијални зависности. Опасноста е тоа што ист елемент на полето со вредности

63
може да биде покажан со повеќе индекси чување во индексното поле. Овој пример е
еден вид на редукција, па та атомската операција add може да се користи за да се
избегне потенцијална податочна трка. Микропаралалеизмот треба да ја изведува истата
задача, иако со доволно пречекорување. Целта на примерот е да прикажен структура
наместо потенцијални подобрувања во брзината.

ПРИМЕР ЗА КОД 9-43 Код кој содржи можни зависности помеѓу итерациите

Прва работа која секој канал треба да ја направи е да одреди која итерација е
одговорна за пресметување. Еден начин за тоа е прикажан на примерот 9-44.

ПРИМЕР ЗА КОД 9-44 Одредување на итерација за пресметка

64
 Кодот од примерот креира два канали. Тој користи променлива која ги задржува
каналите се додека двата не се креирани и работат. Откако двата канали работат, тие
работат низ главната јамка, и секој се обидува да појде на следната интерација.
Атомската инструкција Compare and Swap (cas) гарантира дека само едниот канал ќе ја
извршува секоја итерација. Откако каналот добие право да изведи одредена итерација,
тој повикува do_iteration routine за да изврши работата. Рутината do_iteration routine е
прикажана на примерот 9-45.

ПРИМЕР ЗА КОД 9-45 Код кој гарантира безбедно извршување на работата

65
 Кодот кон не работи мора прво да провери дека нема итерации кои ја користат
вредноста на индексот за таа итерација. Откако овој тест ќе помине, кодот изведува
сигурна пресметка со знаење дека ниту еден друг канам нема да чита или промени
елемент кој се пресметува.
Еден краен дел од кодот е потребен за иницијализација на индексните полиња и
вредности. Ова е прикажано на примерот 9-46. Кодот слободно сетира поле на индекси
за да покаже само првите 8 елементи од полето со вредности.

ПРИМЕР ЗА КОД 9-46 Код за иницијализација на полиња

Оваа деминстрација на микропаралелност докажува дека работата може да се

подели на повеќе канали. Меѓутоа, таа слабо покажува подобрување со брзината
бидејќи количината на работа изведена на секоја канал е намалена со
синхронизацискиот трошок. Очигледно, посложена пресмета за секоја итерација ќе
доведе до повеќе потрошено време во изведување на работата и соодветно помал дел
од времето ќе се изгуби на синхронизација.

66
9.3.11. Програмирање за пропусност

CMT процесорите воведуваат промена на начинот на кој програмерите

треба да пристапат кон брзината на апликацијата. Традиционалниот пристап е да се
направи сериска апликација, да се нагоди апликацијата со елиминирање на чекањата
како што се промаршувања на кеш, потоа откако чекањето е елиминирано, да се
разгледа паралелизација на апликацијата за дополнително подобрување на брзината.
За жал овој пристап води кон ситуација во која апликацијата веќе е доста
сложена пред да се разгледува паралелизам, па така паралелизмот често не е важна
задача. Ако ги разгледаме податоците за собирање на инструкциски броења опфатени
погоре, а сега во поглед на CMT, настаните на чекање веќе не се доминантен фактор
кој одредува брзина и броењето инструкции најверојатно ќе биде фактор за
подобрување на брзината.
CMT процесорите исто така имаат предност, наведено кај избегнувањето на
податочни трки, во тоа што трошокот за синхронизација на повеќе канали е подолг од
оној кај SMP систем. Оваа опсервација се совпаѓа во фактот дека голем број на
виртуелни процесори веќе можат да извршуваат вакви канали.
Овие фактори комбинирани за CMT процесорите (и со додатоците кај
процесорите во иднина, бидејќи скоро сите процесори ќе имаат одредена способност за
повеќеканалност) ќе доведат до максимални брзини кај повеќеканалните апликации,
кои потоа ќе може да се прилагодат да го намалат броењето инструкции (а можеби и
настаните на чекање).
За среќа, дизајнирањето на повеќеканални апликации од почеток ја избегнува
ситуацијата појавена претходно во која способноста за користење на повеќе канали
треба да се „заштрафи“ на постоечка сериска апликација.
Заклучокот е дека CMT процесорите промовираат дизајн на паралелни
апликации. Тие ги намалуваат или отстрануваат традиционалните бариери за
паралелизам, како што се трошок за синхронизација, намалуваат важноста за
елиминација на настани на чекање и овозможуваат голем број на канали за поддршка
на апликација.

67
10. Симулација, верификација и подигнување на системот
SPARC Architectural Model (SAM) е флексибилна, реконфигурабилна виртуелна
платформа за системска симулација. Таа дозволува корисниците да моделираат
различни SPARC системи. Виртуелната платформа има важна улога за системски
испитувања, софтверско подигнување и развој кога новиот хардвер е подготвен –
корисниците може да пуштат софтвер на симулиран систем дури и кога хардверот не е
достапен. Виртуелната платформа може да подигне Open Boot PROM (OBP) и Solaris
опративен систем и да креира околина многу слична со онаа креирана од реалниот
хардвер.

Други бенефиции може да се добијат од употребата на виртуелна платформа:

таа нуди подобра набљудливост отколку реалниот хардвер и креира подобра околина
за дебагирање и испитување на системот.

SAM доста се користи за собирање на траги во архитектурата од оптоварувања

(TPCC, SPECWeb, ICPERF, SPECJAppServer, ICPERF, SPECJbb, SPEC CPU, и слични).
Исто така се користи за моделирање на брзина, подигнување на систем, развој на
драјвери и системски софтвер и RTL верификација.

Оваа точка ги содржи следните подточки:

• Модел на SPARC архитектура

• Фајл за системска цонфигурација
• SAM Huron Sim архитектура
• Креирање на фајл за Root Disk Image
• Дебагирање со SAM
• Симулација со точни циклуси
• Верификација преку косимулација

68
10.1. Модел на SPARC архитектура

SAM го симулира системот кој се состои од следните компоненти:

• Еден или повеќе SPARC CPUs

• Физичка меморија (RAM)
• Сериски конзолен уред
• Подсистеми на диск (пример, SCSI, FibreChannel)
• Мрежни картички (пример, Gigabit-Ethernet device drivers—GEM и Cassini)

Бидејќи SAM може да работи на Solaris OS, поголем дек од функционалноста на

високо ниво направена во OS кернелот е достапна за симулација - TCP/IP, фајл
системи, кернел модули, кернел дебагер, повеќе корисници итн.
SAM е организиран како колекција од динамички вчитани модули кои
симулираат различни уреди. За да се вклучи симулаторот, главниот модул процесира
специјален конфигурациски фајл за да подигне и конфигурира други уреди кои го
сочинуваат симулираниот систем. Конфигурацискиот фајл содржи множество на
параметри за општа конфигурација, на пример: CPU и фреквенција на такт, број на
работни канали на машината за симулација на виртуелен процесор, параметри
карактеристични за платформата и околината, CPU и ниво на дебагирање. Тој исто
така нуди имиња и конфигурациски параметри за CPU и модулите на уредите во
стебло на уреди. Спецификацијата е слична со стеблото на уреди за Solaris; секоја
линија опишува уред и содржи параметри за симулирани уреди.
SAM може да работи во повеќеканален режим. Секој симулиран вирутелен
процесор и контролер на I/O уред може да се врзе со работата на каналот на различен
процесор. SAM е оптимизиран за симулација на мултипроцесорски систем.
Конфигурацискиот фајл мапира множество на симулирани виртуелни процесори за да
сетира канал на хост машината. На секој симулиран виртуелен процесор му е
дозволено да напредува независно во краток временски период. Меѓутоа, виртуелниот
процесор никогаш не е симулиран со повеќе од еден симулациски канал. Моделите на
уреди треба да имаат соодветен синхронизациски механизам за да обезбедат
интегритет на податоци во повеќеканална симулациска околина.

69
 SAM може да управува со време на симулација низ сите хост машини. Тој
имплементира редица на настани за да следи кога податоците од симулираните уреди
треба да се процесираат. Типична симулациска брзина е околу 6-10 MIPS.
SAM поддржува можност за отфрлање/враќање на системот. Симулацијата
може да се стопира во секое време за да се креира точка на проверка. Подоцна,
симулацијата може да се врати и започне од таа точка. Оваа карактеристика е корисна
за брз рестарт после долго подигнување и исто така за дебагирање.
SAM има вграден кориснички интерфејс (UI) базиран на едноставен и лесен за
употреба команден јазик. Тој има богато множество на основни наредби, на пример,
run и stop за симулациска контрола, break за да постави точка на прекин, read-reg за да
испита регистарски фајл. UI исто така поддржува скрипти напишани во Python.

Забелешка Python е избран бидејќи тој е моќен, портабилен, отворен, јазик со јасни
скрипти, и поддржува објектно-ориентирано програмирање, има пристап до голем
број на вградени и надворешни библиотеки и има лесен интерфејс за код напишан
во С или С++.

Два внатрешни интерфејси дозволуваат симулаторот да се преконфигурира:

• Виртуелен CUP (VCPU) интерфејс за plug-in CPU модели

• Интерфејс на модел за модул (MMI) за I/O модели. MMI се користи за
вчитување библиотеки, креирање на инстанци на уреди, мапирање на физики адреси на
I/O уреди, овозможува кориснички наредби специфични за регистри и друго

Забелешка: Важно е да се спомене дека SAM модулот не треба да биде реален уред.
Некои други симулациски компоненти, на пример, модулот за трагање,
дополнителни UI наредви, модел на време и слични треба да се добро
имплементирани како динамички вчитани библиотеки.

Следните подточки детално ги испитуваат следните својства на SAM:

• SPARC CPU
• VCPU интерфејс

70
• Device model interface (MMI)

10.1.1. SPARC CPU модел

SAM поддржува разни нивоа на SPARC CPU модели. CPU модел се

состои од бројни CPU јадра, и секое од нив содржи бројни модели на виртуелни CPU.
Структурата на функционалноста на CPU модел јасно го одразува реалниот хардвер.
CPU и мемориските модели може да се конфигурираат на минимална системска
конфигурација за верификација и почетен развој на системски софтвер.
Стандарден CPU вклучен во SAM не го моделира времето. Единечен
чекор (циклус) како Fetch, Decode, Execute, Retire и состојба на архитектурата е
имплементиран како една операција; со други зборови, CPU моделот е едноставен
симулатор на инструкциско ниво. Понапредни модели на време не се вклучени во
SAM.
Кешовите не се моделирани бидејќи не се потребни со SPARC
спецификацијата.

10.1.2. VCPU интерфејс

VCPU интерфејсот ги сокрива деталите за имплементација кои се

специфични за виртуелниот процесор. Тој е сложен интерфејс на виртуелниот CPU. За
CPU со повеќе канали, тој е претставник на секој канал; за CPU без канали, тој е
претставник на CPU. CPU модулот е направен како споделена библиотека. Неколку
инстанци од CPU објекти може да се креираат, и секој CPU објект може да има
неколку CPU јадра и секое јадро може да има неколку канали.
Интерфејсот ја крие хиерархиската природа на внатрешните структури на
CPU и претставува рамно поле за VCPU објекти. Моделот треба да е разделен за да
работи на различни канали на машината – методите на поврзување треба да се MP
безбедни.
VCPU интерфејсот си има следните компоненти
• Контролен интерфејс

71
• Системски интерфејс (меморија и I/O)
• Интерфејс за следење

Забелешка
Интерфејсот до модул за вчитување се состои од два елементи: извадени и
вметнати (увезени/извезени) интерфејси

Експортираните интерфејси се рутини во CPU модулот кои се повикуваат

надвор од модулот. Покажувачите на рутини достапни за CPU модулот се дефинирани
во експортирана интерфејс структура.
Импортираните интерфејси се рутини кои CPU модулот ги повикува за да добие
пристап до остатокот од системот. Овие интерфејси се дефинирани како импортирана
структура на интерфејс, која е множество на покажувачи кои ги користи CPU Модулот
за да испраќа барања до системски модули.
Така, контролниот интерфејс е дефиниран во VCPU експортиран интерфејс, а
системскиот и трагачкиот интерфејс се дефинирани како импортирани.

10.1.2.1. Контролен интерфејс

Контролниот интерфејс дозволува корисниците да креираат, уништуваат,

ресетираат, зачувуваат и враќаат VCPU инстанци и за пристап до видливи состојби во
архитектурата за сите виртуелни процесори во системот.
Даваме пример за креирање на vcpu инстанца.

ПРИМЕР ЗА КОД 10-1 Креирање vcpu инстанца

72
 Откако vcpu инстанцата е креирана, VCPU методите може да пристапат до
состојба на таа инстанца. Контролниот интерфејс има методи за читање и запишување
на регистарска состојба, n број на инструкции или циклуси на напредна симулација,
точки на прекин за поставување и бришење, преведена адреса во моменталната vcpu
содржина итн.
VCPU контролниот интерфејс дозволува корисниците да фатат надворешен
дебагер на системско ниво или модул на кориснички интерфејс.

10.1.2.2. Системски интерфејс

CPU модулот инпортира системски интерфејс за да пристапи до остатокот од

системот – множество на покажувачи кои се праќаат до VCPU во времето на креирање.
Тој има методи за пристап до меморија и I/O адресен простор.
Меморијата е претставена како сложен интерфејс за да моделира разни нивоа на
мемориска хиерархија, вклучувајќи L2 и L2 кешови. Моментално се користат, модел на
разна меморија и модел на рамна меморија. За подобра брзина, опцијата за мемориски
модел е дефинирана во времето на изградба наместо во времето на работа.
Модели на кеш не се достапни.

10.1.2.3. Интерфејс за следење

Vtracer интерфејсот е аложен интерфејс за поврзување на различни

анализирачки и брзински модели. CPU моделот повикува Vtracer методи за да даде

73
комплетна информација за примени во состојбата на архитектурата при секоја
инструкција.
Информацијата за секоја инструкција се собира во специјална
инструкциска структура која ги акомулира промените на вредностите на состојбата за
секој VCPU. Одделна структура собира информации за стапици и обновувања на TLB.

10.1.3. ММI

Module Model interface (MMI) дозволува корисниците да приклучат модул

на уред во SAM симулаторот. Сите API функции и имиња на типови се со префикси
mmi_ prefix. Модел на уред е изграден како споделена библиотека која динамички се
вчитува во SAM за време на иницијализацијата.
MMI овозможува работна околина за следното:
- Вчитување на динамичка библиотека на модел
- Конфигурирање на модул, известувајќи ги инстанците на модулот за
одредени настани (како што се собирање или пришење на друг модул)
- Обезбедување механизам за операции dump и restore
- Справување со интерфејсите за увоз/извор на модул
- Поддршка за редица на настани кои го моделираат времето
- Нудење на информација за модулот

Протоколот за тоа како SAM модулите комуницираат меѓусебе зависи од

договорените интерфејси кои ги разменуваат преку MMI.
Дел од MMI е поспецифична за одредени типови на уреди, на пример,
магистрални мостови, некои други уреди (како единица на системски интерфејс (SIU),
ROM, TOD, конзоли) кои се прикачени на магистралата на симулиран систем. Акциите
кои ги вклучува дел од MMI се следни:

• Пристап до меморија
• Сигнализирање на прекин

74
• Мапирање на делови од просторот на I/O физички адреси
• Мапирање на некои специфични ASI регистри

MMI интерфејсот е глобална рутина достапна за секој модул да пристапи до

симулирана меморија и да испрати прекини до дестинациски виртуелен процесор.
Севкупно, MMI интерфејсот е доволно генерички за да овозможи основа за
градење на флексибилен системски симулатор.

10.1.3.1. SAM конфигурациски фајл

SAM конфигурацискиот фајл ги опишува сите уреди во симулираниот систем.

Sysconf наредбите во конфигурацискиот фајл одредуваат модул на уред, име на
инстанца и придружни својства. Секоја sysconf линија одредува модул кој е вчитан,
доколку тоа е неопходно, и име на јазолот на уред кој треба да се подигне, проследено
со придружни својства со инстанца во форма на паротви name=value. Моделот на иред
изграден како заеднички објекти (.so фајл) обично има само еден модул кој се
приклучува на SAM. Внатрешно, во моделот на уредот, може да постои хиерархија на
компоненти.
Инстанцата всушност е таа која го претставува уредот во SAM. Главно постојат
повеќе инстанци на даден модул на уред. Секоја инстанца може да се референцира со
opaque mmi_instance_t хендлер. Овој хендлер се користи од модулот за да покаже на
нековата инстанца како и на други инстанци за да добие извезен интерфејс. SAM чува
листа на сите достапни вчитани модули на уреди. Хендлерот на модулот може да се
добие преку името на модулот.
За точно подигнување на јазол на уред, SAM повикува инстанца на
подигнувачка функција регистрирана во модулот на уредот.

10.1.3.2. Вчитување и (вадење) бришење на модул

Модулите може да се вчитаат во било кој редослед како што е одредено во

конфигурацискиот фајл. Во некои случаи (модул за трагач на пример). Модулите може

75
да се извадат во секое време. Секој модул е известен кога друг модул менува статус. За
да се овозможи комуникација мешу модулите, секој модул треба да добие извезен
интерфејс – покажувачи до интерфејс рутини. Кога модулот се вади, други модули
треба да примат соодветена нотификација на конфигурациска промена и да ги
отстранат нивните покажувачи до извадениот модул.

10.1.3.3. Подигнување на модул

Секој модул има метод на иницијализација кој треба да се повика за да се

креира инстанца од овој модул. Така, прва работа која модулот треба да ја направи кога
неговата библиотека е вчитана во регистар со SAM симулатор е да покаже на
иницијализациски метод. Инстанца на иницијалзирачка функција е повикана од SAM
секогаш кога нова инстанца на модулот е креирана – обично кога соодветната линија
во фајлот за системска конфигурација е процесиран. Хендлер на инстанцата opaque се
користи во MMI повиците за да пристапи до методи за одредени инстанци на модули.
Нормално, инстанца за иницијализирачка рутина ќе ги парсира конфигурациските
параметри од конфигурациската линија за да најде на кој опсег на адреси модулот за
уред треба да биде мапиран. Таа исто така регистрира и неколку други рутини кои се
повикуваат за следните цели:
- За да се добие инфпрмација за модул. Оваа функција е повикана преку
modinfo наредбата на корисничкиот интерфејс. Таа ги вади сите важни
информации за модулот
- За да се добие интерфејс за модул. Тука, интерфејс значи договор помеѓу
клиент на интерфејс и провајдер
- За да ги извести модулите за друг модул кој е вчитан или изваден
- Да чита или запишува кога се пристапува до опсег на I/O адреси на кој е
мапиран модулот

76
10.2. Системски конфигурациски фајл

SAM Модулот е споделен објект (ELF фајл), и обично содржи

имплементација на одреден модел на уред: на пример, SAS контролер или можеби
симулациски објект, на пример, PCIE магистрала; па дури и комплетен псевдо уред, на
пример LL (Local Loopback file system) уред. Секој динамички вчитан споделен објект
кој ја следи семантиката на MMI на SAM (mmi. h) може да се нарече SAM модул.
Sysconf е наредба за спецификација на модул во SAM. Таа одредува кој
модул да се конфигурира во одредена симулациска инстанца во SAM. Наредбите се
специфицирани во конфигурацсиски фајл кој е процесиран од SAM, по еден во линија.
Така, sysconf наредбата одредува конфигурација на симулиран систем.
Откако еднаш е вчитан, модулот на уред не може да се изнесе на среде
работа.

10.2.1. Формат на sysconf наредбата

Каде

• mod-name — Имe на SAM модул. Тоа е идентификатор на споделен објект без

наставка .so; на пример sas e mod-name за SAS контролер чија имплементација
подлежи на sas.so.
• instance-name — Уникатно име на инстанца на овој модул во SAM конфигурација.
Можно е да постојат повеќе инстанци на модул на единечна конфигурација (ако е
дозволено во семантиката на модулот). Сите имиња на инстанци во одредена
симулациска инстанца (било да е ист или различен модул) мора да се уникатни,
спротивно, SAM знаменцето дава фатална грешка. Бројни модули опционално
поддржуваа UI наредба со исто име како и името на инстанца (ова се гледа во
помошникот за instance-name).
• arg-name — Име на конфигурациски параметар поддржан од модулот. Модулот
може да има нула или повеќе такви параметри. Аргументот може да е наопходен

77
 или опционален. Неговата бредност може да биде булова (значи дали постои или не
вредност на параметрот) или може да има arg_value.
• arg-value — Дел од вредноста на парот name=value на конфигурацискиот
параметар на модулот. Семантиката и легалните вредности на arg-value се
дефинирани од одреден модул. На пример, конзолен модул може да поддржи
конфигурациски параметар bg_color. Корисникот може да постави вредност на овој
параметар на валидна вредност, како што е црна. Ова ќе се појави во линијата на
sysconf наредбата како bg_color=black. Конфигурациските параметри и нивните
валидни вредности се разликуваат од модул до модул и се дел од документацијата
специфична на модулот. Конфигурациските параметри се интерпретирани од
индивидуални модули
• ddebug-level — опционално знаменце за дебагирање поддржано од одреден
модул. ddebug-level може да биде 0, 1 или 2, со 0 исклучен (исто како –d да не е
присутно) , 1 (verbose), и 2 (verbose++). Семантиката на нивото и дадената
информација се разликуваат од модул до модул. Обично модулот ќе извезе UI
наредба која може да ја промени вредноста на знамето за време на работата.
• mod-path —Во вообичаена SAM инсталација, модулите се сместени во install-
dir/lib директориум и SAM бинарностите во install-dir/bin. SAM ги заклучува
модулите во $ORIGIN/../lib. Меѓутоа, корисникот може да одреди сопствено место
пример -p mod-path, каде SAM ќе погледне прво во mod-path за модули. Секоја
sysconf –p додава патека за проверка, прегледана во LIFO редослед, и последната е
$ORIGIN/../lib. Се препорачува да се користи првичната патека за проверка.

Забелешка
Спецификацијата за наредбата sysconf за CPU е малку различна. mod-name
секогаш е cpu. arg-value od arg-name cpu типот одредува CPU библиотека за
вчитување. На пример, T2 CPU е конфигуриран како

CPU библиотеката во овој случај е libriesling_n2_vcpu.so, вчитана од $origin/.

./lib.

78
10.2.2. Примери

Овој дел прикажува примери за наредбата sysconf.

Во продолжение се вчитува наредбата ioram.so и креира инстанца од ioram
called obp. (ioram е модул кој омплементира ROM). Модулот вчитува фајл openboot.bin
во симулиран ROM на PA FF F008 0000jg. Големината на ROM e 8000016 бајти.

Следните два примери покажуваат како се креира хиерархија на стебло на уреди

со наредбата sysconf. Тука SAS контролерот sas0 е поврзан за PCIE магистралата
pcie_a, која е поврзана за хост магистрален мост piu.
Наредбата од подолу креира инстанца од pcie_bus модулот и ја именува pcie_a.
Магистралата е нагорна. Името на инстанцата на мостот е piu.

Наредбата од подолу креира SAS контролер со име sas0 и го поврзува со PCIE

магистрала именува pcie_a. Контролерот е поврзан со уред 0, функција 0 на PCIE
магистралата. Параметрите на целите даваат информација за целните SCSI дискови
прикачени за sas0.

79
10.2.3. Симулирано време во SAM

STICK регистарот овозможува синхронизиран, системски такт кој се

користи за временско следење со висока резолуција. Првите UltraSPARC процесори
кои не поддржуваа STICK регистар користеа бројач, наречен TICK регистар,
погонуван од брзината на тактот на CPU. Согласно, процесорите кои работат на
различни брзини ќе ги прикажат таквите TICK регистри кои се зголемуваат при
различни брзини. За да се моделира време во симулаторот, мора да дефинираме
политика за тоа кога и каде ќе се обновува вредноста на STICK регистарот.
SAM има два параметри кои влијаат на тоа како се одржува времето во
SAM.

- mips — одредува колку често STICK регистарот е инкрементиран. На

пример, ако mips е поставено на М, SAM ќе го инкрементира STICK на
секои М инструкции. Ако постои повеќе од еден CPU, STICK е
инкрементиран после извршување на М инструкции на секој CPU.
Вообичаена вредност на mips е 1000 (1 милијарда инструкции/CPU/sec).
mips вредноста е конфигурирана во rc фајл на почеток, користејќи conf
наредба, на пример, conf mips 1000. За работа под клупи за тест, mips
вредноста е добиена од cpustat бројачите. Mips параметар може да биде
променет во било кое време на симулацијата.
- stickfreq — одредува за колку е инкрементиран STICK регистарот при секоја
mips инструкција. На пример, ако фреквенцијата на STICK е поставена на
1.4 GHz (stickfreq = 1.4 billion) и mips е 1000, тогаш STICK е инкрементиран
1400 на секои 1000 инструкции.
STICK фреквенцијата е поставена со conf наредбата во rc фајлот на почеток,
на пример, conf stickfreq 1417000000. STICK фреквенцијата може да не се
промени после иницијализазија. Треба да се напомене дека STICK
фреквенцијата конфигурирана во SAM треба се се совпаѓа со STICK
фреквенцијата одредена во описот на машината на гостинскиот OS. Ако не
се совпаѓаат, тогаш симулираниот OS може да гледа време кое е различно од
корисничките подесувања.

80
 Така, најмалата единица на симулирано време во SAM е 1 микросекунда. На
пример, ако mips=M и stickfreq = N, SAM извршува M инструкции пред да го
инкрементира STICK регистарот за N/106. Ова е 1 микросекунда во
симулацијата.

Симулираното време може да се гледа на SAM преку модел на уред за време во

денот (tod) на ниво на дебагирање 2. Тоа треба да се совпаѓа со времето на работа и
излезната наредба за датум во симулиран Solaris. Треба да се води сметка да се
постават mips и stickfreq на разумни вредности.

81
10.3. SAM Huron Sim архитектура

Да разгледаме пример на конфигурирање на симулациска платформа

наречена Huron. Таа не треба да се помеша со систем за продукција; не постои реален
производ со конфигурација како Huron кој тука е опишан.
Важно е да се забележи дека некои I/O модули може физички да постојат
на процесорскиот чип. Huron e само модел кој се состои од колекција на компоненти
конфигурирани да формираат симулиран систем.
Слика 10-1 е преглед на сите главни компоненти на T2 Huron SAM
симулациска платформа. Деталите за секој главен модул се опишани подоцна.
Huron SAM симулациската платформа е симетричен микропроцесорски
систем кој се состои од хомогени повеќеканални SPARC јадра споени со општ
мемориски подсистем. Слика 10-1 прикажува CPU модул прикажен за VCPU интерфејс
и I/O корен прикачен за MMI. UI, кој е интегрален дел од главниот SAM модул,
дозволува корисниците да го контролираат симулираниот систем.
PCIE-to-PCI мостот може да се замени со PCIE премостувач, со PCIE-to-
PCI мостови прикачени за надолните порти. Други PCIE уреди (пример мрежни
контролери) може да се поврзат или за PCIE магистралата или директно на надолните
порти на свичот.
SwitchSim моделира мрежа и исто така синхронизира неколку SAM
симулациски околини. Модулите за кнтролер на мрежен интерфејс (GE и CE) се
вклучени во дијаграмот поради целосност. Моделирањето на SAM мрежата не е
опишано во ова подглавје.

82
СЛИКА 10-1 Преглед на главни компоненти на Huron SAM симулациска
платформа

10.3.1. Пример за конфигурациски фајл за T2 Huron на SAM

Следува пример за конфигурациски фајл за T2 Huron систем. Фајлот започнува со

конфигурациски параметри заеднички за целиот систем: големина на симулирана
меморија, параметри за брзина на системот, фајлови кои треба да се вчитаат за

83
симулирана меморија и име на директориум каде може да се најде модул за уред.
После тоа, секој модул за уред е конфигуриран од одделна sysconf линија. На крај,
sysconf линиите опишуваат стебло на уреди на Huron систем.

84
ПРИМЕР ЗА КОД 10-2 Пример за конфигурациски фајл за T2 Huron на SAM

85
10.3.2. Модул за сериски уред

Модулот за сериски уред (serial_4v) е уред со виртуелна конзола

употребен за OBP. Имплементацијата се базира на својството tip. Модулот нуди UI
наредби и можност за логирање.

Формат sysconf форматот за овој модул е

Каде
- Base е почетна адреса на мемориски мапирана адреса на CSR на уредот
- Size е големина на CSR простор за овој уред.
- Log e опционален булов аргумент кој дозволува логирање на влезови и
излези на конзолата. Ако аргументот дава filename аргумент тогаш конзолата
е логирана во filename. Ако filename не е дадено, тогаш лог фајлот е serial-
instance-name.log. Фајлот се отвора во опаѓачки режим па така претходните
содржини не се губат за време на повеќето пуштања.
- Pop е опционален булов аргумент кој, доколку е понуден, доведува до xterm

86
 прозорец, со tip својство кое веќе работи на него за да го вклучи при старт.
DISPLAY променливата треба да се постави соодветно за ова да работи
точно. Ако pop не е присутен, тогаш корисникот ќе треба да „типува“ во
конзолата од постоечки xterm прозорец.

Забелешка
sam –w опцијата за sun4u систем не е поддржана од овој модул

- fg, bg, font се опционални аргуемнти за поставување на преден план,

позадина и фонт на текст во xterm прозорецот
Забелешка
Корисниците треба да обезбедат fg, bg, font да бидат валидни влезови во xterm
програм. Xterm треба да биде kill и pop (UI подолу) за новите fg, bg, font да имаат
ефект.

- dnkxoe – опционално, не го затвора xterm при излез. Предодрено е

прозорецот да биде затворен
-
sysconf примери за формати

UI команди UI формат за модул на сериски уред е

serial-instance-name command command-args

Модулот ги поддржува следните UI команди:

87
send some-char-string — Ехо на низа од карактери отворена со нова линија на конзолата
sendfile filename — Ехо на содржината на filename на конзолата
Забелешка
Горните наредби симулираат влез од конзолата; излезот кој е ехо на xterm
зависи од Solaris/OBP серискиот драјвер.

debug [level] — Се поставува ниво на дебагирање за дебагот да извади level. Ако level
не е овозможено, се добива тековното ниво на дебагирање
level = [0|1|2]

pop — се вклучува xterm конзола ако веќе не е вклучена

kill — ја затвара xterm конзолата ако е отворена.
fg [color] — Поставува боја на преден план на xterm во color; спротивно; дава инфо за
моменталната боја.
bg [color] — Поставува боја на позадината на xterm во color; спротивно, дава
информација за моменталната боја.
font [font] — Поставува фонт на xterm во font; спротивно дава извештај за
моменталниот фонт.

Пример за UI формат

Следниот пример, базиран на sysconf линијата во примерот за формат од погоре,

испраќа sends “show-devs\n” до гостинската конзола. Ако инструкцијата е откуцана на
OBP ок линијата, овој пример ќе прикаже стебло на уреди.

run: guest-console send show-devs

Mod Info

modinfo serial-instance-name овозможува информација поврзана за инстанцата, на

пример за tip уред:

88
 За да се добие погорната информација, се внесува help serial-instance-name
во линијата на SAM UI.
Пример: help guest-console

10.3.3. NCU модул

NCU модулот (n2_ncu) имплементира функционалност на T2
некешибилната единица (NCU) на T2 чиот. Таа ги снабдува PCI-Express I/O, Mem, и
Config мапирањата, како и прекини до SAM VCPUs.

формат sysconf формат на модулот е

sysconf n2_ncu ncu-instance-name [-d[0|1|2]]

каде
-d е опционален аргумент кој поставува дебагирачко ниво 0, 1 или 2.

Пример за sysconf формат

sysconf n2_ncu ncu -d2

UI команди UI формат за NCU модул е

ncu-instance-name command command-args ...

NCU модулот поддржува следни UI наредби:

• dump [filename] — за отфрла CSR содржината во filename. Преддефинирано е
stderr. dump формат е
csr-name csr-offset csr-value

• restore filename — Враќа CSR содржина од filename. Форматот е исто како и

форматот за dump.
• debug [level] — Поставува ниво на дебаг за дебагирање. Печати level. Ако level не е

89
 овозможено, го принта тековното ниво на дебагирање

level = [0|1|2]

dump наредбата може да се користи за добивање слика од CSR содржината во секое

време. Ново 2 на дебагирање покажува CPU пристапи до овој модул

Mod Info
modinfo ncu-instance-name овозможува информација за доделување на физички адреси
на Т2 PIU мапирања на PCIE IO/MEM/CONFIG простор.
За да се добијат овие податоци, се пишува help ncu-instance-name во SAM UI.
Пример: help ncu

10.3.4. PIU модул

PIU модулот (n2_piu) имплементира функционалност на T2 PCI-Express

интерфејсот (PIU) на Т2 чипот. Моделот е модуларен до SAM MMI и е проширен за
прекини од уреди. Способноста за dump и restore исто така е додадена.

Формат sysconf форматот на овој модул е:

sysconf n2_piu piu-instance-name bus=pcie-bus-instance-name ncu=ncu-instance-name -d[0|

1|2]
каде

• bus е инстанца од името на модулот на SAM PCI-Express магистралата поврзан со

надолниот порт на оваа инстанца (pcie_bus).
• ncu параметарот е име на T2 NCU модел во SAM rc фајлот (n2_ncu).
• -d е опционален аргумент кој сетира ниво на дебагирање 0, 1, или 2.

sysconf пример на формат

90
sysconf n2_piu piu bus=pciea ncu=ncu

UI команди UI формат за PIU модулот е piu-instance-name command command-args.

Модулот поддржува следни UI наредби:
• dump [filename] — ja frla на CSR содржината во filename. Предодредена е stderr.
• restore filename — враќање на CSR содржината од filename. Форматот е ист како и
за dump.
• debug [level] — Се поставува нивото на дебагирање за да се добие level. Ако level
не е овозможено, го печати тековното ниво.
level = [0|1|2]

Наредбата dump може да се користи за добивање на слика од CSR содржината.

Ниво 2 на дебагирање може да се постави за преглед по потреба на пристапите на
читање/запишување до CSR, превод на адреси од витуелни во физички, прекини на
уреди инт.

Пример за дебагирање Следните пример се базирани на sysconf линијата погоре.

Овој пример поставува знаменце на порака за дебагирање на 2:
piu debug 2

Овој пример прави слика од CSR содржината:

piu dump

Mod Info
modinfo instance-name овозможува дополнително мапирање на физички адреси на оваа
инстанца во адресниот простор на T2 I/O.
За да се добие информацијата, се пишува help piu-instance-name во SAM UI линијата

Пример: help piu

91
10.3.5. IORAM модул

IORAM модулот (ioram) имплементира RAM/ROM во адресниот простор

на I/O на процесорот (на пример, ROM за подигнување може да се имплементира со
овој модул). Во подесувањата на Huron, овој модул се користи за вчитување reset .bin,
q.bin (Hypervisor), и openboot.bin (T2 OBP) како инстанци на ioram уред.

Формат sysconf форматот на овој модул е

sysconf ioram ioram-instance-name start_pa=addr size=size [file=name
[addr=load-addr]] [rw|ro|wo] [sparse|flat] [-d[0|1|2]]

каде

• start_pa е стартна адреса на мемориски сегмент во I/O просторот на процесорот

• Size е големина на мемориски сегмент
• file е опционален аргумент, кој ако е овозможен, вчитува мемориски сегмент со
содржина на тој фајл. Ако овој аргумент не е овозможен, тогаш сегметот се полни
со 0.
Форматите на фајлови кои се поддржани се.bin, .img, и .elf. Името на фајлот мора да
ги има овие екстензии со цел да се препознае типот.
• addr има цел да вчита адреса во случај на .bin и .elf фајлови. .img фајловите не
треба да го снабдуваат овој аргумент.
• rw е опционален булов аргумент кој прави овој сегмент да чита/запишува. Само
еден од rw, ro, wo мора да биде додаден. Преддефиниран е rw.
• ro е опционален булов аргумент кој го прави сегментот read-only.
• wo е опционален аргумент кој го прави сегментот write-only.
• sparse е опционален булов аргумент кој го празни типот на сегмент.
• flat е опционален булов аргумент кој го порамнува сегментот. Само два од овие
сегменти мора да бидат додадени

Забелешка:
Моментално е поддржан само sparse моделот. Исто така тој е и преддефиниран.
• -d е опционален аргумент кој поставува ниво на дебагирање 0, 1, или 2.

92
sysconf пример за формат Два примери на формат на IORAM модул се прикажани
подолу

UI команди UI формат на IORAM модулот е

ioram-instance-name command command-args ...

Модулот ги поддржува следните UI наредби:

• write addr value size — Запишува size бајти на адреса addr каде size = [1|2|4|8]
• read addr size — Чита size бајти од меморија на адреса addr каде size = [1|2|4|8]
• dis addr [n-instr] — расклопува n-instr инструкции (default 1) почнувајќи од адреса
addr.
• dump addr size [ format] — ги отвфрла size бајтовите на меморијата на stdout, каде
format е [x|d|c|o]. Преддефинирано е x.
• save filename [addr [size]] — Чува мемориска содржина во filename почнувајќи до
addr за size бајти. Ако не е специфициран аргумент addr и size, ги зачувува сите.
Ако addr е обезбедено а size не, зачувува до крај.

Сите нумерички вредности се очекува да бидат децнимални, окталнио или хексални.

Addr аргументот е абсолутна физичка адреса

dis Example Селдниот пример базиран не sysconf линијата од погоре, печати

расклошување на 256 инструкции од openboot.bin, почнувајќи од адреса
FF F008 0000^.
obp dis 0xfff0080000 0x100

Mod Info

modinfo instance-name овозможува дополнителна инстанца – одредена информација

како што е мапирање на физичка адреса на оваа инстанца во SAM I/O адресниот
простор, вчитува име на фајл итн.

93
 На пример, modinfo obp печати следна информација:

За да се добие оваа информација, се пишува help ioram-instance-name во SAM UI

линијата.

Пример:help hv

10.3.6. Модул за време од денот

Модулот Time-of-Day (tod_4v) имплементира виртуелен уред за време од

денот. Модулот допушта опционално подесување на време од денот. Тој исто така
одржува точно време на денот според глобалното време на SAM. Ова значи дека во
точно конфигурирано подесување, нема да има погрешни податоци за времето од
денот кај Solaris или пак прекорачување на часовникот за време од денот треба да се
случи.
При ниво на дебагирање 2, овој модул печати време на „симулиран“
систем на секоја симулирана секунда (ова може да се покаже ако симулираниот систем
изгледа спор – симулираното време може да се движи поспоро заради конфигурациски
параметри).

Формат sysconf форматот на овој модул е

sysconf tod_4v tod-instance-name base_pa=start-addr size=map- size
[tod=mmddHHMMSSyyyy] [-d[0|1|2]]

каде

• base_pa e стартна адреса на мемориски мапирана адреса на CSR на уредот.

• size е големина на CSR простор.
• tod е почетна вредност на времето од денот. Ако не постои, се чита системското
време. Форматои на TOD низи се
• mm - месец

94
• dd - ден
• HHMMSS – часови, минути, секунди
• yyyy – година, треба да е пред 1970
• -d е опционален аргумент кој поставува ниво на дебагирање 0, 1, или 2.

sysconf формат следниот пример поставува време 12 a.m. Jan 1, 2000.

sysconf tod_4v tod base=0xfff0c1fff8 size=0x8 tod=01010000002000 -d2

UI наредби UI форматот на модулот Time-of-Day module е

tod-instance-name command command-args ...

Модулот ги поддржува следните UI наредби:

• debug [level] — поставува ниво за дебагирање за печатење на level. Печатење на
тековниот tod секоја симулирана секунда и печатење на вкупното симулирано
време. Ако level е оневозможен, го печати тековното ниво на дебагирање.
level = [0|1|2]

Забелешка
Симулациското време на Solaris и tod симулациското време се совпаѓаат само
ако фреквенцијата на Solaris STICK е иста со фреквенцијата на SAM STICK.

Mod Info
modinfo tod-instance-name овозможува информација за инстанцата како што е времето
од денот.
За да се добие горната информација, се пишува help tod-instance-name во SAM UI
линијата.
Пример:
help tod

10.3.7. PCI-E Bus модул

95
 PCI-E Bus модулот (pcie_bus) имплементира апстракција на PCIE магистралата.
Тој рутира нагорни/надолни пристапи помеѓу мостот и надолните уреди. Тој одржува
I/O, Mem I Config просторни мапи на надолните уреди. Тој имплементира интерфејс на
SAM PCIE магистралата и рутира пристап со употреба на SAM PCIE интерфејс. Ова е
генеричка имплементација на PCIE мостен уред.

Формат sysconf форматот на модулот е

sysconf pcie_bus pcie-bus-instance-name bridge=upstream-bridge- name [-d[0|1|2]]

каде

• bridge е име на нагорен мостен уред. Тоа може да биде n2_piu, hammerhead, fire,
итн.
• -d е опционален аргумент и поставува ниво на дебагирање 0, 1, or 2.

sysconf пример на формат

sysconf pcie_bus pciea bridge=piu

UI наредби Овој модул моментално не поддржува UI. Нивото на дебагирање се

поставува само низ sysconf линијата. Дебагирање на ниво 2 покажува трансакции по
потреба кои се прават на магистралниот интерфејс.

Mod Info
modinfo pcie-bus-instance-name овозможува информација за просторни мапирања на
PCIE I/O, Mem, и Config за надолни уреди поврзани на магистралата.

Пример за излез

96
10.3.8. PCIE-PCI Bridge модул

PCIE-PCI Bridge модулот (bridge) е функционален модул за Intel 41210 PCIE-PCI

мост.
формат sysconf форматот на модулот е
sysconf bridge bridge-instance-name bus=primary-pcie-bus dev=device fun=function
secbus=secondary-pci-bus

каде

• primary-pcie-bus е име на инстанца на модул на PCIE нагоре по магистралата.

• device е број на уред на мостот на нагорната PCIE магистрала.
• function е функциски број на мост на нарогна PCIE магистрала.
• secondary-pci-bus е име на инстанца на модул на PCIE надолу по магистралата.

sysconf пример за формат Следните три линии конфигурираат нагорна PCIE

магистрала наречена pciea, надолна PCI магистрала наречена pcia, и PCIE-PCI мост
наречен b0, соодветно.
sysconf pcie_bus pciea bridge=piu

sysconf bridge b0 bus=pciea dev=0 fun=0 secbus=pcia sysconf pci_bus pcia bridge=b0

UI наредби UI форматот за PCIE-PCI Bridge модул е

bridge-instance-name command command-args ...

PCIE-PCI мостот, b0 поддржува следни UI наредби:

• debug [level] — Поставува ниво на дебагирање за печатење на level. Ако level не е

97
 овозможено, се печати тековното ниво.
level = [0|1|2] .

• dump [filename] — Ја отфрла PCIE CSR содржината на filename .pcie во тековниот

раоботен директориум, а преддефинирано е stderr. dump форматот е csr-pciconf-
offset csr-value csr-rw-mask csr-size csr-name
• restore filename — Ја враќа PCIE CSR содржината од filename .pci во cwd. Фајл
форматот на враќањето е исто како за dump.

Ниво 2 на дебагирање покажува на CSR пристап и промена на вредноста во случај

на запишувања. Наредбата dump може да се користи за добиве слика од CSR
содржианта со секое време.
dump пример Примерот е базиран на погорната sysconf линија.

Mod Info
modinfo bridge-instance-name покажува информација специфична за модулот.
За да се добие таа информација, се пишува bridge-instance-name на SAM UI линијата.
пример: help b0

98
10.3.9. PCIE-PCIE Bridge модул

PCIE-PCIE Bridge модулот (pcie_bridge) е функционален модел за PCIE-

PCIE мост компонентата на PLX 8532. Свичот е составен од конфигурација на одделни
PCIE мостови поврзани со внатрешна PCIE магистрала во sysconf фајл. Слика 10-2
прикажува таква конфигурација.

СЛИКА 10-2 Пример за конфигурација на PCIE-PCIE Bridge модул

Модулот прикажан на слика 10-2 може да го замени PCIE-PCI мостот со

системскиот дијаграм на Huron.

format sysconf форматот за одделен PCIE мост е

sysconf pcie_bridge instance-name bus=upstream-bus secbus=downstream-bus
dev=device-number [upstream]

каде

• bus е нагорна магистрала за оваа инстанца.

• secbus е второстепена магистрала за оваа инстанца на мост.
• dev е број на уред на нагорната магистрала.
• upstream е булов параметар кој одредува мост во вид на нагорна порта. Ако не
постои, мостот е надолна порта.

sysconf примери Во следните примери за конфигурација, порт 0 е нагорен порт, и

портовите 1, 2, 8, 9 се надолни портови. Се забележува дека постот е исто со dev.
Корисниците може да додадат порти 3, 10, и 11.

99
Нагорен порт—pcie_a е примарна магистрала на нагорен мост:
sysconf pcie_bridge b0 bus=pcie_a dev=0 fun=0 secbus=pcie_int upstream

Внатрешна виртуелна PCIE магистрала:

sysconf pcie_bus pcie_int bridge=b0

Надолни портови поврзани на нагорно на pcie_int

Надолни PCIE магистрали:

sysconf pcie_bus pcie_b bridge=b1 sysconf pcie_bus pcie_c bridge=b2 sysconf pcie_bus
pcie_d bridge=b3 sysconf pcie_bus pcie_e bridge=b4

UI наредби UI форматот на PCIE-PCIE Bridge модулот е bridge-instance-name command

command-args . . .
Модулот ги поддржува следните UI наредби:
• debug [level] — Поставува ниво на дебагирање за печатење на level. Ако level не е
овозможено, го печати тековното ниво.
level = [0|1|2]

• dump [filename] — Ги исфрла PCIE CSR содржините на filename.pcie во cwd.

Преддефинирано е stderr. Dump форматот е csr-pciconf-offset csr-value csr-rw-mask
csr-size csr-name
• restore filename — Враќа PCIE CSR содржини од filename. pci во cwd. Форматот на
фајл за враќање е исто со фајл форматот на dump.

Ниво 2 на дебагирање покажува CSR пристап и промена во вредностите во случај

на запишувања. Наредбата dump може да се користи за добивање слика од CSR во
секое време.
dumpпример Примерот, базиран на погорната sysconf линијапечати PCIE регистарска
вредност на stderr.

100
stop: b0 dump

Mod Info
modinfo bridge-instance-name покажува информации специфични за модулот. За да се
добие погорната информација се пишува help bridge-instance-name во линијата на SAM
UI.
Пример: help b0

10.3.10. Сериски прикачен SCSI модул

Сериски прикачениот SCSI модул (sas) имплементира функционалност на

сериски прикачен контролер за SCSI (SAS) диск. Тој моделира LSI SAS1064E, дизајн
кој е базиран на Fusion-MPT (Message Passing Technology) архитектурата. Модулот има
PCIE интерфејс низ кој контролерот може да се поврзе на секоја PCIE магистрала.
Секој контролер може да поддржи до 4 SAS дискови. Оваа имплементација не
вклучува модел на време, па така I/O барањата се опслужени и комплетирани веднаш
после нивно добивање во контролерот, без да се земе во предвид доцнење на
симулиран диск. SAS дискот е имплементиран согласно на генерички модел на диск.

Формат sysconf форматот на модуло е

sysconf sas instance-name bus=bus-name dev=device-id fun=function-number
targets=init-file [-d[0|1|2]]

каде

• instance-name е име на овој контролер.

• bus-name е име на PCIE магистралата на која се прикачува контролерот.
• device-number е број на PCIE уред.
• function-number е функциски број на PCIE.
• init-file е конфигурациски фајл за прикачени SAS дискови.
• -d е опционален аргумент кој поставува нивоа на дебагирање 0, 1, или 2.

sysconf пример за формат

101
 SAS контролер наречен sas0 е прикачен на PCIE магистрала pcie_a како уред 0,
функција 1. Конфигурацијата за прикачените дискови е во фајлот sasdisk.init. Нивото
на дебагирање е поставено на 2.

sysconf sas sas0 bus=pcie_a dev=0 fun=1 targets=sasdisk.init -d2

UI наредби—Овој модул

UI форматот за овој модел е

instance-name command command-args

UI наредбите за овој модул се следните:

• debug [level] — Поставува ниво на дебагирање за дебагирањето да испечати level.
Ако level го нема, се печати тековното ниво.
level = [0|1|2]

• disk — Ги прикажува сите прикачени дискови.

За да се добие оваа информација се пишува instance-name во SAM UI.

Пример:
sas0

UI наредби—прикачени дискови

UI формат за прикачени дискови е

gdisk disk-name command command-args

UI наредби за прикачени дискови се следните:

• label — приказ на име на диск.
• geometry — приказ на геометрија на диск.
• stat — Приказ на поддржани статистики.
• partitions [number] —Приказ на бројот на партиција
На почеток се прикажуваат сите партиции
• vpd — Приказ на поддржани дисковни VPD податоци.

102
• op [file] — пренасочување на сите o/p во file. Предодредено е да се печати
тековниот op фајл.
• debug [level] — поставува дебагирање на level.
За да се добие информацијата од погоре, се пишува gdisk help во SAM UI. Со
пишување на gdisk ќе се прикажат сите прикачени дискови на системот.

Конфигурациски фајл за прикачени дискови. Секој контролер бара конфигурациски

фајл за прикачени дискови. Во овој фајл, секоја линија одредува партиција на диск кој
е прикачен за контролерот. Форматот на оваа спецификација е опишана подолу.

каде

• Во tTdDsS, T е целен ID, D е ID на диск, и S е партициски ID. Само еден диск може
да биде дозволен за секоја цел, така D треба секогаш да биде 0.
• filename е име на фајл со слика на дискот (disk image file).
• vtoc е геометрија на диск во фајлот за слика на дискот.
• ro одредува дека фајлот на сликата може само да се чита.
• rw одредува дека на фајлот на дискот може да се запишува.
Дополнителни информации поврзани со дискот, како што е ID на производител,
ID на производ, и ревизиски ID може да се специфицираат на крајот на секоја линија.

10.3.11 LLFS модул

103
 LL уредот овозможува фајл системот на домаќинот да биде пристапуван од
симулиран систем кој работи на Solaris.

LL уредот е конфигуриран во системот со следната линија:

sysconf ll ll-instance-name bus=upstream-pci-bus name dev=pci- device-number

на пример,

sysconf ll 110 bus=pcia dev=2

10.4. Креирање на фајл со слика од root диск

Симулираната платформа може да подигне Solaris од симулиран диск. Најлесен

начин да се постигне ова е да се креира root disk image од референтен систем.

За да се креира оваа слика:

1. Се логираме како root и пуштаме PRTVTOC НА ДИСКОТ КАДЕ ЛЕЖИ root партицијата за
да ја добиеме конфигурацијата на дискот.
За да ја лоцираме оваа партиција, ќе погледнеме во /ETC/VFSTAB И ЌЕ НАЈДЕМЕ ЛОГИЧКИ
ЛИНК КОЈ Е МОНТИРАН НА /. НА ПРИМЕР АКО ROOT ПАРТИЦИЈАТА Е c0t1d0s0, се извршува
PRTVTOC НА ДЕЛОТ 2 ОД ДИСКОТ, ШТО ЗНАЧИ C0T1D0S2. Еве пример:

104
2. Претходната vtoc табела покажува дека партицијатаж root започнува од 0
(прв сектор) и има вкупно 31273544 сектори.Slice 2 од дискот е специјален
дел кој покажува на целиот диск, па така кога извршуваме dd, влезот е дел 2
на дискот кој ја чува партицијата root.

На пример, ќе ја користиме следната наредба за да креираме слика на root диск:

dd if=/dev/dsk/c0t1d0s2 of=/your/work/dir/env09-root iseek=0 count=31273544

Обично, форматот е следен::

• dd if = партиција 2 од дискот во кој лежи коренот ; партиција 2 покажува на

целиот диск од името на фајлот за слика на дискот
• iseek = прв сектор
• count =број на сектори

3. Се следат чекорите 1 и 2 за да се замени партицијата за да се генерира

заменски disk image file. Root сликата може да се промени за вчита
дополнителни драјвери, на пример, LL драјвер. Овој драјвер дава пристап до
локален фајл систем од SAM симулирана околина. SAM поддржува LLFS
(local-host lookup file system), кој дозволува корисниците да читаат и
запишуваат фајлови на нивната машина директно од симуланиот хост.
Притоа, симулираната машина може да пристапи до /your-home-dir или
/tmp/logman на хостот. Уште поважно, LLFS дозволува корисниците да
вклучат SAM како кориснички програм и добијат пристап до сите NFS
фајлови, каде обично лежат програмите за тестирања.

105
 Со мапирање на root директориумот на хостот во /ll/root на симулираниот
хост низ LLFS, коризниците може да пристапат до нивниот директориум од
/home/xyz преку /ll/root/home/xyz во SAM.
За доказ, симболички линкови може да се користат за мапирање на следните
директориуми во симулираниот хост до истиот директориум на реалната хост машина:
/home, /net, /vol, /ws, /import, /usr/ccs, /usr/share, /usr/shared, /usr/dist. Притоа, во
симулирана машина, корисниците може да пристапат до нивниот директориум
преку /home/xyz како и преку /ll/ root/ home/xyz.

10.5. Дебагирање со SAM

Секогаш може да се вклучи дебагер (kmdb за дебагирање керлен или dbx за

апликација) на симулирана машина. Но да се направи тоа потребно е системот да
помине низ ресет и почетни фази на процесот на подигнување. Во фазата на ран развој,
доста труд беше потребен да се дојде то точка до која симулираниот систем може да
вчита дебагер на кернел.
Друга опција за вклучување на надворешен дебагер – gdb има можност да
работи како надворешен дебагер и да се поврзе со целта, во овој случај SAM
симулатор.
SAM име специјален модул кој може да се вчита за да воспостави комуникација
со надворешен gdb дебагер. SAM конфигурациските фајлови треба да се вчитаат во
специјален модул, на пример, sysconf remote port=6450, кој вчитува интерфејс и чека за
конекција од gdb; во овој пример се чека на tcp конекција на порт 6450.

Потоа кога gdb ќе започне, тој се поврзува со SAM и се извршува gdb наредба:

target remote host-name :port

каде

• host-name е име на хостот на кој работи SAM.

• port e ID на портот (6450 во овој пример), кој треба да е ист со sysconf наредбата.

Иако надворешниот дебагер може да вчита информација за дебагирање на изворно

106
ниво, се на се, надворешниот дебагер е главно ограничен за дебагирање на
мултопроцесорски/мултиканални околини.
Дебагирањето одзема поголем дел од енергијата на програмерот, но е една од
најмалку дискутираните задачи во развојот на софтверот, добивање на системот и
проектите на интеграција. Обично основните чекори за наоѓање грешки остануваат
исти:
• Треба да се направи грешката повторлива.
• Да се изолира проблемот.
• Направат корекции.
• Тестира дали корекцијата го решила проблемот

Одредени класи на грешки се тешки за повторување, па некои специјални

стратегии се потребни. Изолирањето на проблемот вклучува стеснување на опсегот на
можности се додека грешката не корелира со одреден сегмент од кодот или
податоците. Постојат неколку општи пристапи за овој проблем.
Еден пристап да се локализира грешката е да се оди чекор по чекор низ кодот
кој е сомнителен, обидувајќи се да се одреди лошото однесување. Главен проблем со
овој пристап е што е доста тежок. За големи програми кои содржат многу јамки,
сложени податочни структури и комплицирани врски помеѓу модулите и каналите,
тешко е да се локализира сегмент каде може да има грешка.
Друг начин да се најде грешка е да се хипотезата која објаснува како софтверот
достгинал таква состојба, потоа да се промени експериментот за да се тестира
хипотезата. Овој пристап бара доста вештини за решавање проблеми доста различни од
оние потребни за првично дизајнирање на код. Историја на траги на извршениот код
кој ако е достапен е најкорисен при локализацијата.
SAM корисничкиот интерфејс има стабилни вградени својства за дебагирање
софтвер за време на подигнувањето на системот и не бара употреба на други
надворешни дебагери. SAM интерфејсот може да започне и стопира симулација цо
секое време, да додели инструкции до секој виртуелен процесор, и да испита
архитектура на состојби за секој виртуелен процесот, мемориска состојба и состојба на
симулирани уреди.
Важно е да се напомене дека оваа дискусија е за дебагирање на машинско ниво,

107
а не програмско дебагирање на кои повеќето софтверски инженери се навикнати.
Дебагерот не работи на симулиран систем, туку работи на хост машина која работи
симулиран систем. Обично, дебагерот ќе земе доста поддршка од компајлерот,
лоадерот и оперативниот систем за да мапира информации за програмот кој се
дебагира.

10.5.1. Пристап до симулирани состојби

PSELECT наредбата селектира преддефиниран виртуелен CPU ID на кој ќе се

однесуваат други наредби за кориснички интерфејс. Бројни наредби кои имаат VPCU
ID како аргумент работата на преддефиниран vcpu кога аргументот е отфрлен.

CPU регистрите може да се читаат во групи или посебно:

108
Може да се промени регистерска состојба:

stop: write-reg g1 0x1

stop: read-reg g1 cpu[0]: g1=0x1
Меморијата може да се чита во бинарен формат или може да се расклопи, на пример:

109
Мемориска состојба може да се промени со наредбата:
set 0x10000 0x1 stop: get 0x10000

0x0000000000010000: 0x00000001
Исто така постои наредба за испитување на регистри мапирани на неподвижни
ASI и TLB состојби за секој виртуелен процесор.
Секој модул на уред има специфично множество на наредби со кои се
пристапува до состојбата на тој модул.

10.5.2. Информација за симболи

SAM може да процесира симболички информации од модулите кои

работат на симулирана машина. За релокациски модули, потребни се почетни адреси
на текс/податок; за извршни модули, адресите за текст и податоци може да се извадат
од ELF фајл.

load_symbols наредбата на SAM интерфејсот вчитува информации за симболи за

ELF фајл, и дозволува корисниците да одредат базна адреса за деловите на текст и
податоци и содржина во која ќе се пристапи до модулот. Информацијата за симболи се
чува на хост машината; таа не ги вчитува овие модули во меморија – симулираниот
систем ги вчитува.
SAM може да најде симбол по име или адреса:

110
 Кернел модулот unix во претходниот пример не може да се реалоцира -
LOAD_SYMBOLS наредбата може да извади вчитана адреса директно од ELF фајл.
Истото важи и за хипервизорски модул. Имајќи информација за симболи за unix и
хипервизор модулите е доста добро во рана фаза на подигнување на системот.
Модулот gnunix е релоцирачки ELF фајл; почетната адреса за деловите за текст и
податоци (-x и –d опциите, соодветно) мора да се овозможени. Наоѓањето на вчитани
адреси за модулот бара дополнителен труд. Кофа kmdb дебагерот работи на
симулирана машина, тој добива информација за базна адреса од вчитувачот на кернел
KRTLD; оваа информација може да не е достапна за хост машината.

Почетните адреси за кернел модулите обично може да се најдат на излезот од

конзолскиот лог генериран од вчитувачот на кернел која MODDEBUG опцијата во
/ETC/SYSTEM ФАЈЛОТ НА СИМУЛИРАН СИСТЕМ Е ОВОЗМОЖЕНА: MODDEBUG 0X80 000 00 0.
За да се овозможи вчитување адреси од првите пет модули (UNIX, KRTLD, GENUNIX,

PLATMOD, and SUNW), се одредува BOOT -VV. Овие пет модули секогаш се вчитани од
USFBOOT во ист редослед. MODDEBUG знаменцето контролира информациски лог
генериран од KRTLD за вчитување на други модули откако самиот KRTLD е вчитан.
Примерот 10-3 исклустрира код.

ПРИМЕР ЗА КОД 10-3 Почетни адреси за кернел модули

111
 Наоѓањето на базни адреси за процесите во корисничко контекст бара работа. Валиден
ID исто така треба да биде достапен. LD_AUDIT И СПЕЦИЈАЛЕН МОДУЛ КОЈ ПРЕСРЕТНУВА

АДРЕСИ НА КОИ КОРИСНИЧКИТЕ МОДУЛИ СЕ ВЧИТАНИ ТРЕБА ДА СЕ КОРИСТИ ЗА ДА НАЈДЕ

БАЗНА АДРЕСА И НЕЈЗИН ID.

Во некои случаи, информација на симбол е потребна за Java програми кои

работат на Јава виртуелна машина (JVM), што за возврат работи на симулиран систем.
Во овој случај, Јава виртуелната машина треба да биде надополнета со специјален
агент кој вади адреси за рутини генерирани од JVM.

10.5.3. Точки на прекин

SAM дозволува корисниците да сетираат неколку типови на точки на

прекин за одреден виртуелен процесор: поставување точка на виртуелна инструкциска
адреса, тип на стапица или RED режим.
Еве пример:

112
За бришење на точката: stop: delete 0

10.5.4. Следење на дебагирање

Специјален трагач, vdebug, е стабилна алатка за наоѓање на временски

прозорец во кој се случуваат одредени проблеми.
Кога се вчита информација за симбол, SAM ќе означи трагач на
дебагирање со имиња на рутини и за пристапи до податоци со структурни имиња
доколку се најде на симболско совпаѓање.
Форматот е

Следењето на дебагирањето вади информации за промена на вредност за секоја

извршена инструкција. Следењето дава многу податоци и дебагирањето е тежок процес
– не постои решение кое се користи за пристап до сите проблеми.

За дополнително стеснување на прозорецот да се фокусира само на неопходни

информации за време на сесијата на дебагирање, добро е да се користат сонди.

113
10.5.5. Сонди

Сондите следат одредени состојби за време на симулацијата. Тие

одделуваат дел од состојба или акција. Внатрешната имеплементација на сонди се
базира на точки на прекин за привремено паузирање на симулацијата и извршување
наредби за сонда.
Следниот пример прикажува повици за виртуелни процесори од 0 до 15:

probe -cpu 0..15 -trap 0x7c -exec "where"

Наредбата where прикажува повик на стек за секој виртуелен процесор секогаш

кога ќе се случи CPU mondo стапица. Наредбите за сонди може да го вклучат/исклучат
следењето на дебагирањето, карактеристика која помага корисникот да се движи низ
масивна количина на информации собрани за време на сесијата на дебагирање.
Користењето на оваа карактеристика е слична со користење на логички анализатор кој
е поврзан на секои сонди на системската плоча и може да собере делови од трагањето
во бафер.

114
10.6. Симулација со точни циклуси

Додека модел на инструкциско ниво може да биде корисен за развој на

системски софтвер, верификација, подигнување на систем, следење и слично, за
анализа на брзината потребен е модел со точни циклуси. Бихевиорални модели со
точни циклуси се користат не само за CPU микроархитектура но исто така и за
испитување на брзина на целосни системи. Може да се коситат неколку пристапи за
постигнување на оваа симулација, секој пристап има предности и слабости.

10.6.1. Пристап со следење

CPU архитектите се навикнати на работа со временски модели со следење

за да направат компромиси во микроархитектурата на одредено множество на тестери.
Временскиот модел е бихевиорален модел кој вклучува циклуси, каналоводи, кашови,
бафери за чување/запишување/спојување, шпекулативно/извидничко извршување итн.
Моделот не си собира сите детали, туку само најзначајните. На пример, временски
модел често се користи кога само тагови на кешот се моделирани за да се види
однесувањето при погодок/промаршување на кеш но податок за линиите на кешот не
постои.
Пристапот базиран на следење претпоставува дека следењето инструкции
некако треба да се собере, обилно со помош на модели на инструкциско ниво.
Следењата прават масивни количини на простор за чување, па потребна е некаква
стратегија за откривање на значајни делови од траги кои претставуваат тест на
однесувањето. Истовремено, трагите се собираат и верификуваат со цел да се види
дали може да се реупотребат за анализирање на микроархитектонски компромиси.
Следењето инструкција содржи само инструкции кои се извршени, но временскиот
модел исто така треба да се справи и со шпекулативно извршени инструкции за да
добие однесување на точно време. Во овој момент постпроцесирачката природа на овој
пристап станува проблем – точноста која може да ја понуди овој временски модел е
ограничена.

115
10.6.2. Пристап базиран на извршување

За подобрување на временската прецизност на моделот, почесто се користи

пристап базиран на извршување. Временскиот модел во пристап базиран на
извршување напредува циклус по циклус и мора да чува сигурни и шпекулативни
состојби. Постои обратна зависност помеѓу точноста (колку многу карактеристики се
рефлектирани во моделот) и брзината на моделот. Овој пристап може да биде точен
како и RTL модел, но во тој случај ќе биде и спор како и RTL моделот. Инженерите за
микроархитектура се обидуваат да фатат само одредено неопходно однесување во
временскиот модел кое влијае на поголем дел од точноста со цел да се задржи брзината
на моделот на прифатливо ниво за работа со реални тестери.

Инструкцискиот, модел со точени циклуси може да се имплементира на неколку

начини. Еден пристап е да се направи од почеток, земајќи во предвид кешови,
канловоди и состојби (реални или шпекувалитени) внатре во моделот. Со модерните
микроархитектури (одделни каналоводи да инструкции и феч, издавање и
комплетирање на инструкции вон редослед итн), тешко е да се конфигурира временски
модел со помош не некаква скрипта. За моделирање на контролна логика на еден или
друг начин, модулите треба да се напишани во виши програмски јазици; С и С++ се
најчест избор. Главна корист од овој пристап е тоа што нуди симулација со реални
циклуси за системски интерфејс. За моделирање на системска брзина, овој пристап
нуди најдобри резултати.

Проблемот со овој пристап е што правењето промени во микроархитектурата

станува тешка задача; промените може да влијаат не само на времето туку и на
точноста на извршување на основни инструкции. Верификација за секое обновување во
моделот е тешко; покрај верификација на времето, треба да се прави и функционална
верификација. Модел на однесувањето на CPU циклусите е потребен за моделирање на
системска брзина, но тој треба да се направи откако архитектурата на CPU е стабилна.

116
10.6.3. Пристап со подмодули

Понекогаш е последно да се подели временскиот модел во неколку модули:

еден подмодел за моделирање на сигурна состојба, друф подмодел за моделирање само
на шпекулативни состојби и главен модул кој контролира овие два подмодули и се
справува со времето на моделот. Две инстанци од модел на инструкциско ниво може да
се користат за следење на архитектурата и шпекулативната состојба сеоодветно.
Така, временскиот модул ќе испрати fetch, execute, retire, abort повици само до
подмоделот за шпекулативно извршување. За непредвидени гранки, некои инструкции
треба да се напуштат, но тоа не влијае на состојбата на подмодулот кој следи сигурна
состојба. Оваа состојба е променета само кога е време да се осигура инструкција.
Овој пристап работи добро за испитување на CPU микроархитектурата.
Релативно е лесно да се направат измени за испитување на нови својства во неа.
Промените влијаат само на временскиот аспект на моделот; функционалната точност
останува недопрена. Во исто време, тешко е да се овозможи симулација на
однесувањето за системски интерфејс, па така симулацијата на циклуси може да биде
проблематична.

10.6.4. Заклучок

На крај, не постои „еден за се“ пристап кога се избира моделирање со

точни циклуси. Барањата треба да се анализираат внимателно за да се најде
вистинскиот приод.

10.7. Верификација со косимулација

Една важна функција на SAM симулаторот е што овозможува CPU златен

референтен модел со кој се верификува модулот кој се развива. Во овој дел, RTL служи
како корисен пример за косимулација.

117
10.7.1. RTL косимулација
За време на развојот на RTL, RTL кодот се верификува со пуштање на
косимулациски режим со SAM CPU модел. Основната идеа е пред да заврши
инструкција на RTL, златниот референтен модел ќе изврши некои инструкции и двете
страни ќе ги споредат промените во регистарот на архитектурата добиени од
инструкцијата. Ако нема совпаѓање, работата на косимулацијата е запрена и се
известува за грешка во верификациски лог.
Слика 10-3 прикажува интеракција помешу RTL модул и SAM CPU
златен референтен модел.

118
СЛИКА 10-3 Интеракција помешу RTL модул и SAM CPU златен референтен модел

Компонентите се поврзани со двонасочно лежиште, кое е прикажано на слика 10-3

како две двонасочни стрелки помеѓу компонентите за да илустрираат нивна поврзаност
низ лежиштето. Главниот драјвер, Verification TestBench, е поврзан со RTL модулот
(DUT = device under test), како што е прикажано на слика 10-4. TestBench ја следи DUT
активноста.

СЛИКА 10-4 Модели потребни за повеќеканална операција

Без разлика дали TestBench детектира дека инструкцијата завршила, таа испраќа
наредба step со SAM преку конекција со утичницата. TestBench исто така собира
промени од DUT регистарот и ги чува во редица (наречена delta queue) за подоцна да
ги спореди до промени во SAM регистарот. Step наредбата кажува дека каналот треба
да изврши една инструкција.

Од страна на SAM, после добивање на наредбата step, целниот канал фечира

една инструкција, врз основа на вредноста на програмскиот бројач (PC) и извршува
инструкција. Откако инструкцијата завршила, соодветните промени во регистарот на
архитектурата се собираат и праќаат низ утичницата (сокетот) до TestBench.
Кога TestBench добие множество на промени во регистарот, тој наоѓа соодветен
DUT во делта редицата и ги споредува двете множества податоци. Ако нема
совпаѓање, TestBench прекинува со извршување и сигнализира грешка.
Важно е да се забележи дека откако TestBench испрати наредба step, SAM, DUT
и TestBench не застануваат и чекаат SAM да заврши со извршувањето и испрати назад
примени во архитектурата (наречено delta set). Навистина, DUT продолжува со
извршување, и TestBench ја следи активноста на DUT и продолжува да праќа
косимулациски наредби низ сокетот до SAM. TestBench повремено проверува влез на
сокет. Кога ново делта множество е достапно од SAM, вредноста се чита од сокетот и
се споредува со соодветното множество во делта редицата на TestBench, Бидејќи DUT
и TestBench продолжуваат со работа после завршувањето на инструкција и не чекаат
SAM да заврши со работа, ја нарекуваме оваа косимулација чекорно заклучена
косимулација (lock-stepped cosimulation).
Овој опис помага кај едноканално извршување, но SAM е функционален
симулатор, и нема концепт за време (броење циклуси), и може да го нема истиот
редослед на извршување како редоследот на DUT. Поради тоа, кога повеќе од еден
канал се користи кај RTL верификацијата, потребно е споделување повеќе информации
помеѓу TestBench и SAM.
Слика 10-4 прикажува нови модели кои се потребни при повеќеканална
симулација. TLB моделот (TLB синхронизација) одржува редослед на TLB пристапи
низ повеќето јанали. Моделот за читање-запишување (LdSt-sync) одржува редослед на
пристап до кеш и меморија за повеќето канали. Follow-me моделот ја синхронизаира
состојбата на DUT архитектура која SAM не може сам да ја одржува. Овие модели на
синхронизација се опишани во продолжение.

10.7.1.1. TLB-Sync модел

Неколку фактори влијаат на редоследот на TLB пристап:

- Сите канали во јадрото делат ист TLB; низата во која каналите пристапуваат
до TLB влијае на содржината на TLB примена од секој канал
- Секој канал може да изврши неколку инструкции во еден момент и да ги
зачува во ifetsh бафер за работа подоцна, па така може да поминат доста
циклуси од времето кога инструкцијата е фечирана и кога инструкцијата е
испратена во каналоводот за извршување. Бидејќи SAM не одржува бројач
на циклуси и не моделира каналовод детално, тој поставува и извршува
инструкции во ист циклус.
- SAM не моделира алгоритам за замена на TLB исто како DUT, па така
локацијата на TTЕ влез во TLB може да е различен за DUT и SAM. За

120
 косимулацијата да се совпадне за секој канал и извршување инструкција,
активноста на TLB може да се синхронизаира помеѓу DUT и SAM.

Едно множество на TLB-sync наредби одржува стабилни TLB состојби помеѓу

DUT и SAM. Наредбите разменуваат информација за TLB читање, TLB запишување и
TLB хардверска табела. Секоја TLB-sync наредба содржи временски печат кој
претставува броење циклуси, каде DUT за изведува соодветна операција. SAM кориси
наредби (согласно на временскиот печат) за направи историја на TLB пристап. Кога
SAM операцијата бара пристап до TLB, историјата нуди пристап до соодветна TLB
содржина. Заштитата вградена во SAM TLB-sync моделот гарантира дека ако DUT и
SAM имаат различни модели за TLB пристап, ќе се даде грешка. Н пример, ако DUT
прави изминување на хардверска ITLB табела а SAM не, се појавува грешка.

Слика 10-5 прикажува пример за употреба на TLB-sync

СЛИКА 10-5 TLB-sync употреба

Горниот дел од сликата покажува TLB прекин помеѓу DUT и SAM кога не се
користи TLB-sync. Левата страна покажува DUT активност разделена на 5 операции:

1. На циклус ts1 (time-stamp 1), канал-0 поставува инструкција instr1, користејќи ITLB
влез itlb#1.
2. На циклус ts2, канал-1 заменува ITLB влез itlb#1 со нов влез itlb#1-new.

121
3. На циклус ts3, канал-1 поставува инструкција instr2 користејќи ITLB влез itlb#1-
new.
4. Канал-1 извршува и завршува инструкција instr2.
5. Канал-0 извршува и завршува инструкција instr1.

Бидејќи SAM не моделира бафер за поставување инструкции, тој не го одделува

ITLB пристапот и извршувањето инструкции. Двете операции може да се случат
истовремено кога наредба step е примена. Тоа значи кофа step наредба дојде од DUT,
SAM пристапува до ITLB, поставува инструкција и потоа ја извршува, и се во една
операција. Поради тоа операциите 1 и 3 не се видливи за SAM. Првата операција која
се случува во SAM е 2, по која ITLB влезот е заменет. Следи операција 4, со која SAM
има пристап до ITLB на канал 1 , каде се користи itlb#1-new; во тој случај,
инструкцијата instr2 се поставува и извршува. Во операција 5, SAM има пристап до
ITLB преку канал 1, каде се користи itlb#1-new и инструкција која е различна од instr1
се поставува и извршува, што води до несовпаѓање на DUT и SAM.

Долниот дел од сликата 10-5 прикажува како TLB-sync го решава роблемот.

Тука, TLB-sync наредба дозволува DUT да го информира SAM за сите ITLB
активности кои се направени па така SAM соодветно гради историја на ITLB пристапи.
Кога канал 1 и 2 дојдат до референтен ITLB за да постават соодветни инструкции, тие
ја даваат истата содржина како и каналите во DUT, па така истата инструкција се
поставува и извршува.

10.7.1.2. LdSt-Sync модел

SAM не моделира кеш; сите пристапи до податоци одат директно до

меморискиот модел на SAM. Ова однесување не е во согласност со реални RTL, кај кои
две нивоа на кеш и нивна кохеренција чува редослед на пристап до податоци за сите
канали (на сите јадра). За синхронизација на редоследот на податочните пристапи
помеѓу DUT и SAM, множество на косимулациски наредби го информираат SAM кога
ледните DUT активности се случуваат:
1. Операција на вчитување е извршена; исто известува дали операцијата на читање ги
добила своите податоци од некој од кешовите.

122
2. Операција за читање на промаршување на L1 кеш носи податоци во L1 кеш.
3. Се извршува операција на запишување.
4. Операцијата за запишување условува невалидност на кеш кога кешто ја менува
содржината поради таквата невалидност.

SAM користи информација добиена од DUT за да направи редица на историја на

податочни пристапи, целосно со однесување на L1 и L2 кешот. Слика 10-6 покажува
пример за работа на LdSt-sync.

СЛИКА 10-6 LdSt-Sync операции

Горниот дел на сликата покажува операции за податочен пристап во DUT и во

SAM. Во DUT, се гледаат неколку операции:

1. Канал-0 запишува податоци datal на адреса addrl.

2. Канал-8, кој е во јадро 1, чита податоци од адреса addrl. Во тој момент, канал-8’s
L1 кеш не е невалиден, па читањето има погодок на L1 кешот и податоците dataO
се враќаат.
3. Барање за невалидност на кеш се прави во јадро 1, па така влез во канал-8 L1 кеш
за адреса addrl станува невалиден.
4. Канал-8 прави друго читање од адреса addr1. Овојпат тој наидува на промаршување
на L1 и нови податоци data1 се вчитани во L1 на канал 8 и вратени кон барањето за

123
 читање.

Бидејќи SAM не моделира кеш, операција 3 не е видлива за SAM бидејќи сите

читања и запишувања податоци одат директно со меморискиот модел на SAM. И
бидејќи SAM не моделира кеш, податоците зачувани при операција 1 се вратени, па
така операција на читање добива податоци data1, кои се различни од податоците на
DUT. Притоа, ќе се случи несовпаѓање кога делта податоците се пратени назад до
TestBench сокетот. При операција 4, втората операција за читање ос канал 8 ќе земе
некои податоци кои се први вчитани со операција 2.

Најдолниот дел на слика 10-6 прикажува размена на информации помеѓу

TestBench и SAM кога LdSt-sync моделот додаден на SAM и TestBench дозволува
наредби. Што се случува во овој случај гледаме подолу:

1. Кога канал 0 запишува податоци data1 на адреса addr1, податоците не одат во

меморискиот модел на SAM директно, туку, се чуваат во LdSt-sync моделот на
SAM, заедно со други операции за читање и запишување. Овие операции на читање
и запишување се изведени само од SAM меморијата кога нивните преддефинирани
услови се задоволени.
2. Кога канал 8 чита податоци од адреса addr1, со нивни ресурси како “L1 кеш
погодок,” податоците од последното запишување од канал 0 не се користат; туку, се
користи критериум на влезен податок кој се случува пред запишувањето и кој има
погодок на L1.
3. Кога јадро 1 повикува на невалидност на кеш, соодветните влезови во LdSt-sync
моделот на SAM соодветно се маркираат.
4. Кога канал 8 прави следно читање од адреса addr1 со “L1 промаршување,”
TestBench издава наредба Load-Fill да му соопшти на SAM за вчита соодветни
податоци во SAM LdSt-sync редицата на историја на податочен пристап, така што
канал 8 ќе дибие нови податоци зачувани од канал 0 во операција 1.

Повторно, LdSt-sync моделот на SAM не зема информација на слепо во поглед на DUT

податочен пристап од TestBench. LdSt-sync моделот на SAM има вградена заштита така

124
што ако TestBench дава погрешни наредби (или редослед), SAM детектира и известува
за грешка.

10.7.1.3. Follow-Me модел

Бидејќи SAM не има концепт за време, тој не може секогаш да подигне

непрецизни стапици во синхронизација со DUT, кои за возврат би дале несовпаѓање за
време на косимулацијата. За да се надмине вој проблем, TestBench испраќа наредба
Interrupt Sync до SAM секогаш кога непрецизна стапица е покрената од DUT па така
SAM може да покрене иста стапица во истиот циклус. Заштитата вградена во SAM
проверува приоритет и услов на непрецизни стапици пред да се покрене стапица;
притоа, SAM и DUT може да одржуваат ист степен на независност дури и кога се
користи Interrupt Sync наредбата.

Друга употреба на “follow me” шемата е да се одржи конзистентност за

регистрите на архитектурата кои може да се променат од хардверска состојба. На
пример, во случај на RAS грешка, промената на регистарот не е резултат на
извршување инструкција, па така SAM не може да го промени регистарот во прав
момент, што значи, во истиот циклус во кој DUT прави промена. “follow me” кој се
користи на таргетирани регистри гарантира дека и DUT и SAM имаат исти состојби на
регистри.

125
10.7.2. RTL-SAM косимулација

Во повеќето случаи, DUT и SAM треба да извршуваат инструкции

независно и ги споредат промените во нивните регистри после секое извршување. Но
бидејќи SAM е фукциски модел, тој нема концепт за време и не одржува бројач на
циклуси. Освен тоа, бидејќи SAM не симулира работа на кеш, синхронизациските
операции може да се користат за синхронизација на TLB и настани на податочен
пристап. За непрезицни стапици и промени на хардверски регистри, може да се
користи follow-me кој ја прави DUT и SAM архитектурата конзистентна. Во ваквата
синхонизација и follow-me операциите, SAM има вградени заштити за двојна проверка
ан синхронизацијата и follow-me акциите известени од DUT, за да гарантира дека DUT
ја прави истата работа.
Без златен референтен модел, RTL верификацијата би станала уште
посложена. На пример, ќе треба да се вградат повеќе монитори и проверки во DUT и
TestBench за проверка на DUT состојбата. Без златен референтен модел, тест
дијагностиката користена за верификација на процесот ќе бара одреден степен на
самопроверка па така секоја тест дијагностика на своја рака ќе известува дали тестот
поминал или не. Кога се прави косимулација со златен референтен модел (во овој
случај SAM), повеќето од проверката е префрлена на него, па DUT и TestBench не
бараат толку монитори и проверки, и тест дијагностиката не треба да биди сложена.
Накратко, златниот референтен модел (SAM) игра важна улога во
обезбедување на точност и ефикасност при RTL верификацијата.

126