Part of the slides. Part of figures from. adapted reused from slides by Alberto Sangiovanni- Vincentelli

Transcription

1 TKT-2431 Soc Design Lec 2 Reuse of IP components Erno Salminen, Tero Arpinen Department of Computer Systems Tampere University of Technology Fall 2010 Erno Salminen - Sep. 2010

2 Copyright notice Part of the slides adapted reused from slides by Alberto Sangiovanni- Vincentelli course EE249 at University of California, Berkeley Part of figures from P.J. Bricaud, IP Reuse Creation for System-on-a-Chip, CICC, 1999, pp D.D. Gajski et al., Essential issues for IP reuse, ASP-DAC, Jan. 2000, pp F. Wagner et al., Strategies for the integration of hardware and software IP components in embedded systems-onchip, Integration, the VLSI Journal, September 2004, Vol. 37, Iss. 4, pp #2/50 Erno Salminen - Sep. 2010

3 Outline Motivation, Intellectual property (IP) HW IP examples Design for reuse, IP design Benefits of reuse IP business and IP-based design #3/50 Erno Salminen - Sep. 2010

4 At first Make sure that simple things work before even trying more complex ones #4/50 Erno Salminen - Sep. 2010

5 Design time breakdown Task Time ratio [%] Verification 40 RTL + synthesis 20 IC layout 10 Test 10 System integration 10 Start from smallest component (Divide&conquer) Other 10 [Bricaud] #5/50 Erno Salminen - Sep Improving verification and RTL design has biggest effect Even larger verification times reported in many sources...

6 Reminder : verification gap [J. Virtanen, SoC Verification, ELKOM 03, Helsinki, Finland, March 2003] #6/50 Erno Salminen - Sep. 2010

7 Increasing system size Hemani s law : size of reused component grows 10x per every decade #7/50 Erno Salminen - Sep [H. Tenhunen, Issues for Communication and Interconnection Design in Gigascale Systems-on-Chip, Tampere Soc, Nov. 2000]

8 Reasons to reuse [Peryer] To accelerate the next design Eliminating a block design task Reduce the risk of failure Using a block which has been proven To bring more of the project variables under control A reusable block is ready to go and doesn t need a time to completion estimate [Salminen] Just because you have to! All SoCs are built around reused components #8/50 Erno Salminen - Sep. 2010

9 Intellectual Property (IP) components Reusable, pre-designed and verified components May be hardware or software (especially HW IP) also called macros and cores E.g. microprocessor, memory, HW accelerator, SW function Simplify system design Don t have to reinvent the wheel Moreover, don t have to re-verify the wheel May be tuned to a particular application #9/50 Erno Salminen - Sep. 2010

10 IP components (2) Principles for reuse [Bricaud] Must be easy to integrate Must be robust Integrator does not have to verify However, integrator must have verification suite [Salminen] To be reusable, must be usable Good documentation Good code Thorough commenting Well-designed verification environment and suites Supporting scripts #10/50 Erno Salminen - Sep. 2010

11 HW IP component examples Erno Salminen - Sep. 2010

12 HW IP examples Following examples from Salminen et al., Comparison of Hardware IP Components for System-on-Chip, Tampere Soc Symposium, dir=dacifs&freal=salminen_-_comparison_of_hardware_ip.pdf&id=67604 Results for 0.18 um CMOS 1. Programmable processors (+few mem) 2. HW accelerators Results from product briefs and articles Not from actual IP documentation #12/50 Erno Salminen - Sep. 2010

13 Processors core examples #13/50 Erno Salminen - Sep. 2010

14 Accelerator examples #14/50 Erno Salminen - Sep. 2010

15 Proportion of known values % of all 200 IPs Poor documentation #15/50 Erno Salminen - Sep. 2010

16 Conclusion of examples Area Frequency Proportion of IP % % % % % % proc. kgates accelerator kgates Proportion of IP % % % % % proc freq accelerator freq 5.00 % 5.00 % 0.00 % % Area [kilogates] Frequency [MHz] Energy per cycle Prorportion of IPs % % % % % % % % 5.00 % 0.00 % proc energy accelerator energy Energy [mw/mhz] HW accelerator have higher performance frequency can be lower #16/50 Erno Salminen - Sep. 2010

17 Marketing example : Car IP Breaking news! Our company offers new car IP! top speed 250 km/h fuel efficiency 4.7 liters /100 km Oh, forgot to mention that there are actually 2 different IPs Mercedes-Benz CL 55 AMG 250 km/h, 11.4 l/100 km This is unlikely for 250 km/h speed Smart fourtwo coupé 37 kw pure 135 km/h, 4.7 l/100 km Photos courtesy of Mercedes Benz and smart Gmbh #17/50 Erno Salminen - Sep. 2010

18 HW IP types 1. Soft core Delivered as synthesizable RTL code Integrator can modify IP by changing generics code 2. Hard core Fully designed, placed, and routed Cannot be modified Delivered as GDSII file (or similar) Technology-specific 3. Firm core Somewhere between soft and hard E.g. RTL with some physical information #18/50 Erno Salminen - Sep. 2010

19 Erno Salminen - Sep Designing IP components

20 Design for reuse Solve a general problem e.g. memory, processor Usable in multiple technologies e.g. TMSC 0.18 um, TI 0.13 um, IBM 90nm, Altera FPGA Includes standard interfaces e.g. OCP, AMBA AXI, PCI-X Can be simulated in multiple environments High-level models available Models must have same functionality All parts verified independently Full, stand-alone testbenches for all entities to achieve high test coverage See also: DCS VHDL coding rules #20/50 Erno Salminen - Sep. 2010

21 IP types: Increasing generality (softer) Bigger potential markets More applications Can be implemented with many technologies Harder to verify Harder to optimize Harder to characterize (predict performance and cost) #21/50 Erno Salminen - Sep. 2010

22 IP design: 1 specify system Timing Preferably synhcronous and register-based Num of clocks doumented (small num preferred) Reset documented (active low preferred) Synthesis scripts (with comments) Debug and test features and strategies Verification strategy Physical issues Partition system into macros (e.g. CPU, DMA) Always in partitioning, aim for minimal interaction between components Components cannot assume anything of each other s internal timing Pay attention to interfaces #22/50 Erno Salminen - Sep. 2010

23 IP design: 2 macro and sub-block block design Create specification and verification plan The more we verify at HDL level, the easier the final verification is Partition macros into sub-blocks Design teams work simultaneously on sub-blocks Only small (1-2 person) design teams needed Develop testbench and write RTL Simulate and synthesize Run code checkers ( lint ) Iterate Sub-block is complete when simulation, synthesis and code checkers results are satisfactory TKT-1212 Digitaalijärjestelmien toteutus / TKT 1426 Digital design for FPGA #23/50 Erno Salminen - Sep. 2010

24 Macro and sub-block block design (2) Term decomposition also used [Bricaud] #24/50 Erno Salminen - Sep. 2010

25 IP design 3: Sub-block block integration Very important step First grading of how reusable sub-blocks are Ease of integration Speed of verification Otherwise, similar to sub-block design [Bricaud] #25/50 Erno Salminen - Sep. 2010

26 IP design: 4 - productization Develop prototype If one can afford... Ensure that macro is synthesizable with multiple technologies Simulate at gate level Verify formally that netlist from synthesis is equivalent to RTL Document everything #26/50 Erno Salminen - Sep. 2010

27 IP Integration First, select IPs After that, like traditional ASIC flow Typical sign-off nowadays after RTL sythesis Aka. tape-out Memories are technology-dependent Generators used for implementation Simulation models needed sign-off system integrator silicon vendor #27/50 Erno Salminen - Sep. 2010

28 IP integration and interfaces #28/50 Erno Salminen - Sep IP must be adapted unless it natively supports the interface provided by the network Soft, white-box, IP allow direct modification of source codes Without source codes, additional wrapper (or adapter) is needed Standard interface Heterogenous interface Original IP IP block IP block Integration operation Modify Create wrapper Attach IP block Wrapper Attach Attach IP block Outcome IP block IP block Wrapper Adapted by A. Rasmus from [F. R. Wagner et al., Strategies for the integration of hardware and software IP components in embedded systems-on-chip, Integration, the VLSI Journal, September 2004, Vol. 37, Iss. 4, pp ] Comm unication network

29 IP deliverables: User guide HUOM! OBS! Key deliverable IP without user guide is useless How to integrate and test lines of HDL without a manual? Muy importante! Used for macro selection, integration, and verification Documents functionality interface non-functional properties (area, latency, power...) test strategy, clockcing strategy architecture block diagram exceptions to coding guidelines names and versions of tested SW tools (e.g. simulators, compilers)! directory structure of deliverables #29/50 Erno Salminen - Sep. 2010

30 IP deliverables (2) Synthesizable HDL codes High-level functional model HDL, Matlab, C/C++, UML SW driver for accessing IP from CPU Bus functional model Application notes, instantiation examples Synthesis, scan insertion, and ATPG scripts for all sub-blocks Installation scripts Testbenches for top-level and all sub-blocks Self-checking testbenches with high coverage HUOM! OBS! Muy importante! #30/50 Erno Salminen - Sep. 2010

31 Reporting digital systems #31/50 Erno Salminen - Sep The result (area/power/performance/frequency/combination) is a sum of several factors Comparison not possible unless they are specified Process line width, supply voltage, worst/nominal/best-case, low power/high speed process, output load, FPGA type number and LUT count, Detail level RTL/layout results, VHDL/Verilog/SystemC, memories inluded?, I/O pads and power supplies included?, memory usage for SW, power simulation: supply voltage, RTL/gate-level/transistor sim., swithing activity, leakage included?, crosstalk included?, glitches included?, memories included? Design method synthesis/full-custom design, tool version, System parameters data width, buffer size, pin-limited/logic-limited system?, memory interface Others... [E. Salminen, On Preparing Clear Publications, lecture slides on TKT On Preparing Clear Publications, lecture slides on TKT-2410 Scientific publishing, Tampere, Finland, Nov ]

32 SoC verification Check that all embdded IP components are thoroughly verified Bricaud: First big return on investment to the reusable effort E.g. embedded CPU may have >500 test suites Running all tests takes weeks Done by IP designer before integration starts When IPs have verified separately, concentrate on communication between components More details in lecture 4 #32/50 Erno Salminen - Sep. 2010

33 Scripts #33/50 Erno Salminen - Sep Also scripts must be commented Purpose of ALL parameters e.g. part of makefile COMPILE = armcc I ${ARMLIB}/armlib_cn.32l -c -fpu none -g+ -c -dwarf2 -Otime -O1 -Ono_inline -o $@ ASM = armasm -xref -g -o $@ LINK = armlink -map -symbols -elf -ro-base 0x0 -rw-base 0x first arm_init.o\(alustus\) -entry 0x0 -remove - info unused,sizes $(OBJS) -output $@ Often more important than code commenting Code languages are more commonly known Whereas, many scripts are tool-specific What if integrator uses different tool Parameter names are different Without comments it is painful find out original meaning of parameters without the tool, most probably there s no manual either

34 Erno Salminen - Sep Benefit of reuse

35 Decreasing design time Decreasing effort (time) in early design phases often lenghtens total design time Especially debug phase a) first method spec rtl tb debug b) save time from rtl spec rtl tb debug c) save time from tb spec rtl tb debug d) save time from spec spec rtl tb debug #35/50 Erno Salminen - Sep time

36 Decreasing design time (2) Increasing effort (time) in early design phases shortens total design time Especially debug a) first method spec rtl tb debug f) add time to rtl spec rtl tb debug g) add time to tb spec rtl tb debug h) add time to spec spec rtl tb debug i) add time to spec+tb spec #36/50 Erno Salminen - Sep rtl tb debug [J.P. Bowen, M.G. Hinchey, Ten Commandments of Formal Methods...Ten Years Later, Computer, Vol. 39, Iss. 1, Jan. 2006, pp ] time

37 Decreasing design time (3) Design for reuse adds design time but reuse saves many times more a) first method spec rtl tb debug i) add time to spec+tb spec rtl tb debug j) i+ design for reuse spec rtl tb debug Reusing j in next product spec rtl tb debug #37/50 Erno Salminen - Sep time

38 IP creation methods?????? Repeat the block design every time, do not reuse anything Reverse engineer an existing IP without specs into reusable form Design a new, reusable IP block from scratch Buy a third-party IP. Costs vary according to license policy Rescue an existing block into more reusable form. Specs available. Adapted from [M. Peryer, When does it make sense to design for reuse?, DesignCon, 1999.] #38/50 Erno Salminen - Sep. 2010

39 IP business and IP-based design Erno Salminen - Sep. 2010

40 Phases of IP creation and reuse Several phases precede the actual integration (phase 6): 1. Creation according to guidelines that simplify reuse 2. Qualification ensures that IP has qualities expected by consumers (integrators) 3-4. Classification and search consumers must find appropriate IP blocks from on-line catalogs where components are classified according to adequate criteria 5. Transfer delivers all needed information for evaluation and integration, including design data, documentation, test specification 5B. Evaluation a more accurate evaluation is usually needed before integrating it into a design, e.g. by instantiating the component into a testbench and simulating it #40/50 Erno Salminen - Sep [Wagner, Strategies for the integration..., VLSI, 2004]

41 IP business (1) Three parties in IP business: 1. IP provider Designs new IPs or converts legacy code into reusable form Has to assure customers on quality of IPs Offers support services 2. IP integrator is the customer Uses IPs to be a producer on other markets #41/50 Erno Salminen - Sep. 2010

42 IP business (2) 3. IP tool developer develops design methodologies and EDA software To migrate IPs to new tehcnologies To support documentatation and data retrieval To select appropriate IPs through analysis and comparison (exploration) Furthemore, IP business needs methods for solving Pricing and licenses Service Distribution Security #42/50 Erno Salminen - Sep. 2010

43 Essential issues #43/50 Erno Salminen - Sep. 2010

44 Salminen s forecast Any legal issue will be far more challenging in IP reuse(*) than any technical issue (*) = any work? P.S. Reuse within the company is less likely to confront legal issues #44/50 Erno Salminen - Sep. 2010

45 System Level Design Science Design Methodology: Top Down Aspect: Orthogonalization of Concerns: Separate Implementation from Conceptual Aspects E.g. separate computation from communication E.g. separate behavior from (micro)architecture Formalization: precise unambiguous semantics Abstraction: capture the desired system details (do not overspecify) Decomposition: partitioning the system behavior into simpler behaviors Successive Refinements: refine the abstraction level down to the implementation by filling in details and passing constraints Bottom Up Aspect: IP Re-use (even at the algorithmic and functional level) Components of architecture are from pre-existing library Lecture 3 #45/50 Erno Salminen - Sep. 2010

46 IP integration How to integrate system blocks? Starting from the system level With a consistent test-bench Getting from the abstract, un-timed system model to the clocked HW or SW implementation model Communication between blocks Addressing Platform Based design Example 3G Cell phone Which are the optimal algorithms? Do they work together functionally? Is the architecture sufficient? Does the implementation integration work? Embedded System Specification and Requirements Platform Function Hardware Assembly System Integration Platform Architecture Performance Analysis and Platform Configuration Communication Refinement Communication Integration Software Assembly Implementation Level Verification Synthesis / Place & Route etc. IP Block System Integration + testing #46/50 Erno Salminen - Sep. 2010

47 1. Separate Behavior from Micro- architecture System Behavior Functional Specification of System. No notion of hardware or software! Implementation (micro)architecture Hardware and software Optimized computer Front End 1 Transport Decode 2 Rate Buffer 12 Rate Buffer 5 Synch Control 4 Mem 13 User/Sys Control 3 Video Decode 6 Sensor Frame Buffer 7 Video Output 8 External I/O MPEG Peripheral Processor Bus DSP Processor DSP RAM Control Processor Rate Buffer 9 Audio Decode/ Output 10 Audio Decode System RAM #47/50 Erno Salminen - Sep Mem 11 Architecture defines only the interface things inside this box are microarchitecture

48 2. Select components Which Bus? AMBA? HIBI? Dedicated Bus for DSP? Which DSP Processor? TI? Motorola? Can DSP be done on Microcontroller? Can I Buy an MPEG2 Processor? External I/O DSP Processor Which One? MPEG Peripheral Processor Bus DSP RAM Control Processor Which Microcontroller? ARM? MIPS? Audio Decode Do I need a dedicated Audio Decoder? Can decode be done on Microcontroller? System RAM How fast will my User Interface SW run? How much can I fit on my microcontroller? #48/50 Erno Salminen - Sep. 2010

49 3. Map behavior to architecture and verify Transport Decode Implemented as Software Task Running on Microcontroller HUOM! OBS! Muy importante! Rate Buffer 12 Mem 13 User/Sys Control 3 Sensor External I/O DSP Processor Front End 1 Transport Decode 2 Rate Buffer 5 Rate Buffer 9 Synch Control 4 Video Decode 6 Audio Decode/ Output 10 Frame Buffer 7 Communication Video Output 8 Over Bus Audio Decode Behavior Implemented on MPEG Peripheral Audio Decode Processor Bus DSP RAM Control Processor System RAM Mem 11 Dedicated Hardware Behavior #49/50 Erno Salminen - Sep Mapping Implementation architecture

50 Conclusion Systems cannot be designed from scratch: Reuse everything you can Bricaud: Impossible not to stress again the importance of documentation... Verify each sub-block separately Develop guidelines for coding (and follow them) Further reading: M. Keating, P. Bricaud, Reuse methodology manual: for system-on-a-chip designs, Kluwer Academic Publishers Norwell, MA, USA, 1998 / 2002, ISBN: Mark Peryer, When does it make sense to design for reuse?, DesignCon, Request free copy from: url=/products/ip/techpubs/index.cfm #50/50 Erno Salminen - Sep. 2010

51 Erno Salminen - Sep Extra

52 Constants vs. generics in VHDL #52/50 Erno Salminen - Sep Basically, generic parameter is a fundamental idea in VHDL and design reuse, use it. Avoid constants (in packages or architecture) if data_width is defined is package, it is impossible to have instances with different data_width e.g. all adders in design are 10 bits wide With generics, that is possible The component size should be changed with generics NOT by modifying the code. When the VHDL code is reused, there should be no need to read the code except the entity definition If there are illegal combinations of generic values, use assert to make sure that given generics are valid However, having many generic parameters, complicates verification Use generics instead of constants

53 IP-XACT standard Standard XML for HW integration and design automation Describes metadata of components and designs Language and tool independent Allows multi-vendor design environments More info on course TKT-3541/3547 SoC-alustat/SoC platforms #53/50 Erno Salminen - Sep. 2010

54 IP-XACT component metadata Bus interfaces (I/O ports) Signals (also those which do not belong to any bus interface) Model parameters (=generics) Address spaces Register definitions Component generators File sets Vendor extensions: e.g. Description, tool-specific settings #54/50 Erno Salminen - Sep. 2010

55 IP-XACT design Structural description of HW platform Instantiates components Connects them together Metadata makes design capture easy Components are connected on interface, not signal level Interface metadata allow plug-an-play integration Stored in XML format Automatically converted to VHDL IP-XACT design Interconnection Component instance 1 Component instance 2 Component instance 3 Hierarchical connection Bus interfaces Ad-hoc connection #55/50 Erno Salminen - Sep. 2010