Minutes of Weekly Meeting, 2017-05-01

Meeting called to order: 11:04 AM EDT

1. Roll Call

Ian McIntosh
Brian Erickson
Heiko Ehrenberg
Brad Van Treuren
Carl Walker

By Proxy:
---

Excused:
Bill Eklow
Peter Horwood

2. Review and approve previous minutes:

  • Approval of April 24 minutes (updated draft circulated on 04/27/2017)
    • In the post meeting note, change "toprovide" to "to provide".
    • Brad moved to approve as amended, seconded by Heiko. No objections or abstentions.

3. Review old action items

  • All: do we feel SJTAG is requiring a new test language to obtain the information needed for diagnostics or is STAPL/SVF sufficient? See also Gunnar's presentation, in particular the new information he'd be looking for in a test language (http://files.sjtag.org/Ericsson-Nov2006/STAPL-Ideas.pdf)
  • Ian: Add the previously discussed lists to the 'master' template. Ongoing.
    • Some sections need further expansion that may take time to develop.
  • Brad: Draft up block diagrams for next meeting. COMPLETE

4. Reminders

  • Consider Adam's three points (from the action from the first weekly meeting) and suggest what is preventing us from answering those questions:
    • Establish consensus on goals and constraints
    • What are we trying to achieve?
    • What restrictions are we faced with?
  • Forum thread for discussion: http://forums.sjtag.org/viewtopic.php?f=3&t=172
  • Possible invitation for Al Crouch to talk about Parallel SIBs.
  • Python Netlists (SKIDL) suggested by Brad for discussion.

5. Discussion Topics

a. Building Blocks - Use Case of a simple Interconnect Test - Continued, Block Diagrams.

  • Brad had drafted diagrams, as requested, which Ian had tidied a little {shared}.
  • Brad remarked that preparing these diagrams raised a number of points. As drawn, there is no way to control the pins or set directionality; registers are strictly input or strictly output. At some point it will be necessary to consider devices that have both inputs and outputs.
  • Page 2 - 1149.1 using custom TDR:
    • The left device is strictly output, and a separate instruction is applied to enable access to the TDR.
    • An assumption here is that if the device is in Run Test Idle then the output pins are being driven.
    • The right hand device is strictly input and is capturing from the input pins.
  • Page 3 - I2C:
    • Addition of an I2C slave interface.
    • Ian commented that the thin orange lines connecting the yellow boxes should be removed (hangover from the 1149.1 diagram, also on SPI diagram).
    • If control bits were added, they could either be in a different register or as an extension of the single register shown. This could be down to the device design and may be a problem.
    • Ian commented that if multiple-byte fields are used or multiple registers then there may need to be a "data valid" type of signal to latch the registers to the IO.  Brad replied that the acknowledge cycle at the end of the data transfer ought to do that.
  • Page 4 - SPI:
    • Broadly the same as the I2C case, although the interface signals are different.
  • Brad removed the spurious orange lines and will post the diagrams as PDFs on the File Manager.
  • Ian felt the next step was to walk through an interconnect test in each of the cases to contrast and compare. Brad asked if a counting or walking 1 pattern was preferable. Walking 1 was selected, although Ian noted that the choice of vectors was maybe not all that important.
  • Brad proposed to capture the steps using a domain specific language (DSL) in a text file {blank file opened}.
  • Steps for applied instructions/vectors for each of the 1149.1, I2C and SPI cases were created, referring to the LH device as "ICL" and the RH device as "ICR".
  • Brad remarked that for SPI, the device selection was by the CS0 and CS1 lines, so replaced "ICL" and "ICR" with these in the pseudo code.  Following up on this, Ian noted that address inputs were missing from the I2C diagram. Brad added these as ADDRL and ADDRR and substituted these labels for "ICL" and "ICR" in the pseudo code.
  • Ian observed that for I2C, the address was part of the serial data stream, but for SPI, the CS lines needed to be controlled "elsewhere" - it was something that the SPI host controller needed to know about.
  • The updated diagrams are available at this link: http://files.sjtag.org/Brad/SimpleModel_Inter_IMM_20170501.pdf
  • The DSL pseudo code developed today is available at this link: http://files.sjtag.org/Brad/Example%20DSL%20of%20Models_20170501.txt

6. Topic for next meeting

  • Building Blocks - Use Case of a simple Interconnect Test - continuation.
    • Pick over the pseudo code written today to consider what it implies for tooling.

7. Key Takeaway for today's meeting

  • None.

8. Glossary terms from this meeting

  • Carried over:
    • Definition of "interchangeability" required.
    • 'Instance' (or a more specific version of the term) may require definition in future.
    • 'Master through Slave Mode'
    • 'Master to Master Mode'
    • Need a refined definition of "system" for the purposes of the PAR.
    • 'Priority' - may relate to 'frequency' and 'urgency' in distinct definitions.

9. Schedule next meeting

  • Next meeting May 8. Carl and Heiko expect to be out.
  • May schedule:
    • 15, 22, 29.
    • May 29 is Memorial Day in the US and a UK holiday.

10. Any other business

  • Ian hopes Michele will be able to provide a fuller report on the TESTA tutorial in due course.

11. Review new action items

  • None.

12. Adjourn

  • Brian moved to adjourn, seconded by Carl.
  • Meeting adjourned at 11:55 AM EDT

Respectfully submitted,
Ian McIntosh