Department of Computer Systems. Reusing verfieid components is much better than re-inventing the wheel!

Transcription

1 TKT-2431 Soc Design Lec 2 Reuse of IP components Erno Salminen Tampere University of Technology Fall 2011 Reusing verfieid components is much better than re-inventing the wheel! Erno Salminen - Sep. 2011

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/43 Erno Salminen - Sep. 2011

3 Outline Motivation, Intellectual property (IP), examples IP design and integration Impact on design time and business #3/43 Erno Salminen - Sep. 2011

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

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] Improving verification and RTL design has biggest effect Even larger verification times reported in many sources... #5/43 Erno Salminen - Sep. 2011

6 Increasing system size Hemani s law : size of reused component grows 10x per every decade All SoCs are built around reused components [H. Tenhunen, Issues for Communication and InterconnectionDesign in Gigascale Systems-on- Chip, Tampere Soc, Nov. 2000] #6/43 Erno Salminen - Sep. 2011

7 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 Faster, better time estimates, less risk May be tuned to a particular application Behemoth-CPU Gizmo-CPU Embedded SRAM Embedded Flash AES encryption PCIexpress Penguin operating system Embedded Graphics lib #7/43 Erno Salminen - Sep. 2011

8 IP components (2) Principles for reuse [Bricaud] Must be easy to integrate Appropriate (stardardized?) pin interface Usage from other HW and SW Must be robust works in many environments Integrator t does not have to verify However, integrator must have verification suite [Salminen] To be reusable, must be usable Good documentation Good code (e.g. DCS VHDL coding rules) Thorough commenting Well-designed verification environment and suites Supporting scripts #8/43 Erno Salminen - Sep. 2011

9 Processors core examples, 180nm CMOS [Salminen et al., Comparison of Hardware IP Components for System-on-Chip, Tampere Soc Symposium, 2004.] _Comparison_of_Hardware_IP.pdf&id=67604 #9/43 Erno Salminen - Sep. 2011

10 HW Accelerator examples, 180nm CMOS #10/43 Erno Salminen - Sep. 2011

11 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 Similarly energy per cycle can be higher, but energy per function is lower #11/43 Erno Salminen - Sep. 2011

12 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 d Delivered as GDSII file (or similar) Technology-specific 3. Firm core Somewhere between soft and hard E.g. synthesized netlist #12/43 Erno Salminen - Sep. 2011

13 IP types: Increasing generality (softer) Bigger potential markets More applications Can be implemented with many technologies Allows changes Separate simulation model not necessarily needed d Harder to verify Harder to optimize Harder to characterize (predict performance and cost) #13/43 Erno Salminen - Sep. 2011

14 Designing IP components Erno Salminen - Sep. 2011

15 Design for reuse Solve a general problem e.g. memory, processor All parts verified independently Full, stand-alone testbenches for all entities to achieve high test coverage 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 Packetized properly Sources, docs, scripts, IP-XACT #15/43 Erno Salminen - Sep. 2011

16 IP design: 1 specify system Overall functionality and verification strategy 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 (e.g. special modes and I/O) Physical issues (noise, power, area, etc) 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 #16/43 Erno Salminen - Sep. 2011

17 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 blocks Only small (1-2 person) design teams needed Develop testbench and write RTL Simulate and synthesize (all warnings enabled) Run static code checkers ( lint ) Iterate Sub-block is complete when simulation, synthesis and code checkers results are satisfactory TKT Digitaalijärjestelm mien toteutus / TKT 1426 Digital design for FPGA #17/43 Erno Salminen - Sep. 2011

18 Macro and sub-block block design (2) Term decomposition also used [Bricaud] #18/43 Erno Salminen - Sep. 2011

19 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] #19/43 Erno Salminen - Sep. 2011

20 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 #20/43 Erno Salminen - Sep. 2011

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

22 IP deliverables (2): others HUOM! OBS! Synthesizable HDL codes Muy importante! SW driver for accessing IP from CPU Application notes, instantiation examples Buyer should be able to run the first example in few minutes High-level functional model HDL, Matlab, C/C++, UML Bus functional model 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 #22/43 Erno Salminen - Sep. 2011

23 Portable and readable support scripts 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 Pay attention to EDA tools project files and directory path settings #23/43 Erno Salminen - Sep. 2011

24 IP integration Erno Salminen - Sep. 2011

25 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 [Wagner, Strategies for the integration..., VLSI, 2004] #25/43 Erno Salminen - Sep. 2011

26 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 rator ystem integ s silic con vendor #26/43 Erno Salminen - Sep. 2011

27 IP integration and interfaces 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 Integration operation Outcome IP block IP block Modify Create wrapper Attach IP block Wrapper Attach Attach #27/43 Erno Salminen - Sep IP block 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 ] work Commun ication net

28 System-level verification Check first that all embdded IP components are thoroughly verified Bricaud: First big return on investment to the reusable effort Running all tests may takes weeks E.g. embedded CPU may have >500 test suites Done by IP designer before integration starts When IPs have verified separately, concentrate on communication between components Test1: If A sends data, then B gets it correctly and acknowledges More details in lecture 4 #28/43 Erno Salminen - Sep. 2011

29 System-design Y-chart Specify behavior and architecture separately These functions must be executed These resources we have Map functions to the resources Foo() is executed on CPU0 Bar() is executed on CPU1 #29/43 Erno Salminen - Sep. 2011

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

31 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 Bus Processor 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? #31/43 Erno Salminen - Sep. 2011

32 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 Proces ssor Bus DSP RAM Control Processor System RAM Mem 11 Dedicated Hardware Behavior Mapping Implementation architecture #32/43 Erno Salminen - Sep. 2011

33 Impact of reuse on design time and business Erno Salminen - Sep. 2011

34 Decreasing design time Decreasing effort (time) in early design phases often lenghtens total design time Especially debug phase a) first spec rtl tb debug method 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 time #34/43 Erno Salminen - Sep. 2011

35 Decreasing design time (2) Increasing effort (time) in early design phases shortens total design time Especially debug a) first spec rtl tb debug method 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 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 ] #35/43 Erno Salminen - Sep time

36 Decreasing design time (3) Design for reuse adds design time but reuse saves many times more a) first spec rtl tb debug method 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 time #36/43 Erno Salminen - Sep. 2011

37 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.] #37/43 Erno Salminen - Sep. 2011

38 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 #38/43 Erno Salminen - Sep. 2011

39 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 #39/43 Erno Salminen - Sep. 2011

40 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 #40/43 Erno Salminen - Sep. 2011

41 Essential issues #41/43 Erno Salminen - Sep. 2011

42 Proof of concept English ARM Ltd. is a fabless company They do not make or sell silicon chips but they sell IP Customers buy licenses to use the CPUs Customer gets the design data of CPU and integrates that t into their own chip ARM is also very strict on license misconduct Extremely high volumes! Approx.14e9 devices with ARM sold so far E.g. nearly all cellphones to date have used ARM- based processors Company s goal is to sell 1 ARM per person each year #42/43 Erno Salminen - Sep. 2011

43 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 block separately Develop guidelines for coding (and follow them) Generality and reusability of a component degrades its performance a little Saving in design effort should be much larger #43/43 Erno Salminen - Sep. 2011

44 For selfstudy Erno Salminen - Sep. 2011

45 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: h.cfm?baseurl=/products/ip/techpubs/index.cfm #45/43 Erno Salminen - Sep. 2011

46 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 #46/43 Erno Salminen - Sep. 2011

47 Old nemesis: Documentation % of all 200 IPs Poor documentation frustrated many during the study. However, note that these results from product briefs and articles. They are not from actual IP documentation ti [Salminen, SoC, 2004] #47/43 Erno Salminen - Sep. 2011

48 Constants vs. generics in VHDL 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 #48/43 Erno Salminen - Sep. 2011

49 Reporting digital systems 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 l/t t 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 ] #49/43 Erno Salminen - Sep. 2011

50 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 #50/43 Erno Salminen - Sep. 2011

51 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 #51/43 Erno Salminen - Sep. 2011

52 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 #52/43 Erno Salminen - Sep. 2011

53 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-existingexisting library Lecture 3 #53/43 Erno Salminen - Sep. 2011

54 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 System Integration Platform Architecture Performance Analysis and Platform Configuration Communication Refinement Communication Integration Hardware Assembly Software Assembly Implementation Level Verification Synthesis / Place & Route etc. IP Block System Integration n + testing #54/43 Erno Salminen - Sep. 2011

55 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 #55/43 Erno Salminen - Sep. 2011