Կտտացրեք ցանկացած փուլ՝ ուղիղ ներքևում դրա բաժինն անցնելու համար։
Specification
Specification-ը VLSI դիզայնի հոսքի առաջին և ամենավճռորոշ փուլն է. այն սահմանում է, թե ինչ պետք է անի չիպը, նախքան որևէ architecture կամ RTL աշխատանք սկսվելը։ Ամբողջական specification-ը ընդգրկում է ֆունկցիոնալ պահանջները, կատարողականության թիրախները (speed, throughput, latency), էներգասպառման budget-ը, area/cost թիրախները, թիրախային process node/foundry-ն, ինչպես նաև memory և I/O պահանջները։ Ամեն հետագա փուլ — RTL, ստուգում, սինթեզ, physical design — ի վերջո գնահատվում է այս փաստաթղթի հիման վրա, ինչի պատճառով այստեղ երկիմաստությունը կամ բացակայող պահանջները ամենաթանկ սխալատեսակն են. RTL գրելուց հետո հայտնաբերված բացը շտկելը շատ ավելի թանկ է, քան թղթի վրա որսած բացը։
Ամեն շերտ նեղացնում է նախորդը. product requirements-ը ասում է, թե ինչ պիտի ձեռք բերի չիպը. architecture spec-ը որոշում է տեխնիկական մոտեցումը. microarchitecture spec-ը սահմանում է component-ները, datapath-ները և control logic-ը. RTL-ն առաջին փուլն է, որտեղ այս ամենը դառնում է իրական կոդ։
Ինչ է ընդգրկում ամբողջական spec-ը
| Փաստաթուղթ | Սահմանում է |
|---|---|
| Product / market requirements | Թիրախային application, մրցակցային դիրքավորում, high-level ֆունկցիոնալ և cost նպատակներ |
| Architecture spec | Այդ նպատակներին հասնելու համար ընտրված տեխնիկական մոտեցումը — instruction set, bus protocol-ներ, memory hierarchy, հիմնական ֆունկցիոնալ block-եր |
| Microarchitecture spec | Ամեն block-ի ներքին կառուցվածքը. datapath-ներ, control logic, pipeline stage-եր, և ինչպես են module-ները փոխազդում — սա այն փաստաթուղթն է, որի դեմ RTL ինժեներներն իրականում implement են անում |
| Design / IP spec | Per-block interface սահմանումներ, register map-եր, ժամանակային պահանջներ և առանձին RTL unit-երի համար ստուգման պահանջներ |
Լավագույն փորձ և ծուղակներ
Ինչքան հեռու է գնում պահանջի բացը մինչև որսվելը, այնքան ավելի թանկ է շտկելը — spec փուլում տեքստի խմբագրում հանդիսացող փոփոխությունը կարող է նշանակել RTL-ի վերագրում, ստուգման վերարկում և վերասինթեզում, եթե որսվում է logic սինթեզից հետո։ Spec-երը պետք է բավական միանշանակ լինեն, որ նույն spec-ի դեմ implement անող երկու անկախ ինժեներ interoperable արդյունքներ ստանան, և պետք է հստակորեն առանձնացնեն «must have» պահանջները «nice to have»-երից, որպեսզի implementation-ի ընթացքում փոխզիջումներն ունենան առաջնահերթության հստակ կարգ։
RTL Design
Register-Transfer Level (RTL) design-ը նկարագրում է synchronous digital սխեմայի վարքագիծը՝ ըստ այն բանի, թե ինչպես են տվյալները շարժվում hardware register-ների միջև ամեն տակտային ազդանշանի cycle-ի ընթացքում, և ինչ logic է դրանց վրա գործում ճանապարհին — առանց նկարագրելու այդ logic-ի տրանզիստորային իրականացումը։ Այն գրվում է hardware description language-ով (Verilog, VHDL կամ SystemVerilog) և synthesizable է. RTL նկարագրությունը կարող է մեխանիկորեն փոխարկվել gate-level հանգույցների ցանկի Փուլ 04-ի գործիքների կողմից։
RTL-ի հիմնական գաղափարը. ամեն ակտիվ տակտային ազդանշանի edge-ին REG B-ն captures է անում REG A-ի նախորդ արժեքի combinational ֆունկցիան։ RTL կոդը նկարագրում է հենց սա — ինչ է շարժվում register-ների միջև և երբ — թողնելով gate-level «ինչպես»-ը logic սինթեզին։
Coding guideline-ներ, որ կարևոր են synthesizable RTL-ի համար
| Ուղեցույց | Ինչու է կարևոր |
|---|---|
| Non-blocking assignment (<=) sequential logic-ի համար | Նախ evaluate է անում բոլոր right-hand side-երը, ապա թարմացնում բոլոր left-hand side-երը time step-ի վերջում — ճիշտ մոդելավորում է իրական flip-flop վարքագիծը և խուսափում մոդելավորման/սինթեզի անհամապատասխանություններից |
| Synchronous reset նախընտրելի է ASIC-ի համար | Sample է արվում տակտային ազդանշանի edge-ին ինչպես ցանկացած այլ data path, ուստի static ժամանակային վերլուծությունը կարող է այն ստուգել նորմալ կերպով. asynchronous reset-երը պահանջում են լրացուցիչ reset-recovery/removal ժամանակային ստուգումներ և հատուկ reset-tree մշակում |
| Ամբողջական combinational sensitivity / assignment-ներ | combinational logic-ում թերի if/case statement-ը infer է անում ոչ նախատեսված latch՝ նախատեսված pure logic-ի փոխարեն — դասական և դժվար նկատվող bug |
| Մեկ հստակ clocking scheme ամեն block-ի համար | Մեկ always block-ի ներսում տակտային ազդանշանի edge-երի կամ տակտային տիրույթների խառնումը և՛ սինթեզը, և՛ ժամանակային closure-ը դարձնում է շատ ավելի դժվար. cross-domain signal-ները պահանջում են explicit synchronizer-ներ |
| Parameterize արեք width-երն ու depth-երը | Դարձնում է նույն RTL block-ը reusable տարբեր configuration-ների միջև՝ առանց bit width-երը ձեռքով խմբագրելու, նվազեցնելով copy-paste bug-երը |
Լավագույն փորձ և ծուղակներ
RTL-ը գտնվում է design abstraction stack-ի կենտրոնում — ավելի կոնկրետ, քան behavioral/architectural model-ը, ավելի աբստրակտ, քան gate հանգույցների ցանկը — և լավ RTL գրելու ողջ իմաստն այն է, որ այն պիտի ճիշտ մոդելավորվի և սինթեզվի հենց այն hardware-ի մեջ, որ designer-ը նախատեսել է, առանց անակնկալների։ Static lint ստուգումները (Փուլ 03) ավտոմատ որսում են վերևի դասական սխալների մեծ մասը և պիտի աշխատեն շարունակաբար RTL-ի մշակման ընթացքում, ոչ թե միայն մեկ անգամ վերջում։
Functional Verification
Functional ստուգումը հաստատում է, որ RTL-ն իրականում implement է անում specification-ի նախատեսված վարքագիծը, նախքան այն սինթեզին ու physical design-ին հանձնվելը — և այն սովորաբար ժամանակակից չիպի մշակման ամենառեսուրսատար փուլն է՝ հաճախ սպառելով ավելի շատ ինժեներական ջանք, քան հենց RTL design-ը։ Միասին օգտագործվում են երկու լայն մեթոդաբանություն. մոդելավորման վրա հիմնված (dynamic) ստուգում, որը RTL-ը զբաղեցնում է stimulus-ով և ստուգում արդյունքները, և formal ստուգում (static), որը մաթեմատիկորեն ապացուցում է RTL-ի վերաբերյալ properties՝ առանց որևէ stimulus-ի կարիքի։
Stimulus-ը հոսում է ներս ձախից (sequencer → driver → DUT). արդյունքները հոսում են դուրս աջ (DUT → monitor → scoreboard / coverage)։ scoreboard-ը ստուգում է DUT-ի output-ը reference model-ի դեմ. coverage collector-ը հետևում է, թե նախատեսված վարքագծի որքան մասն է իրականում զբաղեցվել։
Ստուգման տեխնիկաներ
| Տեխնիկա | Ինչ է անում |
|---|---|
| Constrained-random verification (CRV) | Գեներացնում է randomized-but-legal stimulus՝ հասնելու սցենարների, որոնց համար մարդ չէր մտածի directed test գրել |
| Coverage-driven verification (CDV) | Օգտագործում է functional coverage (covergroup-եր) և code coverage (line/toggle/branch/FSM)՝ չափելու, թե ինչն է իրականում զբաղեցվել, փակելով օղակը «test-երն աշխատեցին» և «վարքագիծը ստուգված էր» միջև |
| SystemVerilog Assertions (SVA) | Ստուգում է temporal properties («եթե A տեղի ունենա, B-ն պիտի հետևի N cycle-ի ընթացքում») շարունակաբար մոդելավորման ընթացքում, որսալով bug-երը իրենց root cause-ին շատ ավելի մոտ, քան scoreboard mismatch-ը կաներ |
| Formal / property checking | Մաթեմատիկորեն ապացուցում է (կամ հերքում) property-ն բոլոր հնարավոր input հաջորդականությունների դեմ — vector-ներ պետք չեն — ամենաուժեղն է control logic-ի, protocol compliance-ի և դժվար հասանելի corner case-երի համար |
| Linting | Հենց RTL-ի static analysis (մոդելավորումից առաջ)՝ վաղ և էժան որսալով ոչ նախատեսված latch-եր, թերի case statement-ներ և այլ structural խնդիրներ |
| CDC / RDC checks | Clock-domain-crossing և reset-domain-crossing analysis-ը որսում է synchronization bug-եր, որոնք սովորաբար անտեսանելի են սովորական functional մոդելավորման համար |
Լավագույն փորձ և ծուղակներ
Coverage closure-ը օղակ է, ոչ թե milestone. աշխատեցրեք test-երը, չափեք coverage-ը, վերլուծեք բացերը, ավելացրեք կամ ճշգրտեք test-երը կամ constraint-ները, և կրկնեք, մինչև և՛ code, և՛ functional coverage-ը հասնեն իրենց sign-off թիրախներին (ցանկացած waiver-ի հստակ հիմնավորմամբ)։ Formal-ը և մոդելավորումը լրացնող են, ոչ մրցակից — formal-ը սպառիչ է, բայց լավագույնս աշխատում է bounded, control-ծանր logic-ի վրա, մինչ մոդելավորումը scale է անում full-chip, data-ծանր սցենարների, որ formal-ը գործնականում չի կարող ծածկել։
Logic Synthesis
Logic սինթեզը փոխարկում է verified RTL-ը gate-level հանգույցների ցանկի, որը կառուցված է թիրախային ստանդարտ բջիջների library-ի իրական բջիջներից, օպտիմալացված էներգասպառման, արագագործության և area-ի (PPA) համար՝ designer-ի տրամադրած constraint-ների ներքո։ Մեկ RTL design-ը կարող է map արվել բազմաթիվ ֆունկցիոնալորեն համարժեք, բայց structurally տարբեր հանգույցների ցանկերի, յուրաքանչյուրը՝ տարբեր PPA բնութագրերով — սինթեզի գործիքին տրված constraint-ներն են այն, ինչ ուղղորդում է դեպի իրականում ցանկալի հանգույցների ցանկը, ինչի պատճառով թերի կամ սխալ constraint set-ը վատ սինթեզի արդյունքի ամենատարածված աղբյուրներից մեկն է։
Կտտացրեք պիտակավորված արկղը՝ դրա էջը կամ բաժինը բացելու համար։ Սինթեզը հոսում է generic technology-independent gate-երի translation-ի, իրական ստանդարտ բջիջների library-ի վրա mapping-ի և վերջնական ժամանակային ուղղորդմամբ օպտիմալացման pass-ի միջով — ամեն ինչ ուղղորդված RTL-ի հետ մատակարարված SDC constraint-ներով։
Տարածված SDC constraint տեսակներ
| Սահմանափակում | Նպատակ |
|---|---|
| create_clock | Սահմանում է տակտային ազդանշանի period-ը և waveform-ը — ամենակարևոր constraint-ը, քանի որ գրեթե մնացած ամեն ինչը չափվում է դրա նկատմամբ |
| set_input_delay / set_output_delay | Մոդելավորում է սինթեզվող block-ից դուրս սպառված ժամանակային budget-ը՝ դրա input-ների և output-ների մոտ |
| set_max_transition / set_max_capacitance | Սահմանափակում է signal-ի slew-ն ու load-ը, որպեսզի mapped gate-երը մնան բջիջների library-ի characterized աշխատանքային միջակայքում |
| set_false_path | Ասում է գործիքին, որ ժամանակային path-ը ֆունկցիոնալորեն երբեք չի զբաղեցվում, ուստի այն ապարդյուն չի օպտիմալացվում |
| set_multicycle_path | Ասում է գործիքին, որ path-ին թույլատրվում է մեկից ավելի տակտային ազդանշանի cycle՝ հաստատվելու համար, թուլացնելով այլապես անհասանելի ժամանակային պահանջը |
| set_case_analysis | Ֆիքսում է signal-ը հաստատուն արժեքի օպտիմալացման նպատակով, թույլ տալով գործիքին պարզեցնել logic-ը, որը հասանելի է միայն մեկ configuration-ում |
Լավագույն փորձ և ծուղակներ
Unconstrained path-երը դասական սինթեզի ծուղակն են. եթե path-ը ծածկված չէ որևէ ժամանակային constraint-ով, գործիքը որևէ պատճառ չունի այն ընդհանրապես օպտիմալացնելու, և այն կարող է լուռ դառնալ design-ի ամենավատ path-ը՝ երբևէ որպես violation չհայտնվելով։ Over-constraining-ն ունի հակառակ խնդիրը — ավելի շատ margin պահանջելը, քան իրականում պետք է, այրում է area և էներգասպառում՝ հետապնդելով երբեք չեղած թիրախ։ Քանի որ սինթեզը և static ժամանակային վերլուծությունը օգտագործում են սերտորեն կապված, բայց ոչ նույնական ժամանակային engine-ներ, սինթեզի հաղորդած ժամանակային տվյալները վաղ signoff STA run-ի դեմ correlate անելը ստանդարտ փորձ է, այլ ոչ թե սպասել մինչև physical design՝ անհամապատասխանություն գտնելու համար։
Ենթաթեմաներ
Փուլ 04-ի երկու թեմա բավական մեծ են, որ արժանանան իրենց առանձին էջերին։
Ստանդարտ բջիջների library-ի ընտրություն
Library տեսակներ (HS/HD/UHD), ընտրության չափանիշներ, don't-use list-ը և multi-Vt քաղաքականություն — ներառյալ դաշտային դիտարկում Vt variance-ի զգայունության վերաբերյալ։
Առաջադեմ սինթեզի տեխնիկաներ և եզրային դեպքեր
Multi-bit flip-flop banking/debanking, combinational բջիջների unpacking, register retiming, topographical սինթեզ և datapath resource sharing։
Աղբյուրներ
Ընդհանուր արդյունաբերական հետազոտություն — այս էջը հիմնված չէ vendor-ին հատուկ ներքին փաստաթղթերի վրա։
- VLSI specification, architecture և microarchitecture design flow — ընդհանուր վեբ հետազոտություն
- RTL design, synchronous design practice և HDL coding guideline-ներ — ընդհանուր վեբ հետազոտություն
- An Introduction to Universal Verification Methodology for the Digital Design of ICs: A Review — IEEE Xplore
- A Proposed Methodology to Improve UVM-Based Test Generation and Coverage Closure — IEEE Xplore
- Efficient Methodology of Sampling UVM RAL During Simulation for SoC Functional Coverage — IEEE Xplore
- Logic Optimization and Synthesis: Trends and Directions in Industry — IEEE Xplore
- RTL Synthesis of Case Study Using Design Compiler — IEEE Xplore
- RTL Synthesis: From Logic Synthesis to Automatic Pipelining — IEEE Xplore
Ստանդարտ բջիջների library-ի և advanced սինթեզի technique ենթաթեմաների աղբյուրները թվարկված են իրենց առանձին էջերում. Ստանդարտ բջիջների library-ի ընտրություն և Առաջադեմ սինթեզի տեխնիկաներ և եզրային դեպքեր։