Chain Segments

[Bradford Van Treuren]

I wanted to throw out an idea for people to debate whether it is a good idea or not or even if it is plausible.

While looking at the bubble diagram of the data architecture, I was noticing we have simplified the original UML diagram into a generalized "Assembly" model to represent element types within the SJTAG domain. Thus, an AssemblyDescription represents the data model that describes a specific element in the domain.

What I wanted to discuss was whether we could generalized the smallest JTAG element as a "ChainSegment". By this I am referring to an object representation of the smallest scannable unit in an abstract form that could define the interface functions required for all scan operations throughout the system domain. Thus, a "Register" is really a ChainSegment. A device is really a ChainSegment with dynamically selected ChainSegments (e.g., IR or multiple DRs). An instrumented device (P1687 device) could be represented as a collection of ordered ChainSegments whose length is the aggregate of all the segments and is dynamically selected as to which aggregate path using the device DR selection method. A board is again a ChainSegment with dynamically selected ChainSegments (e.g., multiple secondary paths), where these paths are a collection of ordered ChainSegments. A system is like a board.

This is similar to what HSDL describes as STATIC_PATH, DYNAMIC_PATH, and EXTERNAL_PATH, but there is no behavioral interface defined in HSDL other than connectivity. For DYNAMIC_PATH, there is a notion of selectable options, but no definition of how that selection is performed (left as an exercise for the implementer). Further, these are 3 distinct elements within HSDL that don't seem to share the same actions that may be applied to them in the language, but instead provide an association for external languages to understand the connectivity of the current JTAG chain. This is a good thing, but seems to be missing the point of the commonality amongst these types of paths.

Is there also a way to be able to leverage this partitioning to delegate the scan operations to the constituent parts instead of at the global vector space?

[Ian McIntosh]

This triggers a number of thoughts, that are kind of shooting off in all directions...

• The chain segment concept (if we think about it as an OO class with "attributes" and "operations") probably addresses the point raised by Peter at the meeting a couple of weeks ago of being able to readily get access to the data associated with a specific device for debugging, etc.
• We probably don't want to require an additional layer of vendor supplied device description above the BSDL - I'd expect that to meet resistance from the device vendors - but the chain segments ought to be readily derivable from the BSDL anyway.
• Arguably, given the above, this is a "tooling issue" and just down to internal representation of the BSDL. But if SJTAG can produce a good "model" of a system description that tool vendors can work from, them tool behaviour should be more consistent across vendors. This is probably a separate discussion, but it does seem to raise a question of where the standardisable interface lies.
• Brad's proposal means we build device descriptions (for scannable devices at least) from the bottom up, as aggregations of chain segements. I guess this may give us a route to the abstract description of an OEM board used within a system.

See also this post on Non-BSCAN devices.

[Ian McIntosh]

Following on from discussions in the March 2nd meeting, I've very quickly pulled together a couple of diagrams. The first represents our initial view of a various device types being described by a single generalised interface:

Single Interface

This second diagram attempts to illustrate my perception that separate interfaces are required for the "functional" and "scannable" usages of a device:

Dual Interface