EMBEDDED AND REAL TIME SYSTEMS-Unit-4_6703.pptx

ERTS NOTES-3

1. EC6703 EMBEDDED AND REAL TIME SYSTEMS

2. Design methodologies Design flows Requirement Analysis Specifications System analysis and architecture design Quality Assurance techniques Distributed embedded systems MPSoCs and shared memory multiprocessors. UNIT IV SYSTEM DESIGN TECHNIQUES AND NETWORKS

3. In this chapter we consider the techniques required to create complex embedded systems . Thus far, our design examples have been small so that important concepts can be conveyed relatively simply. However , most real embedded system designs are inherently complex , given that their functional specifications are rich and they must obey multiple other requirements on cost, performance, and so on . We need methodologies to help guide our design decisions when designing large systems. INTRODUCTION

4. This section considers the complete design methodology — a design process— for embedded computing systems. We will start with the rationale for design methodologies , then look at several different methodologies. DESIGN METHODOLOGIES Process is important because without it , we can’t reliably deliver the products we want to create. Thinking about the sequence of steps necessary to build something may seem superfluous. But the fact is that everyone has their own design process , even if they don’t articulate it. If you are designing embedded systems in your basement by yourself, having your own work habits is fine. But when several people work together on a project, they need to agree on who will do things and how they will get done. Being explicit about process is important when people work together. Therefore, since many embedded computing systems are too complex to be designed and built by one person, we have to think about design processes. Why Design Methodologies?

5. The obvious goal of a design process is to create a product that does something useful . Typical specifications for a product will include functionality (e.g ., cell phone), manufacturing cost (must have a retail price below $200), Performance (must power up within 3 s), power consumption (must run for 12 h on two AA batteries), or other properties. a design process has several important goals beyond function, performance , and power . Three of these goals are summarized below. ■ Time-to-market -beat competitors to market ■ Design cost ■ Quality

6. Design Methodology Waterfall model Spiral model Successive refinement model Hardware/software design flow A hierarchical design flow Concurrent engineering

7. Design flow Design flow : sequence of steps in a design methodology. May be partially or fully automated. Use tools to transform, verify design. Design flow is one component of methodology. Methodology also includes management organization, etc. Models

8. 1. Waterfall model Early model for software development: requirements architecture coding testing maintenance Introduced by Royce , the first model proposed for the software development process. The waterfall model gets its name from the largely one-way flow of work and information from higher levels of abstraction to more detailed design steps

9. Waterfall model 5 steps Requirements: determine basic characteristics. Architecture: decompose into basic modules. Coding: implement and integrate. Testing: exercise and uncover bugs. Maintenance: deploy, fix bugs, upgrade.

10. Waterfall model critique Only local feedback---may need iterations between coding and requirements, for example. Doesn’t integrate top-down and bottom-up design. Assumes hardware is given. Most design projects entail experimentation and changes that require bottom–up feedback . As a result, the waterfall model is today cited as an unrealistic design process . So, an alternative model of software development called the spiral model .

11. 2.Spiral model requirements design test system feasibility specification prototype initial system enhanced system

12. Spiral model critique Successive refinement of system. Start with mock-ups, move through simple systems to full-scale systems. Provides bottom-up feedback from previous stages. Working through stages may take too much time. A spiral methodology with too many spirals may take too long when design time is a major requirement.

13. Successive refinement model specify architect design build test initial system specify architect design build test refined system The system is built several times . A first system is used as a rough prototype, and successive models of the system are further refined.

14. Hardware/software design flow requirements and specification architecture hardware design software design integration testing

15. Co-design methodology Must architect hardware and software together: provide sufficient resources; avoid software bottlenecks. Can build pieces somewhat independently, but integration is major step. Also requires bottom-up feedback.

16. Hierarchical design flow Embedded systems must be designed across multiple levels of abstraction: system architecture; hardware and software systems; hardware and software components. Often need design flows within design flows.

17. A hierarchical design flow for an embedded system.

18. Concurrent engineering Large projects use many people from multiple disciplines. Work on several tasks at once to reduce design time. Feedback between tasks helps improve quality, reduce number of later design problems.

19. Concurrent engineering techniques Cross-functional teams. Concurrent product realization. Incremental information sharing. Integrated product management. Early and continual supplier involvement Early and continual customer focus

20. AT&T PBX concurrent engineering Benchmark against competitors. Identify breakthrough improvements. Characterize current process. Create new process. Verify new process. Implement. Measure results and improve. EX: Concurrent engineering applied to telephone systems

21. Requirements analysis Requirements : informal description of what customer wants. Specification : precise description of what design team should deliver. The overall goal of creating a requirements document is effective communication between the customers and the designers. The designers should know what they are expected to design for the customers

22. Types of requirements Functional : input/output relationships.( FFT ) Non-functional : timing; power consumption; manufacturing cost; physical size; time-to-market; reliability.

23. A good set of requirements should meet several tests Correctness. Unambiguousness. Completeness. Verifiability: is each requirement satisfied in the final system? Consistency: requirements do not contradict each other. Modifiable: can update requirements easily. Traceable: know why each requirement exists; go from source documents to requirements; go from requirement to implementation; back from implementation to requirement

24. Setting requirements Customer interviews. Comparison with competitors. Sales feedback. Mock-ups, prototypes.

25. Specifications Capture functional and non-functional properties: verify correctness of spec; compare spec to implementation. Many specification styles: control-oriented vs. data-oriented; textual vs. graphical. UML is one specification/design language.

26. 1.SDL State machine specification language is the SDL language which was developed by the communications industry for specifying communication protocols, telephone systems, and so forth. Event-oriented state machine model. telephone on-hook dial tone caller goes off-hook caller gets dial tone

27. The SDL specification language

28. 2.State charts Ancestor of UML state diagrams. Provided composite states: OR states; AND states. Composite states reduce the size of the state transition graph. Other techniques can be used to eliminate clutter and clarify the important structure of a state-based specification. The State chart is one well-known technique for state-based specification

29. Statechart OR state S1 S2 S3 S4 i1 i1 i2 i2 i2 traditional S1 S2 S3 S4 i1 i1 i2 OR state s123

30. Statechart AND state S1-3 S1-4 S2-3 S2-4 S5 traditional c d b a r c d b a S1 S3 S2 S4 S5 AND state c d r b a sab r

31. 3. AND-OR tables Alternate way of specifying complex conditions: cond1 T - cond2 - T cond3 - F AND OR Leveson et al. [Lev94] used a different format, the AND/OR table , to describe similar relationships between states

32. TCAS II specification TCAS II: aircraft collision avoidance system. Monitors aircraft and air traffic info. Provides audio warnings and directives to avoid collisions. Leveson et al used RMSL language to capture the TCAS specification.

33. System analysis and architecture design In this section we consider how to turn a specification into an architecture design . we look at how to get a handle on the overall system architecture. The CRC card methodology is a well-known and useful way to help analyze a system’s structure. It is particularly well suited to object-oriented design since it encourages the encapsulation of data and functions.

34. CRC cards The acronym CRC stands for the following three major items that the methodology tries to identify: CRC: Classes ; Responsibilities of each class; Collaborators are other classes that work with a class. Team-oriented methodology.

35. CRC card format Class name: Superclasses: Subclasses: Responsibilities: Collaborators: Class name: Class’s function: Attributes: front back

36. The CRC card methodology is informal, but we should go through the following steps when using it to analyze a system: Develop an initial list of classes. Simple description is OK. Team members should discuss their choices. Write initial responsibilities/collaborators. Helps to define the classes. Create some usage scenarios. Major uses of system and classes.

37. CRC methodology, cont’d. Walk through scenarios. See what works and doesn’t work. Refine the classes, responsibilities, and collaborators. Add class relatoinships : superclass , subclass.

38. EX: CRC cards for elevator Real-world classes: elevator car, passenger, floor control, car control, car sensor. Architectural classes: car state, floor control reader, car control reader, car control sender, scheduler.

39. Elevator responsibilities and collaborators

40. Quality Assurance The quality of a product or service can be judged by how well it satisfies its intended function. The quality assurance (QA) process is vital for the delivery of a satisfactory System. In this section we will concentrate on portions of the methodology particularly aimed at improving the quality of the resulting system . “The pursuit of quality extends throughout the design flow.” For example, settling on the proper requirements and specification cannot be overlooked as an important determinant of quality. Quality assurance ( QA ) makes sure that all stages of the design process help to deliver a quality product.

41. Quality Assurance (QA) ( EX: The Therac - 25 medical imaging system)

42. Therac-25 Medical Imager ( Leveson and Turner) Six known accidents: radiation overdoses leading to death and serious injury. Radiation gun controlled by PDP-11 mini computer. Four major software components: stored data; scheduler; set of tasks; interrupt services.

43. Therac-25 tasks Treatment monitor controlled and monitored setup and delivery of treatment in eight phases. Servo task controlled radiation gun. Housekeeper task took care of status interlocks and limit checks.

44. Treatment monitor task Treat was main monitor task. Eight subroutines. Treat rescheduled itself after every subroutine.

45. Software timing race Timing-dependent use of mode and energy: if keyboard handler sets completion behavior before operator changes mode/energy data, Datent task will not detect the change, but Hand task will.

46. Software timing errors Changes to parameters made by operator may show on screen but not be sensed by Datent task. One accident caused by entering mode/energy, changing mode/energy, returning to command line in 8 seconds. Skilled operators typed faster, more likely to exercise bug.

47. Leveson and Turner observations Performed limited safety analysis: guessed at error probabilities, etc. Did not use mechanical backups to check machine operation. Used overly complex programs written in unreliable styles.

48. Quality Assurance Techniques

49. ISO 9000 Developed by International Standards organization. Applies to a broad range industries. Concentrates on process. Validation based on extensive documentation of organization’s process.

50. CMU Capability Maturity Model Five levels of organizational maturity: Initial : poorly organized process, depends on individuals. Repeatable : basic tracking mechanisms. Defined : processes documented and standardized. Managed : makes detailed measurements. Optimizing : measurements used for improvement.

51. requirements bug Verification Verification and testing are important throughout the design flow. Early bugs are more expensive to fix: time cost to fix coding bug

52. Verifying requirements and specification Requirements: prototypes; prototyping languages; pre-existing systems. Specifications: usage scenarios; formal techniques.

53. Design review Uses meetings to catch design flaws. Simple, low-cost. Proven by experiments to be effective. Use other people in the project/company to help spot design problems.

54. Design review players Designers : present design to rest of team, make changes. Review leader : coordinates process. Review scribe : takes notes of meetings. Review audience : looks for bugs.

55. Before the design review Design team prepares documents used to describe the design. Leader recruits audience, coordinates meetings, distributes handouts, etc. Audience members familiarize themselves with the documents before they go to the meeting.

56. Design review meeting Leader keeps meeting moving; scribe takes notes. Designers present the design: use handouts; explain what is going on; go through details.

57. Design review audience Look for any problems: Is the design consistent with the specification? Is the interface correct? How well is the component’s internal architecture designed? Did they use good design/coding practices? Is the testing strategy adequate?

58. Follow-up Designers make suggested changes. Document changes. Leader checks on results of changes, may distribute to audience for further review or additional reviews.

59. Measurements Measurements help ground our beliefs: Do our practices really work? Do they work where we think they work? Types of measurements: bugs found at different stages of design; bugs as a function of time; bugs in different types of components; how bugs are found.

60. Distributed or networked embedded systems In a distributed embedded system, several processing elements (PEs) (either microprocessors orASICs ) are connected by a network that allows them to communicate.The application is distributed over the PEs,and some of the work is done at each node in the network.

61. Network elements PE PE PE network communication link distributed computing platform: PEs may be CPUs or ASICs.

62. Networks in embedded systems PE PE sensor PE actuator initial processing more processing

63. Why distributed? Higher performance at lower cost. Physically distributed activities---time constants may not allow transmission to central site. Improved debugging---use one CPU in network to debug others. May buy subsystems that have embedded processors.

64. Network abstractions International Standards Organization (ISO) developed the Open Systems Interconnection ( OSI ) model to describe networks: 7-layer model. Provides a standard way to classify network components and operations.

65. OSI model physical mechanical, electrical data link reliable data transport network end-to-end service transport connections presentation data format session application dialog control application end-use interface

66. OSI layers Physical : connectors, bit formats, etc. Data link : error detection and control across a single link (single hop). Network : end-to-end multi-hop data communication. Transport : provides connections; may optimize network resources.

67. OSI layers, cont’d. Session : services for end-user applications: data grouping, checkpointing, etc. Presentation : data formats, transformation services. Application : interface between network and end-user programs.

68. Hardware architectures Many different types of networks: topology; scheduling of communication; routing.

69. Point-to-point networks One source, one or more destinations, no data switching (serial port): PE 1 PE 2 PE 3 link 1 link 2

70. Bus networks Common physical connection: PE 1 PE 2 PE 3 PE 4 header address data ECC packet format

71. Bus arbitration Fixed : Same order of resolution every time. Fair : every PE has same access over long periods. round-robin : rotate top priority among Pes. A,B,C A,B,C fixed round-robin A B C A B C A B C A B C

72. Crossbar in1 in2 in3 in4 out1 out2 out3 out4

73. Crossbar characteristics Non-blocking. Can handle arbitrary multi-cast combinations. Size proportional to n 2 .

74. Multi-stage networks Use several stages of switching elements. Often blocking. Often smaller than crossbar.

75. Message-based programming Transport layer provides message-based programming interface: send_msg(adrs,data1); Data must be broken into packets at source, reassembled at destination. Data-push programming : make things happen in network based on data transfers.

76. I 2 C bus Designed for low-cost, medium data rate applications. Characteristics: serial; multiple-master; fixed-priority arbitration. Several microcontrollers come with built-in I 2 C controllers.

77. I 2 C physical layer master 1 master 2 slave 1 slave 2 SCL SDL data line clock line

78. I 2 C data format SCL SDL ... MSB start ... ack ...

79. I 2 C electrical interface SDL + Open collector interface: SCL +

80. I 2 C signaling Sender pulls down bus for 0. Sender listens to bus---if it tried to send a 1 and heard a 0, someone else is simultaneously transmitting. Transmissions occur in 8-bit bytes.

81. I 2 C data link layer Every device has an address (7 bits in standard, 10 bits in extension). Bit 8 of address signals read or write. General call address allows broadcast.

82. I 2 C bus arbitration Sender listens while sending address. When sender hears a conflict, if its address is higher, it stops signaling. Low-priority senders relinquish control early enough in clock cycle to allow bit to be transmitted reliably.

83. I 2 C transmissions multi-byte write read from slave write, then read S adrs data data P S adrs 1 data P S adrs data S adrs 1 data P

84. Ethernet Dominant non-telephone LAN. Versions: 10 Mb/s, 100 Mb/s, 1 Gb/s Goal: reliable communication over an unreliable medium.

85. Ethernet topology Bus-based system, several possible physical layers: A B C

86. CSMA/CD Carrier sense multiple access with collision detection: sense collisions; exponentially back off in time; retransmit.

87. Exponential back-off times time

88. Ethernet packet format preamble start frame source adrs dest adrs data payload length padding CRC

89. Ethernet performance Quality-of-service tends to non-linearly decrease at high load levels. Can’t guarantee real-time deadlines. However, may provide very good service at proper load levels.

90. Fieldbus Used for industrial control and instrumentation---factories, etc. H1 standard based on 31.25 MB/s twisted pair medium. High Speed Ethernet (HSE) standard based on 100 Mb/s Ethernet.

91. Multiprocessors Why multiprocessors? CPUs and accelerators. Multiprocessor performance analysis.

92. Why multiprocessors? Better cost/performance. Match each CPU to its tasks or use custom logic (smaller, cheaper). CPU cost is a non-linear function of performance. cost performance

93. Why multiprocessors? cont’d. Better real-time performance. Put time-critical functions on less-loaded processing elements. Remember RMS utilization---extra CPU cycles must be reserved to meet deadlines. cost performance deadline deadline w. RMS overhead

94. Why multiprocessors? cont’d. Using specialized processors or custom logic saves power. Desktop uniprocessors are not power-efficient enough for battery-powered applications. [Aus04] © 2004 IEEE Computer Society

95. Why multiprocessors? cont’d. Good for processing I/O in real-time. May consume less energy. May be better at streaming data. May not be able to do all the work on even the largest single CPU.

96. Accelerated systems Use additional computational unit dedicated to some functions? Hardwired logic. Extra CPU. Hardware/software co-design : joint design of hardware and software architectures.

97. Accelerated system architecture CPU accelerator memory I/O request data result data

98. Accelerator vs. co-processor A co-processor executes instructions. Instructions are dispatched by the CPU. An accelerator appears as a device on the bus. The accelerator is controlled by registers.

99. Accelerator implementations Application-specific integrated circuit. Field-programmable gate array (FPGA). Standard component. Example: graphics processor.

100. System design tasks Design a heterogeneous multiprocessor architecture. Processing element (PE): CPU, accelerator, etc. Program the system.

101. Accelerated system design First, determine that the system really needs to be accelerated. How much faster is the accelerator on the core function? How much data transfer overhead? Design the accelerator itself. Design CPU interface to accelerator.

102. Accelerated system platforms Several off-the-shelf boards are available for acceleration in PCs: FPGA-based core; PC bus interface.

103. Accelerator/CPU interface Accelerator registers provide control registers for CPU. Data registers can be used for small data objects. Accelerator may include special-purpose read/write logic. Especially valuable for large data transfers.

104. System integration and debugging Try to debug the CPU/accelerator interface separately from the accelerator core. Build scaffolding to test the accelerator. Hardware/software co-simulation can be useful.

105. Caching problems Main memory provides the primary data transfer mechanism to the accelerator. Programs must ensure that caching does not invalidate main memory data. CPU reads location S. Accelerator writes location S. CPU writes location S. BAD

106. Synchronization As with cache, main memory writes to shared memory may cause invalidation: CPU reads S. Accelerator writes S. CPU reads S.

107. Multiprocessor performance analysis Effects of parallelism (and lack of it): Processes. CPU and bus. Multiple processors.

108. Accelerator speedup Critical parameter is speedup : how much faster is the system with the accelerator? Must take into account: Accelerator execution time. Data transfer time. Synchronization with the master CPU.

109. Accelerator execution time Total accelerator execution time: t accel = t in + t x + t out Data input Accelerated computation Data output

110. Accelerator speedup Assume loop is executed n times. Compare accelerated system to non-accelerated system: S = n(t CPU - t accel ) = n[t CPU - (t in + t x + t out )] Execution time on CPU

111. Single- vs. multi-threaded One critical factor is available parallelism: single-threaded/blocking : CPU waits for accelerator; multithreaded/non-blocking : CPU continues to execute along with accelerator. To multithread, CPU must have useful work to do. But software must also support multithreading.

112. Total execution time Single-threaded: Multi-threaded: P2 P1 A1 P3 P4 P2 P1 A1 P3 P4

113. Execution time analysis Single-threaded: Count execution time of all component processes. Multi-threaded: Find longest path through execution.

114. Sources of parallelism Overlap I/O and accelerator computation. Perform operations in batches, read in second batch of data while computing on first batch. Find other work to do on the CPU. May reschedule operations to move work after accelerator initiation.

115. Data input/output times Bus transactions include: flushing register/cache values to main memory; time required for CPU to set up transaction; overhead of data transfers by bus packets, handshaking, etc.

116. Scheduling and allocation Must: schedule operations in time; allocate computations to processing elements. Scheduling and allocation interact, but separating them helps. Alternatively allocate, then schedule.

117. Example: scheduling and allocation P1 P2 P3 d1 d2 Task graph Hardware platform M1 M2

118. First design Allocate P1, P2 -> M1; P3 -> M2. time M1 M2 P1 P2 P3 P1C P2C

119. Second design Allocate P1 -> M1; P2, P3 -> M2: M1 M2 P1 P2 P3 P1C time

120. Example: adjusting messages to reduce delay Task graph: Network: P1 P2 P3 d1 d2 M1 M2 M3 allocation 3 4 3 execution time Transmission time = 4

121. Initial schedule time M1 M2 M3 network 20 10 5 15 P1 P2 d1 d2 P3 Time = 15

122. New design Modify P3: reads one packet of d1, one packet of d2 computes partial result continues to next packet

123. New schedule time M1 M2 M3 network 20 10 5 15 P1 P2 d1 P3 d2 d1 P3 d2 d1 P3 d2 d1 P3 d2 Time = 12

124. Buffering and performance Buffering may sequentialize operations. Next process must wait for data to enter buffer before it can continue. Buffer policy (queue, RAM) affects available parallelism.

125. Buffers and latency Three processes separated by buffers: B1 A B2 B B3 C

126. Buffers and latency schedules A[0] A[1] … B[0] B[1] … C[0] C[1] … A[0] B[0] C[0] A[1] B[1] C[1] … Must wait for all of A before getting any B

127. System On Chip - SoC

128. Agenda Introduction . What is SoC ? SoC characteristics . Benefits and drawbacks . Solution . Major SoC Applications . Summary .

129. Introduction Technological Advances today’s chip can contains 100M transistors . transistor gate lengths are now in term of nano meters . approximately every 18 months the number of transistors on a chip doubles – Moore’s law . The Consequences components connected on a Printed Circuit Board can now be integrated onto single chip . hence the development of System-On-Chip design .

130. Agenda Introduction . What is SoC ? SoC characteristics . Benefits and drawbacks . Solution . Major SoC Applications . Summary .

131. What is SoC ? People A: The VLSI manufacturing technology advances has made possible to put millions of transistors on a single die. It enables designers to put systems-on-a-chip that move everything from the board onto the chip eventually. People B: SoC is a high performance microprocessor, since we can program and give instruction to the uP to do whatever you want to do. People C: SoC is the efforts to integrate heterogeneous or different types of silicon IPs on to the same chip, like memory, uP , random logics, and analog circuitry. All of the above are partially right, but not very accurate!!!

132. What is SoC ? SoC not only chip, but more on “ system ” . SoC = Chip + Software + Integration The SoC chip includes : Embedded processor ASIC Logics and analog circuitry Embedded memory The SoC Software includes : OS, compiler, simulator, firmware, driver, protocol stackIntegrated development environment (debugger, linker, ICE)Application interface (C/C++, assembly) The SoC Integration includes : The whole system solution Manufacture consultant Technical Supporting

133. Agenda Introduction . What is SoC ? SoC characteristics . Benefits and drawbacks . Solution . Major SoC Applications . Summary .

134. System on Chip architecture Top Level Design Unit Block Design Integration and Synthesis Trial Netlists System Level Verification Timing Convergence & Verification Fabrication DVT DVT Prep 6 12 12 4 14 ?? 5 8 Time in Weeks Time to Mask order 48 61 Unit Block Verification ASIC Typical Design Steps Typical ASIC design can take up to two years to complete

135. System on Chip architecture Top Level Design Unit Block Design Integration and Synthesis Trial Netlists System Level Verification Timing Convergence & Verification Fabrication DVT DVT Prep 4 14 5 4 Time in Weeks Time to Mask order 24 33 Unit Block Verification 4 2 With increasing Complexity of IC’s and decreasing Geometry, IC Vendor steps of Placement, Layout and Fabrication are unlikely to be greatly reduced In fact there is a greater risk that Timing Convergence steps will involve more iteration. Need to reduce time before Vendor Steps. Need to consider Layout issues up-front. SoC Typical Design Steps

136. System on Chip interconnection Design reuse is facilitated if “standard” internal connection buses are used . All cores connect to the bus via a standard interface . Any-to-any connections easy but … Not all connections are necessary . Global clocking scheme . Power consumption . Standardization is being addressed by the Virtual Socket Interface Alliance (VSIA)

137. System on Chip interconnection AMBA (Advanced Microcontroller Bus Architecture) is a collection of buses from ARM for satisfying a range of different criteria. APB (Advanced Peripheral Bus): simple strobed-access bus with minimal interface complexity. Suitable for hosting peripherals. ASB (Advanced System Bus): a multimaster synchronous system bus. AHB (Advanced High Performance Bus): a high- throughput synchronous system backbone. Burst transfers and split transactions.

138. System on Chip cores One solution to the design productivity gap is to make ASIC designs more standardized by reusing segments of previously manufactured chips. These segments are known as “blocks”, “macros”, “cores” or “cells”. The blocks can either be developed in-house or licensed from an IP company. Cores are the basic building blocks .

139. System on Chip cores Soft Macro Reusable synthesizable RTL or netlist of generic library elements User of the core is responsible for the implementation and layout Firm Macro Structurally and topologically optimized for performance and area through floor planning and placement Exist as synthesized code or as a netlist of generic library elements Hard Macro Reusable blocks optimized for performance, power, size and mapped to a specific process technology Exist as fully placed and routed netlist and as a fixed layout such as in GDSII format .

140. System on Chip cores Reusability portability flexibility Predictability, performance, time to market Soft core Firm core Hard core

141. System on Chip cores Locating the required cores and associated contract discussions can be a lengthy process Identification of IP vendors Evaluation criteria Comparative evaluation exercise Choice of core Contract negotiations Reuse restrictions Costs: license, royalty, tool costs Core integration, simulation and verification

142. Agenda Introduction . What is SoC ? SoC characteristics . Benefits and drawbacks . Solution . Major SoC Applications . Summary .

143. The Benefits There are several benefits in integrating a large digital system into a single integrated circuit . These include Lower cost per gate . Lower power consumption . Faster circuit operation . More reliable implementation . Smaller physical size . Greater design security .

144. The Drawbacks The principle drawbacks of SoC design are associated with the design pressures imposed on today’s engineers , such as : Time-to-market demands . Exponential fabrication cost . Increased system complexity . Increased verification requirements .

145. Design gap

146. Agenda Introduction . What is SoC ? SoC characteristics . Benefits and drawbacks . Solution . Major SoC Applications . Summary .

147. Solution is Design Re-use Overcome complexity and verification issues by designing Intellectual Property (IP) to be re-usable . Done on such a scale that a new industry has been developed. Design activity is split into two groups: IP Authors – producers . IP Integrators – consumers . IP Authors produce fully verified IP libraries Thus making overall verification task more manageable IP Integrators select, evaluate, integrate IP from multiple vendors IP integrated onto Integration Platform designed with specific application in mind

148. Agenda Introduction . What is SoC ? SoC characteristics . Benefits and drawbacks . Solution . Major SoC Applications . Summary .

149. Major SoC Applications Speech Signal Processing . Image and Video Signal Processing . Information Technologies PC interface (USB, PCI,PCI-Express, IDE,..etc) Computer peripheries (printer control, LCD monitor controller, DVD controller,.etc) . Data Communication Wireline Communication: 10/100 Based-T, xDSL, Gigabit Ethernet,.. Etc Wireless communication: BlueTooth, WLAN, 2G/3G/4G, WiMax, UWB, … ,etc

150. Agenda Introduction . What is SoC ? SoC characteristics . Benefits and drawbacks . Solution . Major SoC Applications . Summary .

151. Summary Technological advances mean that complete systems can now be implemented on a single chip . The benefits that this brings are significant in terms of speed , area and power . The drawbacks are that these systems are extremely complex requiring amounts of verification . The solution is to design and verify re-useable IP .