Abstract
As the improvement of the SoC technology, it is getting more and more difficult to validate the functionality of SoC, especially for the debugging of multi-core SoC. There are more challenges of SoC pre-silicon or post-silicon debugging when SoC becomes more complex, such as how to trace multiple cores and various types of bus with different clock domains real-time, and how to handle huge amount of trace data from complex SoC cycle by cycle. In the thesis, we propose a real-time embedded debug and trace platform (Trace Debug System) for platform-based or core-based SoC. It consists of Core Monitors and Bus Monitors which can trace the data from target cores and system bus of SoC. Our Trace Debug System also contains 4-stage real-time architecture to compress and store trace data cycle by cycle. And there is an independent Debug Bus to transfer all trace data from Monitors to trace buffer. In that way, our Trace Debug System would not impact the performance of the target SoC. Our Trace Debug System also can trace the SoC with various types of system bus with different clock domains. Moreover, we implement the bottleneck-aware Cross Trigger on our Trace Debug System so that we can trigger Monitors to trace targets when the user-defined trace event occurs or the target system hangs because of system bottleneck. In addition, in order to reduce the huge amount of trace data, we classify trace data to 5 types, and select an individual compression methodology for each types of trace data by analyzing the trace data from Starfish multimedia platform. As a result, we reduce 90% of trace data from Starfish DSP core, and reduce 80% of trace data from system bus (AHB). Moreover, we propose a methodology to optimize area cost of our Trace Debug System in terms of compression ratio (that affects trace depth) and trace capability. For Starfish platform, the area cost of our Trace Debug System (with one Core Monitor and one Bus Monitor) costs only 8%. Besides, under the multi-core environment, the comparison shows that our approach requires 20.82k gates, which is 36% as compared with previous work.