UML modeling for SJTAG?

Discuss the generic proposals for SJTAG
Post Reply
User avatar
Michele
SJTAG Established Member
Posts: 31
Joined: Wed Nov 11, 2009 8:39 am
Location: Grenoble, France

UML modeling for SJTAG?

Post by Michele » Wed May 27, 2015 6:37 pm

I know this is a little bit off the current topic, but I have been thinking a lot about the EISA paper Brad shared some time ago, and how we could apply the same modelling to SJTAG to express a variable open architecture through some clear basic bricks. Object-Oriented is IMHO the best way to go thanks to its flexibility and expandability, and if we can express the concept in UML, it then becomes easy to translate it in one language (NSDL? SystemC) and/or exchange format (XML?).

So I tried my hand on this, but with two reserves:
- I never wrote any real UML before, so I do not assure it is 100% formal and correct;
- I based the analysis on my engine, so I used some of my own terminology (ex: crossroad).

These are the main ideas I tried to put down:
  • at the TDR level, I defined an abstract "pull" method for I/O, which is responsible for reading/writing to the register. The method would be
    instantiated by an Access Interface, most typically becoming a JTAG CSU cycle. I believe this should be modelled by an UML "interface", but I
    did not get that far yet.
  • Instruments would have some abstract methods to implement (ex: "init" or "status"). I still have not decided if they should rather be independent nodes connected to one or more TDR (the "Raw instrument" of 1687) or a derivation of the TDR node with added functionalities
  • for dynamic topologies, I use what I call "crossroad nodes", which contains a set of methods to manipulate, configure and query them. The idea is that any given arbitrary dynamic elements behaviour should be described through these primitives (a little bit like any algorithm can be executed through some basic assembler instructions), which can be freely overloaded by the instrument provider. I showed some examples of this in slides 2-3-4
  • to allow for complex behaviour, I added some methods for "preconditioning" and "postconditioning", with an example of their usage in slide 5. The idea is it allow for configuration operations to be performed before and/or after the main data cycle.
  • in an OO world, users could freely add methods and attributes to cater for their own needs, without breaking standard compliance. For instance in my implementation I use some tables and flags to help SIB and MIB methods, but which are not part of the basic primitive set.
A big absent is the JTAG TAP: I hesitate between giving it a special status or express it as a crossroad. I believe the former would better suit the "UML Interface" concept, but I have not set my mind yet. It also depends on how the implementation of the abstract "pull" method is actually done....

So, any thoughts about this direction?
Attachments
SJTAG-UML.pptx
(94.67 KiB) Downloaded 49 times

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

Re: UML modeling for SJTAG?

Post by Ian McIntosh » Wed May 27, 2015 6:38 pm

Thanks for this Michele.

My UML is very rusty so I'm not about to criticise your use of it. I think UML is likely to be the best modelling tool available to us for this, but I'm not sure how many in the group are familiar enough with it to read the diagrams readily (I think I'd need to brush up a bit as my OO background goes back to Rumbaugh and Jacobsen and UML was just appearing as I moved out of that area).

When you refer to the "JTAG TAP" in your last comment, do you mean the TAP Controller on a device, the JTAG Host TAP or something else?
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: UML modeling for SJTAG?

Post by Michele » Wed May 27, 2015 6:39 pm

As we are all rusty, we can help each other out!

A good remark: in my modelling I only consider the device, so it would be a TAP controller on the SUT, either the top-level or in a combination (ex: eTAP or after a BS Linker). I believe that we can make good progress without having to go into details about the host itself: this UML modelling would eventually be translated into the Circuit Model, but not directly influence the host controller which would use it.

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

Re: UML modeling for SJTAG?

Post by Ian McIntosh » Wed May 27, 2015 6:40 pm

I used to have a UML manual on my desk (not anymore), but I think it was v1.00 and still had Booch's "fluffy clouds".
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

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

Re: UML modeling for SJTAG?

Post by Bradford Van Treuren » Wed May 27, 2015 6:40 pm

Michele,
I am probably the least rusty with UML, albeit I have not kept up to date recently. I knew Rumbaugh and Jacobsen when I was quite involved with the OOPSLA conferences in the 1990s. I knew Grady Booch best as he was a class mate and squadron mate of my brother while at the US Air Force Acadamy (class of '77). All these guys used to participate in the "think tank" workshops Tom O'Rourke and I used to host at OOPSLA each year.

One of the things I am observing from your UML diagrams is some fundamental issues that you may wish to revisit. The most powerful feature of OO is its ability to perform abstraction of the problem domain and hide the complexity of the implementation using various tools. One such tool is delegation. What I am observing in your interfaces/methods is the explicit use of the bit_vector type as the argument type for the methods. A bit_vector may not really be the correct fit for all interfaces. Case in point is I see you having cast arguments with the to_binary() method in order to create the correct format. That casting should be a warning flag that the interface needs to be revisited. Step back and look at the bigger picture. We are needing to describe behavior. The details of how that behavior is ultimately implemented is delegated to the instance/derivation and not specified in the interface abstraction. There are some cases where a bit_vector is relevant. For example, the data being sent to a TDR (a DataLink abstraction). It is not necessarily relevant for the crossroad selection (an AccessLink abstraction). That is a behavioral method that will take on different implementation details depending on how the derivation is designed. These are the concrete crossroad details and not the abstract behavioral concept.

Yes, UML is able to describe the SJTAG model, but its limitation comes in needing to explicitly define the various behaviors as methods or parameters. It requires the SJTAG model to explicitly define and apply names to the different behavioral aspects of the model. I am not convinced it is the best tool for describing something that has constraints on that interface implementation depending on the design. For example, a crossroad may have the constraint that only one of its many sub-chains may be connected at a time. While another crossroad may have one or more sub-chains connected at a time. The notations in UML describe each case differently in their relationships. So it is impossible to reuse the same method for the two very different relationships for an interface. I have been struggling with this limitation of UML for years with regard to the SJTAG modeling. It is almost there, but not quite. This is why I liked the notion of NSDL in that only relevant interfaces were specified that could be common for all instances (e.g., the scan interface of the TDR). UML forces you to define more than you need in order to generate code from it. The workaround in UML is to use special design patterns, like the command pattern, to provide the a standard method for performing this kind of multifaceted behavior to UML notations. It is indirectly hiding the relationship behind a dynamic plug-in module using a common interface while leaving it open-ended in UML.

More specific feedback: for your select(integer) and deselect(integer) how do you interpret the argument for a BSCAN2 crossroad compared to the TI ICEPick? BSCAN2 allows one or more chains to be selected at a single time. The ICEPick allows only one sub-chain at a time. These are the kind of constraints I am talking about. The argument can't be the port number (what OpenOCD uses to select the ICEPick chain) as the BSCAN2 allows more than one port at a time. The argument can't be a bit field of port states as one could give an invalid value to ICEPick and a crossroad may have more than 32 ports in the future if the integer is implemented using 32 bits. I think you are getting my message.
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: UML modeling for SJTAG?

Post by Michele » Wed May 27, 2015 6:41 pm

Brad,

thanks for the feedback: I will need some time to digest all of it, but there are some things I can directly answer:

- the way I see it, UML can be a good tool for our discussion and for sketching out ideas in a common format between us. It is also a good way to find points in need of generalisation (like you did for the bit_format). At one point in time we will have to decide to either put the effort for a real UML specification or to drop it and move to a specific language. Personally I see UML as a good starting point for specification, not as a final deliverable.
- the formalisation of delegations is one of the points I struggle most, and as you point out one of the key ones!
- I am not familiar with the ICEPick, but I looked at the issue of multiple/single ports for MIBs and BSCAN2. Rather than being explicitly put as an attribute (but it could be), I see it as implicit in the "select/deselect" method pair and in the "is_active" query. So, when the crossroad only allows for mutually exclusive paths, selecting path "n" automatically deselect the other ones, while if multiple-choice a path remains active as long as it is not explicitly deselected. In my engine I have the two types of MIBs: the only difference is in the realisation of the two methods, everything else is the same. And as the configuration routines have only the right to cal the exported methods as in the UML, they become immediately able to use the multiple paths. The BSCAN2 follows the same script: "select/deselect" and "is_active" act on the internal representation of the I2C register (not depicted in the UML), so that multiple-path selection is possible. The JTAG TAP does the same, but the internal value is the Instruction Register, and "select/deselect" allow only for one path at a time.

This is what I means by "minimum primitive set" to describe the dynamic behaviour. It is exactly what we started doing with NSDL, but with an higher abstraction that we were not able to achieve as VHDL is not OO.

User avatar
Peter.Horwood
SJTAG Member
Posts: 10
Joined: Fri Nov 16, 2007 9:24 am
Location: Firecron Limited, UK
Contact:

Re: UML modeling for SJTAG?

Post by Peter.Horwood » Wed May 27, 2015 6:41 pm

For SJTAG to be vendor independant the UML should be capable of supporting "ALL" GATEWAY type devices, as each vendor has its own feature set an some devices are much more capable than others

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

Re: UML modeling for SJTAG?

Post by Michele » Wed May 27, 2015 6:42 pm

That is really a key point, I completely agree. SJTAG must be as inclusive as possible, but this can be achieved only if we can extract the common features (i.e. what I call primitives) that can describe any given gateway.

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

Re: UML modeling for SJTAG?

Post by Bradford Van Treuren » Wed May 27, 2015 6:43 pm

Hi Peter,
I think the point Michele was making is that there needs to be a standard core or minimal set that all GATEWAY devices support and using an OO model allows for extensibility of an interface to add the extensions to a defined GATEWAY for the features that are outside of the standard set. That is what the derivation is able to provide. So I think Michele's proposal handles your concern. Keep in mind this is a notation to capture our discussions and concerns and to let us identify interfaces that do not allow for generalization.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Peter.Horwood
SJTAG Member
Posts: 10
Joined: Fri Nov 16, 2007 9:24 am
Location: Firecron Limited, UK
Contact:

Re: UML modeling for SJTAG?

Post by Peter.Horwood » Wed May 27, 2015 6:44 pm

So the common features could be broken down into two very simple cases

The min. functions that any GATEWAY should support in a Multi Drop type system are :
Addressability
Chain selection

Whilst in a NON Multi Drop type system you can argue that you do not need the Addressability, so you would only need the :
Chain selection.(However you can use the Multi Drop type device in a system that does not require the feature.... to enable a common software interface.)

Then the question would be how to pass this information that does not preclude the use of any device type and also include the feature sets of the devices.

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

Re: UML modeling for SJTAG?

Post by Ian McIntosh » Mon Jun 01, 2015 4:10 pm

This may be a kind of dumb suggestion, but if we're concerned about the ability to represent certain "system" aspects in UML would SysML be any better? My UML may be sketchy, but my knowledge of SysML is even more so.
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: UML modeling for SJTAG?

Post by Michele » Mon Jun 01, 2015 7:21 pm

Ian, I don't believe that UML is really the way to go standard-wise: it is too much alien to the test community we target, and if we end up with something too software it won't be understood, and remain unused. UML is a great work tool, we can decide about a language form once we have fleshed out all the details.
Personally I am starting to look at SystemC : it has all the feature needed to describe complex systems, and it might be interesting to open a bridge to the validation phase of ICs....
Last edited by Michele on Mon Jun 01, 2015 7:43 pm, edited 1 time in total.

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

Re: UML modeling for SJTAG?

Post by Ian McIntosh » Mon Jun 01, 2015 8:35 pm

Michele wrote:Ian, I don't believe that UML is really the way to go standard-wise: it is too much alien to the test community we target, and if we end up with something too software it won't be understood, and remain unused.
I'd generally agree, and UML is probably sufficiently alien to enough to those in the group to cause us a learning curve. On the other hand, it might be appropriate for describing the model to the S/W engineers who have to produce the supporting tooling. As far as SystemC is concerned, then I'm in the dark - Never had cause to use it.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

Post Reply