Back to Minutes page
Back to IEEE P1532 home page
Neil Jacobson - Xilinx Kurt Guntheroth - Data I/O Howard Tang - Lattice Dave Thompson - Lattice Alan Herrmann - Altera Ken Parker - HP Sung Chung - Cisco Mark Moyer - Vantis Brad Ishihara - Altera
IEEE P1532 Working Group Minutes of meeting at Xilinx, San Jose CA March 8, 1999 10:00 AM
Agenda:
Howard Tang - Lattice Proposal on Operation Modes Kurt Guntheroth - Data I/O Issues and Suggestions
In preparation for Howard's presentation, Neil reviewed section 4 with figures 2-4 showing system modes and modal states. Alan brought up the issue of I/O noise during programming. Ken drew distinction between "internal" spinning plates (using TAP of all devices) and "external" spinning plates (using I/O pins to program non-ISC devices concurrently with ISC devices). Ken cited rule 10.3.1 (d) from 1149.1 - no limit shall be imposed on the number of output pins that may change state in a single update-DR (etc.) state. (This rule is new in 1149.1a -1993 - it was not in the 1990 version.) Sung believes that in spite of this rule, it is wise to limit the number of signals switching. Sung mentioned that today's vector generation tools do not automatically provide this feature. Ken gave an example where a board failed during boundary-scan testing due to ground-bounce. The system was poorly designed. Testing during programming could fail the same way in a poorly-designed system. Ken also described a case where a board is being tested during programming and the test reveals a short-circuit, causing excessive current to flow on the board. The resulting noise could cause programming to fail. Ken suggested that we should recommend that boards should be tested before programming is attempted.
Much discussion on Howard's state diagram (p.8 - Proposed Operation Modes). Howard agreed to add "extra" states to manage the ISC_DISABLE transition. With that addition, most attendees agreed that Howard's diagram is "isomorphic" with the diagrams in the P1532 draft, with the possible exception of TLR. The diagrams in the P1532 draft give better guidance to I/O behavior - Howard's diagram doesn't show I/O behavior clearly. The P1532 diagram needs to be modified to show that ISP_DISABLE always transitions to the ISC Complete modal state, then either to Operational mode or Unprogrammed mode, based on the state of ISC_DONE.
<lunch break>
Neil suggested that we try to get closure on the issues raised in Howard's presentation. Howard reviewed the concluding page of his presentation, including the suggestion to add a capture-IR bit showing the state of the internal ISC_ENABLED bit. Mark argued that this is not needed, because the test system will know whether the ISC_ENABLE instruction was issued. Kurt and Brad agreed. Ken suggested that Howard discuss with David Rutledge whether Lattice's proposal is different in a functional way from the current description in the draft, or whether it is only a different representation of the same functionality. Howard agreed, but wanted to pursue the operation of TLR today. Mark and Neil pointed out that we had that discussion at a previous meeting and agreed on the behavior of TLR.
Ken suggested the concept of ISC-prohibited instructions, which "pop" the device out of ISP mode if they are used. This is suggested on page 32, in 5.2 permission (q) which permits some non-ISP instructions to have the side-effect of clearing the ISC_ENABLED signal. Kurt complained that this would greatly complicate generation of vectors for external concurrent programming. Ken asked rhetorically whether test is needed during programming, and whether future technologies will make it easier or more difficult to support. Permission (q) gives relief for vendors who cannot support test during programming, while providing for the default case where test is fully supported during programming. BSDL will document which instructions are forbidden during programming. Kurt argues that it will be very difficult for tools to successfully make use of that information. Customers will demand the capability for full concurrent programming of external devices with ISC devices. The important element of permission (q) is for the BSDL notation to inhibit the use of forbidden test instructions during programming, rather than describing the behavior if the forbidden instructions are used.
Kurt suggested adding a rule in place of permission (q). Neil wrote out the following: "If there are illegal instruction sequences, they need to be defined in BSDL. The behavior of the device when such instruction transitions are executed is undefined." Ken agreed to add this. Sung pointed out that this implies that 1149.1 instructions might not work after the illegal sequence occurred. Kurt called this the "escape clause" for vendors that don't provide any support for test-during -programming (or external spinning plates).
Review of Kurt's suggested changes:
p.21 - The designer of a particular ISC device… we accepted changes, with edit "A particular ISC device…"
p.32 - Permission 5.2 (q)… moot because deleted.
p.35 - Rule 6.1.1.c - Ken agreed to modify section 6.2.1.2 on p.40. Loading PRELOAD will change the pin behavior. The data values driven through the system pins are determined by the state of the boundary-scan register.
p.36 - Rule 6.1.1.e - If an ISC instruction is used improperly (ISC_ENABLED = 0) should I/O behavior be determined by the instruction or by the system modal state, or should it be undefined? Ken argues that this reduces the "failure space". Alan argued that the standard should not define the result of taking an illegal instruction sequence. The I/O behavior is influenced by the system modal state and by the current instruction (if it is a test instruction). Kurt described a situation where a device emulates the specified behavior without implementing an ISC_Enabled bit in hardware, but on deeper investigation he found that the ISC_Enabled bit is required so that 1149.1 system-mode instruction can implement the desired I/O behavior in ISC mode. Mark argued that the silicon implementation should be left as flexible as possible. Ken said that he is willing to demote the rule to a recommendation.
Kurt pointed out an inconsistency on p.36 rule 6.1.1 clause (c) says that ISC instructions have CLAMP behavior, but clause (e) says that non-test instructions have system-mode behavior. Neil asked, should system-mode instructions (such as USERCODE) preserve CLAMP behavior in ISC mode? After much discussion, we agreed that when ISC_Enabled is true, non-test 1149.1 instructions will have CLAMP behavior if ISC instructions have CLAMP behavior, and will have HI-Z behavior if ISC instructions have HI-Z behavior.
p.26 Rule 5.1.3 Additional Pins - we added permission for the state of the additional pins to modify the timing of ISC programming, but not the flow. This permits faster programming with external high-voltage supply.
p.37 permission (j) Maximum programming time - we need a way for the component vendor to specify absolute maximum RTI burn times for each ISC instruction.
p.49 6.3.2 ISC_ERASE - if the device does not support status, but does support erase security, there may be no way to check that the device is erased. What is the behavior of the ISC_Done bit when erase security is enabled? Can the ISC_ERASE_DONE instruction erase the ISC_Done bit? We agreed that the erase security bit should inhibit the action of the ISC_ERASE_DONE instruction.
p.31 rule 5.2 (d) is too strict. We need to allow ISC_Done to be protected by erase security.
IEEE P1532 Working Group Minutes of meeting at Xilinx, San Jose CA March 9, 1999 9:00 AM
Attendees:
Neil Jacobson - Xilinx Kurt Guntheroth - Data I/O Howard Tang - Lattice Dave Thompson - Lattice Alan Herrmann - Altera Ken Parker - HP Sung Chung - Cisco Mark Moyer - Vantis Brad Ishihara - Altera
Agenda:
Review Section 4 - System Modal States
Kurt Guntheroth - Data I/O Proposal for Concurrent Programming ("spinning plates")
Neil began by reading the introduction to section 4. Kurt asked, is it the instruction that determines the I/O behavior, or is it the current system modal state? It seems to be both. 1149.1 test-mode instructions always control the pins, but 1149.1 system-mode instructions do something different in ISC Accessed mode than in "normal" system mode. Alan drew a table:
Instruction Type Test Operational Unprogrammed ISC Accessed or ISC Complete 1149.1 Test BSR X X X 1149.1 System X Mission HI-Z HI-Z or CLAMP ISC X Mission(?) HI-Z(?) HI-Z or CLAMP
Ken argued that for consistency, the system modal state alone should determine the I/O behavior, and therefore the standard should specify that nullified ISC instructions have the behavior shown above (i.e. remove the question marks in the table). Kurt agreed, but brought up issue of the ISC_ENABLE instruction, which causes the transition into ISC Accessed mode. Does the I/O behavior change upon update-IR, or on the Nth clock cycle in the RUN-TEST/IDLE state? Kurt suggested that the I/O behavior should change immediately on update-IR, and if ISC_ENABLE fails, the system modal state would still remain ISC Accessed, but the error condition would be available in the status register. This is similar to RUNBIST. Ken drew a table (UIR means the Update-IR TAP state):
Instruction I/O State Test Unprogrammed ISC Accessed ISC Complete Operational ISC_ENABLE X CLAMP @UIR CLAMP @UIR CLAMP @UIR CLAMP @UIR ISC_* X CLAMP @UIR CLAMP @UIR CLAMP @UIR CLAMP @UIR ISC_DIABLE X CLAMP @UIR CLAMP @UIR CLAMP @UIR CLAMP @UIR BYPASS X HIZ @UIR CLAMP @UIR Mission @UIR Mission @UIR IDCODE X HIZ @UIR CLAMP @UIR Mission @UIR Mission @UIR EXTEST EXTEST @UIR X X X X
This implies that the consistent behavior for nullified ISC instructions is CLAMP. The interesting cases where the instruction code does not clearly indicate the system modal state is (1) nullified ISC instructions, and (2) system instructions like BYPASS, IDCODE and USERCODE which may be used in the ISC Accessed system modal state.
Brad presented a hand-written foil showing the next state for each state transition. The columns represent the previous state, and the table entries show the next state that will be active after Update-IR.
Instruction Test Unprogrammed ISC Accessed ISC Complete Operational ISC_ENABLE Accessed Accessed Accessed Accessed Accessed ISC_* Oper/Unprog Unprogrammed Accessed Oper/Unprog Operational ISC_DIABLE Oper/Unprog Unprogrammed Complete Complete Operational BYPASS Oper/Unprog Unprogrammed Accessed Oper/Unprog Operational IDCODE Oper/Unprog Unprogrammed Accessed Oper/Unprog Operational USERCODE Oper/Unprog Unprogrammed Accessed Oper/Unprog Operational EXTEST Test Test Test Test Test INTEST Test Test Test Test Test
We agreed that the I/O behavior should change upon Update-IR, not at a later time (Nth clock in RTI). Even if ISC_ENABLE can fail, the device should go to ISC Accessed mode immediately. A status register can indicate the error. If the current system modal state determines the I/O behavior, then these transitions must be synchronized to Update-IR.
Ken is concerned that if the state transitions are synchronized by Update-IR, then the success of ISC_ENABLE is not required in order to enter the ISC Accessed system modal state. Ken pointed out that it is equivalent to say that I/O behavior depends on system modal state synchronized to Update-IR, or that I/O behavior depends on the current instruction plus the state of the ISC_DONE, ISC_ENABLED, and ISC_COMPLETE signals. Since these signals cannot change while an instruction is active that has I/O behavior that depends on those signals, the two descriptions are equivalent even if the signals themselves are not synchronized to Update-IR. To declare that the ISC_ENABLED signal is updated immediately on Update-IR would force changes elsewhere in the draft. Mark recommended making the changes anyway because it is a clearer description of the behavior.
Kurt asked, if ISC_DISABLE is displaced by ISC_ENABLE, does the system modal state become ISC Accessed? Ken argued that the state would be Operational or Unprogrammed for a short time, then would pass into ISC Accessed when the ISC_ENABLED signal becomes true, before the next Update-IR. Brad voiced the concern that lacking the explicit transition arc from ISC Complete to ISC Accessed for the ISC_ENABLE instruction, readers might assume that the ISC_ENABLE instruction would be nullified if immediately follows ISC_DISABLE.
Ken recommended that system modal state transitions not be synchronized to Update-IR, but be driven by other events that affect the signals ISC_DONE, ISC_ENABLED, and ISC_COMPLETE. The I/O behavior should then be described as a function of the current instruction and the current system modal state (or equivalently, the states of the ISC_DONE, ISC_ENABLED, and ISC_COMPLETE signals), rather than solely as a function of the current system modal state. Changes in I/O behavior are still synchronized to Update-IR. Brad pointed out that this constitutes an asynchronous state machine, and an asynchronous state machine is more difficult to define precisely than a synchronous state machine.
<lunch>
Sung Chung left the meeting at noon.
Kurt presented his proposal for spinning plates. Neil commented that he is uncomfortable with having a specific burn-time that is considered "long". That number will evolve through time. Also he would prefer to have a definition that has more similarity to the non-spinning-plates scheme, more as an extension than as a dissimilar alternative scheme. Alan suggested a "stealth" spinning plates scheme where a device programs in RTI with self-timed internal circuitry, but if it leaves RTI it would still continue to program until it is done. Mark expressed concern over the silicon overhead for this if it becomes a mandatory feature of the standard, and also the possibility that a device would see excessive programming time. There are three possible implementation schemes:
(1) apply "start" instruction, apply "continue" instruction to continue, anything else to stop
(2) apply "start" instruction, any instruction to continue, apply "stop" instruction to stop
(3) apply "start" instruction, any instruction to continue, device stops by itself, read status register to see whether the operation is still running or has completed.
The third option requires internal self-timed circuits. The "continue" instruction can target the status register.
Kurt argued that the ISC_PROGRAM instruction can work in the conventional way or can function as the "start" instruction. The termination of the programming cycle would not occur upon leaving RTI, but upon Update-IR of an instruction that is not ISC_PROGRAM. Brad pointed out that this will not work if the part has auto-increment and the ISC_PROGRAM instruction is only loaded once. Mark suggested a new "start" and "continue" instructions to support this mode. Kurt lamented that if new optional instructions are needed, vendors will not implement it, and the spinning plates feature will not be supported. Alan pointed out that customers care about total programming time, and semiconductor vendors will optimize the programming time in the ways that seem most appropriate, and spinning plates does not seem like the most effective way to optimize programming time. As technology evolves and programming times decline, the potential benefit for spinning plates becomes less compelling. A typical board has four to ten 1149.1 devices in a chain. The cost of programming the programmable devices in two sets, the short-pulse devices together and the long-pulse devices together, is less on bigger boards that would normally program the devices in multiple blocks anyway.
Lacking a consensus to make spinning plates a required feature, Kurt suggested that it be described as an optional feature (rather than as an Annex). Brad concurred. Brad prefers scheme #1 - "start" instruction to start and "continue" instruction to burn. Neil pointed out that this scheme would not support "external" spinning plates using EXTEST to switch external signals during the programming pulse. Schemes #2 and #3 do not have that problem. Another solution would be to allow EXTEST (and perhaps other instructions) to have the "continue" behavior, and any instruction not in that list would terminate the programming cycle. If it is unsafe to switch output pins during the programming pulse, this feature may not be needed anyway.
Kurt agreed to write up text for section 6 and an example for section 9 to complete the spinning plates proposal. Brad suggested the name "interleaved programming". Ken suggested that the "start" instruction should be called ISC_START_PROGRAM to leave the door open for other possible start instructions.
Kurt asked, is it likely that future technology will have the ability to support output switching during the programming pulse? Mark said yes, the standard should provision for that capability. Mark requested clarification on the ISC_DISABLE signal shown on p.22 figure 5. Ken will clarify.
Section 8 - Conformance and Documentation Requirements
p.67 section 8.2.2 - Brad requested adding IDCODE and USERCODE. Mark requested adding HIZ or CLAMP.
Alan asked, it is our goal that the BSDL file would contain enough information to enable a tool to generate a full set of programming vectors? All agreed that this would be very desirable.
Howard asked if the BSDL extensions would support a description for different TCK frequencies at different times in the programming flow, as supported by STAPL and SVF. Ken expressed the opinion that such a device would not be 1149.1 compliant. Brad recommended clarification to that effect in the standard. Kurt argued that 1149.1 does not expressly forbid frequency switching, and that a device that requires dynamic frequency switching is still fully compliant, even though some 1149.1 test systems cannot support it. Ken recommended adding a rule that restrictions on TCK above the restrictions described in 1149.1 are not permissible. Kurt objected, saying that 1149.1 does not forbid dynamic frequency switching, and that P1532 should not either. Alan argued that the goal of automatic generation of programming vectors will not be achievable if exotic requirements like dynamic frequency switching is tolerated. We must either abandon that goal, or make restrictions on things like dynamic frequency switching. The group wants to pursue the goal of automatic vector generation by generic tools.
Attribute ISC_Protection
What is the polarity of the security protection bits? Ken suggested that the standard should mandate the polarity of the bit, and the silicon should contain logic to invert this value if necessary. Silicon vendors preferred adding a representation for polarity. Ken suggested tabling this issue until later when the overall algorithm is discussed.
Brad asked if the BSDL extensions are optional. Ken confirmed that they are optional in the sense that the file is still syntactically correct without these fields, but that some of these fields are required to document the behavior of the device. The BSDL must provide a complete and correct description of the device.
Attribute ISC_Instruction_Sequencing
Ken's concept is to store an algorithmic description of the programming flow here. Ken asked, is this achievable? Brad suggested a simpler scheme - simply providing the settings for algorithmic attributes, and the overall algorithmic flow would be referenced from the 1532 standard. The existence or non-existence of instructions in the BSDL file could also provide information about the flow.
The goal is to templatize the actions so that tool vendors can construct tools to automate the generation of programming vectors, ultimately encompassing complex multi-device situations. Neil suggested forming a small group to work on this issue. Neil will drive this effort and call on other working-group members for assistance as needed.
Next meeting: May 20-21. Ken offered to host the meeting at HP, Loveland CO .