Студопедия

Главная страница Случайная страница

КАТЕГОРИИ:

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






SoC жобалау маршруты






Қ азіргі уақ ытта тө мен қ ұ лайтын («waterfall»)дә стү рлі жобалау тү ріне спираль тә різдес ә дістемелік жобалау алмасуғ а келеді. Тө мен қ ұ лайтын модельде келесі кезең ге ө тпес бұ рын ағ ымдағ ы барлық жоба тапсырмалары аяқ талуы тиіс. Реалистік спираль тә різдес моделінде бір уақ ытта 4 бағ ыт бойынша жобалау жү ргізіледі, олар: БЖ жасау, RTL-код жасау, логикалық синтез, физикалық синтез. Бұ л процесс нә тижесінде қ ұ растырушы топтары жоблау нә тижелерімен алмасады. Жобалаудың негізгі маршруттары(бағ дарламалық қ ұ ралдар бизнесінде алдың ғ ы қ атарлы EDA компаниялар Cadence Design Iystems жә не Synophsys)№1 жә не №3 қ осымшаларда кө рсетілген ASIC негізгі жобаларында қ абылданғ ан.

33)Жобалаудың жү йелік дең гейі.

ә детте жү йелік дең гейдегі жобалау - бұ л негізгі кү ш салу жә не уақ ытша шығ ындардың ауысуына алып келеді. SoC жобалау маршруты жә не back – end қ ұ рал-саймандық қ ұ рылғ ылар ASIС, АSSP жә не мамандандырылғ ан СБИС жасауда пайдаланғ ан қ ұ ралдарғ а ұ қ сас болуы мү мкін. Олардың айырмашылығ ы тек оларды пайдаланудағ ы ә дістемесі мен IP-блоктар қ алай қ ұ рылып, салып алынады жә не интегралдауына байланысты болады. Бірақ IP-блоктар негізіндегі фундаментальды жобалау табиғ аты жү йелік дең гейге қ атты ә серін тигізеді. Дә л жү йелік дең гейде базалық жү йелік архитектураның ең маң ызды тапсырмаларын таң дау жә не аттестациясы, онымен қ оса, IP-блоктарды таң дау шешіледі. Бұ л «жобалау кең істігін зерттеу» деп аталады. бірігіп жобалау жә не жү йелік дең гейде DSE кө бірек кү шті талап етеді жә не бұ ғ ан сә йкес келетін термин болып «function- architecture co-design» (совместное функциональное-архитектурное проектирование). Жү йе мұ ндай модельдерді екі тү рлі дең гейде бағ а беріп сипаттауғ а болады:

Функционалды белгілеу – дискретті оқ иғ а, ақ ырғ ы автоматтар немесе мә ліметтер ағ ыны сияқ ты, есептеуіш модельдердің кө мегімен модельденетін функционалды тапсырмаларының қ атарына бө лінген жү йенің қ осымшалар торабы.

Архитектуралық қ ұ рылымы – коммуникация архитектурасы, процессор, негізгі аппараттық блоктар жә не жады сияқ ты негізгі IP-блоктар.

 

34)SoC жаң а архитектуралары.

SoC-те негізінен орнатылғ ан RISC процессорлары – ARM, PowerPC, MIPS жә не кейбір конфигурацияланғ ан процессорлары SoC интеграциясы ү шін арнайы жобаланғ ан. Мұ нын бә ріне қ оса, кө птеген тұ тынушылар қ осымшаларында аудио жә не видео деректерін ө ндеу ү шін Texas Instruments, Motorola, ParthusCeva секілді дә стү рлі жеткізушілерден DSP орнатылғ ан процессорлары пайдаланылады.SoC аймағ ындағ ы зерттеушілер компиляция мен нақ ты қ осымшаларғ а конфигурацияланатын мамандандырылғ ан процессорлардың синтезі сұ рақ тарын зерттеумен айналысады. Мұ ндай процессорлар болашаұ та ү лкен рқ л атқ аруы мү мкін. SoC қ осымшалар талаптарына динамикалық адаптация жасауғ а шамасы жетеді, конфигурацияланатын логиканың кең қ олданылуын ескерсек, бұ л ө те қ ызық ты. Бірақ бү гінде кө п процессорлы SoC кө п бө лігі 2-4 дә стү рлі процессорлардан қ олданады; ә детте ү лкен ө лшемді тораптарды ө ндірісте жә не ғ ылыми зертханаларда кездестіруге болады.

35)ЖҮ ЙЕЛІК ДЕҢ ГЕЙДЕ ЖОБАЛАУДАҒ Ы SystemC ТІЛІ

Кіріспе SystemC пайдалануының артық шылығ ы

Жү йелік дең гейде SoC жобалау жә не верификациялау ү шін жү йелік дең гейде жобалаудың абстракцияларына сеніп қ ұ рылғ ан, сонымен қ атар қ азіргі SoC қ иындығ ын ескеретін жобалау жә не верификациялау тілі қ ажет.

Неге SystemC SoC схемалары мен жү йелерін жобалау жә не верификациялау, ү лгілеу жә не айрық шалау ү шін қ олайлы тіл болып табылады? Бұ л тілдің ерекшеліктері мен артық шылық тарын жоғ арыда кө рсетілген талаптар тұ рғ ысында кө рсетейік:

· SystemC – C++-қ а негізделген жә не C++-та жазылғ ан симуляция ядросы мен кең ейту кітапханасы негізінде қ ұ рылғ ан. Демек, ол С++-қ а негізделген барлық ү лгілерді интегралдай алады, оғ ан команда жү йелерінің симуляторлары, бағ дарламалық ү лгілер, аппараттық ү лгілер жә не С немесе С++ кодында генерацияланатын, жоғ арғ ы дең гейдегі ү лгілендіру ә дістерінің жұ мыс қ орытындылары кіреді.

· SystemC каналдар, интерфейстар менбарлық модельдердің бірігіп жұ мыс істеуін қ амтамасыз ете алатын жә не ә ртү рлі есептеу ә дістерінің негізінде модельдеуде ү лкен икемділік беретін ә дістер сияқ ты қ арапайым қ ұ ралдарды қ олданады. SystemC-дағ ы барлығ ын мә ліметтер ағ ынын, ақ ырғ ы автоматтарды, аналогты бө лігін жә не HW дискретті оқ иғ аларды қ осатын жү йелік модельдер кө рсетілген.

· SystemC модельдерді барлық абстракция дең гейлерінде қ олдайды жә не OSCI (Open SystemC Initiative) ө зіндік бастама шегінде, стандартты семантиканы транзакциялар мен API дең гейінде пайдаланады. Ол модельдеудің бірігіп жұ мыс істеуіне кепілдік бере алады.

· SystemC тілі C++-ке негізделген, ал ол ө з кезегінде С-ғ а негізделген. Дегенмен, кейбір HW сарапшыларына C/C++ таныс емес болуы да мү мкін. Аппараттық салада, бағ дарламалық, алгоритмдер саласында жә не жү йелер саласында кө птеген сарапшылар мен бағ дарлама жасаушылар C/C++-пен азды кө пті таныс.Техникалық жоғ арғ ы оқ у орындарында оқ ыту кезінде C/C++-пен кездеспеген тү лек сирек кездеседі. SystemCкең таралғ ан тілге негізделген.

· SystemC кө пдең гейлі верификация кітапханасының (SCV – SystemC Verification library) кө мегімен SystemC верификацияның заманауи ә дістерін қ олдайды. SCV тесттік платформаларын, транзакциялар жазбаларын (кіріс сигналдары, мониторлар, дыбыс беруді бақ ылау), айнымалылар рандомизациясын, шектеу/байланыс қ ондыруды жасауды, сонымен қ атар транзакция негізіндегі верификацияның жаң а ә дістемелерін қ олдануды қ олдайды.

· SystemC –IP-блоктар базасында жобалау жә не С++ пен OSCI стандарттарының компоненттерінің транзакциялар дең гейінде ө зара ә рекетке негізделетін жобалық жә не верификациялық компоненттерін қ айта қ олдану мақ сатымен жасалғ ан. SystemC «қ айталап қ олдануғ а жобаланғ ан».

· SystemC жобаның RTL дең гейіне дейінгі аппараттық бө ліктің модельдеуін жә не талдап тексеруін қ олдайды. SystemC аппараттық, сигналдық, биттік қ ұ рылымдық компоненттердің ө зара ү йлесімділігін қ амтамасыз етеді. Жә не қ олмен талдап тексерумен қ атар RTL дең гейіне дейінгі ә діс синтезін толық қ олдайды.

· SystemC чиптағ ы – стандартты шиналарды, желілік жә не нү кте-нү кте типіндегі (point to point) барлық коммуникация схемаларының тү рлерін икемді, қ олайлы жә не нә тижелі модельдеуге мү мкіндік беретін каналдар, модульдер, интерфейстар жә не ә дістерді пайдалануғ а береді. Чипта коммуникацияларды модельдеу кә дімгі қ алпымен SystemC-да қ олдау табады.

36)SystemC мә нмә тіні

Болашақ ә дістемелік жұ мыс ү шін кө п ү міт кү ттіретін салалардың бірі ү ш тіл ә лемін қ ұ ру болып табылады. Онда UML-да дайындалғ ан жә не модельденген бағ дарламалар платформағ а оң тайландырылғ ан кодты генерациялай алады. Ал код ө з кезегінде транзакциялар дең гейінде SystemC негізіндегі платформалық модель шегінде, сә йкес ОС модельдерін қ олданумен жасала алады. Жобаның аппараттық бө лігі Verilog-2005 жә не VHDL кө мегімен, алдында жасалғ ан функционалдық прототиптерді қ олданумен жү зеге асырылады жә не верификацияланады. Бұ ндай амал жү йелік дең гейде жобалауда SystemC-ны қ олдану (мә нмә тінмен) модельдерінің бірі болып табылады. Ә рине SystemC-ны уақ ытқ а тә уелсіз функционалды аппарттық модельдерді қ ұ ру, кейін оларды регистрлік беріліс (RTL) дең гейінде жү зеге асыруғ а ауыстырып, ары қ арай Verilog немесе VHDL кө мегімен жү зеге асыру ү шін қ олмен тарату немесе жинақ тауғ а қ олдануғ а болады.Бұ л сондай-ақ SystemC-ны жү йелік жобалау тілі ретінде қ олданудың қ ызық ты моделі.

SystemC-ны қ олданудың мә нмә тіндері жобалаудың қ андай да бір қ атаң маршрутын талап етпейтінін естен шығ армау керек. Мысалы, жоғ арыдан тө менге, тө меннен жоғ арығ а немесе тағ ы басқ адай. Жобалау маршруттарының кө п бө лігі қ айталама болғ андық тан, жә не жобаның барлық бө ліктері абстракцияның бір дең гейінде модельденуі сирек кездесетіндіктен, модельдеу абстракцияларының дең гейлері бірың ғ ай жү йелік модельге жиі қ осылатынын ескерткен маң ызды.

37)SystemC аспектілері 38)Модельдеу дә лдігі. біз модельдің дә лдігін бірнеше тә уелсіз бағ ыттармен ө лшей аламыз. Мұ нда қ ұ рылымдық дә лдік кіреді: модель мен нақ ты жү зеге асыру қ ұ рылымы арасындағ ы айырмашылық дә режесі. Модель функционалдық модуль мен оның сыртқ ы интерфейсінің дә л мінез-қ ұ лық тық кө рінісі бола алады, бірақ сонымен бірге оның ішкі қ ұ рылымы IP блок немесе модульдың ақ ырғ ы жү зеге асыру қ ұ рылымынан қ атты ерекшеленуі мү мкін. Жү йелік модельдердің уақ ыттық дә лдігі ө те қ атты ө згере алады. Басында уақ ыт дә лдігі оқ иғ аларды реттеу дең гейінде болуы мү мкін. Сондық тан уақ ыт наносекунд немесе такттарда шығ арылса да, маң ыздысы модельдердің орындалу реттілігі. Функционалдық дә лдік – жү йелік модель ақ ырғ ы жү зеге асырудың толық функционалдығ ын қ аншалық ты дә л жаң ғ ыртатынын кө рсетеді. Модельді жең ілдету мақ сатымен, оның жасалуына кететін уақ ытты азайту немесе орындалу жылдамдығ ын арттыру, жобалық командалар қ иын немесе сирек қ олданылатын функционалдық аспектілерді қ алдырып кете алады. Мысалы, егер олар сирек қ оладанылатын болса, ә ртү рлі диагностикалық немесе тесттік режимдерді тастап кете алады; Сонымен бірге модельдер дә лдігі мен мә ліметтерді ұ йымдастыру толық тығ ына байланысты ерекшеленеді. Бұ л модельдегі жә не ақ ырғ ы жү зеге асырудағ ы мә ліметтердің орналасуы арасындағ ы ү йлесімділік дең гейін білдіреді.

39)Есептеу модельдері Есептеу моделі (model of computation – MoC) жү йелік дең гейде жобалаудың негізгі ұ ғ ымы болып табылады. Бұ л ұ ғ ым аппараттық дең гейде жобалауда сирек талқ ыланғ ан, сондық тан кө птеген оқ ырмандарғ а қ ызық ты болуы мү мкін. Ол берілген жобағ а немесе қ олданбалы салағ а жақ сы сә йкес келетін жә не сонымен бірге симуляция, синтез жә не анализда қ ажет ерекшеліктерге ие. Ресми тү рде есептеу моделін ү ш анық тамамен кө рсетуге болады:

· Базалық уақ ыттық модель (уақ ытсыз, немесе берілген дә лдікпен толық жә не бү тін сандар негізінде) жә не уақ ыттық модель негізіндегі оқ иғ аларды реттеу семантикасы (қ атаң реттеу, нон-детерминизм, ішінара реттеу, кездейсоқ реттеу жә не т.б.).

· Процесстер арасындағ ы ә рекеттестік. Оқ иғ алар, объектілер жә не бір процесстен екіншісіне мә ліметтерді беру семантикасы.

· Процессті «іске қ осу» немесе активтеу шарттары (кейде «процессті іске қ осу ережелері» деп аталады). Мә ліметтер ағ ыны моделінде, мысалы, процесс кірісіне белгілі мө лшерде токендер келгенде іске қ осылады.

SystemC тілі мү мкін есептеу модельдерінің кө бін қ олдайды жә не оның ашық тығ ы кө п тә жірибе жасауғ а мү мкіндік береді. Кө п тә жірибелер табысты болды, мысалы мә ліметтер ағ ыны мен процесстер желісі (Кана процесстер желісі (Kahn)), RTL дең гейінде аппараттық модельдеу, желілік модельдеу,

40)Функционалдық модельдеу

Жү йенің функционалдық моделі – орындалатын спецификация ретінде белгілі. Жалпы бұ л SystemC-да модель жә не модельдер иерархиясын таратқ ан жобалық спецификациялар мен талаптар. Функционалдық модельдер уақ ыттық (уақ ытқ а тә уелді (timed)) немесе уақ ытқ а тә уелсіз (untimed) бола алады. Біз функционалдық спецификациямен жұ мыс істейтініміздіктен, бә сең дейтін жобалау процесінде (top-down) уақ ытқ а тә уелсіз функционалдық модельден бастап, ары қ арай талдап тексеру процесінде кідіріс туралы ақ паратты кірістерген жө н.Бірақ, функционалдық модель жү зеге асыруғ а тә уелсіз болғ андық тан, бұ л кідіріс туралы ақ парат нақ тылы жү зеге асырудың бө лігі ретінде қ арастырылмауы керек. Функционалдық модельдер негізінен абстрактілі болғ андық тан, спецификацияғ а бағ дарланғ ан жә не тез орындалуғ а арналғ ан, интерфейстер абстрактілі, екі нү ктелік (point-to-point), (модульдар арасындағ ы аралық тасушыларсыз тура байланыс), абстрактілі мә ліметтерді қ олданатын (эффективтілігі ү шін), жә не қ арапайым механизмдер, оқ у мен жазып алуды оқ шаулайтын FIFO сияқ ты болады.

Транзакция дең гейінде модельдеу

Транзакция дең гейінде модельдеу модульдар арасындағ ы ә рекеттестікті жалпылауғ а мү мкіндік береді. Сондық тан модульдердің функциясы нақ ты анық талады, ал олардың арасындағ ы ә рекеттестік симуляцияны тездету ү шін оң тайландырылғ ан. OSCI (Open SystemC Initiative) байланысты мамандарда, транзакция типтерінің стандартты жиынтығ ын анық тауда ү лкен қ ызығ ушылық бар. Олардың мақ саты транзакцияларды жү йелік модельдеуде қ олдану жә не ә ртү рлі ІР модельдердің ә рекеттестігін қ амтамасыз ету. Транзакция дең гейінде модельдеу платформалы бағ дарланғ ан SoC модельдер ү шін ө те маң ызды. Мысалы, тү зетілген модельдеуді қ амтамасыз ету, жә не шинаны жү ктеу, шинадағ ы шиеленіс, сонымен бірге шинаның жалпы жү йенің ө німділігіне ә сері сияқ ты жоғ арғ ы дең гейдегі коммуникацияда ә ртү рлі эффекттерді зерттеу.

41)RTL дең гейі жә не жү зеге асырумен байланысВерификациялық кең ейтілімдер

SCV SoC-ты жобалау ү шін қ ажет IP ретінде де, ө зге жобаларда қ айталап қ олдану ү шін қ ажет IP ретінде де қ арастырылатын верификациялық IP-блоктарды қ ұ руғ а мү мкіндік береді. Верификацияғ а (жобалау ү рдісінде) қ анша кү ш-жігер жұ мсалатынын (бейресми кө рсеткіштер бойынша –50-70%) ескеретін болсақ, верификациялық ІР қ ұ ру мү мкіндігі ө те маң ызды болып табылады. SCV кітапхананың басты верификациялық мү мкіншіліктеріне келесілер кіреді:

· Мә ліметтердің ө зін диагностикалауы (introspection), жә не еркін типтердің мә ліметтерінің элементтерін басқ ару мү мкіндігі. SCV осы негізде пайдаланушымен белгіленген типтерді басқ арып, оларғ а сілтеме жасай алады – мысалғ а, пакеттер мен фреймдерді кө рсететін қ ұ рылымдар. Бұ л осындай объектілерге PLI (Programming Language Interface – Verilog) шығ у мү мкіндігін қ амтамасыз етеді жә не осындай типтердің барлық атрибуттары мен сипаттамаларын анық тауғ а мү мкіндік тудырады.

· Транзакциялар жазбасы, ол транзакциялар негізіндегі верификацияны (TBV) транзакциялар дең гейіндегі жү йелерді модельдеудің қ ұ рамдас бө лігі етеді. Сонымен қ атар TBV оқ иғ алар тізбегін бір «транзакция» ретінде маркілеу арқ ылы, симуляцияны жекелеген оқ иғ алар дең гейінде жазып, нә тижені тестілік платформаның ортақ транзакциялары дең гейіне жалпылауғ а мү мкіндік береді, сондай-ақ осы жалпыланғ ан дең гейде транзакцияларды жазып, маркілеуге мү мкіндік туғ ызады. SCV ө зара байланысты транзакцияларды ағ ымдарғ а топтауғ а жағ дай туғ ызады, ол ө з кезегінде симуляциялар нә тижесі бойынша іздестіру жү ргізуге, жоғ ары дең гейдегі верификациялық транзакциялар, сондай-ақ бақ ылаушы жә не қ адағ алаушы бағ дарламалар қ ұ руғ а мү мкіндік туғ ызады.

· Рандомизация – қ арапайым, ө лшеулі жә не қ ойылғ ан шектеулер негізінде. Рандомизация қ азіргі заманғ ы функционалды верификация ү рдістеріндегі кү шті ә діс болып келеді. SCV қ арапайым рандомизацияны (онда, мысалғ а алатын болсақ, мә ліметтер мекенжайларының мә ндері дұ рыс мекенжайларды теру арқ ылы жү зеге асатын қ арапайым интервалды функция негізінде қ алыптасады) қ оса алғ анда, бірнеше типтермен жұ мыс жасайды. Қ арапайым рандомизация дұ рыс интервалдарды кү рделі жолмен теру арқ ылы мә ндердің бө лінуін жасауғ а, сондай-ақ бос интервалдар қ ұ руғ а мү мкіндік береді.

· Ө лшеулі рандомизация берілген аралық та мағ ыналары не кө птеген мағ ыналары бар ық тималдық тар ү лестірімін байланыстыруғ а мү мкіндік туғ ызады, сол себепті кү рделі ү лестірімдер (мысалы биноминал, Пуассон, қ алыпты) тестілік платформалармен байланыстырылуы мү мкін. Бұ л – тестілік платформада нақ ты статистикалық ү лестірімдерді кө рсетудің жақ сы амалы.

42) Қ орытынды – SystemC тілінің болашақ дамуыжә не SLD (System-Level-Design) талаптары

Қ азіргі уақ ытта OSCI-дың тілді дамыту бойынша тобы келесідей мә селелер бойынша жұ мыс жү ргізуде:

· Стандарттау ү шін IEEE-ге берілу жоспарланғ ан SystemC 2.01 бойынша анық тамалық дайындау.

· Мә ліметтер ағ ымдары мен сә йкесінше тілдік кең ейтілімдердің моделін қ олдау қ андай болу керектігі туралы анық тама дайындау.

· SVC кітапханасы IEEE-ге стандарттау ү шін берілуі ә бден мү мкін.

· SystemC-ның 3.0 нұ сқ асы бойынша ү лкен жұ мыс жү ргізілді, ол бағ дарламалық модельдеуді жә не SystemC-ның HW мен SW ү лгілерінің келесідей ерекшеліктері – RTOS жоспарлаушыларды модельдеу, есептер қ ұ ру жә не оларды басқ ару, ОС дең гейінде хабар алмасу – негізінде ө зара ә рекеттесу мү мкіндігін қ олдайтын болады.

43)SystemC негізіндегі верификация жә не SoC жобалауы Кіріспе

Біздің жағ дайда жобалаудың жә не верификацияның (анық таудың) негізі - транзакция дең гейінде жобаның функционалды виртуалды прототипін қ ұ ру. Cadence бірлестігі шығ арғ ан верификацияның біріктірілген ә дістемесі функционалды виртуалды прототипті(FVP) тесттік платформағ а сә йкес келетін жә не барлық қ ұ рылғ ылардың (DUV – Device Under Vertification) идеалды функционалды кө рсетілімі ретінде анық тайды. Толық FVP-ны қ ұ ру SystemC негізіндегі SoC жобалауы жә не верификация (анық тау) процесінің міндеті болап табылады. Біз мысал ретінде қ арастыратын жоба кіріктірме (встроенный) ARM920процессорынан, жоғ ары ө німді АМВА шинасынан жә не сыртқ ы (периферийный)АМВА шинасынан тұ рады. Ол кө п дең гейлі жоғ ары ө німді AMBA (AHB) шинасының кө мегімен байланысқ ан жә не сыртқ ы (периферийный) AMBA (APB) шинасымен кө пір арқ ылы байланысқ ан процессор ядросынан (core) ARM 920T, жадыдан жә не сұ йық -кристалдық монитордан (LCD) тұ рады. APB шинасына таймерлер, ә мбебап сыртқ ы (периферийный) қ ұ рылғ ылары (GPIO), нақ ты уақ ыт сағ аты жә не ү зілістер контроллері қ осылғ ан.

44)Функционалды Виртуалды Прототип ү лгісінің қ ұ рылуы

Жобаны жоғ ары дең гейде анық тау ү рдісі – архитектураның, негізгі қ ұ раушылардың, чиптегі коммуникация архитектураларының тапсырмасы. Ол функционалды виртуалды прототип ү лгісінің табиғ атын анық тайды. Бұ л жағ дайда жоғ ары дең гейдегі жобалау жә не SystemC негізіндегі верификация (анық тау) бірін-бірі толық тырады жә не қ атар (параллельно) орындалуы мү мкін.Берілген нә рсені анық тау (верификация) қ ажет; ал анық талғ ан (верификация) нә рсені зерттеу жә не архитектурасының сә йкестігін тексеру қ ажет. Виртуалды Прототип жобадағ ы негізгі қ ұ раушылардың SystemC ү лгілерінің комбинациясы негізінде қ ұ рылғ ан. Негізгі қ ұ раушылары: кө п дең гейлі АНВ шиналары, жады қ ұ раушылары, шина кө пірлері жә не LCD контроллері. Сондай-ақ процессордың функционалдығ ы ARM920Т ISS ү лгісімен симуляцияланады (ARM920Т Instruction Set Simulator Model (ISS)). Мұ ндай ISS ү лгісінің басқ алармен салыстырғ анда кө птеген артық шылық тары бар. Мысалы, SystemC формасында қ ол жеткізуге болатын процессордың тө менгі дең гейлі ү лгісімен салыстыратын болсақ (RTL-дең гейіндегі):

· ол тікелей жә не тү рлендірусіз ARM кодының қ ұ растырылғ ан немесе жинақ талғ ан ағ ындарын орындайды;

· ол басқ аларғ а қ арағ анда жылдам. Процессорлардың ISS ү лгісі RTL-дең гейіндегі ү лгілерден 100-ден 10000 есеге дейін жылдамырақ. Себебі, олардан аппараттық бө лімдегі жұ мыстың анық кескіні емес, тек функционалды дұ рыстылық (корректность) қ ажет.

· ол ретке келтіретін бағ дарламалармен тікелей байланысқ ан. Олар кейін берілген процессорғ а арналғ ан бағ дарламаларды ө ң деуде қ олданылады.

· ол SystemC-да жазылғ ан жү йенің қ алғ ан бө ліктерімен ө зара ә рекеттесе алады.

45)FVP-ны қ олданудың ү лгілері

Тө менде SystemC негізінде қ ұ рылғ ан функционалды виртуалды жобалық прототиптерді қ олданудың бірнеше ү лгілері кө рсетілген:

46)Кіріктірме бағ дарламаларды қ ұ ру

SystemC ү лгілерімен байланысқ ан СPU (ISS) нұ сқ амасының жинақ талғ ан ү лгілерінің жә не FVP прототипінің кө мегімен бағ дарлама жасаушылар бағ дарламаларды секундына 10000 такт жылдамдық пен мінете алады (отлаживать). Сонымен қ атар олар қ осымша тесттік толтырудың (покрытие) талдауын (анализ) ө ткізе алады. Егер бағ дарлама жасаушылар сә йкес келетін ө ң деудің қ ұ ралдарының жә не FVP ү лгісінің кө мегімен, араласқ ан SystemC/Verilog немесе VHDLсимуляцияларын ө ткізсе (SystemC, HDL, араласқ ан SystemC-HDL-да симуляцияны кө тере алатын Cadence компаниясындағ ы Incisive верификациясының платформасы сияқ ты), онда олар аппараттық бө лімде (HW) орнатылғ ан ассерттерді (Assertions) пайдалана алады.

47)Функционалды верификация (анық тау)

Транзакция дең гейіндегі FVP прототиптері, жобаны RTL дең гейінде қ ұ руды аяқ тағ аннан кейін, бү кіл жобаның мә нмә тінінде (вконтексте) ә р тү рлі қ осалқ ы жү йелерді тестілеу мақ сатында жү йенің жоғ ары дең гейде кө рсетілуі ү шін қ олданылуы мү мкін. Мысалы, кідіріс контроллерінің RTL нұ сқ асын (версия) бү кіл жобаның RTL коды дайын болғ аннан кейін тестілеуге болады. Сө йтіп, транзакция дең гейіндегі FVP эквивалентті RTL кодына қ арағ анда тез орындалатындық тан, кө бірек тесттер орындауғ а жә не тесттік толтыруды (покрытие) жақ сартуғ а болады.


Поделиться с друзьями:

mylektsii.su - Мои Лекции - 2015-2024 год. (0.012 сек.)Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав Пожаловаться на материал