Potential SJTAG Value-Adds

Discuss the generic proposals for SJTAG
Post Reply
User avatar
Ian McIntosh
SJTAG Chair
Posts: 395
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo MW Ltd, UK
Contact:

Potential SJTAG Value-Adds

Post by Ian McIntosh » Wed Mar 02, 2016 9:26 am

From here, it may be useful to try to list current practices that we think can be improved through the "application of SJTAG" - I'm leaving that scope rather open for now. So, the idea would be to record:
  • What the current practice or activity is,
  • The nature of the improvement (not the detail of the "solution"),
  • The area of interest, e.g. test, programming, verification, etc. (I'm not sure about this - maybe we don't need it, but my initial feeling was that it might with identifying subsets that share perspectives),
  • Whether it is a "core" item for SJTAG or a "stretch goal" (probably something we decide in committee).
I think this would be the basis of the table we discussed during the Feb 24 meeting. I had hoped to try and start on this over the weekend, but time ran away from me again :roll: .
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Ian McIntosh
SJTAG Chair
Posts: 395
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo MW Ltd, UK
Contact:

Re: PAR scope and direction

Post by Ian McIntosh » Tue Mar 08, 2016 6:59 pm

Value-add suggestions...

Current Practice: Trying to include testing of COTS boards requires board vendor to expose IP.
Value Add: Define portable data set that permits at least go/nogo testing of third party items - permits easier integration of COTS items and avoidance of NDA negotiations.

Current Practice: Inter-board testing often requires hand linking of netlists to each other or to the motherboard.
Value Add: Recommend that "system" designs are captured in ECAD data (designer behavioural change). Simplified generation of board-board test, improved portability.

I found this to be really difficult to do. Some of the things I wanted to suggest suddenly seemed like they belonged elsewhere, e.g. they were something that needed ECAD tools to change first.
Last edited by Ian McIntosh on Wed Mar 09, 2016 3:44 pm, edited 1 time in total.
Reason: Amended to show "value" more explicitly.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 94
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Post by Bradford Van Treuren » Wed Mar 09, 2016 1:33 pm

To address value add examples requested during the last meeting, I discussed the expansion of the Programming aspect/perspective that Ian identified. The notion of Programming ends up being a very generalized term with quite a large variation of meaning and intent. I pointed out that the purpose and scope of the term "Programming" is really based, not only on the type of target, but is also based on the environment. Ian described the scenario of programming in the factory versus programming in the field with a system installed in an aircraft. I noted that board level programming may actually require different tooling than what is used at other aspects of programming the same target in other situations (e.g., shelf programming, installation upgrades, field upgrades). At the board level programming, this is usually accomplished by an external tester. For field updates, this may use an embedded controller to perform the operations instead. Field updates may required an external controller connected to a system with the "covers on" access providing a very different access link to the board level JTAG chain (e.g., via a multi-drop or a proxy interface). So the model of the system would be very different based on the environment of the test. This is true for programming of FLASH, CPLDs, EEPROMs, etc. The value add is the ability to update the product in-place without requiring the product to be returned to the factory for the upgrade. With an embedded controller, the upgrade may be performed remotely while the board is still installed in the system.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 94
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Post by Bradford Van Treuren » Wed Mar 09, 2016 2:25 pm

I see Ian has a good format in his posts. So here is another value add using his format.
Current Practice: The coordination of tests using instrumentation (e.g. SERDES BERT) requires coordination of instrument configuration. If a loopback path is required on the far end, that needs to be established first. Then the parameters for the instrument providing the source data needs to be provided. The coordination of the Tx side and the Rx side needs to be synchronized for data collection to ensure the values observed are aligned with the data sent. Currently, there is no standard way of performing this coordination. So it is left as a task for the implementer to hand craft to perform these types of testing. Some tool vendors are starting to provide the instrument access, but the coordination is still a task performed by the implementer. What complicates this process is that instruments are controlled by sometimes different hardware interfaces (e.g., I2C, SPI, IEEE 1149.1-2013, IEEE 1687, IEEE1500). So it requires different applications/sequences from the current tool sets.
Value Add: SJTAG may be the solution to the coordination of commanding the diverse interface space of instrument interfaces. It may be able to provide a common method for coordinating these instrument commands and responses through an abstraction of the interface to the instrument. The difficulty comes in that standards like IEEE 1687 and IEEE 1149.1-2013 tend to rely on a retargeter that exists above this access link interface to provide a global vector for the entire model space. Without understanding the topology and architecture of the board and system level, I don't see how this retargeter may be used for complex architectures like described here. This requires a different execution model from the global vector execution model as used by tools today.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Ian McIntosh
SJTAG Chair
Posts: 395
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo MW Ltd, UK
Contact:

Re: PAR scope and direction

Post by Ian McIntosh » Wed Mar 09, 2016 3:53 pm

Bradford Van Treuren wrote:At the board level programming, this is usually accomplished by an external tester. For field updates, this may use an embedded controller to perform the operations instead. Field updates may required an external controller connected to a system with the "covers on" access providing a very different access link to the board level JTAG chain (e.g., via a multi-drop or a proxy interface).
This touches on something that was going through my mind but seems difficult to express in the Current Practice/Value Add format: The system needs to be designed to support these post-manufacture operations. It's one thing to design a board that supports addressability and chain management, but that does not guarantee that it can be successfully reprogrammed (or even tested) once installed in a system (e.g. on a multidrop bus) as other factors can affect performance: Motherboard signal integrity, loading from other boards on the bus, sub-optimal termination of signals (possibly also variable depending on rack population).
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

Post Reply