System-wide visibility in post-silicon to drive meaningful analytics

Transcription

1 System-wide visibility in post-silicon to drive meaningful analytics EPS Symposium September 2017

2 Agenda Some obvious statements Some problems with existing approaches Key Requirements Some examples of Performance analysis and ebug Use cases Summary 2

3 Some obvious statements SoCs have become increasingly complicated and they are not going to get simpler. Contain several processors, from different vendors Verified in isolation and come with test suite Contain 100s of SP Each verified in isolation Contain complex interconnects Verified for certain, identified conditions Software created by large disparate teams. f lucky, modules and subsystem verified for certain, identified conditions. All this has to successfully work together Understanding real world system behaviour is just plain HAR! 3

4 Some Problems with existing approaches -centric, not system-centric s are a very small part of the overall system Hard to get a handle on bus behaviour, memory controllers, let alone interactions between blocks etc. Where they include analytics it s lip service - very little smarts Knock-on effect of fast data pipe off-chip ntrusive Ad hoc eveloping, but still essentially signal-based. Hard to close timing n-field itoring is not easy 4

5 Key requirements A System-centric vendor-neutral debug and itoring infrastructure One that enables access to different proprietary debug schemes used today by various cores Allows for itors into interconnects, interfaces and custom logic These need to be run-time configurable Re-use the hardware to provide visibility for different scenarios. Run-time configuration of cross-triggering Support 10s if not 100s of cross-triggering events These can be interrogated after a problem to determine actual status Need to be power aware Security built-in Can be used during the whole development flow and more importantly in the field 5

6 Advanced Monitoring and ebug for the Whole SoC System Modules are protocol aware and smart with filter and trace Custom Circuit itor Bus Master/ Slave Bus Monitor Analytics Module Byte Stream Memory Controller Accelerator Custom Circuit Additional Monitors Graphics Security Engine JTAG Control Portfolio of configurable modules, optimized for different system P blocks Flexible scalable message fabric, easy to route ebug & trace is transparent: does not impact system bus GPO Family of Communicators USB Comm. USB Phy UltraSoC nfrastructure Parallel Comm. Parallel /O Stream Comm. Seres ::: On-Chip JTAG Comm. JTAG Supports subsystems with different power domains, clock domains System block UltraSoC 6

7 Some examples of Performance analysis and debug

8 Example of UltraSoC Enabled SoC UltraSoC P $ $ FFT Radio F Radio F Bus Turbo USB MAC ebug Hub UltraSoC nfrastructure Peripheral MA-1 RAM MA-2 Timer Security Bus F-PHY RAM controller PHY R3 8

9 Example Problems UltraSoC Solves UltraSoC P Why is the CPU not performing as fast as expected? Why do some MA transfers take too long? UltraSoC nfrastructure $ MA-1 $ Peripheral RAM FFT Bus Turbo MA-2 Radio F Timer Radio F Security USB MAC ebug Hub What is the mismatch between the host & the? What is going on with my memory controller? Bus F-PHY R3 RAM controller PHY Why does the system hang or deadlock on rare occasions? 9

10 Example 1: Where Have My MPS Gone? UltraSoC P Why is the CPU not performing as fast as expected? UltraSoC nfrastructure $ $ FFT Bus 12% Turbo 8% Peripheral Radio F Radio F CPU spent cycles USB MAC ebug Hub Compute MA-1 RAM MA-2 Timer 80% Security SM Stall 1 outstanding Stall 2 outstanding Bus F-PHY RAM controller PHY R3 10

11 Effective B/s Example 2: R Bandwidth UltraSoC P Why do some MA transfers take too long? UltraSoC nfrastructure $ MA-1 $ 1.00E E+08 SM 6.00E E E E+00 Peripheral RAM FFT Bus Turbo MA-2 Radio F Timer Radio F Security USB MAC ebug Hub Windowed R traffic Time in ns 1 2 CPU1 CPU2 What is going on with my memory controller? Bus F-PHY R3 RAM controller Look at from compute engines Aggregate bandwidth from each is within spec PHY But at Time 2300 Combined peak read request of >2GB/s, cf average of ~570MBs SM 11

12 Example 3 : eadlock etection Many different types but consider this as an example CPU (master) asserts arvalid and issues a read address to the Slave Slave asserts rvalid and outputs read data but never sees rready asserted Configure bus itor trace to trigger when transaction duration exceeds threshold (programmable up to 16k cycles) Trace not output until triggered. When triggered by deadlocked transaction, trace will output most recent transactions up to and including the deadlocked transaction Trace identifies transaction and address, identifying both master and slave of deadlocked transaction 12

13 Example 4 : ata Corruption etection nitiator 1 nitiator 2 nitiator N To detect the initiators doing write access to a same memory location (or a range) - MemAddress. We can configure our Bus Monitor do something like: if <Address> == MemAddress && <RW> == Write then if Count > 1 CaptureTrace() SendEventMessage() else ncrementcount() fi Bus RAM controller Where: <> are AX bus fields being observed by the bus itor. CaptureTrace() puts the transaction into the trace buffer SendEventMessage() is an instruction to the itor to send an event out on our message bus ncrementcount increments the counter by 1 R NB This is pseudo-code actual filtering is down in hardware and not software 13

14 Stall Triggers Observed Metrics Generation Example 1 Runtime Configuration Monitor configured to count Stall triggers from 10 9 Set period of nterval Timer 8 Counter values snapshot on 7 expiry 6 of interval timer. ata Flow 1. Stall trigger observed on SM inputs 2. Counter data periodically output from SM 3. ata traced out via USB FFT Monitor Counter Values 2 Bus F-PHY 1 UltraSoC nfrastructure $ Sample Time (ns) RAM controller UltraSoC P MA-1 $ Peripheral RAM Bus Turbo MA-2 Radio F Stall Triggers Timer Radio F Security USB MAC ebug Hub PHY 3 R3 14

15 Cross Triggering Example 1 Example ARM Subsystem Runtime Configuration Bus Monitor A outputs Event on MA access Set the period of the Monitor s nterval Timer Configure the Monitor to observe the following sequence: Memory access Non CPU Masters Bus Monitor A Bus Monitor B APB ARM Core BG CT ETM LE MA START NoC or Bus Fabric nterval expired Stall Trigger Bus Monitor C MA-AX PAM-APB Monitor Trace Receiver STALL System SRAM Output trigger from SM when entering the STALL state Configure Trace Receiver(s) to enable tracing on receipt of trigger SoC Boundary 15 Optional Storage USC-P Message Engine Xilinx AURORA P External ebugger SERES

16 Cross Triggering Example 1 (cont) Example ARM Subsystem ata Flow 1. Bus Monitor A outputs UltraSoC event when memory access detected 2. Monitor receives Stall trigger A AATA A AATA 3. Event output from SM after transitioning A AATA A AATA from MA START -> STALL A AATA 4. Trace Receiver(s) enabled after receiving A AATA A AATA event A AATA 5. Trace output via USC-P A AATA Memory access ATB Samples A A A AATA AATA AATA Non CPU Masters Bus Monitor A A A A A 1 NoC or Bus Fabric Bus Monitor C System SRAM Bus Monitor B Only capture data of interest AATA AATA AATA AATA MA-AX PAM-APB APB 2 CT Monitor ARM Core BG 3 ETM Trace Receiver 4 LE nterval expired MA START Without Cross- Triggering With Cross- Triggering Optional Storage Message Engine STALL Stall Trigger SoC Boundary Xilinx AURORA P 16 USC-P External ebugger SERES 5

17 Example of nstrumented SoC UltraSoC Bus F-PHY R3 $ RAM controller UltraSoC P MA-1 $ RAM Turbo Peripheral Efuse FFT Bus MA-2 Static nstrumentation Radio F Timer Key Store Radio F Security USB MAC ebug Hub PHY The S provides independent memorymapped channels (mailboxes) Software and hardware can post writes to these channels which can be used to understand system wide behaviour The data is timestamped Or no data if only timestamp needed. The channels can be filtered Each channel can be enabled to provide events which can be used for cross-triggering The Virtual Console provides bidirectional channels 17

18 Simple S visualization 18

19 ntegration with external tools 19

20 Key Features Non-intrusive Smart itors Protocol-aware bus itors (AX, ACE, ACElite, OCP, OCP 2.0, CH etc.) Full support for all standard processors (ARM, RSC-V, MPS, Xtensa, CEVA, etc.) Message-based protocol Powerful status itor Secure Bare Metal Security Monitoring does not impact system performance. nstrumentation (light intrusion) seamlessly incorporated. etect items of interest in hardware, at wirespeed. Massively reduce trace bandwidth & memory. Home in on problems efficiently dentify specific transactions; easily spot problems Easily support heterogeneous architectures; mix & match across vendors; fix hardware, software or HW+SW integration problems Easy to place & route; extensible & versatile; allows local processor for autonomous control in the field Configurable smart logic analyzer for custom logic Powerful security architecture Provides for observation of target system in order to raise alarm 20

21 Use Cases

22 Classic ebug n this case the SoC may be on a prototype board or in the final product form. This allows for device validation and bring-up. Typically done with board attached to work station. CPU breakpoints, starting, stopping of software executing on the SoC. More and more of the system will be integrated (brought up) and exploration of the whole SoC, under realistic conditions, takes place. 22

23 n field debugging and analysis n this case the SoC is in the final form and issues such as integration of the software can be debugged. The performance of the system can be analysed. The software being used could be the E as shown previously or specific views of key flows of data through the system. These could be traffic to the memory controller MA completion times epth of FFOs in RF interface Performance of processing engines within the SoC Cache behaviour Etc. This can be used to help diagnose why a product has hung-up in the field. uring operation the device has been continuously capturing trace in circular buffers in the itors. This effectively gives a system wide core dump. Trace data is extracted from the device and analysed and replayed to give the last N transaction before the failure occurred. The device does not need to be attached as the trace could have been extracted in the field and shipped to the manufacturer 23 UT

24 n field analysis The areas of interest can be extracted from the system-core dump and specific views created which can be analysed by domain specific engineers These could be memory controller designers, RF interface designers etc. Traces extracted from the field can be used for the next generation architecture of the SoC 24

25 Corporate and ot use Performance and Security Monitoring of server farms An example would be observing utilisation of the individual servers and the resources such as memory and disks os can be reported back to root/base. Security and safety can be itored in a similar manner Updates would be maintained by the root/base. Any breaches of security can be reported back to base. Network 25

26 Standalone and unconnected use n this there is a self contained Analytics Subsystem. Any communication, if required is done over the air. Many systems will not even have wireless connection etect unauthorized access Eg processors reading from key store Eg Attempt to read decrypted boot code Update audit & verification Scan internal/external regions etect frequent access / os Ensure system operates in the bounds of safety. f any divergence, invoke fail safe state R3 F-PHY $ RAM controller MA-1 $ RAM Turbo Peripheral 26 UltraSoC Bus UMA UltraSoC P SMB Efuse FFT Bus MA-2 Clock and Reset Radio F Timer Key Store Radio F Security Analytics Subsystem

27 Summary UltraSoC provides a complete advanced universal on-chip analytic and debug platform Full visibility of whole SoC Non-intrusive ndependent provider enabling free-selection of P Multi-vendor and multi-processor in one environment USB connectivity for faster debug or /O constrained devices Advanced analytics: forensics, optimization, dynamic, power saving Bare metal security Low-power and power-down; power domains & clock domains Full support for large heterogeneous SoC Fully message-based communication ata-flow management and security Silicon proven 27