Defining what we mean by "Configuration"

Discussion and feedback on the SJTAG Initiative Group weekly meetings.
User avatar
Ian McIntosh
SJTAG Chair
Posts: 495
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK

Defining what we mean by "Configuration"

Post by Ian McIntosh »

Follow up from the discussion of August 31, 2009.

The word "configuration" was giving us a problem in our discussion of the Device Versioning Use Case, mainly because the word can mean different things to people and can depend on the context, e.g configuration control of firmware, configuration of an FPGA, configuration of boards in a system, etc. We all seemed to feel we knew what we meant; we could visualise it, but couldn't find an unabiguous way to express it in a few words.

Brad suggested that an illustration might work better than words.

Other single words that may each capture part of our intent include: architecture, arrangement, composition, content, construction, form, organisation, revision and structure. Some possibly less helpful ideas might be: anatomy, constitution, disposition, grouping, makeup. Add to those, things like build standard or design standard.

I'm playing a thesaurus game here, because I don't think a single word will do the job; we may find that using different words as we bore down through the hierarchy will get the idea across more clearly. Something like:
Configuration in this case means the arrangement of boards/modules/FRUs within a system, the composition and build standard of those boards and the revision of any firmware they may contain.


Please criticise and improve :D
Ian McIntosh
Testability Lead
Leonardo UK
User avatar
Peter.Horwood
SJTAG Member
Posts: 10
Joined: Fri Nov 16, 2007 9:24 am
Location: Digital Development Consultants, UK

Re: Defining what we mean by "Configuration"

Post by Peter.Horwood »

Ian McIntosh wrote:I don't think I've really captured device identification.
I understand device identification is missing but post was covering devices versioning and configuration which I do think you worded well.

How about....

Configuration in this case means the arrangement of boards/modules/FRUs within a system, the composition and build standard and verification of those boards and the revision of any firmware they may contain.

Best regards

Peter
User avatar
BrianE
SJTAG Member
Posts: 1
Joined: Mon Apr 27, 2009 1:51 pm
Location: JTAG Technologies, USA

Re: Defining what we mean by "Configuration"

Post by BrianE »

What about using the term "structure" of the system? It denotes physical form and we can expand the term to include firmware. I guess that I am still hung up on "configuration"... probably too long at Brand X.

Best regards,
Brian
User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 152
Joined: Fri Nov 16, 2007 2:06 pm
Location: VT Enterprises Consulting Services, USA

Re: Defining what we mean by "Configuration"

Post by Bradford Van Treuren »

After I have been thinking about this for a while, it seems to me that we are trying to shoehorn a multidimensional problem space into a single term. I believe this is why we are having such a difficult time in drafting a single sentence to define what we mean by "Configuration". For a system, we look at its configuration based on multiple things. First, we look at its structure: what boards are installed where and what mezzanine cards are installed in them. This is an ordered set of boards where the boards may be identical, but the function is also determined by where it is located (e.g., standby or active). The order might also be determined by the boot order over time with the system controller (ATCA model). Second, we look at the boards themself. There is a structure associated with each board which could be defined as a different art master/layout of the board, a different ordered set of mezzanine card assemblies, different firmware programmed into programmable devices (e.g., Serial Rapid IO vs. PCI Express vs. GigE, or even how the mezzanine cards are stitched together). This structure is defined in different terms from what we view at the system level and yet it relates to the overall structure of the system. Third, the structure is determined by the bill of materials used to assemble the boards. In some cases a different brand of device might have been substituted during assembly which technically constitutes a different structure because for boundary-scan, the IDCODE is probably different. So we have a structure that is defined by the PCB/PWB layout and still more structure defined by what is defined in the devices assembled to the PCB/PWB. The latter point is what gets nasty as a problem domain, because our industry had developed multiple technologies or ways to define behavior within a device. There are programmable logic devices of many different technologies (persistent vs. non-persistent, etc.). There are tunable logic devices (registers define the parameters of operation). There are also devices that adapt the path through the logic dynamically based on the data being sent through it (e.g., ATM switch, SRIO switch, PCIe switch). Likewise, each device may have different structures associated within it. There are different brands of parts for the same functionality or nearly the same functionality (the test logic may differ). There are different versions of devices available just as there are different versions of boards. There are also different versions/revisions of firmware that gets programmed into programmable devices. Each of these differences may and usually do impact the operation of the board.

The Device Versioning Use Case was developed originally for the ability to discover the IDCODE of all the devices assembled on the board in order to validate that the order and type of devices assembled on the board were indeed what was expected to be there. This ordered set of defined devices might have an impact on what software must be installed on a board. This was true for one case where the CM installed a substitute part that ended up missing a special hardware feature that only existed in the original brand hardware. Thus, those boards with the substituted part required a software patch to perform an emulation of the missing hardware feature.

Device Versioning is really not just limited to a single type of operation (the reading of IDCODE values), but is useful for reading any information from a device that allows one to determine the structure. This also includes reading information indirectly using boundary-scan signals as the access point to the data (e.g., reading FLASH data by stimulating the address and control lines from boundary-scan).

Regarding the current tooling and the Device Versioning Use Case, not a lot of support is possible. The tooling today usually bases a scan operation validation on some precomputed/deterministic golden value that is compared with to provide a GO/NOGO identification. The ideal tooling would allow one to read this data from a register or pseudo register in a signal space and use the value to condition the flow of control through the test program that is responsible for the validation operation - what ever that might be. This need brings this use case into more alignment with what the P1687 and instrumentation domain use cases require.

To summarize, I don't think we can define "configuration" as a single term in a tidy single sentence given the scope crosses a multidimensional domain of uses. I think it is better served to define the meaning for the respective domains. I have tried to do this with possibly many gaps still in the framework of explaination. I claim our difficulty in nailing down a single definition is a testament to this fact that we are dealing with more than one domain.
Last edited by Ian McIntosh on Tue Sep 15, 2009 6:35 am, edited 1 time in total.
Reason: Adjust layout
Bradford Van Treuren
Distinguished Member of Technical Staff
VT Enterprises Consulting Services
User avatar
Ian McIntosh
SJTAG Chair
Posts: 495
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo, UK

Re: Defining what we mean by "Configuration"

Post by Ian McIntosh »

Bradford Van Treuren wrote:The Device Versioning Use Case was developed originally for the ability to discover the IDCODE of all the devices assembled on the board in order to validate that the order and type of devices assembled on the board were indeed what was expected to be there. This ordered set of defined devices might have an impact on what software must be installed on a board.
That description better matches the title of the Use Case than I think our current perception of the Use Case does. So, are we trying to stretch the Use Case to fit too many things? Narrowing the scope would help us to define what we mean but would that mean we miss opportunities?

My first thought is that we don't want to narrow the scope, but we may be able to use some of Brad's words to more explicitly describe our Application Fields. If we do that properly then it may take away the whole need to explain "configuration".
Ian McIntosh
Testability Lead
Leonardo UK