Design-for-Debug Architecture for Distributed Embedded Logic Analysis

1. Design-for-Debug Architecture for Distributed Embedded Logic Analysis Ho Fai Ko, Member, IEEE, Adam B. Kinsman, Student Member, IEEE, and Nicola Nicolici, Member, IEEEIEEE TRANSACTIONS ON VERY LARGE SCALE INTEGRATION (VLSI) SYSTEMSVolume: PP Issue:99 2010Reporter : Chien-Hung Chen Embedded System Laboratory

2. Abstract(1/2) In multi-core designs, distributed embedded logic analyzers with multiple trigger units and trace buffers with real-time offload capability through high-speed trace ports can be placed on-chip. This brings new challenges on how to connect the debug units together in such way that the limited storage space in the trace buffers can be used efficiently. This problem is further aggravated when shadow registers are used to capture data for some signals in the design. Embedded System Laboratory

3. Abstract(2/2) In this paper, we propose a new architecture that can dynamically allocate the trace buffers at runtime based on the needs for debug data acquisition coming from multiple data sources and user-programmable priorities. Experimental results show that using the proposed architecture, real-time observability can be improved using only a small amount of on-chip logic hardware, while avoiding excessive storage on-chip. Embedded System Laboratory

4. What’s the problem? • How to distributed Embedded Logic Analysis in multi-core SoC? • How to connect the debug units together as trigger units and trace buffer…? Embedded System Laboratory

5. The purpose of this paper • A novel debug methodology for improving the real-time observability of multi-core SoC. • Design-for-debug architecture based on distributed embedded logic analysis. Embedded System Laboratory

6. Related Work • State-of-the-art design-for-debug architecture for trace buffer-based debug Assumption 1: Growth in the number of cores Assumption 2: Adoption of high-speed trace ports [20] [21]-[26] [29] [31] [30] [32] [11] Embedded System Laboratory

7. Under two assumptions that the following scenarios are considered • 1. When there are multiple trigger events occurring simultaneously, how to choose trace buffers to sample data from different data sources? • 2. When some of the trace buffers are already occupied, is it necessary to reallocate the trace buffers when a new trigger event from a different data source occurs? Embedded System Laboratory

8. 3. How to allocate trace buffers when the number of sample requests is more than the number of available trace buffers? • 4. How to allocate trace buffers for data sampling before knowing when trigger events from multiple data sources will happen? • 5. How to decide which trace buffers to offload first when multiple trace buffers are idle? • 6. How to balance the sampled data among trace buffers such that more trace buffers will have available space for fulfilling upcoming data acquisition requests? Embedded System Laboratory

9. 7. In the case when debug experiments are repeatable, can the controller be reprogrammed to acquire different sets of debug data during each rerun of the experiment? • 8. When all or some of the state elements are shadowed, how to offload data from these shadow registers without using dedicated scan pins? To address the scenarios presented debug architecture with 7 new features. Embedded System Laboratory

10. Proposed design-for-debug architecture based on distributed embedded logic analysis. Trace Buffer => On chip area Allocation unit to better utilize the storage space in all the trace buffers Allocation unit Embedded System Laboratory

11. Allocation unit The queue control unit and the individual queue FSMs to monitor what and where segments of prioritized data are stored in the trace buffers in the background. Trace buffer control unit toupdate the status registers for controlling the read/write operations of the trace buffers. Top control unit so that only sample requests from low priority data sources should be ignored. They are responsible in providing the appropriate controls to the Communication fabric in the proposed architecture Embedded System Laboratory

12. (a) Overflowing trigger events. (b) Overwriting data in trace buffer. Embedded System Laboratory

13. Out-of-order offloading. Example of using windows to support sampling before trigger. (a) Sampling before trigger. (b) After triggering. Embedded System Laboratory

14. (a) Insufficient bandwidth, resulting sample requests being dropped. Embedded System Laboratory

15. Sufficient bandwidth to satisfy all sample requests. Embedded System Laboratory

16. Segmented data. Embedded System Laboratory

17. Nonsegmented data. Embedded System Laboratory

18. Example of data sampling with different priority settings. (a) Priority setting 1. (b) Priority setting 2. Embedded System Laboratory

19. Area investment analysis when varying the number of cores. Area investment analysis when varying size/number of trace buffers. Area investment analysis when varying the number of trace ports. Effect of programmable priority on data loss. Embedded System Laboratory

20. Area distribution among hardware components when varying the number of cores. Area investment analysis when varying the organization of trace buffers. Area distribution among hardware components when varying the number of trace ports. Impact of various features on acquisition of debug data. Embedded System Laboratory

21. Conclusion • A distributed embedded logic analysis • With shadow scan registers to improve real-time observability during post-silicon validation. • Using two case studies on a digital video decoder • analyzed the cost of managing on-chip distributed trace buffers. • The Dfd hardware is below 30% of the total area required for debug. Embedded System Laboratory