Slidepack for 1687.1

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

Slidepack for 1687.1

Post by Ian McIntosh » Tue Oct 20, 2015 6:36 pm

Michele distributed the slidepack Al Crouch presented at ITC to group members on October 19th.

I wasn’t sure about how best to handle them: I could put them on the website for ease of reference, but I don’t how “private” or privileged the slides are.

Use this thread to discuss the slides.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Michele
SJTAG Established Member
Posts: 31
Joined: Wed Nov 11, 2009 8:39 am
Location: Grenoble, France

Re: Slidepack for 1687.1

Post by Michele » Tue Oct 20, 2015 6:38 pm

I wouldn't know about publishing them on the website or forum, but Al explicitly authorized me to share them with the group, that is why I used the internal mailing list.

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

Re: Slidepack for 1687.1

Post by Bradford Van Treuren » Tue Oct 20, 2015 6:39 pm

I find it interesting and amusing to see on slide 4 the bubble about retargetting: 1) Model Access Network in ICL, 2) Vectors in PDL.
Because of the use of ICL specifically being used as the "separation of concerns" (software philosophy term) to provide the Access Link modeling separate from the DataLink application, they have created a separate modeling aspect just to deal with the "Access" description to the TDR. What is amusing is PDL is just dealing with vectors. I think that is too simplistic of a descriptions of PDL from what the standard states, but is interesting that one of the officers simplifies its purpose to just applying vectors. Maybe it is true for PDL Level 0, but not PDL Level 1. We, in SJTAG, know there has to be behavioral descriptions in "PDL" that define the intent of the instrumentation when used to represent a down stream access link and insights into the coordination aspect with other instrumentation "vectors." PDL cannot be just a programmatic representation of vectors. We have SVF and STAPL for that and these are insufficient in the 1687 domain. PDL appears to be insufficient for the SJTAG domain where we need to interact with changing the state and intent of the "AccessLink". By separating these two dependent domains into two separate languages may make the integration of SJTAG impossible to implement with using the 1687 strategy.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Michele
SJTAG Established Member
Posts: 31
Joined: Wed Nov 11, 2009 8:39 am
Location: Grenoble, France

Re: Slidepack for 1687.1

Post by Michele » Tue Oct 20, 2015 6:39 pm

I recently went through the 1687 draft about PDL, and I realized that it is much more tied to vectors than we realized in the WG. PDL 1 just adds some primitives to help interfacing with TCL,but nothing more. Moreover, during this ITC, PDL was always called up exclusively for applying vectors and there was absolutely no talk about doing anything different. I do not recall anyone, for instance, talking about PDL-1 based TCL script execution.

My impression in looking at the slide deck (especially slides 15 to 18 ) is that what Al is aiming at is giving an ICL description of the AccessLink making the protocol conversion . But that would mean having to make a structural description, and hope the CAD tools will be able to extrapolate the behaviour from it .... when I see my Verification colleagues struggling in extracting behaviour from gate-level netlists, I wonder how difficult this will be!

And this is how I came to my proposal of having a fully functional description of AccessInterfaces as I wrote in the forums: the role of the AI is to translate a register-level vector (i.e. the value of each bit in a scan chain) into a series of operations (SDR,SIR, etc..), and I honestly don't see how you could make it in ICL/PDL.

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

Re: Slidepack for 1687.1

Post by Bradford Van Treuren » Tue Oct 20, 2015 6:43 pm

I see what you are observing about slides 15 to 18. I also agree with your point in your last paragraph. Another aspect that I was thinking about this weekend after reading about some new features available in OpenOCD 0.9.0 and the frustration I have with validating an instrument design, moreover the validation of the access link, is the ability to support the integration with simulation environments to be able to use the testing tools from manufacturing as a test engine for a design concept. I have had to create my own tooling to translate SVF and STAPL files into the simulation TestBench vectors to be able to do complex validation test cases. I am unable to deal with they dynamic cases being limited to SVF and STAPL out of the tools. I remember Ken Posse talking about the same issue in Avago and Jeff in AMD. Both 1149.1-2013 and 1687 fail to provide the kind of support necessary for automated TestBenches to aid in the validation of an instrument and its access link during design and validation. ICL and PDL are clearly targeting the post-implementation aspect of the product life cycle. People are needing to create their own ad hoc tooling to aid in design verification and validation still. The section in OpenOCD that caught my eye is:
Interface Driver: remote_bitbang

Drive JTAG from a remote process. This sets up a UNIX or TCP socket connection with a remote process and sends ASCII encoded bitbang requests to that process instead of directly driving JTAG.
The remote_bitbang driver is useful for debugging software running on processors which are being simulated.
Config Command: remote_bitbang_port number
Specifies the TCP port of the remote process to connect to or 0 to use UNIX sockets instead of TCP.
Config Command: remote_bitbang_host hostname
Specifies the hostname of the remote process to connect to using TCP, or the name of the UNIX socket to use if remote_bitbang_port is 0.
For example, to connect remotely via TCP to the host foobar you might have something like:

Code: Select all

interface remote_bitbang
remote_bitbang_port 3335
remote_bitbang_host foobar
To connect to another process running locally via UNIX sockets with socket named mysocket:

Code: Select all

interface remote_bitbang
remote_bitbang_port 0
remote_bitbang_host mysocket
They clearly are thinking about the ARM simulation and validation process with this interface. It provides the simple JTAG interface signal patterns required to be applied to the access link interface of the DAP. Quite elegant and similar to what everyone else does in an ad hoc manner for their own validation. SJTAG needs to think about whether we can provide such an interface to support simulation efforts for proving in access link and data link designs.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

Post Reply