I was asked recently whether engineers could just check the CRC error counts coming from the Operating System to ensure they had good
signal integrity and operating margins. After all, a CRC checks for bit errors,
right? Here’s why this is not good enough:
Our chief technologist of non-intrusive board test, Adam
Ley, recently published an e-Book
on solving the problem of diminishing test coverage from In-Circuit Test (ICT).
What’s the key take-away from this publication?
Brian Bailey, editor of EETimes’ EDA Designline, recently
penned a blog questioning the ubiquity and value of embedded instrumentation
within chips. It’s a fascinating and timely read, and I’d like to put my two
cents worth in…
PCI Express (PCIe) buses, in particularly Gen3, are susceptible to defects which may be masked from conventional test. What are these defects and how are they detected?
In my last Blog, I wrote about the iNEMI report on how testing memories is one of the top three problems engineers face today. Why is memory test so important?
Many legacy In-Circuit Testers (ICT) support some kind of boundary scan for structural testing, to address limited access issues. But are these as good as advertised?
In addition to board design/layout issues, manufacturing defects and variances, other factors such as pollution and power marginalities can affect a design’s signal integrity and subsequent performance.
One of several buses I’ve been working on with the ScanWorks High-Speed I/O (HSIO) products is PCI Express (PCIe). We’ve had tools in ScanWorks to test PCIe in various ways since the Intel server chipset code named Twincastle back in the 2005 timeframe. And we’ve often run into issues with having robust enough support to handle any random endpoint that customers might choose for their system.