Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

EXTEST register in JTAG

Status
Not open for further replies.

manoj009

Newbie level 5
Newbie level 5
Joined
Sep 6, 2011
Messages
9
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Visit site
Activity points
1,335
HI guys,
Can anyone please let me know more on the purpose of extest register used for boundary scan in JTAG

Regards
Manoj S
 

To remind the goal of the boundary is to check the PCB connection between multiple chip on the board, via the boundary.
One chip drive the pad via the boundary structure and the other pads received the value by the boundary structure.
As I remind the extent is to drive the pad from the core, could double check.
 

The shortest answer is that the EXTEST instruction is what is typically used during board-level testing via JTAG, when testing continuity between ICs on a PCB.

Maybe you already know this, but you might want to obtain some kind of IEEE 1149.1 specification reference or app-note (e.g. do a search for "1149.1 std").

There are two types of registers in a TAP ctrlr: instruction (IR) and data (DR):
-> the IR is a special, single shift-register which effectively serves as a MUX select which connects a different shift-register to the TDI & TDO ports, but it also can modify the behaviors of the boundary-cells or other test-related behaviors (e.g. memory-BIST or internal ATPG-scan)
-> the DR is one of these latter MUXed shift-registers
One of the standardized instructions in the IEEE 1149.1 is EXTEST, but it is helpful to think of it as more of a "mode" than a register.
Once you are in the EXTEST mode (via Shift-IR & Update-IR states in the TAP controller to load the proper value into the IR) ...
-> the DR becomes the serially-connected boundary-cells (each which consist of MUXes and registers)
-> input-port boundary-cells are placed into a configuration which supports the sampling of externally-applied input-levels into the boundary-cells
-> output-port boundary-cells are placed into a configuration which supports the substitution of levels to output-ports
-> Capture-DR and Shift-DR states in the TAP-ctrlr are used for the sampling of external inputs (via shifting-out the sampled levels to the TDO pin)
-> Shift-DR and Update-DR states in the TAP-ctrlr are used for the driving to external outputs (via shifting-in the driven levels from the TDI pin)

Again, there are some good app-notes out there that will expand on this and the other standardized instructions, and also show schematics of what the boundary-cell internals look like.
 

Thanks guys, I have one more query.
I am working on a multi million SOC.
DO I need to access the extest mode from the TOP level TAP or the module TAP which is connected serially?
I need to set this mode on the module, but I am not sure if this is implemented in the module.
 

This is impossible to confidently answer without knowing more - I would think someone on your team would be handling such DFT planning.

In cases where I've encountered module-level TAP-ctrlrs, they've only been there for the purpose of some type of BIST, such as MBIST.
And, they were not enabled until a certain TAP instruction was selected, and would then require a reset to get back out of that mode.
And, they were typically inserted into the design by a tool, such as Mentor's LogicVision.
And, they were not in series with the main TAP, but instead were MUXed in-place of it only in this mode (though the module-level TAPs were all connected in series with each other, just not with the main one).
Note the reason for having distributed controllers had to do with practical chip-distances and/or clock-domains, plus a need to divide-and-conquer the fanouts/controls due to the large #s and diverse configs of memory-macros.

EXTEST only has to do with off-chip continuity testing, and thus only relates to the top-level external I/Os.
The main TAP-ctrlr is what typically handles this (consistent with the IEEE 1149.1 spec), but I also do not know if that spec or commercial JTAG control S/W allows for deviations from this notion.

A boundary-cell also must be inserted somewhere between each I/O pad-cell and the functional core-logic.
(but, not all I/Os will get this treatment, such as the actual JTAG I/F ports and maybe other special dedicated-test I/Os)
I do not know how you have inserted these boundary-cells, but they use control signals that would be fed from a TAP-ctrlr.
Determining if that TAP-ctrlr is solely the top-level one might help answer your question.
But again, it seems odd to me that you do not have someone involved in the design that already has the answers you seek.
 

This is impossible to confidently answer without knowing more - I would think someone on your team would be handling such DFT planning.

In cases where I've encountered module-level TAP-ctrlrs, they've only been there for the purpose of some type of BIST, such as MBIST.
And, they were not enabled until a certain TAP instruction was selected, and would then require a reset to get back out of that mode.
And, they were typically inserted into the design by a tool, such as Mentor's LogicVision.
And, they were not in series with the main TAP, but instead were MUXed in-place of it only in this mode (though the module-level TAPs were all connected in series with each other, just not with the main one).
Note the reason for having distributed controllers had to do with practical chip-distances and/or clock-domains, plus a need to divide-and-conquer the fanouts/controls due to the large #s and diverse configs of memory-macros.

EXTEST only has to do with off-chip continuity testing, and thus only relates to the top-level external I/Os.
The main TAP-ctrlr is what typically handles this (consistent with the IEEE 1149.1 spec), but I also do not know if that spec or commercial JTAG control S/W allows for deviations from this notion.

A boundary-cell also must be inserted somewhere between each I/O pad-cell and the functional core-logic.
(but, not all I/Os will get this treatment, such as the actual JTAG I/F ports and maybe other special dedicated-test I/Os)
I do not know how you have inserted these boundary-cells, but they use control signals that would be fed from a TAP-ctrlr.
Determining if that TAP-ctrlr is solely the top-level one might help answer your question.
But again, it seems odd to me that you do not have someone involved in the design that already has the answers you seek.



Thanks a lot for the help!!
Yes, I contacted the person who has inserted this. It has to be configured at the top level, thanks
Guess the design is still not mature enough for integration, so facing lot of issues.
Thanks a lot for the help.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top