
- •1 Тарау
- •1.1 Сурет. Толық кристалдағы жүйеннің блок-сұлбасы.
- •Инфрақұрылымы
- •Ip (блоктар)
- •Ip (блоктар)
- •Ip (блоктар)
- •Ip (блоктар)
- •Ip (блоктар)
- •Ip (блоктар)
- •Бағдарламалық облыстағы тәуелсіз ip Компаниялар
- •Аппаратты-бағдарланған жүйелік Компаниялар
- •Ip кітапханаларға қойылатын талаптар
- •Ip блоктың бейімделуі:
- •Ip біріктіруінің сапасы,
- •5 Тарау
- •6 Тарау
- •7 Тарау SystemC негізіндегі верификация және SoC жобалауы
- •7.1 Сурет. Arm негізіндегі жоба архитектурасының мысалы
Ip кітапханаларға қойылатын талаптар
IP кітапханаларға қойылатын талаптар, жалпы көп ретті пайдаланудың әр түрлі үлгілеріне қатысты қатты өзгере қоймайды. Барлық жағдайларда барлық блоктар IP модельдерінің толық жиынтығымен, құжаттамалармен және сәйкес келетін стандарттарды талап ететін басқа да нәрселермен берілуі керек. Олар Design and Reuse-те [13] сипатталған немесе зерттеу жобаларымен (ТООLIР секілді [14]) құрылған коммерциялық сұлбалар негізіндегі жылдам іздестіруді қолдау үшін иерархиялық түрде ұйымдасуы және саралануы қажет. Ақырында, IP блоктар жайлы мета-мәліметтер («мәліметтер жайлы мәліметтер» ‒ жылдам сәйкестендіруді (идентификацияны), баға мен іздестіруді қолдайтын құжаттамалық ақпарат) жылдам іздестіру мүмкіндігімен мәліметтер қорына ұйымдасуы қажет.
Алайда, блоктық амалға қарама-қарсы тұғырнамалық жобалауда, IP кітапханалардың бөлек блоктар базасында ғана емес толық тұғырнама базасында да сақтауды, шығаруды, іздестіруді қолдағандары да маңызды. Басқаша айтатын болсақ, бағдарламалық және аппараттық тұғырнамалармен бірге пайдалану үшін мамандырылған виртуалды құраушылар блоктарынан тұратын тұғырнама біртұтас іздестіруге мүмкіндік беруі және сақталуы қажет: иерархиялық мәліметтер қорының мүмкіншілігі қөмегімен, тұғырнама кітапханасын құраушы индивидуалды құраушылар бір-бірімен және тұғырнаманың өзімен байланысты болуы қажет. Процессорлы және стандартты интерфейстер сияқты жалпы функционалды блоктар бірнеше тұғырнамаларға кіруі мүмкін екендігі белгілі; сондықтан блок туралы ақпаратты бір рет сақтауға және оған рұқсат бірнеше әр түрлі жолдармен (SoC жобалаудың блоктық үлгісіндегі бөлек блоктар мен тұғырнама бөлімдері сияқты) болатын мүмкіндігі бар мәліметтер қорының сұлбасын иемдену өте маңызды. Сондықтан жобалық топ нақты блок негізінде оның қандай тұғырнамаларға жататынын, тұғырнаманың тіркелген архитектурасының бөлігі болатын/болмайтынын немесе тұғырнаманың айнымалы кітапханаларына жататын/жатпайтындығын анықтауға қабілетті болуы тиіс.
ІР блок үшін біріктіру архитектуралары
және оның салдары
Заманауи SoC архитектуралары чиптегі стандартты шиналардың дәстүрлі иерархиясын қолданады. Мысалы, ARM-нен AMBA, IBM-нен CoreConnect түріндегі стандарттар негізіндегі процессорлы шиналар, жоғарыжылдамдықты жүйелік шиналар және сыртқы (периферийный) шиналар, сондай-ақ master-slave стандартты шинасы. Жақында пакетті технологияға негізделген (packet-switching) чиптегі желі түріндегі коммуникационды архитектураларға үлкен қызығушылық пайда болды; әдебиетте бұл тақырыпқа сәйкес келетін көптеген тәсілдер көрсетілген, бірақ ол жоғары оқу орындарындағы сияқты, өнеркәсіптік зерттеу зертханаларында да негізінен зерттеушілер тақырыбы болып қала береді.
SONICS-те өңделген және қазір OCP-IP стандартымен қолдаулы Open Core Protocol протоколы SoC біріктіру архитектураларына «коммуникацияға бағдарланған» тәсілін ұсынады – ол SoC коммуникацияларынң стандартты жұйелерінде жиналады және осы ІР блоктардың әр түрлі желілерінің бейімделуінің «бағдарланғандарды-процессорға» SoC амалдарында қабылданған процессорлы блоктары сияқты функционалды блоктарға негізделген дәстүрлі акценттен айырмашылығы.
SoC коммуникациясының желісіне назар аудару SoC архитектурасындағы негізгі мәселе сияқты дәйекті болып көрінеді. Оны ОСР мысалындағыдай чиптегі желінің даму бағытында анық байқауға болады. Негізгі себебі, қажетті орындау мүмкіншілігі және чиптегі коммуникация кідірісі жеке ІР блоктың тез әсер етуі сияқты SoC-тың тез әсер етуіне осындай дәрежеде ықпал етеді. Егер коммуникационды желі нашар жобаланған болса, онда SoC берілген спецификацияларға лайықты бола алмайды және бұған басқа ІР блоктарды алмастырып қою көмектеспейді. Мәселені тек коммуникационды желіні қайтадан толық тексеру арқылы шешуге болады. Сондықтан желі топологиясын, иерархияны (қабаттың саны және түрі), коммуникацияның егжей-тегжейлі (детальный) протоколдарын және желінің нақты конфигурациясын таңдау SoC жобалауының негізі болып барады.
SoC-тың 10-20 блоктар жинағынан 50-100 блоктар жинағына, одан әрі жүздеген жеке ІР блоктарға ауысуынан кейін жеке блоктың тез әсер етуімен салыстырғанда блоктардың арасындағы байланыс (ІР блоктар деңгейіндегі байланыс) басты мәселеге айналып барады. Осы жағдайда SoC жобалауы, логикалық элементтің (gate) кідірісін аралық байланыс кідірісімен салыстыруы бойынша қатыстық өзгерістерін анағұрлым жоғары деңгейде белгілейді. Біз ИС сандық жобалауындағы 500 нм-ден 350,250,180,130 және қазіргі уақытта 90 нм-ге дейінгі ауысуды бақыладық. Бұл ауысу чиптегі коммуникацияның және блок ішіндегі есептеудің қатысты маңыздылығының өзгеруі.
Сөйтіп, минималды өлшемдердің азаюымен және чиптегі коммуникацияның сенімді желілерін құру тапсырмаларының күрделенуімен, чиптегі коммуникация желілерін жобалау маңыздылығы артады, соның ішінде коммуникация жобалауының асинхронды үлгілері күрделілігін синхронды түрімен салыстыра отырып қайта қарау мүмкіндігі.