![\"\"](\"https:\/\/www.techdesignforums.com\/practicefiles\/2012\/07\/tdf-jul12-mentor-ijtag-fig-1-lrg.jpg\")
<\/a><\/p>\nFigure 1<\/span> Instead, you can gain access to the IPs by modeling the WTAPs, and the operation of the IP blocks at their boundaries with the WTAP, in P1687. To be able to do this, you describe the TAP and the WTAPs as \u2018instruments\u2019, that is, IP with a P1687-compliant interface and behavior (Figure 2).<\/p>\n Figure 2<\/span> The behavior of the TAP and WTAP fulfils the requirements of P1687. [The hardware requirements of P1687 were derived from 1149.1 and 1500, so the TAP and WTAP are compatible with P1687 by definition.]<\/p>\n P1687 defines two languages. The first, Instrument Connection Language (ICL), uses a set of keywords to describe the (test) input\/output interface of instruments. For example, the ICL keyword \u2018TMSPort\u2019 says that an input port should be considered a TMS port as defined in IEEE 1149.1. Using these keywords, ICL defines syntaxes for each port, as well as a semantic, and a relative timing of events. The body of the TAP and WTAP ICL module definition is rather generic. The only variations come through the length of the registers, which can be parameterized, or any user-defined bits, ports, or opcodes.<\/p>\n In ICL, you can then define instances of modules and describe their connections, creating an ICL \u2018netlist\u2019. The ICL netlist for our example would only include three instances \u2013 the two modules and the top level. [If you would like a more complete example, feel free to email me<\/a>.]<\/p>\n One feature of the ICL language is particularly helpful when defining a TAP or WTAP, because it lets you define a string representing a value, for example, using the \u2018alias\u2019 keyword:<\/p>\n You can also use enumeration tables, which are be bound to the registers for which they are valid:<\/p>\n The benefit of aliases and enumeration tables becomes clearer when we consider the second language that P1687 defines: PDL, or Procedural Description Language. PDL is a command language that instructs an application tool how to generate patterns. It does not describe the patterns themselves, which may include control values to gain access to instruments. Instead PDL defines at the instrument level where (either a port or a register) to apply care bit values. The application tool follows the PDL instructions and retargets the care bits through the ICL hierarchy, automatically adding control values as needed. When the top-most ICL level is reached, the final PDL can be translated into any common pattern format, like STIL, WGL, or can be written out as a verification test bench.<\/p>\n Using the example design, here\u2019s how you would enable the IP3 connection to the first WTAP (see Figure 2):<\/p>\n This tells the application tool to generate a sequence of operations for the TAP and WTAPs that puts the bit-sequence 01000 in the instruction register \u2018IR\u2019 of the instance \u2018instWTAP\u2019 in \u2018core1\u2019. The \u2018iApply\u2019 keyword ends the instruction block.<\/p>\n Notice the absence of any user-defined control operations. What needs to be done to get the user-defined care bits \u2018enableIP3\u2019 into the specified location \u2018core1.instWTAP.IR\u2019 is up to the application tool and doesn\u2019t concern you as the P1687 user.<\/p>\n Let\u2019s move the test one hierarchy level higher. Figure 3 shows two dice in a system.<\/p>\n Figure 3<\/span> Again, you want to enable IP3. This additional level of hierarchy only slightly changes the actual PDL instruction, which now reads:<\/p>\n Compare this to the work involved in reusing a die-level validated test at the system level.<\/p>\n Now, what if you want to enable IP3 in parallel to IP12 (assuming the hardware allows this)? In PDL, this is simply:<\/p>\n With the goal of minimizing the overall scan operation and recognizing that the hardware allows it, the application tool will find a way to apply both opcodes at the same time to the two WTAPs.<\/p>\n In our example, we couldn\u2019t assume that any of the IP blocks complied with P1687. Let us revisit this situation. Because they are controlled by a WTAP and probably receive and send data through the WTAP\u2019s scan port, it is very likely that they are actually P1687 compliant or very close to it. If this is so, you would no longer need to address the IP block at the WTAP boundary but could talk directly to it and easily execute complex tasks such as an MBIST repair, leaving the WTAP operation to the application tool.<\/p>\n Figure 4 shows a situation in which some IPs are already migrated to P1687 and can be directly operated. The others remain proprietary and continue to be operated through PDL at the WTAP level. The figure also shows that all of the P1687 instruments can be added to a single P1687 access network. This network is under the control of the application tool, and allows it to further optimize access time to instruments and to improve the scan data volume. Over time, the entire WTAP may become redundant.<\/p>\n Figure 4<\/span> Adopting P1687 on a design that already uses IEEE 1149.1 and\/or IEEE 1500 is easy and doesn\u2019t require hardware changes. The biggest advantages of P1687 in this scenario are the automation of generating tests for different hierarchy levels, and the general ease of use: you only need to define the care bits of the operation. The P1687 application tool applies them at the right time and in the right location, independently of how complex it is to access the IP. You can easily migrate IP to the P1687 standard piece by piece, mixing P1687 instruments and proprietary IP in the same design. P1687 offers a smooth transition from a proprietary in-house solution to an IEEE-standard backed commercial test solution.<\/p>\n 1. The IEEE P1687 Working Group\u2019s Web site is located at http:\/\/grouper.ieee.org\/groups\/1687\/<\/a><\/p>\n 2. J. Rearick, et al., \u201cIJTAG (Internal JTAG): A Step Toward a DFT Standard,\u201d International Test Conference, 2005.<\/p>\n 3. K. Posse, et al., \u201cIEEE P1687: Toward Standardized Access of Embedded Instrumentation,\u201d International Test Conference, 2006.<\/p>\n 4. B. Vermeulen, et al., \u201cOverview of Debug Standardization Activities,\u201d IEEE Design & Test of Computers, May\/June 2008.<\/p>\n 5. F. Ghani Zadegan, et al., \u201cReusing and Retargeting On-Chip Instrument Access Procedures in IEEE P1687,\u201d to be published in Design & Test of Computers, IEEE.<\/p>\n 6. M. Keim, R. Press, \u201cWhat\u2019s The Difference Between JTAG (IEEE 1149.1) And IJTAG (IEEE P1687)?<\/a>\u201d Electronic Design, May 16, 2012, http:\/\/electronicdesign.com<\/a>, article ID 73938.<\/p>\n Martin Keim joined the Silicon Test Solutions group of Mentor Graphics in 2001, where he is currently a technical marketing engineer. He is a member of the organizing committee of the International Symposium for Testing and Failure Analysis (ISTFA) and an active member of the IEEE P1687 working group. He holds several national and international patents and is author of many technical publications. He received a doctorate degree in informatics from the Albert-Ludwigs University, Germany. He can be reached at <\/em>martin_keim@mentor.com<\/em><\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Making a smooth transition to IJTAG, the scan-test strategy for IP blocks, without having to change your existing hardware. <\/p>\n","protected":false},"author":329,"featured_media":3180,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1386,43],"tags":[1574,1062,441,1063],"coauthors":[996],"class_list":["post-3123","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-assembly-integration","category-test-design","tag-ieee-p1687","tag-ijtag","tag-jtag-debugging","tag-standards-2"],"_links":{"self":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/posts\/3123","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/users\/329"}],"replies":[{"embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/comments?post=3123"}],"version-history":[{"count":0,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/posts\/3123\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/media\/3180"}],"wp:attachment":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/media?parent=3123"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/categories?post=3123"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/tags?post=3123"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/coauthors?post=3123"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nA test access mechanism using an IEEE 1149.1-compliant TAP at the top level and IEEE 1500 compliant WTAP for core access. (Source: Mentor Graphics \u2013 click image to enlarge)<\/p>\n<\/div>\n<\/a><\/div>\n
\nYou can get going with IEEE P1687 by describing the TAP, the WTAP, and the connection in ICL. No hardware changes are needed. (Source: Mentor Graphics \u2013 click image to enlarge)<\/p>\n<\/div>\nDescribe what you need<\/h2>\n
Alias myUserOpcode1 = 5b\u201910100<\/pre>\n
EnumTable {<\/pre>\n\u00a0\u00a0\u00a0\u00a0 Reset = 5b\u201900000 ;<\/pre>\n
\u00a0\u00a0\u00a0\u00a0 myUserOpcode1 = 5b\u201910100 ;<\/pre>\n
\u00a0\u00a0\u00a0\u00a0 enableIP3 = 5b\u201901000 ;<\/pre>\n
\u2026<\/pre>\n
}<\/pre>\n
Where is the advantage?<\/h2>\n
iWrite core1.instWTAP.IR enableIP3 \r\niApply<\/pre>\n
<\/a><\/div>\n
\nMoving from die level to system level is painless in P1687. (Source: Mentor Graphics \u2013 click image to enlarge)<\/p>\n<\/div>\niWrite die1.core1.instWTAP.IR enableIP3 \r\niApply<\/pre>\n
iWrite die1.core1.instWTAP.IR enableIP3\r\niWrite die2.core2.instWTAP.IR enableIP12 \r\niApply<\/pre>\n
Migrate your hardware step by step<\/h2>\n
<\/a><\/div>\n
\nAll P1687 components are in a network behind the WTAP, enabled through one WTAP opcode, for optimal P1687 access. (Source: Mentor Graphics \u2013 click image to enlarge)<\/p>\n<\/div>\nSummary<\/h2>\n
References<\/h2>\n
Author<\/strong><\/h2>\n