IEEE P1532 Meeting - March 8-9, 1999 - AMD

Back to Minutes page
Back to IEEE P1532 home page

Attendees

The following individuals attended the meeting: 

Neil Jacobson
Dave Bonnett
Alan Herrmann
Bradley Ishihara
Ken Parker
Howard Tang
David Thompson
Mark Moyer
Tapan J. Chakraborty(Thursday Only)
Kurt Guntheroth
Arthur Khu
Ted Eaton

Minutes

   IEEE P1532 Working Group
   Minutes of meeting at Altera
   May 20th and 21st

Ken Parker was again thanked for his extensive work on the draft.

Action Item: Neil Jacobson

Neil will invite the 1149.1 and 1149.4 working groups to review the current standard.

Tapan brought forth a concern that the result from loading the ISC_ACCESS instruction while in ISC_COMPLETE was not clearly defined. Figure 3 indicates that this will bring the state machine into operational mode.

It was noted that this has come up several times in the past. The group decided to address this concern with the addition of a timing diagram showing the transition sequence following the update of the ISC_ACCESS instruction while in the ISC_COMPLETE modal state.

Action Item(s): Ken Parker

  1. Ken will add a timing diagram to illustrate the transition sequence following the execution of the ISC_ACCESS instruction while in the ISC_COMPLETE modal state.
  2. Text will be added to clarify that I/O behavior changes at update I/R while modal state transitions may happen a finite period of time following update I/R
  3. The dotted line indicating the possible transition from Test Mode to ISC_COMPLETE will be removed from Figure 3.

Discussion on Section 5:

Changes: Ken Parker

  1. Section 5.16 Title will be changed to Mandatory Instructions from IEEE Std. 1149.1-1993
  2. Section 5.1.8.1 Second Sentence will be removed.
  3. Section 5.1.9 A note will be added to indicate that status in only updated while in RTI
  4. Execute will be added to the definitions section. To execute an ISC instruction is to spend time in RTI
  5. Load will be added to the definitions and will be defined to be synonymous with update.

Action Item(s): Ken Parker

  1. Ken will determine the proper format for the glossary
  2. Ken will investigate and potentially add wording describing how and when status is updated.

    Motion: Status Bits

    A status capture of 01 in the LSB of the status register indicates success for all instructions.
    A status capture of 10 in the LSB of the status register indicates fail for all instructions.

    Motion By: Kurt Guntheroth
    Second By: Mark Moyer
    Carried: 9-1-0

    Motion: Bit Fields

    Bit 0 and 1 are general pass and fail bits.
    Bit 2 optional interleaved complete bit.
    Additional bits may be added for Error sub-codes.

    Motion By: Mark Moyer
    Second By: Kurt Guntheroth
    Carried: 10-0-0

    The group had some further discussion centering on the enumeration of the optional Sub-Code status field.

    Motion: Status Sub-Code Enumeration

    A BSDL extension will be added to indicate both user defined failure status as well as several defined failure mechanisms including but not limited to Duration_Error and Security_Error.

    Motion By: Alan Herrmann
    Second By: Kurt Guntheroth
    Carried: 9-0-0

    It was then noted that Kurt had nothing further to say. ve

    Text Changes: Ken Parker

    1. The word "optional" will be removed from the last sentence on page 56.
    2. Section 6.4.1 ISC_DISABLE_PROGRAM should not be all caps.
    3. Note 3 and possibly section 5.1.10.2 will be rewritten to indicate that Isc_Disable_Program is an internal chip signal.
    4. Rule (d) will be changed to indicate that a program security violation may be indicated in a status sub-code.
    5. 6.2.3.2 will be re-written to remove the idea that data is captured back in the ISC_Pdata register.
    6. 6.4.1.2 Sentence #1 the word programmed should be changed to programming.
    7. 6.4.2.1.a Changed to reflect that ISC_PROGRAM_STOP may only be implemented if ISC_PROGRAM_START is implemented.
    8. Add the limitation that only allowed 1149.1 instructions and ISC_NOOP may be loaded following an ISC_PROGRAM_START and prior to an ISC_PROGRAM_STOP.
    9. The following ideas will be added as rules in section 6.4
      (a) only allowed 1149.1 instructions and ISC_NOOP may be loaded following an ISC_PROGRAM_START and prior to an ISC_PROGRAM_STOP
      (b) ISC_PROGRAM_START and ISC_PROGRAM_STOP must be added as pairs
    10. A recommendation will be added to 6.4 that ISC_DISABLE should include the ISC_PROGRAM_STOP functionality.
    11. 6.4.2.1 Add a note that it is an error to execute the ISC_PROGRAM_STOP instruction prior to the expiration of the specified burn time. It is also an error to execute an ISC_PROGRAM_STOP instruction without first executing an ISC_PROGRAM_START instruction.
    12. ISC_PROGRAM_STOP does not need to return security violation information
    13. 6.4.2.1 Rules (c),(d),(e),(f) and notes are to be removed.

    Action Item: Ken Parker

    Ken will add an extension to figure 5 to indicate the transitions following the displacement of the ISC_DISABLE instruction with the ISC_ENABLE instruction.

    Motion: Register Association

    All Instructions be assigned a unique DR register name. A general permission be granted to allow alias(ing) registers to one another. When no register is required the bypass (or NOOP if status is implemented) register may be targeted.

    Motion By: Kurt Guntheroth
    Second By: Dave Bonnett
    Carried 6-0-2

    Motion: Minutes from Previous Meeting

    Minutes from previous meeting be approved.

    Motion By: Mark Moyer
    Second By: Dave Bonnett
    Carried: 8-0-0

    Considerable discussion was centered on the possible addition of instructions to support programming a set of predefined special purpose bits. It was noted that we already allow direct access to the done and security bits.

    Kurt suggested the possible addition of general-purpose auxiliary program instruction that would replace any and all individual bit programming instructions.

    The discussion was tabled until a later date. The noted points of contention include:

    1. Do ISC_PROGRAM_DONE and ISC_PROGRAM_SECURITY need to be specifically defined or may we use the auxiliary instruction?
    2. Do we need an ISC_PROGRAM_AUXILARY set of instructions or should we just attempt to define all special purpose bit fields?
    3. Would the Auxiliary instruction be a full featured program instruction or a simplified version?
    4. Do we need the Architecture shift instruction
    5. Do we need a program usercode instruction

    Action Item: Howard Tang

    Howard will put together a description for the use of Architecture Shift as well as program usercode.

    Section 8.3.2.3

    How does sector security work and how do we describe this in BSDL. -> Tabled waiting for a champion.

    Text Changes: Ken Parker

    Pg. 82. 8.3.2.5 The word can in the second sentence should be may?

    The rest of the discussion centered around BSDL and how much or how little is needed to be defined in the language and how little or how much could be included in the data file.

    Ken Parker proposed the addition of a file format that would minimize file size and BSDL information.

    The basic file format is described below via example.

    Fully instantiated file: 

    PATTERN X
[16:0000]
[16: 0001, 22: F2AB0
16: 0002, 22: F2374
16: F001, 22:77777
...
]
[16: FFFF, 3:1 ]
Same File Compressed.
PATTERN X
[16:0000]
[16: ++, 22: F2AB0
,: F2374
: F001, :77777
...
]
[16: FFFF, 3:1 ]

    The data compression is realized with a set of basic operators and through the grouping of fields.

    Basic Operators:

    ++ add 1
    -- Subtract 1
    += add X
    +- Subtract X
    ~ complement
    >> << shift left or right.

    1. Data and Address identification.

    Action Item: Ken Parker

    Ken will add the file format description to the document.

    NOTE: Please suggest names for addition to the balloting group.

    Back to Minutes page
    Back to IEEE P1532 home page