Embedding a single test solution

Embedded instruments can be used to implement such a strategy, but the starting point is to have an industry standard interface to access these instruments. This was the role projected for P1687, also known as iJTAG, but its adoption has not been as smooth as some would like. Boundary scan, JTAG, was seen as a good way using the JTAG Test Access Point (TAP) featured on the majority of chips to access embedded instruments. However, its limitations quickly became apparent. Al Crouch, chief technologist for embedded instrumentation methodologies and JTAG at Asset InterTech, observed: "There is a faction that thinks IEEE1149.1 covers everything and that P1687 is unnecessary. They are 'old school JTAG' and don't really understand that JTAG is not scalable." The problem arises when, instead of having a handful of instruments accessed through the TAP, there can now be hundreds, or even thousands – temperature sensors, voltage sensors, power domain on and so on. "It is like taking all the traffic in London and running it through one point," commented Crouch. "However, if you send out one set of signals – shift, capture, update, reset – as a bus across the whole chip and hook something up to it, an SIB [a segment insertion bit] local to the instrument can create the select signal. What you have done is to move the decode from the TAP controller into the chip. And that makes it more scalable, because the instruments and their decode are distributed across the chip and not all contained in one little area. That is what we were aiming for with P1687." The initial ballot for ratification of P1687 came unstuck, partly down to those who believed it should look like the old JTAG with a centralised instruction register. A new ballot is currently underway on the revised standard. Half the battle Providing access is only half the battle. Asset's ScanWorks platform is a tool familiar to many hardware engineers, allowing hardware and firmware test and debug from design to prototyping to production. According to Osborn, what ScanWorks, or any other platform on the market, doesn't do is support concurrent software debug, which is why, in 2013, the company bought software debug company Arium. Osborn said: "We are in the process of merging our software debug tools into our platform. The reason is that we see the future of system validation debug and test as being able to do hardware and software debug on the same platform. The speed of today's systems means a lot of difficulties stem from that intersection of hardware and software and it is very difficult to tell where the problem is coming from. They really will need these kind of tools that do both at once." While P1687 brings access to embedded instruments, the plan is to develop ScanWorks into a platform that both software and hardware engineers will feel comfortable using concurrently. Osborn continued: "It is the ScanWorks platform that gives the user of the hardware or software or both, access to the instrument and access to the software side." A typical example in hardware development would be when a first generation board gets a new SoC or FPGA. The resultant tests might show the hardware is operating fine, but the software engineer could find the first generation software is behaving erratically for no obvious reason. Osborn explained the role that ScanWorks is being developed to fill. "The software engineer will be able to cross into the hardware domain and, for example, run a high speed I/O test on a memory bus to figure out what is going on. First of all, they could run a processor control test, which is a functional test within the ScanWorks platform, to verify the functionality of the new interface – because it is a new board – on the controller to the memories. "If they were still having problems they could do a high speed I/O test to see if there were margining issues. If margining issues did surface, they could call their colleagues over and have them use exactly the same tool that was used during the validation process to see if there was something on the board which had changed physically." In this case, the object is to essentially look at the hardware and the software in parallel to determine what happened with that particular spin of the board and why it caused the software to behave improperly. Osborn said: "Maybe it was just a bug embedded in the software that manifested itself on the second generation, but you wouldn't know that until you started to look at the totality of the system. That is the purpose of the whole Scanworks platform; to provide access via 1687 to these instruments and to let the whole community access it in a domain with which they are comfortable." This last point refers to the proposed ability of software debug engineers to access the platform through a SourcePoint interface with which they are already familiar, SourcePoint being the Arium software debug tool. Platform development Osborn hopes the fully functioning platform will be available later in 2014 or perhaps into 2015, but the project is obviously more complex than just adding the two components together. He concluded: "Arium had its own interface to its targets and we had our hardware interface at ScanWorks to those targets. Those interfaces have to merge. Secondly, the two companies have to get together and work out what is needed for software debug, what is needed for hardware debug and make sure there is one connectivity point into the target through that hardware controller mechanism that satisfies both camps. "Then we need to connect the current environments to that particular controller. That is what we are trying to figure out right now: what the requirements are. You only want to lay that hardware foundation once and only once, because you don't want to end up changing it as you learn. "We need to combine the years of experience from Arium with the years of experience from Asset and get that hardware interface right from the word go."