Modeling Performance Use Cases with Traffic Profiles Over ARM AMBA Interfaces

Transcription

1 Modeling Performance Use Cases with Traffic Profiles Over ARM AMBA Interfaces Li Chen, Staff AE Cadence China

2 Agenda Performance Challenges Current Approaches Traffic Profiles Intro Traffic Profiles Implementation Real Life Example an ARM ARMv8-A Mobile SoC Real Life Use Case Video Playback from Flash Summary Q&A

3 Performance challenges Today s large heterogeneous SoCs present a range of competing and conflicting performance goals which can be appreciated by reviewing the key peripherals Multi-core compute subsystems Powerful graphics engines Latest wireless and wired communications protocols High-resolution display drivers Interconnects and memory controllers are highly configurable Buffer depths, acceptance capabilities, issuing capabilities, interface data widths and programmable quality of service (QoS), arbitration mechanism,... to meet the performance challenges The real challenge is to ensure all the performance goals are met without over design which would result in area and power challenges

4 CoreLink NIC-400 Performance challenges IP IP CoreLink NIC-400 IP IP IP CoreLink NIC-400 DMA LCD PCIe RC CoreLink NIC-400 System Control Processor ARMv8-A Mobile Example System What is the latency of the processor clusters to memory paths including all async bridges? What is the bandwidth of the paths from IP with high bandwidth demands to memory? What is the bandwidth and latency of the paths from real-time IP to memory? #1 #3 #4 ARM Cortex- A53 Cluster L2 Cache CoreLink GIC-400 #2 #1 #3 #4 ARM Cortex- A57 Cluster L2 Cache Customer GPU ADB ADB ADB #2 Cache-Coherent Interconnect Customer DMA ADB ADB ADB DVFS CLK/PSO Domain CLK/PSO Domain Coherent Masters Non-Coherent Masters Timers ADB ADB ADB ADB On-Chip ROM F3 F2 F1 F0 CoreLink TZC-400 CoreLink NIC-400 (2x1) ADB SRAM Video SRAM UART Customer DDR Controller IP

5 Current approaches SoC architects and designers utilize many tools and techniques to optimize performance: Rule-of-thumb spreadsheets Very early analysis of SoC performance requirements, based on experience and previous similar SoCs Good guideline for SoC architecture, but cannot be relied on for hardware results SystemC Modelling Exploration model of the RTL system to support early software integration Initial performance analysis possible Typically +/-20% due to model timing inaccuracies Due to missing cycle accurate FIFO models, cache models and memory models result in inaccuracies SoC level RTL simulations with IP blocks and preliminary software Cycle accurate with typical traffic loads produced by actual IP blocks and bare metal software Very accurate performance results but only available very late in the development cycle Lets look at additional options by reviewing a stepped performance methodology

6 Performance Characterization Static Workloads Application Specific Use Cases Performance methodology Path-by-path traffic measuring the performance envelope Targeting: Integration bugs (clock freq, buffer sizes, bridge conf.) Analyze: Latency critical paths Bandwidth critical paths Master-by-master modeled use-cases mimicking realistic loads Targeting: Impact on bandwidth when running multi-master traffic, QoS tuning Analyze: DDR efficiency & measured bandwidth Masters QoS contract met (or not) Software-driven use-cases Targeting: Application performance corner cases Analyze: Master requested bandwidth DDR efficiency & measured bandwidth

7 Static workload requirements The need to implement static workloads that realistically model the behavior of IP blocks in a complex SoC is a key driver for the introduction of Traffic Profiles

8 Simplifying system modeling Latency Sensitive High Bandwidth Real Time Replace complex IP with simple, representative traffic CPU CPU GPU PCIe Display Latency Traffic Latency Traffic BW Traffic BW Traffic RT Traffic CoreLink Interconnect CoreLink Interconnect CoreLink Dynamic Memory Controller CoreLink Dynamic Memory Controller DRAM DRAM

9 Abstracting complex IP with Traffic Profiles Example How to model the ARM Cortex-A73? Vary 1, 2 or 4 CPUs Vary L1 and L2 cache sizes (up to 8MB) Multi-core initializing and warming cache takes significant time before settling For system modeling, only need traffic pattern on the interface

10 The need for standardization Define a simple, standard method of representing complex IP traffic Dynamic behavior and concurrency Latency Traffic Latency Traffic BW Traffic BW Traffic RT Traffic Rules checks over standard AMBA interfaces Bandwidth and transaction checking Portable to multiple simulation environments and across different IP options Transaction modeling, RTL emulation, FPGA prototyping CoreLink Interconnect CoreLink Dynamic Memory Controller DRAM

11 Traffic Profiles basics Define complex traffic vectors by combining simple traffic profiles This can be done sequentially or concurrently Each profile can drive either read or write bursts Each profile s behaviour is modelled using a FIFO like mechanism A small set of primary parameters defines the behaviour of each FIFO Secondary parameters added for fine control

12 FIFO-based traffic flow control Fill behaviour This side of the FIFO is the AMBA interface. Requests are issued and data returned. This side of the FIFO is inside the component. Data is consumed at a fixed rate. Addr Memory Data

13 FIFO-based traffic flow control Drain behaviour This side of the FIFO is the AMBA interface. Requests are issued and data returned. This side of the FIFO is inside the component. Data is consumed at a fixed rate. Memory

14 FIFO-based traffic flow control Parameters LimTxn Limit of Transactions issued. The maximum number of outstanding transactions. Addr Addr Addr Full Size of FIFO in bytes Rate Rate that data is consumed in bytes per cycle TxnSize Transaction Size. The number of bytes requested by a single transaction request. (Typically 64 bytes) Addr Data Data Data DataSize Data Size. The number of bytes returned in one data beat. (Same as bus width) Start FIFO can start full or empty Memory Data

15 Traffic Profiles implementation Overview Cadence have created a UVM implementation, targeting RTL simulation There can be other implementations based on the same parameters targeting SystemC simulations, RTL emulation, FPGA prototyping etc. Implementation architecture: Each traffic profile is implemented as a protocol agnostic, UVM virtual sequence The FIFO mechanism is implemented within the sequence Layered on top of protocol specific sequences Delivered along with Cadence Verification IP for AMBA protocol As each profile is a sequence, multiple profiles can run concurrently Each profile is either read or write

16 Optional Automated TB Active Master monitor Active Master monitor Clocks fifo fifo fifo fifo fifo TP User Test Traffic Profiles implementation - Diagram User writes test sequences and test virtual sequences to co-ordinate the traffic across multiple interfaces Virtual sequence Test sequence Test sequence Virtual sequencer The fill and drain logic is implemented as a virtual FIFO managing the traffic on the interface to satisfy the requested bandwidth seq seq seq fill fill fill drain drain drain adaptor seq seq fill fill drain drain adaptor The sequence item includes all the Traffic Profile transaction fields sequencer driver sequencer driver Traffic Profiles are implemented as a layered virtual sequence over AMBA protocol sequences Clocks ingress1 DUT ingress2 TB

17 Usage example Concurrent profiles Group 1 M1 Group 2 M1 Group 3 M1 cdn_tp(p1c, M1) cdn_tp(p1b, M1) cdn_tp(p1a, M1) cdn_tp(p2b, M1) cdn_tp(p2a, M1) cdn_tp(p3c, M1) cdn_tp(p3b, M1) cdn_tp(p3a, M1) Group 1 M2 Group 2 M2 cdn_tp(p1c, M2) cdn_tp(p1b, M2) cdn_tp(p1a, M2) cdn_tp(p2b, M2) cdn_tp(p2a, M2) AHB M1 AXI M2

18 Usage example Concurrent profiles Group 1 M1 Group 2 M1 Group 3 M1 cdn_tp(p1c, M1) cdn_tp(p1b, M1) cdn_tp(p1a, M1) AHB M1 Group 1 M2 cdn_tp(p1c, M2) cdn_tp(p1b, M2) cdn_tp(p1a, M2) cdn_tp(p2b, M1) cdn_tp(p2a, M1) Group 2 M2 cdn_tp(p2b, M2) cdn_tp(p2a, M2) AXI M2 fork : Group1 begin fork cdn_tp(p3c, M1) begin `uvm_do_with( {profile1a} cdn_tp(p3b, M1) end cdn_tp(p3a, M1) begin `uvm_do_with( {profile1b} end begin `uvm_do_with( {profile1c} end end begin Group1_exit_event end join any fork : Group2

19 ACE Traffic Profiles sequence example `uvm_do_with(ace_tp_vseq, {ace_tp_vseq.agentid == agent_id; ace_tp_vseq.direction == TP_READ; ace_tp_vseq.limtxn == 3; ace_tp_vseq.addresspattern == TP_SEQUENTIAL; ace_tp_vseq.startaddress == start_address_p1; ace_tp_vseq.endaddress == end_address_p1; ace_tp_vseq.domain == att_indx_p1; ace_tp_vseq.txnsize == 64; ace_tp_vseq.datasize == 4; ace_tp_vseq.rate == 120.0/(150.0); // requestedbandwidth / Frequency ace_tp_vseq.start == TP_EMPTY; ace_tp_vseq.full == 128; ace_tp_vseq.numoftransactions == 500; ace_tp_vseq.artv == 2; ace_tp_vseq.rbr == 3;} );

20 ACE Traffic Profiles sequence example `uvm_do_with(ace_tp_vseq, {ace_tp_vseq.agentid == agent_id; ace_tp_vseq.direction == TP_READ; ace_tp_vseq.limtxn == 3; ace_tp_vseq.addresspattern == TP_SEQUENTIAL; ace_tp_vseq.startaddress == start_address_p1; ace_tp_vseq.endaddress == end_address_p1; ace_tp_vseq.domain == att_indx_p1; ace_tp_vseq.txnsize == 64; ace_tp_vseq.datasize == 4; ace_tp_vseq.rate == 120.0/(150.0); // requestedbandwidth / Frequency ace_tp_vseq.start == TP_EMPTY; ace_tp_vseq.full == 128; ace_tp_vseq.numoftransactions == 500; ace_tp_vseq.artv == 2; ace_tp_vseq.rbr == 3;} );

21 Real-life example an ARM ARMv8-A mobile SoC A typical ARMv8-A based mobile subsystem design presents designers and architects with a significant performance optimization challenge. We chose such an SoC as the vehicle for demonstrating Traffic Profiles ARM provides Reference Data and document specific use-case tests to describe the performance capabilities of such a mobile subsystem Cadence tools are used to create the required UVM testbench and implement one of these use cases before analyzing the results

22 ARMv8-A mobile example CPU subsystem Cortex-A73 GIC-500 I/O Coherent Masters NIC-400 Snoop Filter * Cortex-A53 MMU-500 CoreLink TM CCI-550 Mali TM -G71 GPU * Mali- V550 Video NIC-400 Mali DP650 Display MMU-500 SCP Peripherals * Configurable options CoreSight TM DMC-500 PHY LPDDR4 Memory System PHY LPDDR4 PHY LPDDR4 *3 rd Party DMC option DMC-500 DMC-500 DMC-500 PHY LPDDR4

23 Virtual Sequencer Routing Model IVD Testbench implementation and architecture Automated Testbench Traffic Profile TP Aggressive Passive User Integration Testbench Cadence AMBA Library SoC Metadata Cadence Interconnect Workbench Automation TP TP TP TP TP TP TP TP Cortex-A73 GIC-500 Snoop Filter * Cortex-A53 I/O Coherent Masters NIC-400 MMU-500 CoreLink TM CCI-550 Mali TM -G71 GPU * Mali- V550 Video NIC-400 Mali DP650 Display MMU-500 SCP Peripherals * Configurable options CoreSight TM DMC-500 PHY LPDDR4 Memory System DMC-500 DMC-500 DMC-500 PHY LPDDR4 PHY LPDDR4 *3 rd Party DMC option PHY LPDDR4 User Verilog Testbench Tests UVM Testbench

24 Use-case definition Camcorder Use-case definition: Camcorder rear camera with local display preview Rear camera video (3840x2160p60 YUV4:2:0 ) HEVC encode (3840x2160p60) Local display non-rotated (3840x2160p60) Which translates to the following interface bandwidth requirements: Using the Traffic Profile s sequence layer with the testbench s virtual sequence, it s possible to create a static workload testcase Interface Read Requested BW Write Requested BW Total Requested BW Big CPU 1488MB/s 200MB/s 1688MB/s Little CPU 320MB/s 320MB/s 640MB/s Display Controller 3564MB/s 0MB/s 3564MB/s Video Codec 2432MB/s 1214MB/s 3646MB/s Non-coherent Expansion Port 0MB/s 1188MB/s 1188MB/s Coherent Expansion Port 10MB/s 10MB/s 20MB/s Total 6326MB/s 2732MB/s 9058MB/s

25 Use-case implementation with Traffic Profiles The traffic profile sequence for each initiator is done within its own thread fork `uvm_do (big_cpu_read_traffic) `uvm_do (big_cpu_write_traffic) `uvm_do (little_cpu_read_traffic) `uvm_do (little_cpu_write_traffic) `uvm_do (display_controller_read_traffic) `uvm_do (video_codec_read_traffic) `uvm_do (video_codec_write_traffic) `uvm_do (isp_write_traffic) `uvm_do (flash_controller_read_traffic) `uvm_do (flash_controller_write_traffic) join_any Fork statement ensures each profile runs in its own thread Read and Write traffic sequences as required by the use case join_any all sequences are cleanly terminated when the first (fastest) completes other join s can be used to create different behaviour

26 Use-case implementation - with Traffic Profiles Now, to look at the key constraint for one of the Traffic Profiles `uvm_do_with(ace_atp_vseq, { ace_atp_vseq.agentid == p_sequencer.get_agent_id( little_cpu ); }); ace_atp_vseq.numoftransactions == 10000; ace_atp_vseq.atpdirection == ATP_READ; ace_atp_vseq.rate == 320.0/(1600.0); ace_atp_vseq.transactionsize == 64; ace_atp_vseq.datasize == 16; ace_atp_vseq.addresspattern == ATP_RANDOM; ace_atp_vseq.addressalignment == 64; ace_atp_vseq.startaddress == start_address; ace_atp_vseq.idpattern == ATP_ID_CYCLE; ace_atp_vseq.endaddress == end_address; ace_atp_vseq.lowerid == 0; ace_atp_vseq.upperid == 31; ace_atp_vseq.start == ATP_EMPTY; ace_atp_vseq.full == 2048; ace_atp_vseq.atpdomain == 1; Specify an ACTIVE agent Number of transactions to issue Direction and Bandwidth constraints Address constraints ID constraints fifo configuration constraints

27 Use-case performance analysis - Introduction Once the use case is implemented using Traffic Profiles and simulated we can review the behavior of the design when exercised with the requested bandwidth profiles Interconnect Workbench Performance Analyzer provides many ways to analyze the system s performance We will start with a bandwidth analysis to show that the requested bandwidth is supported We will use Outstanding Transaction count as a proxy for system saturation

28 Use-case performance analysis - Bandwidth Requested B/W 3564MB/s 2432MB/s 1488MB/s 10MB/s 320MB/s 1188MB/s 1214MB/s 200MB/s 320MB/s 10MB/s

29 Use-case performance analysis System stress level

30 Use-case performance analysis System stress level

31 Summary Performance analysis and optimization of complex ARM-based SoCs is a challenge that must be approached in a structured, methodical manner A key aspect of the strategy discussed is the use of static workload use cases Introduced Traffic Profiles over ARM AMBA interfaces to facilitate creation of static workload use cases Shared example ARMv8-A mobile subsystem demonstrating usage of Traffic Profiles implemented on top of Cadence simulation to model a static workload use case Analysis of the performance metrics show that the example subsystem is capable of meeting the performance needs of the use case

32 2016 Cadence Design Systems, Inc. All rights reserved worldwide. Cadence, the Cadence logo and the other Cadence marks found at are trademarks or registered trademarks of Cadence Design Systems, Inc. All other trademarks are the property of their respective holders. ARM, AMBA, and Cortex are registered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. Mali, CoreLink, and CoreSight are trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. PCI-SIG, PCI Express, and PCIe are registered trademarks and/or service marks of PCI-SIG. 32