In a previous blog, I shared some prospective information on the real-time performance of Intel CScripts, when run on our SourcePoint debugger, versus legacy methods. This article contains quantitative measurements, and supports the theory that SourcePoint yields much higher throughput.
Intel® Customer Scripts, or simply Cscripts, can be quite helpful in tandem with a debugger like SourcePoint™ when you’re trying to bring up a new Intel-based design. In fact, Intel Cscripts can let you know when there are certain problems in the hardware design and, to a certain extent, they can help debug the firmware. They’ll also help you diagnose catastrophic errors. And, just as importantly, they can give you some insight into those murky gray areas, those places in the system that are not working as they should, but the overall system seems to be working. Or mostly working.
For almost three decades the JTAG or boundary-scan standard (IEEE 1149.1) has been a workhorse, but let’s face it, there are some functions it was never intended to perform and, as a result, it doesn’t do them well. It certainly has been a great access mechanism for testing circuit boards and in-system programming. But, over the last five years or so, as more and more IP in the form of embedded instruments has been integrated into chips, the JTAG standard has frayed a bit around its edges. Specifically, the explosive proliferation of embedded instruments has challenged JTAG with regards to issues such as scalability, IP portability, sustainability, ease and efficiency of operation of embedded IP, and others.
When the Extensible Firmware Interface (EFI) was being defined several years ago, debug resources were an important consideration. We all know that you can have great technology, but if you can’t effectively debug it, it’s not really all that great. Every new technology needs to be coupled with an efficient development paradigm for relatively easy adoption and deployment.
Since the early days of the PC, BIOS (Basic Input/Output System) was the firmware platform for booting a computer out of reset and for providing basic run-time services to an operating system. Of course, PCs have evolved over the years with new system architectures, processor technologies, option ROMs, security safeguards, addressing enhancements and many other innovations which meant that BIOS needed to expand as well. Over time, managing the assembly-level code of BIOS had become more and more problematic for the industry.
New silicon features, along with debugger tool features that use them, can make a large difference in the time it takes to find the really hard bugs encountered during each UEFI port. Intel® has recently introduced two very important debug features in its processors. These debug features are (1) Trace Hub, and (2) Intel Processor Trace. Source level debuggers like ASSET InterTech’s SourcePoint™ contain trace features that use these silicon debug hooks to offer some very strong tool elements that have never been found in the Intel environment before.