Print

Minutes of Weekly Meeting, 2010-02-08

SJTAG conference call:
Monday, February 8, 2010 at 10:30 AM EST (15:30 GMT)

Called to order:
10:35am EST

1. Roll Call

present: Heiko Ehrenberg
Patrick Au
Eric Cormack
Adam Ley
Brian Erickson
Brad Van Treuren
Carl Walker
Tim Pender (joined 10:43am EST)

excused absence:
Ian McIntosh

2. Review and approve previous minutes:

3. Review old action items

4. Discussion Topics

    1. How to progess revision of Volume 3
      • Brad combed past meeting minutes and provided the following summary {presented online during the meeting}:
      • [Brad] spent some time doing some data mining out of the 2009-12-07 and 2009-12-14 meeting minutes to glean as much information as I could from our previous discussion on Volume 3 {Brad continued to go through the following notes}:
        • Volume 3 may better address System Architectures rather than just Hardware Architectures. Hardware Architectures are really a subset of System Architectures.
        • A given System Architecture may actually consist of a set of sub-System Architectures, each of which could function independently for the purpose of testing
        • There are specific roles identified in a System Architecture that may exist on many different planes of the architecture that are may not be specifically spelled out in the CAD data
        • Assembly Manager (e.g., System Manager, Board Manager, Shelf Manager, Power Manager)
        • Chain Linking Fabric
        • Scan Chain(s)
        • Logical Connectivity Element(s)
        • Primary TAP(s)
        • Secondary TAP(s)
        • Addressing (Some control over chain selection)
        • Single Scan Chain
        • Multiple Chains describing the connection state as either on or off
        • Multiple Chains describing the connection state as one of the 1149.1 stable states or TMS held value
        • Interconnections (e.g., backplanes, cable assemblies, parent/child mating connectors, board traces, jumper blocks)
        • Signal Interconnections
        • TAP Interconnections
        • Power Interconnections
        • Test Registers (e.g., Test Data Registers, Test Instruction Registers)
        • Test Managers
        • JTAG operates as part of a bigger picture when embedded in the architecture where its scope is defined by the use case(s) of operation
        • The system software (embedded control system) uses message passing to interact with the JTAG process/activity
        • The extent of the message passing resulting from the JTAG activity is dependent on the scope of the use case(s) implemented
        • Current JTAG Tooling is unable to integrate with this embedded control system
        • Leads to inability to control some Chain Linking Fabric implementations
        • Requires coordination of JTAG Tooling with embedded control system state
        • Coordination of tooling may not be the right approach as the tooling can’t be expected to do all things for everyone (Are there a set of "hooks" that could be defined allowing event coordination – concurrency controls?)
        • Clouds/interfaces identified
        • System/Board Boundary
        • Board/Device Boundary
        • Device/Instrument Boundary
      • [Brad] I would suggest we spend our time today looking at the board architectural level and define the building blocks that are used to test a board today – first from an external tester and then from an embedded tester.
      • [Heiko] are you referring to device types on a board or more a scan chain architecture?
      • [Brad] more the latter
      • [Heiko] so, like a connector and/or test points needed to access the scan chain from an external tester (there needs to be some way for an external tester to connect to the unit being tested)
      • [Eric] are we talking about single chain or multi-drop?
      • [Brad] all of the above
      • [Carl] so, it could be one or multiple chains; One or more TAP interfaces arranged in some form of hierarchy
      • [Brad] Let's take the simple case of a single chain first.
         
      • [Adam] there may be elements required to satisfy device enable conditions, provision clock buffering or clock tree, perhaps provide some sort of identity module that is unambiguous, directly accessible, and it might be carried forward at the system level
      • [Carl] Even at the daughter board level this is important
         
      • [Tim] there may be some "hidden" (not well documented) requirements to enable certain types of tests; even requirements related to the order of tests or ability to run certain tests under certain conditions; Regarding DDR testing, there is something that has to be set up or required to make the device testable - control of the clock for example. These may be some kind of a compliance issue. I have a case where the flash has to be programmed before the DDR can be tested.
      • [Brad] This may be some sort of a dependency rather than a compliance
      • [Eric] I have seen this before
      • [Tim] Ideally, it would be nice to have something like this in the BSDL
      • [Brad] It looks like you are describing a set of dependencies or a set of states that must exist in a set of devices that are required to be able to test another device
      • [Tim] Yes
      • [Brad] BSDL really doesn't cover the scope of dependencies between devices. That is something that is missing in the current description mechanisms.
      • [Brad] What else is required to exist when testing a board?
      • [Brad] I know we have bypass mechanisms in place for parts that are new and not yet proven in to work with JTAG.
      • [Heiko] I've seen the same; means to isolate certain parts of a chain or a whole chain;
      • [Tim] We partition devices in a separate chain. The NIOS emulator, for example, requires the FPGA to be the first device in a chain.
      • [Tim] Is there a need to know whether a device requires a TRST?
         
      • [Eric] that's described in the BSDL
      • [Brad] I think Tim is getting at some non-compliance issues that may require a /TRST to be toggled at least once, where a TAP Controller reset sequence (TCK/TMS controlled) is not sufficient; (The point Tim is making is whether the TRST MUST be strobed in order for the device to work properly. A soft TAP reset may not be enough on its own. This might be a compliance issue.)
      • [Adam] it is debatable if that is actually a non-compliance; if /TRST is provided, it is expected to be strobed before the device can be used for JTAG, even before the device is used at all; but there should be no requirement to toggle /TRST again afterwards (while the device is powered up); a TRST pin available means you must strobe it at least once in the power up sequence to get a sane chain;
      • [Heiko] a decision to implement one or multiple chains on a board is an architectural decision (a decision must be made at the board level on whether one or more scan chains are going to be needed to perform an operation); and anything required to block and enable access to scan chain(s) on the board are architectural elements related to the scan chains
      • [Tim] Brad, you were talking about preserving the TMS state. Do you need to preserve more of the TAP signals? Many of the automation tools embed reset operations in their algorithms that may cause problems for sub chains.
      • [Brad] The point about holding only TMS constant by many of the gateway and linker devices is the fact that TMS is required to transition between states in the TAP state machine. So if the TMS is held constant, the software is able to remember what state it was last parked in. So the other signals are not really necessary. The only way you could get a state transition while TMS is held constant is if the TRST is strobed on the secondary chain.
         
      • [Heiko] so, how can we move this discussion into chapter 3 of the White Paper? What is it we are looking to put into the document from this discussion?
      • [Brad] well, we need to get our hands around what "board architecture" is from a test point of view; then we can create block diagrams and move those into the white paper; I am looking for a block diagram of what it takes to do a test of a board.
      • [Heiko] another requirement is to be able to power up the board by itself in order to be tested
      • [Tim] Many times you need to control the power sequencer to be able to power up a board.
      • [Tim] You also need the proper temination of pull-ups and pull-downs to get a board configured properly.
         
      • [Heiko] It is 15 after the hour. I think we should table this discussion and move on to the next agenda item as time is running out for today's call.
      • ... discussion to be continued on Forum and next week ...

 

  1. 2009 Survey
    • Revisit tabulated results for 3.7 and 3.8
    • 3.7: no detailed discussion
    • 3.8: the concern is that there seem to be no automated ways for creating mapping files for merging system modules (several CAD files) which would preserve the relationship of those modules; simply merging nets together may result in lost information (e.g. net names change with the merging process, as a result the pinpointing of faults in PCB layout based on the original CAD files may become impossible; multiple boards of the same type in the system add to the degree of difficulty)
       
    • Review of submissions from Q6.8 onwards
    • ... postponed to next week ...

5. Schedule next meeting

February 15

6. Any other business

suggestions for upcoming Newsletter:

7. Review new action items

8. Adjourn

move to adjourn: Eric
second: Brian