![SoC & ASIC Design at Ericsson
© Ericsson AB 2015 30
SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 62
BUILDING THE RTL TEST BENCH
› Create test benches to verify functional behavior and RTL
implementation
› Feature based verification
› High-level hardware verification language (HVL) with
declarative constructs for compactness
– e, SystemVerilog
› Stimuli generation
– Specify data format rather than exact content
– Random data generators with constraints
› Checkers verify stimuli/response relationship
– Basis for functional coverage analysis
SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 63
BUILDING THE RTL TEST BENCH
CONSTRAINED RANDOM TESTING
› Instead of specifying which variable values to test, specify
constraints for the interesting ranges
› Auto generate random values within the constraints
X
Y
Constraint{Y}
Constraint {X}
class CRT_example;
rand shortint X;
rand shortint Y;
constraint x1
{X inside {[xmin:xmax]};}
constraint y1
{Y inside {[ymin:ymax]};}
endclass: CRT_example
ymax
xmax
ymin
xmin
SystemVerilog code:](https://image.slidesharecdn.com/7c220026-84eb-415d-8613-89e688da0265-150812152304-lva1-app6891/85/lith-guest-lecture-2015-30-320.jpg)
lith-guest-lecture-2015
- 1. SoC & ASIC Design at Ericsson © Ericsson AB 2015 1 SOC & ASIC DESIGN AT ERICSSON Björn Fjellborg Ericsson AB, Radio Hardware Design Kista SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 2 THIS LECTURE › Mobile networks and HW infrastructure › Systemization and System design › Design challenges › SoC/ASIC design flow
- 2. SoC & ASIC Design at Ericsson © Ericsson AB 2015 2 Mobile Networks and HW Infrastructure SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 4 A MOBILE NETWORK LTE RAN GSM, WCDMA, LTE Radio Base Stations
- 3. SoC & ASIC Design at Ericsson © Ericsson AB 2015 3 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 5 ERICSSON RADIO BASE STATIONS The most visible part of a base station are usually the antennas (and antenna mast) The cabinet housing the HW and SW is located at a sealed off area below the antenna mast or inside a nearby building Cabinets come in different sizes, for different capacity OUTDOOR INDOOR SMALL INDOOR RADIO DOT SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 7 AN LTE (4G) SIGNAL PROCESSING ASIC › Uplink signal processing › 36 DSP cores › 1 CPU core › 29 M gates logic › 65 Mbit SRAM › 520 M transistors › 12 W power dissipation › 65 nm CMOS std cell › 675 ball flip chip PBGA package
- 4. SoC & ASIC Design at Ericsson © Ericsson AB 2015 4 Systemization and System Design SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 11 GSM 2G HSCSD EDGE 2.5G GPRS THE CELLULAR ROADMAP 1990 2000 2005 20101995 10k 100k 10M 1M 100M Bits/s 1G Evolved 3G ("Turbo 3G") UMTS/WCDMA WiMAX3G SMS Audio streaming/ download HDTV Voice Email WAP MMS Interactive data eHSPA Online gaming, Virtual worlds Data streaming, Web access Push to talk/ walkie-talkie Video streaming/ download HSPA See next page for abbreviations See next page for abbreviations High speed data and web access Web feeds/ RSS Location/positioning services LTE Mobile WiMAX4G 4G LTE-A 2015 App updates Social networking SW downloads Online video, audio, radio Video telephony/ conference 2020 Augmented reality 10G 5G Cloud services, storage UHDTV Connected vehicles Connected wearables InternetofThings NetworkedSociety Smart grid Smart home
- 5. SoC & ASIC Design at Ericsson © Ericsson AB 2015 5 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 12 ABBREVIATIONS › EDGE Enhanced Data rates for GSM Evolution › eHSPA Evolved HSPA › GPRS General Packet Radio Service › GSM Global System for Mobile communications › HDTV High Definition TV › HSCSD High-Speed Circuit-Switched Data › HSPA High-Speed Packet Access › LTE Long Term Evolution › LTE-A Long Term Evolution Advanced › MMS Multimedia Messaging Service › RSS Really Simple Syndication › SMS Short Messaging Service › UHDTV Ultra High Definition TV › UMTS Universal Mobile Telecommunications System › WAP Wireless Application Protocol › WCDMA Wideband Code Division Multiple Access › WiMAX Worldwide Interoperability for Microwave Access SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 13 MOBILE TRAFFIC DEVELOPMENT
- 6. SoC & ASIC Design at Ericsson © Ericsson AB 2015 6 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 14 GSM 2G HSCSD EDGE 2.5G GPRS THE CELLULAR ROADMAP 1990 2000 2005 20101995 10k 100k 10M 1M 100M Bits/s 1G Evolved 3G ("Turbo 3G") UMTS/WCDMA WiMAX3G SMS Audio streaming/ download HDTV Voice Email WAP MMS Interactive data eHSPA Online gaming, Virtual worlds Data streaming, Web access Push to talk/ walkie-talkie Video streaming/ download HSPA High speed data and web access Web feeds/ RSS Location/positioning services LTE Mobile WiMAX4G 4G LTE-A 2015 App updates Social networking SW downloads Online video, audio, radio Video telephony/ conference 2020 Augmented reality 10G 5G Cloud services, storage UHDTV Connected vehicles Connected wearables InternetofThings NetworkedSociety Smart grid Smart home SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 15 SIGNAL PROCESSING REQUIREMENTS Per user Per component Increased integration Increased integration Application complexity Air interface complexity Bits/s 10G 10k 100k 10M 1M 100M 1G 2000 2005 20101995 2015 20201990 OPS (for signal processing) 100G 10G 1G 100M 10M 1T 10T
- 7. SoC & ASIC Design at Ericsson © Ericsson AB 2015 7 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 16 LTE RAN SYSTEM LEVEL(S) Radio network Base station Board + SW package ASIC + SW module DSP core + SW routines Ericsson terminology: Node system SoC subsystem SoC Node subsystem Network system SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 17 SYSTEMIZATION PURPOSE › Find the most cost-efficient combination of HW components and SW modules that meets requirements on: – Performance (traffic capacity, latency) – Cost – Size (weight, height, footprint – physical area on ground/board/silicon or memory size) – Power consumption – Flexibility (for capacity expansion, functionality upgrade) – Environmental protection (hazardous substances, recycling)
- 8. SoC & ASIC Design at Ericsson © Ericsson AB 2015 8 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 18 SYSTEM IMPLEMENTATION CHOICES In-house developmentIn-house re-use External purchase ASIC DSP/CPU Hardwired logicIP* block HW accelerator ALU/FPU/... Node system SoC subsystem DSP/CPU core SoC FPGA Node subsystem HW components SW modules * IP = Intellectual Property, design block from another source SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 19 HW/SW TRADE-OFFS › System design is in many cases a trade-off between HW and SW solutions to best meet the systemization requirements: › The same trade-off applies to – ASIC/FPGA vs DSP/CPU – Hardwired logic vs DSP/CPU cores Performance CostPower Flexibility Better Worse HW SW HW SW HW SW SW HW single function single function set of functions set of functions SW HW
- 9. SoC & ASIC Design at Ericsson © Ericsson AB 2015 9 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 20 HW VS SW PERFORMANCE › HW has higher performance than SW because: – HW tailored to a specific functionality requires fewer gates than a general instruction execution engine Higher capacity/gate – Tailored HW can exploit parallelism to a higher degree than a DSP/CPU Lower latency (faster execution of complex functions) SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 21 HW VS SW POWER › HW has lower power dissipation than SW because: – Tailored HW uses few transistor switches/function (HW optimized for the specific function) Low energy/function step – SW that runs on an instruction execution engine induces many transistor switches/function (several SW instructions to load, decode, and execute) High energy/function step
- 10. SoC & ASIC Design at Ericsson © Ericsson AB 2015 10 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 22 HW VS SW FLEXIBILITY › SW has higher flexibility than HW because: – Correcting errors in SW requires no new HW Faster correction at customer site – Upgrading functionality in SW may require more memory but no new HW No HW production cost for upgrading, say, 100 000 customer sites (provided enough memory was designed in) – Note: Functionality upgrades in SW do not necessarily get to customer faster than HW upgrades, because development and verification times are comparable to those of HW (for complex systems)! SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 23 HW VS SW COST › HW has lower cost than SW when: – The functionality can be implemented on a tailored piece of HW that is cheaper/smaller than a general purpose DSP/CPU › A set of functions may have lower SW cost (a DSP/CPU): – Re-uses the same HW (instruction execution engine) for multiple functions – HW tailored to each function Cost = tailored HW blocks > 1 DSP/CPU
- 11. SoC & ASIC Design at Ericsson © Ericsson AB 2015 11 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 24 HW VS SW COST FURTHER CONSIDERATIONS › Concurrency-based allocation: – Has inherent concurrency: Use HW (utilize HW concurrency) › May require a large number of DSP/CPUs to obtain same performance › Typical for filter functions – Has inherent sequentiality: Use SW (no speed-up with tailored HW) DSP DSP DSP DSP Computational graph: Tailored parallel HW General DSP cores (larger HW cost for same performance)Parallel concurrency Pipelined concurrency SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 25 HW VS SW COST HW COST/PERFORMANCE TRADE-OFF › Often many alternatives for tailoring HW for a function: – Fast but expensive (parallel HW) – Slow but cheap (sequential HW) Cost Performance
- 12. SoC & ASIC Design at Ericsson © Ericsson AB 2015 12 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 26 HW/SW TRADE-OFFS SUMMARY › Finding the best HW/SW trade-off is a multi-dimensional optimization problem! Cost Performance Feasible solution space: Satisfies all constraints SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 27 SYSTEM DESIGN TOOLS AND MODELS › Signal processing algorithms are designed and analyzed in Matlab – Functionality and performance – Based on GSM/WCDMA/LTE standards › The signal chain is modelled at algorithmic level in C/C++ – Includes model of the air (radio channel mobile device – base station) – Constitutes a reference model for HW and SW implementation › Systemization alternatives are evaluated in various ways – Spreadsheets for cost, power, capacity – High-level architectural models for performance (transaction level models in SystemC) › SW Virtual Platforms – High-level functional models for SW development (transaction level models in SystemC) Node subsystem SoC
- 13. SoC & ASIC Design at Ericsson © Ericsson AB 2015 13 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 28 EXAMPLE: RANDOM ACCESS & DEMODULATION (RA-DEM) › WCDMA Uplink Baseband Antenna Near Signal Processing › A result from node subsystem systemization for baseband is that HW support for Random Access and Demodulation is needed in the receiver chain (for WCDMA receivers). › A RA-DEM detects and correlates all reflections of coded signals into one signal per transmitter › A RA-DEM performs a number of functions: – Preamble detect – Message search – Rake finger despread › The RA-DEM functions imply a number of operations: – Code match filtering – Interference estimation – Coherent and non-coherent accumulation – Interpolation – Squaring – ... SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 29 RA-DEM ARCHITECTURE First SoC/SoC subsystem systemization*: • Node subsystem systemization has resulted in a RA-DEM algorithm, given requirements at that level • SoC systemization has defined subfunctions (boxes in the picture) • All subfunctions are performed inside the SoC ASIC • System design task: For each box, decide whether to use - hardwired logic - SW (DSP core) * Subfunctions are anonymized for confidentiality reasons
- 14. SoC & ASIC Design at Ericsson © Ericsson AB 2015 14 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 30 RA-DEM DESIGN GOAL › Main goal: Minimize cost › Constraints: – Performance (can be determined with high precision per subfunction from the algorithm and max input data rate) – Power (total for the SoC; if the SoC power budget does not hold, re- systemization has to be done on the SoC or even the node subsystem level) – Flexibility (flexibility requirements are limited to those subfunctions that have to change in case of future upgrades) SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 31 RA-DEM SYSTEM DESIGN PERFORMANCE TRADE-OFF HW SW • Determine the subfunctions' performance requirement (in OPS) • Subfunctions that exceed one DSP core's performance (350 MOPS) HW (to avoid splitting over several DSPs) 2.2G 72M 184M 46M 55.6G 19G 588M 588M 294M 47M 40M 1.8k 184M 8.8G 4.32M 1.66M 1.8k 1.8k 3.6k 6.2G 3.1G 4.32M 92M 3.6M 92M 59.6M 59.6M 3.1G 59.6M 59.6M 588M
- 15. SoC & ASIC Design at Ericsson © Ericsson AB 2015 15 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 32 2.2G 72M 184M 46M 55.6G 19G 588M 588M 294M 47M 40M 1.8k 184M 8.8G 4.32M 1.66M 1.8k 1.8k 3.6k 6.2G 3.1G 4.32M 92M 3.6M 92M 59.6M 59.6M 3.1G 59.6M 59.6M 588M 72M 2.2G 184M 46M 55.6G 19G 588M 47M294M 40M 1.8k 184M 8.8G 4.32M 1.66M 1.8k 1.8k 3.6k 6.2G 3.1G 4.32M 92M 3.6M 92M 59.6M 59.6M 3.1G 59.6M 59.6M 588M 588M RA-DEM SYSTEM DESIGN FLEXIBILITY TRADE-OFF HW SW • Determine the subfunctions' flexibility requirement (upgradable or not) • Subfunctions that must be upgradable SW • Conflicting trade-offs may occur! ? SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 33 294M588M 588M 588M184M 46M 47M 1.8k 72M 2.2G 55.6G 19G 40M 1.8k 184M 8.8G 4.32M 1.66M 1.8k 3.6k 6.2G 3.1G 4.32M 92M 3.6M 92M 59.6M 59.6M 3.1G 59.6M 59.6M RA-DEM SYSTEM DESIGN LOAD TRADE-OFF HW SW • Determine the subfunctions' peak performance (OPS/max latency) – (A function that requires 10 MOPS and has to finish in 0.1 s has a peak performance of 10/0.1 = 100 MOPS) • Subfunctions that exceed one DSP core's performance (350 MOPS) HW • New conflicts may occur! ? ? 184M 46M 166M 1.6G 588M 118M 40M 1.8k 184M 36M 2.22M 3.6k 3.6k 3.6k 34.6M 736M 14.4M 736M 477M 477M 477M 477M
- 16. SoC & ASIC Design at Ericsson © Ericsson AB 2015 16 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 34 184M 46M 47M 1.8k 72M 2.2G 55.6G 19G 588M 294M 40M 1.8k 184M 8.8G 4.32M 1.66M 1.8k 3.6k 6.2G 3.1G 4.32M 92M 3.6M 92M 59.6M 59.6M 3.1G 59.6M 59.6M 588M 588M RA-DEM SYSTEM DESIGN CONCURRENCY TRADE-OFF HW SW • Determine which subfunctions that are inherently concurrent • Subfunctions with high degree of concurrency and reasonably high performance requirement HW ? ? 184M 46M 166M 1.6G 588M 118M 40M 1.8k 184M 36M 2.22M 3.6k 3.6k 3.6k 34.6M 736M 14.4M 736M 477M 477M 477M 477M 184M 46M 166M 1.6G 588M 118M 40M 1.8k 184M 36M 2.22M 3.6k 3.6k 3.6k 34.6M 736M 14.4M 736M 477M 477M 477M 477M SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 35 184M 46M 47M 1.8k 72M 2.2G 55.6G 19G 588M 294M 40M 1.8k 184M 8.8G 4.32M 1.66M 1.8k 3.6k 6.2G 3.1G 4.32M 92M 3.6M 92M 59.6M 59.6M 3.1G 59.6M 59.6M 588M 588M RA-DEM SYSTEM DESIGN HW COST TRADE-OFF HW SW • Cost of HW implementation = area of tailored HW • Cost of SW (DSP core) implementation = (load requirement/DSP performance) · DSP core area + extra interconnect • Express as % of a DSP core's area: Tailored HW area| DSP area + interconnect • Subfunctions with lower HW cost HW, the rest SW ? ? 184M 46M 166M 1.6G 588M 118M 40M 1.8k 184M 36M 2.22M 3.6k 3.6k 3.6k 34.6M 736M 14.4M 736M 477M 477M 477M 477M 5| 10+10 3| 10+3 5| 1+3 4| 0+3 5| 0+2 30| 34+2 20| 11+2 5| 0+2 45| 457+10 35| 168+10
- 17. SoC & ASIC Design at Ericsson © Ericsson AB 2015 17 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 36 184M 46M 47M 1.8k 72M 2.2G 55.6G 19G 588M 294M 40M 1.8k 184M 8.8G 4.32M 1.66M 1.8k 3.6k 6.2G 3.1G 4.32M 92M 3.6M 92M 59.6M 59.6M 3.1G 59.6M 59.6M 588M 588M RA-DEM SYSTEM DESIGN RESOLVING CONFLICTS HW SW ? ? 184M 46M 166M 1.6G 588M 118M 40M 1.8k 184M 36M 2.22M 3.6k 3.6k 3.6k 34.6M 736M 14.4M 736M 477M 477M 477M 477M 5| 10+10 3| 10+3 5| 1+3 4| 0+3 5| 0+2 30| 34+2 20| 11+2 5| 0+2 45| 457+10 35| 168+10 294M588M ? ? 1.6G 588M 45| 457+10 35| 168+10 › How important is the flexibility? – If worth the extra cost (4.22 resp 1.43 cores) SW, otherwise HW › Or, re-systemize: – Can the flexibility requirement be isolated to part of the subfunction? Split into sub-subfunctions and map to HW resp SW – Can we use SW- configurable HW? › The conflict is caused by the requirement on flexibility – everything else points to a HW solution › Cost for HW vs DSP core: – 0.45 vs 4.67 cores – 0.35 vs 1.78 cores Design Challenges for SoCs
- 18. SoC & ASIC Design at Ericsson © Ericsson AB 2015 18 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 38 RBS SIGNAL PROCESSING ASICS 1995-2015 – SIZES 5 M 500 M 50 M 10 M 20 M 100 M 200 M 1 G Logic 2 G 5 G Memory 2 million transistors 4 billion transistors Transistors SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 39 TECHNOLOGIES AND CHALLENGES 5 M 500 M 50 M 10 M 20 M 100 M 200 M 1 G 2 G 5 G Signal integrity Soft errors Leakage power Variation Wire delay Sum of all! 0.8 m 0.25 m 0.18 m 0.13 m 0.13 m 90 nm 65 nm 45 nm 40 nm 28 nm Transistors 16 nm +Reliability
- 19. SoC & ASIC Design at Ericsson © Ericsson AB 2015 19 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 40 WIRE DELAY, CROSSTALK, SOFT ERRORS › Wire delay dominates over logic delay at ≤ 0.35 µm – Solution: New delay models for timing analysis, interconnect-driven design › Signal integrity, e.g. crosstalk (capacitive coupling between parallel wires) that cause excessive delays and false pulses, at ≤ 0.18 µm – Solution: New design rules (wire spacing) and analysis methods › Soft errors (charged particles hit the silicon with enough energy to change the logic state) at ≤ 0.13 µm – Solution: Error correction coding of memory content SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 41 LEAKAGE POWER › Leakage current (transistor turn-off current) is a major contributor to power dissipation at ≤ 90 nm › Power is a limiting factor for design also for stationary equipment (i.e., not battery operated) – Cooling – Energy consumption Typical power budget 0% 20% 40% 60% 80% 100% Technology Powerdissipation Dynamic Leakage Conventional power reduction methods apply to dynamic power
- 20. SoC & ASIC Design at Ericsson © Ericsson AB 2015 20 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 42 PROCESS VARIATION AT THE ATOMIC SCALE › Parameter variation increases with decreasing geometry: – Dopant – Instrumentation – Mask precision – Lithography – Variations between fabs and batches › Timing characteristics vary significantly from chip to chip 10 100 1000 10000 1000 500 250 130 65 32 Technology Node (nm) MeanNumberofDopantAtoms Random dopant fluctuation: Number of dopant atoms SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 43 WHY ASIC? › 95 % of the functionality on a radio base station receiver board is signal processing › Developing an ASIC takes 1-1.5 year and costs several 10 MSEK › Buying a high-performance DSP costs 2000 SEK and it is available off the shelf › So why do we keep making ASICs?
- 21. SoC & ASIC Design at Ericsson © Ericsson AB 2015 21 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 44 ASIC VS DSP › ASICs are: – Custom made – Tailored to the application › Pros: – High functionality/transistor (tailored HW) – Few transistor switches/function (optimized HW; low energy) – Low component price (100-1000 SEK) › Cons: – Expensive to introduce (high development cost) – Available after 1-2 year development – Not upgradable for new functionality › DSPs are: – Commodity products – Used for general applications › Pros: – Cheap to introduce – Available at once (but SW will likely take at least 1 year to develop...) – Upgradable for new functionality (through SW) › Cons: – Less functionality/transistor (general SW) – Many transistor switches/function (several SW instructions to load, decode, and execute; high energy) – High component price (500-3000 SEK) SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 45 ASIC VS DSP PERFORMANCE › A 100 GOPS ASIC: – Uses massive parallelism (1000's of parallel threads in concurrent HW) – Can run at moderate frequency (100 MHz-1 GHz) Use low to medium performance Si process (high Vt transistors) Low current leakage Low to medium power dissipation (5-50 W) › A 100 GOPS DSP: – Uses moderate parallelism (pipelining, co-processors) – Must run at high frequency (2-20 GHz) Use high performance Si process (low Vt transistors) High current leakage High power dissipation (100- 1000 W)
- 22. SoC & ASIC Design at Ericsson © Ericsson AB 2015 22 SoC/ASIC Design Flow SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 47 FROM IDEA COMPONENT ... E ROP1011503 R1A
- 23. SoC & ASIC Design at Ericsson © Ericsson AB 2015 23 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 48 ... LIKE THIS? Hey! I've got this marvelous idea! Great! Let's go hack some code! Geez... Imagine life without VHDL... Your ASIC vendor Invoice $ 1,000,000 Product plans? Market window? Software? Firmware? O&M? Board? System integration? System verification? Type approval? Export control? Thermal design? Environmental protection restrictions? Price models? Supply agreement? Test? Patents? Product structure? Vendor negotiations? Documentation? Version control? Interfaces? Debug? Reliability? Signal integrity? Power budget? Producibility? Building practice? Soft errors? E ROP1011503 R1A SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 49 MAIN STEPS Technology study Structuring HW modeling & design ASIC technology mapping ASIC prototype manufacturing ASIC prototype verification SW modeling & design SW implementation SW verification
- 24. SoC & ASIC Design at Ericsson © Ericsson AB 2015 24 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 50 TECHNOLOGY STUDY › Analyze functional and performance requirements › Analyze technological possibilities › Investigate different technical solutions, consider: – standards – production costs – life cycle costs – reliability – environment – legal directives › Create a high level description of the system architecture (text and graphics) › Provide a decision base for project launch decision Hey! I've got this marvelous idea! Great! Let's go hack some code! SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 51 STRUCTURING › Partition into HW and SW › Define HW/SW interface › Partition into functional blocks › Create behavioral models to evaluate critical functionality (Matlab, C, VHDL) › Select IPs, IOs and memories, consider re-use of previous designs › Select ASIC technology and vendor › Choose package › Investigate patent opportunities › Specify system testability and diagnostics in production, field, and repair › Choose test strategy: scan test, memory test, boundary scan, logic BIST
- 25. SoC & ASIC Design at Ericsson © Ericsson AB 2015 25 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 52 TYPICAL ASIC DESIGN FLOW Processor cores BIST & TAPC RAMs PLL Coding Specification Synthesis Place & Route Production Prototypes Floorplanning Ericsson ASIC vendor IP (macros) Front-end Back-end Design & verification of - function - timing - power SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 53 ASIC DEVELOPMENT ACTIVITIES SpecificationSpecification TLM modelingTLM modeling Verification planningVerification planning Define TLM test casesDefine TLM test cases Build TLM testbenchBuild TLM testbench TLM simulationTLM simulation Debug - CorrectDebug - Correct RTL modelingRTL modeling RTL design rule checkRTL design rule check Formal property checkFormal property check RTL simulationRTL simulation Debug - CorrectDebug - Correct Continued verification (simulation, formal)Continued verification (simulation, formal) Build regression test suiteBuild regression test suite Debug – Correct/work aroundDebug – Correct/work around Define RTL test casesDefine RTL test cases Build RTL testbenchBuild RTL testbench Define propertiesDefine properties SpecificationSpecification TLM integrationTLM integration Define TLM test casesDefine TLM test cases Build TLM testbenchBuild TLM testbench TLM simulation (run SW)TLM simulation (run SW) Debug - CorrectDebug - Correct Verification planningVerification planning RTL integrationRTL integration Build RTL testbenchBuild RTL testbench Define RTL test casesDefine RTL test cases RTL simulationRTL simulation Connectivity check (formal)Connectivity check (formal) Build emulation testbench Build emulation testbench Define emulation test cases Define emulation test cases Emulation (with SW)Emulation (with SW) Continued verification (simulation, emulation) Continued verification (simulation, emulation) Debug – Correct/work around Debug – Correct/work around Debug - CorrectDebug - Correct Logic synthesisLogic synthesis Design planningDesign planning DFT insertionDFT insertion Equivalence checkEquivalence check Static timing analysisStatic timing analysis Gate level simulationGate level simulation Debug – Correct (ECO)Debug – Correct (ECO) Timing back-annotationTiming back-annotation Prototype verificationPrototype verification Debug – Work aroundDebug – Work around Constraints (re-)definitionConstraints (re-)definition Build regression test suite Build regression test suite DFT implementationDFT implementation FloorplanningFloorplanning Place & RoutePlace & Route Design rule checkDesign rule check Parasitic extractionParasitic extraction Chip manufacturingChip manufacturing Verification managementVerification management Verification managementVerification management 3 rounds of deliveries Block development ASIC chip development ASIC realization (by ASIC vendor) Several deliveries
- 26. SoC & ASIC Design at Ericsson © Ericsson AB 2015 26 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 54 Several deliveries BLOCK DEVELOPMENT SpecificationSpecification TLM modelingTLM modeling Verification planningVerification planning Define TLM test casesDefine TLM test cases Build TLM testbenchBuild TLM testbench TLM simulationTLM simulation Debug - CorrectDebug - Correct RTL modelingRTL modeling RTL design rule checkRTL design rule check Formal property checkFormal property check RTL simulationRTL simulation Debug - CorrectDebug - Correct Continued verification (simulation, formal)Continued verification (simulation, formal) Build regression test suiteBuild regression test suite Debug – Correct/work aroundDebug – Correct/work around Define RTL test casesDefine RTL test cases Build RTL testbenchBuild RTL testbench Define propertiesDefine properties SpecificationSpecification TLM integrationTLM integration Define TLM test casesDefine TLM test cases Build TLM testbenchBuild TLM testbench TLM simulation (run SW)TLM simulation (run SW) Debug - CorrectDebug - Correct Verification planningVerification planning RTL integrationRTL integration Build RTL testbenchBuild RTL testbench Define RTL test casesDefine RTL test cases RTL simulationRTL simulation Connectivity check (formal)Connectivity check (formal) Build emulation testbench Build emulation testbench Define emulation test cases Define emulation test cases Emulation (with SW)Emulation (with SW) Continued verification (simulation, emulation) Continued verification (simulation, emulation) Debug – Correct/work around Debug – Correct/work around Debug - CorrectDebug - Correct Logic synthesisLogic synthesis Design planningDesign planning DFT insertionDFT insertion Equivalence checkEquivalence check Static timing analysisStatic timing analysis Gate level simulationGate level simulation Debug – Correct (ECO)Debug – Correct (ECO) Timing back-annotationTiming back-annotation Prototype verificationPrototype verification Debug – Work aroundDebug – Work around Constraints (re-)definitionConstraints (re-)definition Build regression test suite Build regression test suite DFT implementationDFT implementation FloorplanningFloorplanning Place & RoutePlace & Route Design rule checkDesign rule check Parasitic extractionParasitic extraction Chip manufacturingChip manufacturing Verification managementVerification management Verification managementVerification management 3 rounds of deliveries Block development ASIC chip development ASIC realization (by ASIC vendor) SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 55 SPECIFICATION › Each function block has a Design Specification – There are also Interface Descriptions, Verification Specifications, Verification Reports + a number of other documents › Example of content:
- 27. SoC & ASIC Design at Ericsson © Ericsson AB 2015 27 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 56 VERIFICATION PLANNING Define how to reach verification goals within available time and resources: 1. Analyze the design requirements to identify features 2. Analyze the features’ characteristics: typical and extreme data/conditions 3. Set verification goals – Include all types of coverage 4. Design tests to achieve verification goals 5. Plan resources for verification (personnel, computers, licenses) 6. Commence verification SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 57 VERIFICATION FEATURES AND COVERAGE › Features of a design – Operations to perform – Data to process – Protocols to follow › Verification goals – Cover x % of typical cases – Cover y % of corner cases – Cover z % of interactions between features › Verification complete when cover goals reached (and bugs attended to) Three different verification features • Filled and emptied every FIFO in the design • Transmitted all packet types across a particular channel of the design • Transmitted packets across all channels in the design • Transmitted all packet types across all channels (cross-coverage) For example, functional coverage might track whether the verification process has: Interacting features
- 28. SoC & ASIC Design at Ericsson © Ericsson AB 2015 28 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 58 TRANSACTION LEVEL MODELING (TLM) › Model functionality at a high level › Communication modeled as transactions › Use SystemC and TLM-2 standard – Timing can be added › Simulates fast (10-1000 x faster than RTL) › Example SystemC code: – Communication modeled as function calls struct sender: sc_module { sc_out<pkt> pkt_out; sc_in<sc_int<4> > source_id; sc_in_clk CLK; SC_CTOR(sender) { SC_CTHREAD(entry, CLK.pos()); } void entry(); }; void sender:: entry() { pkt pkt_data; while(true) { // Data generation code ... pkt_out.write(pkt_data); wait(); } } SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 59 REGISTER TRANSFER LEVEL (RTL) MODELING › Model functionality and implementation at HW level › Communication modeled as signaling › Use VHDL, Verilog, SystemVerilog – Clock-based timing › Example VHDL code (excerpts) for a serial interface: entity serdes_rif is port ( clk : in std_logic; reset_n : in std_logic; cif_hss_strb : in std_logic; cif_hss_data : in std_logic_vector(cif_di_width_c downto 0); cif_hss_ack_strb : in std_logic; cif_hss_data_out : out std_logic_vector(cif_do_width_c downto 0); cif_hss_req : out std_logic; cif_hss_halt : out std_logic; rc_clk : in std_logic; rc_reset_b : in std_logic; rcmh_address : out std_logic_vector(31 downto 0); rcmh_wdata : out std_logic_vector(15 downto 0); rcmh_wmask : out std_logic_vector(15 downto 0); rcmh_write_req : out std_logic; rcmh_wmask_req : out std_logic; rcmh_read_req : out std_logic; rcmh_ack : in std_logic; rcmh_rresult : in std_logic; rcmh_rdata : in std_logic_vector(15 downto 0) ); end serdes_rif; rcmh_read_req <= not sr_data(65) when req_trigger_d1 = '1' else '0'; rcmh_write_req <= sr_data(65) when req_trigger_d1 = '1' and sr_data(64) = '0' else '0'; rcmh_address <= sr_data(63 downto 32) when req_trigger_d1 = '1' else (others => '0'); rcmh_wmask_req <= sr_data(64) when req_trigger_d1 = '1' and sr_data(65) = '1' else '0'; rcmh_wmask <= sr_data(31 downto 16) when req_trigger_d1 = '1' and sr_data(65) = '1' else (others => '0'); rcmh_wdata <= sr_data(15 downto 0) when req_trigger_d1 = '1' and sr_data(65) = '1' else (others => '0'); rc_ctrl_fsm : process (state_rs, sr_data(65), sr_data(64), req_trigger_d1, rcmh_ack, rcmh_rresult, rc_domain_clear_s) begin -- process rc_ctrl_fsm nextstate_rs <= state_rs; read_data_valid <= '0'; case state_rs is when idle_e => if rc_domain_clear_s = '0' then if req_trigger_d1 = '1' then if sr_data(65) = '1' then nextstate_rs <= wait_acknowledge_w_e; else nextstate_rs <= wait_acknowledge_r_e; end if; end if; end if; when wait_acknowledge_w_e => if rc_domain_clear_s = '0' then if rcmh_ack = '1' then read_data_valid <= '1'; nextstate_rs <= idle_e; end if; else nextstate_rs <= idle_e; end if; when wait_acknowledge_r_e => if rc_domain_clear_s = '0' then if rcmh_ack = '1' then nextstate_rs <= wait_read_data_e; end if; else nextstate_rs <= idle_e; end if; when wait_read_data_e => if rc_domain_clear_s = '0' then if rcmh_rresult = '1' then read_data_valid <= '1'; nextstate_rs <= idle_e; end if; else nextstate_rs <= idle_e; end if; when others => nextstate_rs <= idle_e; end case; end process rc_ctrl_fsm; + about 400 additional code lines of declarations, synchronization processes, meta-stability handling, etc Signal assignments: Entity with ports: FSM controller (part):
- 29. SoC & ASIC Design at Ericsson © Ericsson AB 2015 29 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 60 SystemC TLM-2 model (system or sub-system level) SYSTEM PERFORMANCE ANALYSIS Shared memory HW block HW block DSP core IO Communication Infrastructure Traffic gen. Traffic gen. Traffic gen. Performance analysis Debug Latency Contention Throughput Bandwidth Utilization (time, memory) Transaction tracing CCI* information exchange: Registers Internal state Transaction logging etc *CCI = Configuration, Control & Inspection SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 61 DEFINE PROPERTIES › Properties are used for three purposes: – Assertions: Define conditional expected events and sequences (what you want to test) – Assumptions: Constraints (what states the design can have) – Covers: Check that certain states are reached (can be prerequisites for tests) SystemVerilog codeSystemVerilog code Example assertion: Check that a bus request is followed by an acknowledge 1-3 cycles after the request
- 30. SoC & ASIC Design at Ericsson © Ericsson AB 2015 30 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 62 BUILDING THE RTL TEST BENCH › Create test benches to verify functional behavior and RTL implementation › Feature based verification › High-level hardware verification language (HVL) with declarative constructs for compactness – e, SystemVerilog › Stimuli generation – Specify data format rather than exact content – Random data generators with constraints › Checkers verify stimuli/response relationship – Basis for functional coverage analysis SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 63 BUILDING THE RTL TEST BENCH CONSTRAINED RANDOM TESTING › Instead of specifying which variable values to test, specify constraints for the interesting ranges › Auto generate random values within the constraints X Y Constraint{Y} Constraint {X} class CRT_example; rand shortint X; rand shortint Y; constraint x1 {X inside {[xmin:xmax]};} constraint y1 {Y inside {[ymin:ymax]};} endclass: CRT_example ymax xmax ymin xmin SystemVerilog code:
- 31. SoC & ASIC Design at Ericsson © Ericsson AB 2015 31 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 64 RTL DESIGN RULE CHECK › Designability = Ability to design › Rule check: Find design patterns that may cause problems in the design flow – Static check of HDL code › Typically several hundred rules › Rule examples: – Avoid latches (incomplete HDL conditions may cause unintentional latches) – Memory inputs should be observable (for test) – Use specified identifier suffixes, e.g. ”_n” for active low – One file per HDL design unit (entity/module etc) – Use fixed indentation – Use IEEE Numeric_std packages SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 65 RTL VERIFICATION AND DEBUG › First verify assertions by formal property check – Mathematical proof that a behavior always/never occurs › Then simulate what’s left – Mathematical computations – Performance › Debug is typically waveform based
- 32. SoC & ASIC Design at Ericsson © Ericsson AB 2015 32 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 66 VERIFICATION MANAGEMENT › Collect results from all dispatched jobs – Failures (design errors) – Coverage › Track progress of test suite A session = a sequence of testsA session = a sequence of tests P – Passed F – Failed R – Running W – Waiting O – Other P – Passed F – Failed R – Running W – Waiting O – Other SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 67 ASIC CHIP (TOP-LEVEL) DEVELOPMENT SpecificationSpecification TLM modelingTLM modeling Verification planningVerification planning Define TLM test casesDefine TLM test cases Build TLM testbenchBuild TLM testbench TLM simulationTLM simulation Debug - CorrectDebug - Correct RTL modelingRTL modeling RTL design rule checkRTL design rule check Formal property checkFormal property check RTL simulationRTL simulation Debug - CorrectDebug - Correct Continued verification (simulation, formal)Continued verification (simulation, formal) Build regression test suiteBuild regression test suite Debug – Correct/work aroundDebug – Correct/work around Define RTL test casesDefine RTL test cases Build RTL testbenchBuild RTL testbench Define propertiesDefine properties SpecificationSpecification TLM integrationTLM integration Define TLM test casesDefine TLM test cases Build TLM testbenchBuild TLM testbench TLM simulation (run SW)TLM simulation (run SW) Debug - CorrectDebug - Correct Verification planningVerification planning RTL integrationRTL integration Build RTL testbenchBuild RTL testbench Define RTL test casesDefine RTL test cases RTL simulationRTL simulation Connectivity check (formal)Connectivity check (formal) Build emulation testbench Build emulation testbench Define emulation test cases Define emulation test cases Emulation (with SW)Emulation (with SW) Continued verification (simulation, emulation) Continued verification (simulation, emulation) Debug – Correct/work around Debug – Correct/work around Debug - CorrectDebug - Correct Logic synthesisLogic synthesis Design planningDesign planning DFT insertionDFT insertion Equivalence checkEquivalence check Static timing analysisStatic timing analysis Gate level simulationGate level simulation Debug – Correct (ECO)Debug – Correct (ECO) Timing back-annotationTiming back-annotation Prototype verificationPrototype verification Debug – Work aroundDebug – Work around Constraints (re-)definitionConstraints (re-)definition Build regression test suite Build regression test suite DFT implementationDFT implementation FloorplanningFloorplanning Place & RoutePlace & Route Design rule checkDesign rule check Parasitic extractionParasitic extraction Chip manufacturingChip manufacturing Verification managementVerification management Verification managementVerification management 3 rounds of deliveries Block development ASIC chip development ASIC realization (by ASIC vendor) Several deliveries
- 33. SoC & ASIC Design at Ericsson © Ericsson AB 2015 33 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 68 EMULATION › RTL or gate level verification › Acceleration: Replace design in simulation (keep simulated test bench) › In Circuit Emulation: Replace circuit on board with model in emulator; connect emulator to board › Emulates design with configurable hardware arrays (FPGAs or custom developed) – Extremely fast, ~1 M cycles/s › Requires long test cases for efficient use – Random or real data streams, application SW SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 69 HW/SW CO-VERIFICATION EXAMPLE › Typical signal processing architecture: ASIC CPUDSP DSP DSP Logic & RAM EPROM DSP SW Control SW
- 34. SoC & ASIC Design at Ericsson © Ericsson AB 2015 34 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 70 HW/SW CO-VERIFICATION SWHW ASIC HW Test DSP SW Simulator ASIC integration DSP SW host environment DSP SW verification Emulator HW/SW co-verification HW SW Simulator + C ASIC/DSP SW co-verification Step 1 SW target environment SW integration Control SW host environment Control SW verification DSP SW Control SW IP models (CPUs etc) DSP modelStep 2 Step 3 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 71 SYNTHESIS AND DESIGN PLANNING › Map RTL to optimized gate level netlist – Needs cell library for target technology › Work towards goals – Typically minimized area or power › Find result within constraints – Typically timing or power › Synthesis result depends on physical layout – Layout affects timing constraints › Physical layout depends on synthesis – Synthesis determines size of blocks › Good result requires interaction synthesis – design planning (= preliminary layout) Synthesis Layout AreaTiming
- 35. SoC & ASIC Design at Ericsson © Ericsson AB 2015 35 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 72 EQUIVALENCE CHECK › Checks functional equivalence of two designs – RTL - gate (before and after synthesis) – Gate - gate (before and after netlist modification) – (RTL - RTL) › Formal methods – Reference design logically implies* compared design – No test bench, no test vectors – Verifies complete design * Implication () means that all reference functionality is present in the compared design, but the compared design may have additional functions not present in the reference design. Equivalent? SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 73 STATIC TIMING ANALYSIS › Verify timing › Gate level › Estimated or back-annotated timing from layout › Calculate delay along all clock and data paths – Check for setup and hold violations, delays, pulse widths – Locate critical paths – Analysis for worst case, best case, on-chip variation Timing path for worst case (setup check) setup time d ck min_path time max_path time
- 36. SoC & ASIC Design at Ericsson © Ericsson AB 2015 36 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 74 BACK-END DESIGN & VERIFICATION RTL NHO netlist Sign-off netlist Synthesis = Back-end design & verification team Equivalence checker Equivalence checker Preliminary netlist Floorplanning Test insertion Place & Route Test insertion Equivalence checker SDF Simulator SDF Simulator Ericsson ASIC vendor Typically at least 3 deliveries to ASIC vendor Typically at least 3 deliveries to ASIC vendor Constraints Static Timing Analyzer Static Timing Analyzer SIGN-OFF! Increasing precision SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 75 PROTOTYPE VERIFICATION › Establish that ASIC prototypes meet specifications: – functionality at full speed – interaction between blocks – I/O pad connectivity – timing on interfaces – electrical characteristics › Tested in lab environment: – production board or test board BGA adapter Logic analyzer Oscilloscope Data generator CPU debugger RISCWatch/Green Hills Probe DSP core debugger Ericsson inhouse Simulation test vectors DSP SWCPU SW Other components E ROP1011503 R1A
- 37. SoC & ASIC Design at Ericsson © Ericsson AB 2015 37 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 76 ASIC DESIGN FLOW – OVERVIEW Design activity Verification activity Logic synthesis Static timing analysis ASIC vendor back-end & manufacture Prototype verification Gate simulation Timing & Loads Equivalence check Test coverage Gate emulation Gate level power analysis Rule check RTL design entry Acceleration Test vectors SW RTL simulationFormal verification TLM design entry TLM simulation Architectural exploration RTL power analysis Verification planning Verification run management Verification environment design & entry Debug Testbench qualification Design planning Switching frequencies Reference models CDC check Performance analysis SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 77 LOGIC DESIGN FLOW Rule check Design planning Logic synthesis Equivalence check Simulation Floorplan data DEF/MW Parasitics Switching SAIF Simulation Reports - area - timing - power - DRC ASIC vendor back-end RTL VHDL/ (System)- VerilogSynthesis Design rules Netlist verification Timing Gate level power analysis Static Timing Analysis Power model DB Timing model DB Design rules Power Timing SDF Power reports Design exploration Architectural exploration TLM SystemC Analysis database Perfor- mance reports DRC reports Netlist Verilog RTL power analysis Verification setup SVF Constraints TCL
- 38. SoC & ASIC Design at Ericsson © Ericsson AB 2015 38 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 78 RTL FUNCTIONAL VERIFICATION FLOW HW/SW co-verification Verification management Acceleration Formal verification RTL code VHDL/ (System)Verilog Properties SVA DSP SW Require- ments Verification planning Modify/ Extend Directed tests Constrained random tests Assertions OK OK Emulation Target debug Board environment Verification IP eVC/UVC Ref. model (alg. parts) C++ Testbench e/ SystemVerilog Simulation Test coverage OK Code coverage Functional coverage Assertion coverage Testbench qualification Verification run management SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 79 LANGUAGES SpecificationSpecification TLM modelingTLM modeling Verification planningVerification planning Define TLM test casesDefine TLM test cases Build TLM testbenchBuild TLM testbench TLM simulationTLM simulation Debug - CorrectDebug - Correct RTL modelingRTL modeling RTL design rule checkRTL design rule check Formal property checkFormal property check RTL simulationRTL simulation Debug - CorrectDebug - Correct Continued verification (simulation, formal)Continued verification (simulation, formal) Build regression test suiteBuild regression test suite Debug – Correct/work aroundDebug – Correct/work around Define RTL test casesDefine RTL test cases Build RTL testbenchBuild RTL testbench Define propertiesDefine properties SpecificationSpecification TLM integrationTLM integration Define TLM test casesDefine TLM test cases Build TLM testbenchBuild TLM testbench TLM simulation (run SW)TLM simulation (run SW) Debug - CorrectDebug - Correct Verification planningVerification planning RTL integrationRTL integration Build RTL testbenchBuild RTL testbench Define RTL test casesDefine RTL test cases RTL simulationRTL simulation Connectivity check (formal)Connectivity check (formal) Build emulation testbench Build emulation testbench Define emulation test cases Define emulation test cases Emulation (with SW)Emulation (with SW) Continued verification (simulation, emulation) Continued verification (simulation, emulation) Debug – Correct/work around Debug – Correct/work around Debug - CorrectDebug - Correct Logic synthesisLogic synthesis Design planningDesign planning DFT insertionDFT insertion Equivalence checkEquivalence check Static timing analysisStatic timing analysis Gate level simulationGate level simulation Debug – Correct (ECO)Debug – Correct (ECO) Timing back-annotationTiming back-annotation Prototype verificationPrototype verification Debug – Work aroundDebug – Work around Constraints (re-)definitionConstraints (re-)definition Build regression test suite Build regression test suite DFT implementationDFT implementation FloorplanningFloorplanning Place & RoutePlace & Route Design rule checkDesign rule check Parasitic extractionParasitic extraction Chip manufacturingChip manufacturing Verification managementVerification management Verification managementVerification management 3 rounds of deliveries Block development ASIC realization (by ASIC vendor) SystemC VHDL Verilog SystemVerilog, e SystemVerilog, e SystemC/C++SystemC/C++ ASIC chip development SVA, PSL Several deliveries
- 39. SoC & ASIC Design at Ericsson © Ericsson AB 2015 39 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 80 AFTER PROTOTYPE VERIFICATION ASIC prototype verification Board verification Subsystem verification System verification Type approval Sales & marketing Board Subsystem SW Other subsystems System SW Mechanics Design & verification Design & verification Design & verification Design & verification Design & verification SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 81 WANT TO PARTICIPATE? › Do you want to: – Contribute to the world-wide expansion of mobile communications? – Use the absolutely latest microelectronics technology? – Be part of a world class ASIC design team? – Work at the #1 telecommunications company? › Look for job opportunities and thesis works at www.ericsson.com/careers !
- 40. SoC & ASIC Design at Ericsson © Ericsson AB 2015 40 SoC & ASIC Design at Ericsson | © Ericsson AB 2015 | Page 83