On the list of activities that system designers enjoy doing, “debugging” is invariably near the bottom. That’s because it is often complicated, time-consuming and downright frustrating to track down and identify what is going wrong on the chip. However it goes without saying that debug is a critical part of SoC development. The ‘quality control’ that debugging provides means that OEMs can be assured of a high standard of functionality from a chip. The peace of mind this affords is invaluable, much in the same way you would be a lot more relaxed in the knowledge the new car you have just bought has had its brakes tested for quality assurance.
An effective debug strategy requires an experienced head and a good set of tools to get things done properly. When it comes to experience, Mark LaVine is an expert on the matter, having spent the last 15 years developing debug and trace solutions in order to minimize the frustrations that system designers feel when attempting to diagnose on-chip problems. Mark sat down recently with williamorme to talk about some of the common challenges related to silicon debug and some of the strategies available to overcome them.
In the video below he opens up about the topic of silicon debug and the major problems that surround this area, “today we’re looking at highly integrated products with very limited visibility”. He goes through some of the scenarios that lead to bugs being found in silicon, as well as the implications they can have, “usually it’s either a lock up or data corruption. Data corruption is the most difficult area to debug because typically it gets detected very late, from where the originating corruption occurred. To do experiments and trace back the original source can be very time-consuming”.
Mark has just finished working on the development of the brand new ARM® CoreSight™ ELA-500 Embedded Logic Analyzer, which is designed especially to diagnose and identify corner-case bugs. These are the type of bug that typically slip through the net of normal debug and trace protocols and only show up later on in the process when it suddenly becomes a more arduous task to get rid of them. Not to mention the greater costs involved in removing bugs found in silicon. In the video below you can see Mark speak about some examples of how the ELA-500 could be used to provide greater visibility and detect these issues before it’s too late, including on the new Cortex®-A72 processor “With the Cortex-A72 processor we provide a visibility on the CPU to L2 interface, which is very useful for accesses that could go external. In the case of a hang or lock-out you could find out which accesses were going on prior to the lockup. For other things like data corruption you could get a trace of those instructions”.
An example of the ELA-500 being deployed in a system
If you have any questions for Mark on the subject of silicon debug then please leave them in the comments section below and we will do our best to answer them here or with a follow up video.
My colleague William Orme has also written a blog that goes into more detail on the ELA-500 and how it succeeds in Taking the fear out of silicon debug.
For more information on the CoreSight ELA-500
Nice one. Thanks.
William
Sent from my iPhone