Ip блоктың бейімделуі:

Коммуникативті қабықшалары

Әр түрлі коммуникационды архитектураларға IP блоктардың бейімделу механизмдерінің бірі ‒ коммуникационды адапторларды немесе «қабықшаларды» пайдалану болып табылады. Бұл сұрақ [6]-да кеңінен талқыланады, ал Виртуалды Құраушылар Интерфейсі (VCI) контексінде VSIA-ден. Қабықшалар көмегімен перифериялы құраушылардың бейімделуі бойынша VSIA VCI-мен жүргізілген тәжірибелер SoC-тің жалпы параметрлерінің (өлшем, өнімділік және қуаттың) нашарлауы қабыршақсыз біріктірумен салыстырғанда (бірнеше пайызға) әлдеқайда аз [16]. Көп ретті пайдалану жеңілдігінің басымдылығы мен қабыршақтарға негізінделген IP блоктардың жақсартылған бейімділігі SoC-тің жалпы параметрлерінің аз ғана нашарлауынан мәнді жоғарылайды.

Ip біріктіруінің сапасы,

Сертификатталған әдістер мен стандарттар

Біз SoC жобалауындағы көп ретті пайдалану аспектілерін және SoC өңдейтін жобалық топтар бойынша ішкі және сыртқы IP блоктарын көп ретті қолданудың қажеттілігін қарастырдық. жоғарыда жобалау үрдісін талқылау барысында біз IP блоктардың сапа стандарттары, IP квалификациясы мен инспекцияда қолданылуы сияқты сұрақтармен кездестік. IP сапасының мәселесі IP негізіндегі SoC жобалауы жолындағы басты кедергілердің бірі болып қалады [17]. Сапа стандарттары мен VSIA және OpenMORE өлшеулері тек белгілі бір деңгейде ғана көмектеседі. Блоктарды біріктіру сапасы бойынша, IP таратуы бойынша талаптарға сай келетін кепілдемелі IP сапасының сертификациясы бойынша формальды ұйымдар құру өнеркәсіп үшін өте пайдалы болар еді. Мұндай сертификационды үрдіс, ең алдымен, көптеген IP блоктар үшін мүмкін болатын конфигурацияның көп санына және осы блоктар біріктіріле алатын SoC қолданбаларының шексіз дерлік санына байланысты өте күрделі болатын еді. Сертификатталған IP блоктар VSIA-де сипатталған виртуалды құраушылардың өздері болып шығуы мүмкін.

Формальды сыртқы анықтаулар (мұндай сертификационды зертханаларға жету әлі алыс) болмаған жағдайда жобалық топтар өздерінің көп ретті пайдалану сапасы бойынша нақтылы өлшемдер мен сертификационды үрдістерін жобалау тәжірибесі негізінде құруы тиіс. Тұғырнамалық жобалау әдістері, осы жерде, берілген қолданбалы аймақтағы сәйкес құраушылар кітапханасының, IP блоктардың топ сипаттамаларының және алғашқы сертификация басымдылығының арқасында көмектеседі. Бұдан тек қана тәуелсіз баға мен біліктілік жақсырақ болуы мүмкін.

IP-ді жоспарлы және жүйелі түрде көп ретті пайдалану бағдарламаны көп ретті пайдалануды бастағаннан кейінгі өнімділіктің жоғарылауының жоғары ықтималдылығын береді. Көп ретті пайдалану стандарттарына сай келмейтін қолданыстағы (существующий) жобалық блоктарды қайта қолданудың мұқият ойланылмаған әрекеттері, әдетте құрдымғаәкеледі және талап етілген сапа мен жобалау өнімділігін қамтамасыз етуге қабілетті емес.

5 Тарау

SoC ЖОБАЛАУ ПРОЦЕСІ

Кіріспе

SoC туралы айта кететін болсақ, SoC жобалау процесі мультидисциплинарлы сипаттамаға ие, сондықтан жобалауға электрониканың барлық спектрінен амалдарды қолдануды талап етеді. Құрастырушылар электрониканың барлық салалары жөнінде белгілі түсінігі болуы керек, бірақ олардың осы салаларда сарапшы болулары міндетті емес. IP- блоктардың қайта қолданылуы және платформалы бағдарланған жобалау жобалушыларға оларға тиісті емес заттарды иемденуді болдырмайды. Бұдан басқа, DFT-тен (Design for Test – жобаға мәтіндік құрылымды енгізу) Цифрлық және аналогтық аппараттық бөліктерді жасауға дейін, верификациядан жүйелік жобалауға дейін, құрылымды БЖ (ПО) жасаудан IP- блоктарды алу және интеграциялауға дейін, аппараттық бөлікті таңдаудан СБИС анализіне дейін құраушылар командасы түгелдей қажетті көлемде білімге ие болуы керек. Тек команда, жеке алынған құраушы емес!

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

1-суретте SoCжобалау процесінің кейбір негізгі құраушылары көрсетілген. Бұл, әрине, жобалау маршрутының белгілі стилизациясы және линеаризациясы. Қазіргі уақытта төмен құлайтын («waterfall»)дәстүрлі жобалау түріне спираль тәріздес әдістемелік жобалау алмасуға келеді. Төмен құлайтын модельде келесі кезеңге өтпес бұрын ағымдағы барлық жоба тапсырмалары аяқталуы тиіс. Реалистік спираль тәріздес моделінде бір уақытта 4 бағыт бойынша жобалау жүргізіледі, олар: БЖ жасау, RTL-код жасау, логикалық синтез, физикалық синтез. Бұл процесс нәтижесінде құрастырушы топтары жоблау нәтижелерімен алмасады. Мысалы, SoC архитектурасын жасауда қандай да бір белгілі IP-блоктың толық және бөліктікжүзеге асыру қажеттігі туындауы мүмкін, сондықтан оның өлшемін, яғни пайдаланатын қуаты мен өнімділігін бағалау үшін мұндай нәтиженің бағасы бойынша архитектура толықтай немесе бірен-саран түрленеді. Немесе мысалы, тез синтез(логикалық және физикалық) құралы көмегімен SoC барлық архитектурасының бағасын жасауға болады.

5.1 сурет. SoC жобалау процесінің кезеңі (идеалдандырылған маршрут).

Жоба бөлігінің жылдам прототиптенуі ұқсас концепция немесе архитектуралық деңгейде барлық SoC барлық заманауи жобалау маршрутының ажырамас бөлігі болып табылады.

Енді жобалау процесінің әрбір кезеңін анықтайық(5.1 сурет). Жобалаудың негізгі маршруттары(бағдарламалық құралдар бизнесінде алдыңғы қатарлы EDA компаниялар Cadence Design Iystems және Synophsys)№1 және №3 қосымшаларда көрсетілген ASIC негізгі жобаларында қабылданған.

SoC талаптарының анализі – РЭА үшін қажетті бұл күрделі SoC-тың соңғы тауар ретіндегі анықтамасы мен сипаттамасы. Маркетингтік зерттеу нәтижесінде анықталған функционалды және функционалды емес болашақ SoC сипаттамаларының жиынтығы негізгі ақпарат болып табылады. Оларға маналар жатады: бағасы, өлшемі, энергия пайдалануы, өнімділігі, корпус түрі және т.б. Бұл берілген кезең бірмәнді жауабын беруі қажет: жоба жүзеге асырылатын болып табыла ма? Жобаны жүзеге асыру үшін қандай амалдар қолдану қажет? Жобаның қандай бөлігін қайта пайдалануға әкелуге болады? Бұл жоба алдынғы ұрпақ тауарларына негізделіп құрылуы мүмкін бе? Немесе платформалы бағдарланған жобалау жағдайында берілген жоба ертеден келе жатқан платформа негізінде құрылуы мүмкін бе?

Алгоритм анализі және оны жасау. Бұл негізгі қадамдамәліметтерді өңдеу және жүйені басқару бөлігінде де SoC жұмысының кілттік алгоритмдері құрылады, бейімделеді және зерттеледі. Басқару алгоритмдері күйдің соңғы санды автоматы түрінде өрнектеледі. Мәліметтерді өңдеу алгоритмі ереже бойынша мамандандырылған бағдарламалар( әдетте С/С++) тілінде жазылады. Мұндай түрдегі мәліметтер құрылымының анализі үшін келесідей автоматтандыырлған құралдар қолданылуы мүмкін: Mathworks Matlab/ Simulink, Cadence SPW, Synopsys CoCentric System Studio Ptolemy/PtolemyII(Беркли университетінің профессоры Эда Лидің жасауы)

Бұл кезеңде жауап алынатын негізгі сұрақтарды атап өтейік. Олар: берілген SoC дұрыс жүмыс істеуі үшін қандай басқарушы функция мен мәліметтерді өңдеудің қандай түрі қажет? Мәліметтер қандай дәлдікпен өңделуі қажет? Мысалы, байланыс жүйелері үшін кодтау/декодтау алгоритмі мен қандай әдістері қажеттігін анықтау. Бар алгоритмдерді бейімдеу мүмкін бе немесе жаңасын құру қажет пе? Таңдалынған алгоритм талап етілгенөткізу қабілетін қамтамасыз ете ала ма(байланыс жүйелері негізінде)? Идеалдандырылған канал моделі қаншалықты шындыққа жанасымды? Архитектуралық деңгейде таңдалынған алгоритм жүзеге асыру барысында қаншалықты күрделі?

SoC архитектурасы. Бұл кезеңде болашақ SoC базалық архитектурасы анықталады. Алдыңғы тарауда көрсетілгендей, SoC үшін каркасы болатын коммуникациялық архитектураны таңдау аса маңызды. Сәйкес емес коммникациялық архитектураны таңдау SoC-ты тым ауыр етеді, әсіресе, бұл өзіндік құнында қатты білінетін болады. Әрине алғашқы кезекте бағдарланатын процессорлық ядролармен анықталу қажет. Мұндағы құрастырушы бірнеше сұраққа жауап беруі керек: RISCпроцессоры қолданылады ма? Кірістірме DSP ядролары қолданылатын бола ма? Олардың қаншасы қажет? Кристалғы тек«жалаңаш» процессор интентгралданады ма немесе дайын процессорлық ішкі жүйе ретінде қолдану қажет пе? Қазіргі уақытта процессорлық ядро толық тіршілікті қамтамасыз ету қосалқы жүйесімен толықталынады, қосымша IP- блок терімдерінен тұрады, оның ішіне бар мүмкін болатын интерфейстер, жады контроллерлері, диагностика құрылғылары, PLL және т.б. кіреді. Аппараттық және бағдарламалық бқліктерге бөлудегі идеясы қандай? Кіріктірме жадының блоктарына(өлшемі, тезәрекеттігі, рұқсат) қандай талаптар қойылуы қажет?

Жүйелік деңгейдегі жобалау SoC процесіндегі маңызды бөлігінің бірі, бірақ сол жағдайды ескере отырып, ол көбіне формальды емес түрде жүргізіледі. SoC архитекторлары әдетте қағаз бен тақтайды және де т.б. заманауи құралдарды қолданады. Бірақ бұрыннан бері көп жағдайда бұл кезеңде С/С++ негізіндегі формальды емес модельдерді архитектура жағынан базалық шешімдерді тексеру мақсатында пайдаланады. Күрделі алгоритмдердің жобалаушылары аудио-видео өңдеу аймағында сигналдарды өңдеуде бұрыннан мәліметтер ағыны моделін қолданып келеді жәнеөздерінің қолайлы параметрлерін анықтау, бағдарламалық, сондай-ақ аппараттық жүзеге асыру өнімділігін тексеруалгоритм тапсырмалары үшін мамандандырылған құралдарына сәйкес келеді. Әр түрлі стандарттармен моделдеудің С/С++ негізіндегі активті жұмысы жүйелік архитекторлар үшін соңғы жылдарда SystemC-ның пайда болуына алып келді. Модельдеудегі қажеттілік және күрделі құрылғалар(SoC типі) анализі жүйелік деңгейде қаншалықты жоғары болса, соншалықты құрылғы күрделірек. Бұл кезеңде бағдарламалық-аппараттық декомпозиция тапсырмасы орындалуы керек. Мұнда тағы да сипаттамалық модель құру қажет және жобаланған SoC қызметін атқару, өндіргіштігі және функционалды емес атрибуттарын талаптарын қадағалауынаанализ жасау(компьютерлік модельдеу жолымен) керек. Соныңда, барлық қолданатын IP-блоктар(қайта құрылатын, сондай-ақ қайта қолданылатын) иденфитикация арқылы біріктіріруі қажет.

Идентификациядан кейін жүйелік деңгейде жобаға қажетті процессорлар мен коммуникациялық архитектура және басқа IP-блоктарды құрастырушылар тобы IP-блоктарды сатып алу жөнінде қандайда бір әрекет қолдануы қажет. Практикада бұл кезең уақыт бойынша жеткілікті ұзақ, онымен қоса паралельді түрде басқа фазалармен, мысалы, жүйелік жобалау немесе транзакция деңгейіндегі верификациямен орындалуы мүмкін. Топ үлкен фирмада жұмыс істегенде, тиімді мәліметтер базасына біріктірілген IP-блоктардың өзіндік үлкен таңдауы болса немесе келісім бойынша IP-блоктардың сыртқы кітапханасына шығысы болса, немесе топта минимум бір адам іздеу, бағалау, сатып алу және IP-блоктардың интеграция тәжірибесімен бар болғаны жақсы.

Осы тәрізді «бақытты» топтар үшін бұл кезеңнің мәселелерін шешу әлдеқайда жеңіл. Ал тәжірибесі және инфрақұрылымы аз басқа топтар үшін бұл сұрақтарды зерттеумен етене айналысу керек және алғашқы уақыттарда IP-блоктардың жеткізушілерінің тәжірибесіне сенуіне тура келеді. Бұл жолдағы тегіс емес жерлерді түзету үшін IP-блоктардағы бар стандарттарды VSIA немесе VCX секілді пайдалануға болады. Сатып алынатын IP-блоктардың қатаң әрі толық тексеруден өткізу, оның нақтылығын және толыққандығын, сонымен қатар, интеграция кезеңіне дейін мүмкін болатын қателердің анықталуы негізгі өзекті қиындықтардың бірі болып табылады.

Транзакция деңгейіндегі верификация. Жүйелік жобалау кезеңінде құрылған сипаттамасы бойынша модель транзакция деңгейінің абстракцияларын пайдаланатын біршама детальдендірілген модельді құрудағы негізі болуы мүмкін. Транзакция деңгейінің моделі виртуальды архитектура деңгейіндегі функционалды верификация жүргізуге арналған жобаның программалық және аппараттық бөлігі жүйе прототипін құруға мүмкіндік береді. Оны басқаша сұлбаның алтын макеті(golden testbench) деп атайды. Виртуалды прототип толық жобаның микроархитектурасы сияқты верификациялауға, сонымен қатар аппаратурлық тілдерде(Verilog, VHDL) және жалпы жобаның контексінде оның жеке бөліктері мүмкіндік береді.

Орнатылатын БЖ архитектурасын анықтау. Әлбетте, кристалда жүйе бұл жай ғана СБИС емес, онымен қоса ішіне орнатылатын бағдарламалық жабдықтама кешені. Бұл әрине, жетілдіріп жатқан SoC электроника аймағындағы пайдаланылатын спецификация және коммуникациялық архитектура немесе процессорлық ядро таңдауда ғана емес, БЖ да айтарлықтай әсерін тигізеді. Сондай-ақ , нақты уақыттағы базалық операционды жүйені(RTOS – Real-Time Operating System) таңдау тура процессордың типіне байланысты(негізінен, оның рязрядына), яғни өз кезегінде болашақ SoC нақты пайдалану аймағы анықталады. Мысалы, OSEK- бұл автомобильді жүйелерге арналған операциондық жүйе, Symbian OS – сымсыз байланыс құралдарына(ұялы телефондар) арналған, PalmOS- PDA(Personal Digital Assistants) шағын ДК үшін және т.б. SoC перифериялық құрылғылары драйверлермен, яғни қолданбалы БЖ, RTOS және аппараттық периферияның өзара әрекетін жабдықтайтын мамандандырыған БЖ жабдықталуы тиіс. Аппаратты IP-блоктар тәрізді бағдарламалық IP-блоктар туралы да айта кетуге болады. Түрлі дайын мамандандырылған бағдарламалар пакеттері - орнатылатын БЖ архитектурасының маңызды бөлігінің бірі. Кодтау/декодтау бадарламалары дауысты немесе суретті дайын ассамблер коды түрінде нақты DSP немесе CPU үшін құрылады. Сөйтіп, SoC құруда бағдарламалық жабдықтаудың барлық архитектурасын толық және нақты анықтау қажет. Қандай операционды жүйені таңдау қажет? ОЖ, қолданбалы БЖ және периферияның өзара әрекетін қалай ұйымдастыруға болады? Қандай бағдарламалық блокты басқа жақтан алуға және қайта пайдалануға болады, ал қандай блокты толық жасауға тура келеді?

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

• команда мүшелері арасында кристалдың физикалық жобалауы жөнінде келісімге келу;

• барлық IP-блоктар толық және біржолата конфигурациялануы тиіс.

• микроархитектурасы соңына дейін анықталуы және конфигурациялануы тиіс (сынақтар, қуат көзі, тактты сигналдар, шиналар, уақыт параметрлері)

• барлық аппараттық блоктар жүзеге асырылуы тиіс (RTL-код түрінде болса да)

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

DFT архитектурасы және оны енгізу. SoC жобасына дайын СБИС-ті (DFT- Design-for-Test) тестілеу және қосымша сұлбалар үшін сынақ жүргізу міндетті түрде енгізілуі тиіс. Дайын IP-блоктарды қолдану кезінде жағдай қиындай түседі. Әр түрлі жеткізушілер мен өндірушілерден түскен түрлі IP-блоктартарда әр түрлі тестілеудің түрі бар. Сондықтан SoC жасауда бұл құралдардың бәрін құрамдастыруға(BIST немесе SCAN сияқты) тура келеді. Берілген пакет SoC-тың «Big D/Little A» типіне(көп бөлігі – цифрлық, аз бөлігі -аналоговая) бейімделген. «Big А/ Big D» типіндегі SoC өте сирек кездеседі.

Аппараттық IP-блоктардың интеграциясы. Бұл этап дәстүрлі әдістермен шешіледі. Жобалық топтардың көпшілігі қабылданған архитектураға сәйкес, басқа құрастырушылармен жасалған дайын жобалық блоктарды монтаждау және оны жинауда жеткілікті тәжірибесі бар. SoC-тың СБИС-тен негізгі айырмашылығы – сыртта жасалған блоктармен жиі жұмыс жасауға тура келеді. Қиындықтардан арылу үшін мұнда толықтай квалификация мен сырттан келіп түсетін IP-блоктарды іріктеу кажет.

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

Бағдарламалық-аппараттық верификация. Бағдарламалық-аппараттық верификация маршруттың блок-схемада барлығы бір блок ретінде көрсетілсе де, тәжірибе жүзінде бейнетті және шығынды тапсырма болып табылады, оның шешіміне жалпы SoC сапасы тәуелді. Верификациялау нәтижелі болу үшін алдыңғы кезеңдердегі («алтын прототип») алынған сынақ ортасын жасаудағы нәтижесін пайдалану қажет. Бұдан басқа, верификация құралы сипаттаудың бірнеше тілін және аралас моделдеуді қолдайтын болуы тиіс. Мысалы, SystemC моделі мен HDL аппаратурасының сипаттамасын дұрыс сәйкестендіру қажет.

Қазіргі уақытта бағдарламалық-аппараттық верификацияның кең спектрі орын алады: бағдарламалық симуляторлардан аппаратттық бөліктің эмулятор және акселераторларына, онымен қоса ПЛИС үшін прототиптерге дейін. Соңғы уақытта формальды верификация(моделдеусіз) негізінде верификация құралдарын жиі пайдаланады, мысалы, модель ерекшеліктерін бақылау. Біріктірілген АЖ және БЖ верификацияның бір мезетте орындауының – ко-верификацияның түрлі тәсілі бар. Орнатылатын БЖ процессордың(ISS- Instruction Set Simulator) нұсқау деңгейінде толығымен бағдарламалық модель түрінде(мысалы, С/С++) жүзеге асырылуы мүмкін немесе RTL-коды түріндегі аппараттық бөлігі аппараттық эмуляторға берілуі мүмкін, ал программалық бөлігі нақты уақыт режимінде жұмыс стансасында орындалады. Бағдарламалық-аппараттық верификацияның басқа тәсілі аралас прототип құру болып табылады, қайта жасалатын блоктар жұмыс стансасында эмулирленеді немесе модельденеді, бағдарламалық жабдықтама баспа платасында орнатылған арнайы интерфейс арқылы жұмыс стансасына қосылған «тірі» процессорда орындалады. Бәріне қоса,сол IP-блоктар «тірі» электронды компонеттер түрінде жүзеге асырылады және процессормен қоса баспа платасына бірге орналаса алады.

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

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

Құрастырушылар командасы құралдар мен құрылғылар санына тәуелсіз бір нәрсені есте сақтаулары тиіс, тек жақсы ұйымдастырылған верификация процесі сұраққа нақты жауап алуға мүмкіндік береді: «Верификация орындалғанын қайдан біле аламыз?» және келесі жұмысқа өтеміз.

SoC верификациясы және ақырғы құрастыру. Ақырғы құрастыру фазасы және верификациясы орналастыру, барлық кристалдың трассасын белгілеу, технологиялық нормалар бақылауынан тұратын(DRC – Design Rule Checking) физикалық верификациядан, сұлба мен сәйкес топология бақылауынан(LVS-Layout vs.Schematic), паразит элементтердің экстракциясынан(RCX-Resistor Capacitor eXtraction) тұрады. Терең субмикрон технологиясы бойынша дайындалатын сұлбалар 0,18 мкм және одан аз, DSM әсеріне қатысты қаттардың болмауына анализден өту қажет: жер/ қуат көзі шиналарында кернеудің төмендеуі, сигнал тізбектерінің тұтастығы(signal integrity), жер/ қуат көзі тізбегінің тұтастығы (power network integrity) және т.б.

Өндіру, сынақтан өткізу, орау және зертаханалық байқау. SoC өндіріске берілгеннен кейін, құрастырушылар командасы демалатын уақыт табылады. Бірақ, бұл уақытты SoC аппараттық бөлігінің контекстінде толық талдап, БЖ тексеруге жұмсауға болар еді. Тәжірибеде аппараттық бөліктегі жеке қателерді шектеп, БЖ көмегімен жойылуы мүмкін.

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

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

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

Дәл жүйелік деңгейде базалық жүйелік архитектураның ең маңызды тапсырмаларын таңдау және аттестациясы, онымен қоса, IP-блоктарды таңдау шешіледі. Бұл «жобалау кеңістігін зерттеу» деп аталады. Егер платформалы бағдарланған тәсіл қолданса, онда бұл зерттеуге нақты тапсырма бойынша SoC платформасын баптау кіреді. Платформаның жобалау кеңістігін зерттеу жалпы DSE(Design Space Explotion) ұқсас деп қарастыруға болады, ал базалық коммуникацинды архитектура, процессор бекітілген зерттеу аймағы мен шекарасы айырмашылық ретінде біршама қатаң шектелген. Жоба командасы баптаулар параметрі мен IP-блоктарды таңдауда шектелуі мүмкін.

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

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

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

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

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

Суреттегі 1 және 2 сандарымен белгіленген 2 қадам функционалдылық анализі мен белгілеуді және SoC архитектурасының екі эквивалентті көрінісін белгілейді.

5.2 сурет. Біріккен функционалды-архитектуралық жобалау.

3 қадамда SoC жүзеге асыру үшін архитектураның жарамдылық анализі мен көрінісі шығады. Соныңда, 4 қадам архитектураның толық талдауы(әсіресе коммуникация жөнінде және жүйелік модельдерде деталь қосу) және SoC толық талдауын жүзеге асыру.

Функцияны бірігіп жобалау тәсілі мен архитектураның жүзеге асырылуы зерттеу және коммерциялық САПР бағдарламалық құралдарында пайдаланылады. Бұл тәсіл платформалы бағдарланан жобалау жағдайында табысты пайдаланылады.

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

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

SoC аймағындағы зерттеушілер компиляция мен нақты қосымшаларға конфигурацияланатын мамандандырылған процессорлардың синтезі сұрақтарын зерттеумен айналысады. Мұндай процессорлар болашаұта үлкен рқл атқаруы мүмкін. SoC қосымшалар талаптарына динамикалық адаптация жасауға шамасы жетеді, конфигурацияланатын логиканың кең қолданылуын ескерсек, бұл өте қызықты. Бірақ бүгінде көп процессорлы SoC көп бөлігі 2-4 дәстүрлі процессорлардан қолданады; әдетте үлкен өлшемді тораптарды өндірісте және ғылыми зертханаларда кездестіруге болады.

Чиптегі тораптарды пайдаланатын, гетерогендік көп процесссорлы архитектура енгізу SoC архитектуралық анализі мен жүйелік жобалау мәнін одан әрі ұлғайтады. Келешекте SoC жобалаудың басты тапсырмасы ретінде гетерогендік, есептеуіш және коммуникациондық ресурстардағы оптимальды тапсырма жиынының көрінісі, архитектура және конфигурация болуы мүмкін. Бірнеше жыл бойы орнатылған процессорлардың көп бөлігі база бөлігінде кеш-иерархияны пайдаланбады, бірақ жағдай өзгеріп, қазіргі таңда RISC және DSP процессорларында 1-ші деңгейлі, чиптегі және оның сыртындағы жоғары деңгейі кеш-жадыларынын жеткілікті саны бар. Жүйелк жобалаудың құралы мен тапсырмасы құрылымды, өлшемді және жалпы SoC конфигурациясынын негізі шешімін жады иерархиясы конфигурациясы ретінде қарастыруы қажет.