IEEE 1532 Meeting - February 20-21, 2001

Back to Minutes page
Back to IEEE 1532 home page


Attendees

The following individuals attended the meeting:

   Neil Jacobson, Xilinx, chairperson
   Ken Parker, Agilent
   Brad Ishihara, Altera
   Sanjeev Sharma, Altera
   Howard Tang, Lattice
   Dave Bonnet, ASSET, vice-chairman
   Dan Gravitz, ASSET
   Mark Moyer, Lattice
   Jack Griffin, Cypress
   Doug Way, Alcatel
   Ray Dellecker, JTAG Technologies, interim secretary

Minutes

    Meeting of the IEEE 1532 Work Group
    Feb. 20-21, 2001, at Altera, San Jose, CA

Status

  1. Everyone on the WG should have received a copy of 1532, but many haven’t. Neil will take care of this. It’s available on the IEEE website, hardcopy or pdf.
  2. Demo boards from Alan Hermann should be avail 3/7 and will be mailed to the attendees. Lattice, Altera, and Xilinx parts are on-board, and a footprint is provided for Cypress. A spec will be provided and files from the vendors. Boards can be connected in series. (More discussion on this board later in the meeting.)
  3. Software from Xilinx (J-Drive) source is avail now on their website or from Neil. He will also put in on the reflector. This version of J-Drive complies with previous revision of the BSDL. Next rev will correspond to the latest version of the BSDL. Anyone can use it for free, as long as the Xilinx name remains in the code. Neil reported recent success in running some of their own devices concurrently and observed performance improvement (37 sec for 5 in a row, vs 20 sec concurrently.) It looks ahead and stores in a temporary file—but doesn’t look forward through the entire job.

BSDL Discussion Points:

  1. Extensive discussion of topic raised by Wim Driesen related to the capture field and definition of which data goes to the output stream when using the ! operator. Wim provided 40 examples. TDO = 1010, EXPECT = 1001, XMASK = 1101. Here is the resulting interpretation of these examples, plus some additional ones, new ones shown in bold.
    14:Shift 4 bits out, does no compare, no CRC
    24::CRCThe 4 bits “A” come in on TDO, shift 4 bits out and add to CRC
    34:*$XMASKShift out 4 bits, mask against XMASK, no compare, no CRC (allowed by the syntax but not logical)
    44:*$XMASK:CRCShift out 4 bits, mask them with XMASK, the value 8 = A&D goes to CRC
    54:*$XMASK?!Read XMASK from input, write XMASK (= “D”) to output, shift out 4 bits, mask them with XMASK, no compare, no CRC
    64:*$XMASK?!:CRCRead XMASK from input, write XMASK (= “D”) to output, shift out 4 bits, mask them with XMASK, no compare, “8” = A&D goes to CRC
    74:*!$XMASKWrite masked raw data to output (8 = A&D), default “expected” value is all 0’s
    84:*!$XMASK:CRCWrite masked raw data to output (8 = A&D), default “expected” value is all 0’s, 8 to CRC
    94:*!$XMASK?!Read XMASK from input, write XMASK to output, write masked raw data to output (8=A&D), default expected value is all 0’s
    104:*!$XMASK?!:CRCRead XMASK from input, write XMASK to output, write masked raw data to output (8=A&D), default expected value is all 0’s, 8 = A&D to CRC
    114:!Write raw TDO (A) to output
    124:!:CRCWrite raw TDO (A) to output, A to CRC
    134:!*$XMASKWrite raw TDO (A) to output, mask data with XMASK, ignore result
    13a4:!*$XMASK + 2Write raw TDO (A) to output, increment XMASK by 2 (this operation can’t be optimized out because it affects future XMASK value), mask data with XMASK, ignore result
    144:!*$XMASK:CRCWrite raw TDO (A) to output, mask data with XMASK, ignore result, send 8 to the CRC
    154:!*$XMASK?!Read XMASK from input, write raw TDO to output (A), write XMASK (D) to output, mask data with XMASK but ignore result
    164:!*$XMASK?!:CRCRead XMASK from input, write raw TDO to output (A), write XMASK (D) to output, mask data with XMASK but ignore result, 8 (=A&D) to CRC
    174:!*!$XMASKWrite raw TDO (A) to output, write masked TDO (8=A&D) to output
    184:!*!$XMASK:CRCWrite raw TDO (A) to output, write masked TDO (8=A&D) to output, 8 to CRC
    194:!*!$XMASK?!Read XMASK from input, write raw TDO (A) to output, write masked TDO (8=A&D) to output, write XMASK to output (D)
    204:!*!$XMASK?!:CRCRead XMASK from input, write raw TDO (A) to output, write masked TDO (8=A&D) to output, write XMASK to output (D), 8 to CRC
    214:$EXPECTTest A against 9, fails
    224:$EXPECT:CRCTest A against 9, 3 (= A^9) to CRC
    234:$EXPECT*$XMASKTest (A ^ 9)&D, fails
    244:$EXPECT*$XMASK:CRCTest (A ^ 9)&D, fails, 1 (=A^9)&D to CRC
    254:$EXPECT*$XMASK?!Read XMASK from input, test (A ^ 9)&D, fails, write XMASK (D) to output
    264:$EXPECT*$XMASK?!:CRCRead XMASK from input, test (A ^ 9)&D, fails, write XMASK (D) to output,1 (=A^9)&D to CRC
    274:$EXPECT*!$XMASKWrite masked TDO (1 (=A^9)&D) to output, test (A^9)&D, fails
    284:$EXPECT*!$XMASK:CRCWrite masked TDO (1 (=A^9)&D) to output, test (A^9)&D, fails, (1 (=A^9)&D) to CRC
    294:$EXPECT*!$XMASK?!Read XMASK from input, write masked compared TDO (1=(A ^ 9)&D) to output, write XMASK (D) to output, test (A^9)&D, fails
    304:$EXPECT*!$XMASK?!:CRCRead XMASK from input, write masked compared TDO (1=(A ^ 9)&D) to output, write XMASK (D) to output, test (A^9)&D, fails, 1=(A^9)&D to CRC
    314:$EXPECT?!Read EXPECT from input, test TDO (A) against EXPECT (9), fails, write 9 to output
    324:$EXPECT?!:CRCRead EXPECT from input, test TDO (A) against EXPECT (9), fails, write 9 to output, 3 = A^9 to CRC
    334:$EXPECT?!*$XMASKRead EXPECT from input, write EXPECT (9) to output, test (A^9)&D, fails
    344:$EXPECT?!*$XMASK:CRCRead EXPECT from input, write EXPECT (9) to output, test (A^9)&D, fails, 1=(A^9)&D to CRC
    354:$EXPECT?!*$XMASK?!Read EXPECT from input, read XMASK from input, write EXPECT (9) to output, write XMASK (D) to output, test (A^9)&D, fails
    364:$EXPECT?!*$XMASK?!:CRCRead EXPECT from input, read XMASK from input, write EXPECT (9) to output, write XMASK (D) to output, test (A^9)&D, fails, 1=(A^9)&D to CRC
    374:$EXPECT?!*!$XMASKRead EXPECT from input, write EXPECT (9) to output, write masked compared TDO (1=(A^9)&D) to output, test (A^9)&D, fails
    384:$EXPECT?!*!$XMASK:CRCRead EXPECT from input, write EXPECT (9) to output, write masked compared TDO (1=(A^9)&D) to output, test (A^9)&D, fails, 1 = (A^9)&D to CRC
    394:$EXPECT?!*!$XMASK?!Read EXPECT from input, read XMASK from input, write EXPECT (9) to output, write XMASK (D) to output, write masked compared TDO (1=(A^9)&D) to output, test (A^9)&D, fails
    404:$EXPECT?!*!$XMASK?!:CRCRead EXPECT from input, read XMASK from input, write EXPECT (9) to output, write XMASK (D) to output, write masked compared TDO (1=(A^9)&D) to output, test (A^9)&D, fails, 1 = (A^9)&D to CRC
    414:!$EXPECT?!*!$XMASK?!:CRCRead EXPECT from input, read XMASK from input, write raw TDO to output (A), write EXPECT (9) to output, write XMASK (D) to output, write masked compared TDO (1=(A^9)&D) to output, write XMASK (D) to output, test (A^9)&D, fails, 1 = (A^9)&D to CRC
    424:!?!*!?!:CRCRead expected data from input, read ask data from input, write raw TDO to output (A), write expected data (9) to output, write masked compared TDO (1=(A^9)&D) to output, write mask data (D) to output, test (A^9)&D, fails, 1 = (A^9)&D to CRC
    434:!$EXPECT+2!*!$XMASK>>1!:CRCAdd 2 to EXPECT (B=9+2) from input, shift XMASK right 1 (6=D>>1), write raw TDO to output (A), write new EXPECT (B) to output, write masked compared TDO (0=(A^B)&6) to output, write new XMASK (6) to output, test (A^B)&6, passes, 0 = (A^B)&6 to CRC
    444:!2!*!C!:CRCWrite raw TDO to output (A), write expected data (2) to output, write masked compared TDO (0=(A^2)&C) to output, write mask data (C) to output, test (A^2)&C, passes, 0 = (A^2)&C to CRC

    Additional rule: Only explicitly do a compare when a compare value is given, and the same with mask. If there is no expected data, it can’t fail. Multiple bangs result in comma-delimited data written out. (Decimal when it’s an operand, else hex.) The examples shown in the table will result in some syntax changes in Capture Field.

    A logical flow was drawn to illustrate where we want to be able to capture date, and Ken prepared a modified syntax based on this discussion.

  2. Issue raised by Howard Tang concerning JEDEC-style pre-load and functional vectors: In the past, there has been a provision for a vector record to tell how to test a device in isolation, such as a functional test, and also an ability to set up a preloaded value. Do we want to put these items in the ISC data file? For functional tests that test inward to the part, this would require INTEST. At present, the BSDL provides the ability to set values and clamp, but without keywords for this specific function. Do we need to provide specific keywords? The system-level tool needs to provide the system-level initialization and control, but adding the device-level procedure provides a known way to put the device into a safe state.

    This would be a procedure called proc_preload. Would be used for devices that have CLAMP-like behavior, and if used, must be called before ISC is enabled. Recommended that this procedure be associated with ?, and it would be optional. A different preload could be used while in ISC mode, to provide sequencing as multiple parts begin to become operational. We are adding the keyword PRELOAD as a standard data name.

  3. Section 5.1.1.2 Fixed system pins are those whose characteristics aren’t affected by programming. There is nothing in the BSDL to document these pins. Suggestion is to add attribute ISC_Fixed_System_Pins to Section 8. Required if a device has this type of pin.

    Attribute ISC_Fixed_System_Pins of PLD: entity is <fixed pin string>;
    <fixed pin string> ::= “<fixed pin list>”
    <fixed pin list> ::=<fixed pin>{, <fixed pin>}
    <fixed pin> ::= <port ID> | <port name>

    Refer to Fig 14. If the fixed pins don’t have ISC behavior, when the device is in ISC mode the fixed pins behave as though they are in bypass. Anything that’s not a fixed pin is treated as an ISC pin.

Review of the previously modified sections:

3.1.39 Using 2001 as the expected release date.

8.5.5.2 Allow other mechanism other than an unprocessed tag. Change “immediately” to “subsequently” for data following the ?! operators.

8.5.6.1 Two new mandatory procs:
     proc_error_exit
     and proc_program_done
must be supported by the tool. Try to concurrentize proc_done in all devices. In case of error, the process can either exit (in every device) or continue without programming the done bit. (Further discussed later in the meeting during BSDL review)

Add security example to proc_program.

8.5.7.2 Add HIGHZ and CLAMP to the instructions that other devices should be executing when another device is executing a proprietary instruction.

Allow either sequence, programming of security before or after programming of ISC_program_done.

A tool should not execute proprietary instructions, but this is not a rule.

Discussion of Next Steps > Ballot process begins with forming the ballot group, based on suggestions from the WG and the IEEE. There were 30 on the ballot last time. All have to be members of the IEEE Standards Association. Looking for a balance between vendors and users. 40-45 days after start to have an approved ballot group. > Letter will go out from Neil directing the ballot group to go the IEEE website and read the draft standard, and to make comments and cast their ballot there. Site stays live for 30 days. We will send out the hardware section (already standardized) and the new software section. 80% of the participants have to return ballots. Of the 80%, for approval must have 75% in favor. WG must respond to all of the comments and decide whether and how to respond to them. If there are significant changes, a re-ballot is customary. 10-30 day review period. > WG should submit names for candidates for this upcoming ballot. Neil will send out a list of who was on the hardware ballot. > Remaining action needed prior to ballot (with approximate dates):

Allowing time for going out for re-ballot, our target is to present 1532 for approval at the December 2001 meeting of the IEEE RevCom.

Next WG meeting, May 7 at Xilinx.

Discussion on new Demo Board:

Brad described the board that Altera is developing. Purpose is to assist tools vendors in development of multi-vendor concurrent programming (Altera, Lattice, Xilinx, Cypress). Can chain boards together but require individual power sources. Toggles allow devices to be switched out. 6 devices, 5 of them with a 7-segment display. Three of the devices are 1532 compliant, and 3 are 1532 compatible. All can be concurrently programmed, and also one of the Xilinx devices can be programmed from a Xilinx PROM (no LED display). TAP is a 10-pin header. 6-12 volt power jack creates two dc levels on the board, 2.5 and 3.3. Activity LEDs on-board for TDI, TDO, TMS, and TCK.

BSDL Review:

Based on files from Altera, Lattice, and Xilinx. Further discussion on how to handle error in any device during concurrent ISC. The tool user interface could allow:


Back to Minutes page
Back to IEEE P1532 home page