You may have heard: if you fail to plan, you plan to fail. This was never truer than when you’re integrating an SoC and your IP blocks have embedded TAPs (eTAPs). Failing to consider how multiple eTAPs relate, block-to-block and top-to-bottom, leaves designers unable to tap into the embedded instruments for validation and debug. And, if you think this is bad, just wait until the test people on the production line start screaming at you!
Many problems start at the top, stemming from the lack of proper relationship among the chip’s primary Test Access Port (TAP) – as defined by IEEE 1149.1, commonly known as JTAG – and the eTAPs now found on IP blocks. The original TAP was conceived as a single hardware port on a chip and not an embedded IP port. But now eTAPs are everywhere as multi-core, multi-IP and multi-level everything is more or less standard practice.
So, without careful design practices, conflicts tend to crop up among embedded instruments across different applications domains. The access that a certain tool chain needs to particular embedded instruments might be compromised or blocked entirely! A nightmare scenario is a hardware-assisted debug tool that is denied access to processor cores. Think about it – no debug access for software and firmware development! And now we have more test standards than ever before: IEEE 1149.7, IEEE 1500 embedded core test, IEEE 1687 Internal JTAG (IJTAG) and so on. Each exists for good reasons, but how do you make them all work together?
We’ve taken a long and hard look at the problem of multiple eTAPs from all the angles – hardware to software, chips to boards – to ensure that your tools will just work. Whether you’re involved in design or test, you will find useful guidelines and best practices in our new eBook: “Mixing Embedded eTAPs | 1149.1, IJTAG, Software Debug.” Download it for free.
