Article 2 – The IP Test Evolutio

The new structural description capabilities for both standards include a few standard building blocks. These building blocks are pre-defined in an 1149.1-2013 standard package or a P1687 ICL file and can be used to connect IP segments together to create a reconfigurable network that forms the test data register. A basic network can be built from three types of segments: always in-line segments, excludable segments, and selectable segments. The chip integrator can use the excludable segment building blocks to bypass a segment or not, or a selectable segment description to select one out of N segments to include. These basic switched segments can be combined and nested to form complex networks.  This ability to document a reconfigurable network, or any network with a changing JTAG TDR length, was not supported in a standard prior to 1149.1-2013.

1149.1-2013 also supports specific controls for power-down domains during test.  We will not dwell on this, or several other new capabilities of this revised standard in this series of articles.

P1687 is a proposed IEEE standard that will hopefully be approved and published very soon. P1687 has been created to address how to gain access to internal blocks of logic called “instruments”. An instrument can be almost any group of logic from a single gate to a huge block, sub blocks, or an entire sub-system. Examples could be IP such as DDR, CPUs, temp sensors, memories, sub-systems, etc. Basically any group of gates that you’d like to group together to have test stimulus applied internally within a chip can be described. 

P1687 provides a modeling language, ICL, which is more robust than BSDL.  This allows the description of the reconfigurable network, and even allows the description of combinational logic between a TDR segment and the instrument ports.  Since the standard currently only uses the 1149.1 TAP as its access mechanism, the shift register cells of the TDR must still comply with that standard.

You can think of P1687 as providing a superset of the network description section of 1149.1-2013. P1687 has a lot of the same goals and shares most of the advantages of 1149.1-2013 for IP.

Steps Towards the IP Evolution

Leveraging these standards has many advantages to allow significant savings. The steps in the development process will also need to be changed slightly and the deliverables from step to step will change as well.  The flow chart, figure #1, shows the major changes to traditional design and reuse.

IP Providers will have several advantages in utilizing 1149.1-2013 and P1687. Providers will have more control over the way their IP is being tested. This will lead to fewer customer issues and risk of support problems. The IP provider will need to develop the tests in the correct PDL format and create the BSDL package or ICL.

Chip integrators will then be able to “Plug and Play” the IP into the chip test network described from using either standard.  The provided IP PDL can be called from the chip level PDL. There is no need to develop a new test access strategy and no need to try and develop test sequences based on the IP spec. 

Chip level test verification test patterns can then be automatically generated (retargeted) based on the original IP PDL, chip level PDL, and integrated network description provided by the chip integrator (ICL or BSDL).

After the test patterns simulate without errors, the chip level manufacturing patterns can be generated from the simulation patterns along with any other formats to support board test, debug, or system test. 

The retargeting step should ideally only occur once to ensure that the simulated patterns are used downstream in the target manufacturing platforms. This gives another level of quality assurance to the process and makes debug possible if issues need to be tracked back to simulation. It is almost guaranteed that retargeting with different tools will produce slightly different patterns and possibly different results. Since PDL is a high level procedure description language, how the data arrives, the number of serial frames needed, the order of tests, which tests are run in parallel, and more could vary between vendors. Analyzing the network and being efficient in the pattern generation process is important to reducing vector count and optimizing the overall solution.

1149.1 and P1687 Network Description

The simple 1149.1-2013 network above in the figure #2 shows three presumably different IP (shown in dark blue) connected into a complex network.  The first (left) IP does not have an internal TDR segment, so a simple wrapper (shown in light blue) is provided to include the TDR segment with the IP.  When this wrapper is supplied by the IP provider, then the IP provider can also supply 1149.1 PDL for this IP.  1149.1-2013 treats the wrapped IP as a single entity.  In this network, the first IP may be bypassed, or “excluded” in the terms of the standard, with the selecting multiplexer controlled from a register cell, in red, that is outside the segment it controls.  The two IP on the right are two of possibly many IP where only one will be selected for scanning.  A TDR field that is outside the selectable segments, again in red, will control the selection, as shown.  Both control cell fields can be anywhere in the TDRs of the chip, allowing full hierarchical nesting to any level, but must always be outside the segment controlled by that control cell.

The above P1687 network, figure #3, shows a similar network but illustrates the greater flexibility of the P1687 structural description.  The first IP again has no built-in TDR segment, but no wrapper is needed.  Similarly, the second IP (top right) not only has no built-in TDR segment, but has combinational logic between the TDR and the IP.  In both of these cases, the PDL would write to and read from ports of the IP, and the retargeting process will convert the values at the ports to values in the register segment.  In the last IP shown, the TDR segment is built-in and the IP provider would provide the ICL description of this TDR segment.  Again, the two IP on the right represent two out of possibly many IP, only one of which may be selected at a time.  Again, control cells are in red, and the structures may be nested in a hierarchy.

As shown in the figure, P1687 has the advantage of immediately supporting existing (or future) IP that do not have a test data register built-in or in a wrapper.  For IP not having the TDR segment included, P1687 has the disadvantage of forcing every chip integration team using the IP to build a test data register within the network and to write the ICL that describes the network. This may increase the possibility of introducing errors. Furthermore, the P1687 retargeting tool will need to analyze and retarget the pattern through any logic, as illustrated above with the top right IP block, between the TDR and the ports of the instrument. If the TDR segment for accessing the IP is built-in, then the IP provider would supply the ICL as well as the PDL. The PDL could then be written to the register fields, and one source of possible integration errors would be eliminated.

The structural documentation of either standard can provide any desired level of detail of test data register fields or instrument ports. If a TDR segment is supplied, full documentation could include the number of bits and position of each appropriate field in a register segment, even if the bits are not contiguous.  Fields or ports that are reserved for proprietary purposes can be listed as reserved or even left undocumented.  Also, legal, illegal, and reserved values to be written to or read from the fields or ports can be defined and given names for convenience.  Where desired, 1149.1-2013 also allows constraints. A constraint is checked by software prior to scanning a register to prevent illegal values or combinations of values from being scanned to a TDR, whereas P1687 has no such function.

With this type of fully described structural documentation, the procedural documentation becomes a matter of writing or reading named values to and from named fields or ports.  It is not necessary for the PDL writer to know all the details of the register network, location of fields or ports within the network, or even the binary values being written and read.  This makes it easier to think about the problem and define the proper solutions. This type of higher level test stimulus can then be applied with automated tools leveraging either of the new standards.


Review Article Be the first to review this article

Featured Video
Peggy AycinenaWhat Would Joe Do?
by Peggy Aycinena
H-1B Visa: de Geus’ tragedy looms large
Peggy AycinenaIP Showcase
by Peggy Aycinena
IP for Cars: Lawsuits are like Sandstorms
More Editorial  
Technical Support Engineer EU/Germany/UK for EDA Careers at N/A, United Kingdom
ASIC/FPGA Design Engineer for Palo Alto Networks at Santa Clara, CA
Mechanical Designer/Engineer for Palo Alto Networks at Santa Clara, CA
Lead Java Platform Engineer IOT-WEB for EDA Careers at San Francisco Area, CA
Staff Software Engineer - (170059) for brocade at San Jose, CA
Technical Support Engineer for EDA Careers at Freemont, CA
Upcoming Events
Embedded Systems Conference ESC Boston 2017 at Boston Convention & Exhibition Center Boston MA - May 3 - 4, 2017
2017 GPU Tech Conference at San Jose McEnery Convention Center 150 West San Carlos Street San Jose CA - May 8 - 11, 2017
High Speed Digital Design and PCB Layout at 13727 460 Ct SE North Bend WA - May 9 - 11, 2017
Nanotech 2017 Conference & Expo at Gaylord National Hotel & Convention Center WA - May 14 - 17, 2017

Internet Business Systems © 2017 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
AECCafe - Architectural Design and Engineering TechJobsCafe - Technical Jobs and Resumes GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy