Because of the inherent advantages of in-system programming over standalone programming stations, many design and production engineers have long sought to program soldered-down flash, I2C and SPI memory devices through the JTAG port on a connected device like an FPGA. The problems with pre-programming memory on a standalone station is quite often the contents of the device will change, especially if it's firmware or software. Without in-system programming, updating the stored data would require de-soldering, reprogramming and re-soldering. And the likelihood of damage to the device and board skyrockets.
Software and hardware debug, validation and test of complex systems has always been a challenge that’s demanded innovative new solutions. Now, one of the biggest challenges facing our industry is the disappearing boundary between hardware and software when it comes to finding the root causes of problems. Solving those tough problems is what ASSET InterTech is about, no matter where the problem is.
Intel® provides a collection of scripts (collectively known as Intel® Customer Scripts, or CScripts for short), which assist customers with platform debug and validation. Can they be made to run faster?
The good news is that the EDK2 software distribution continues to grow, adding features to better support the community. The not-so-good news is that the complexity of the EFI code has grown to take advantage of silicon features until it now looks more like an operating system than a BIOS replacement. That can be problematic for software engineers during debug unless they have the right tools.
IEEE 1687 IJTAG is winning great interest throughout the ecosystem, from chip to board to system, due to the manner in which it enables interoperability of embedded instruments and their tool chains from the early stages of chip design through to fully deployed systems.
Debate rages in the embedded software development community about the cost/benefit of using printf statements to debug code. With today’s silicon embedded intellectual property (IP), there is no reason why instrumentation can’t be used in conjunction with trace to provide immediate real-time insight into defect-laced code.
For years, the industry has been grappling with how to access, control and operate instruments that have been embedded in chips. The problem wasn’t that the instruments couldn’t be accessed. Instead, there were too many access methods, each proprietary or customized by the chip supplier. The IEEE 1687 IJTAG standard changed this. Not only has IJTAG standardized the access method, but it’s also widened the scope of re-use for embedded instruments. Rather than being limited to just chip characterization, test and debug, IJTAG enables re-use of instruments and their test vectors to validate, test and debug circuit boards as well.
This is the second in a two-part blog on 64-bit ARM and the server marketspace. If you missed the first blog, read it here.
When ARM introduced its first 64-bit processing core, ARMv8, several years ago, many experts wondered whether it would replicate its disruption of embedded applications by doing the same in the server market, which has long been dominated by the Intel architecture. Since ARMv8s introduction, server system suppliers have made several significant strategic decisions with regards to ARM IP. The first such supplier was Applied Micro Circuits Corporation.
Over the last decade, the rise of ARM® Holdings in the chip industry has been nothing short of phenomenal. And the UK company doesn’t even sell chips! It sells its smarts; its intellectual property (IP).
Apparently, one of the next mountains ARM has set about to climb is the emerging 64-bit server market. But first, let’s recall where ARM came from before look at where it’s going. In Part 2 of this blog series, we’ll examine ARM’s impact on the emerging microserver marketplace.