IEEE P1532 Meeting - Sep 28-29, 1998 - Cypress Semiconductor

Back to Minutes page
Back to IEEE P1532 home page

Attendees

The following individuals attended the meeting 

   Neil Jacobson          Ted Eaton
   Dave Bonnett           Steve Klinger
   Alan Herrmann          Bradley Ishihara
   Carmy Yellin           Ken Parker
   Howard Tang            David Thompson
   Mark Moyer

Minutes

Monday 9/28/1998

Election of Secretary

Ted Eaton was elected P1532 secretary with a vote of 8-0-0

Neil Jacobson discussed some recent changes in the email reflector and the addition of our new IEEE web page which will be maintained by Dave Bonnett.

Neil then briefly discussed the ballot process including the selection of a ballot group.

Alan Herrmann inquired about ways of insuring a fair and accurate ballot without the possibility of ballot group stacking.

Action Item

Neil will address Alan's concerns with the IEEE.

Motion: Minutes from June 29th and 30th

Ken Parker moved that the minutes from the June 29th - 30th meeting be approved. Brad Ishihara seconded the motion.

The motion carried 7 - 0 - 0

ITC Meeting? There was some discussion concerning a potential P1532 meeting at ITC and with the lack of working group member attendance at ITC along with the hectic schedule of the week, it was decided to have an informational meeting with no Working group activities.

Action Item

Neil Jacobson will produce a flyer announcing the meeting and distribute it among the working group members with booths at ITC as well as to the ITC information table

Draft Review: Review of the first "IEEE" style P1532 draft prepared by Ken Parker (Thank you Ken)

Section 2.

The definitions for CPLD and FPGA need to be updated with the addition of the general term Programmable Device (PD) and potentially PAL, PLD and any others deemed reasonable.

Action Item:

Neil Jacobson will provide Ken Parker with a list of generically defined terms for addition to the standard.

Section 2.1.10.3: Protect

The definition of protect is too narrow and will be expanded to include protection methodologies other than read protect. The definition will also be expanded to include multiple protection bits.

Action Item:

Neil Jacobson will provide an updated definition

General Note:

A general consensus was reached that the document will use the term "Programmable Device" rather than "Programmable Logic Device" as the base target of the standard.

Section 3 System Modes

Figure 3-3

  1. References to "blank", "not blank" will be rewritten to refer to the state of the "ISC_DONE" bit.
  2. A loop-back path will be added to the "operational" mode indicating that any instruction other than ISC_ENABLE will cause the device to remain operational.
  3. The reference to "any instruction but ISC_ENABLE" will be removed from the figure.

Section 3.1 Definitions

In general the definition section will be updated with the following goals.

  1. Remove and clarify the statement "operation nullified"
  2. The statement "contains no programming" will be re-written in the context of the "ISC_DONE" bit.

Section 3.2 IOB -> IOM

To avoid any vendor specific notational confusion the term Input-Output Blocks (IOB) will be redefined as Input-Output Modules (IOM)

Action Item(s):

  1. Ken Parker will add "pin-permission instruction" to the definitions section
  2. Ken Parker will add the concept of an ISC_DONE bit to the definition section.

Section 3.3

The Group then discussed in some detail the idea of an ISC_DONE bit, with topics including:

  1. How is the bit set?
  2. How is the bit cleared?
  3. How is the bit read?

Following this discussion the group formulated and approved the following Motions.

Motion: ISC_DONE bit programmed

That the ISCDONE bit shall be programmed (set) via one of two methods

(i) using the optional ISCPROGRAMDONE instruction
-or-
(ii) Using the ISCPROGRAM instruction to program (set) specified bit(s) on the device.

Motion By: Alan Herrmann
Second: Bradley Ishihara
The motion carried 7 - 1 - 0

Motion: ISCDONE Bit Cleared

That devices which require external control of the ISCDONE bit, shall have the ISCDONE bit erased (cleared) via one of the following 2 methods:

(i) using the optional ISCERASEDONE instruction
-or-
(ii) using the ISCERASE instruction to erase (clear) bits including the ISCDONE bit.

Motion By: Ken Parker
Second: Howard Tang
The motion carried 7 - 1 - 0

Motion: Internal Done bit control

Devices are allowed to manage the state of the ISCDONE bit without requiring external algorithmic control. (Setting and Clearing only)

Motion By: Brad Ishihara
Second: Mark Moyer
The motion passed 6 - 1 - 1

Motion: Reading the ISCDONE bit

The ISCDONE bit is read by examining

(i) Bit 2 of the instruction register capture value
(ii) Bit 2 of the optional status register
(iii) Direct read of the location storing the ISCDONE bit <if possible??>
(iv) With the optional ISCREADDONE instruction

Motion By: Ken Parker
Second: Howard Tang
The Motion carried 5 - 1 - 2

Action Item: Neil

Neil will pursue concerns that the specification of an instruction register capture value violates the 1149.1

September 29 1998 - Day Two.

Figure 5-1

Ken Parker corrected figure 5-1 to allow for EXTEST in a non-programmed device.

Section 5-12

The group discussed the existence and placement of status bit(s). The following was agreed upon without a vote.

  1. Status will available on all data register scans operations
  2. The status Register bit count and location will be consistent for every instruction.
  3. The two LSBs of the status register (field) will indicate the success of the previously executed instruction.
  4. There will NOT be an ISCDONE bit reflected in the status field.

Action Item: Ken Parker

  1. Wording will be added to section 4 to indicate that the status register(field) holds the result of the previous RTI operation, how these bits are set, and what they indicate.
  2. All references to a "status register" will be changed to "status field".

Section 6. ISC Data Registers

It was decided to remove any vendor specific meaning from the capture value of ISC_DATA registers.

Section 5.3.1 ISC_IDCODE Instruction

The reference to a 512 bit register will be removed. The length of this register is unspecified.

The ISC_IDCODE register will be defined as an optional register containing unspecified vendor specific information.

Motion: ISC_READINFO Instruction

That an optional ISC_READINFO instruction be permitted and targets a register of unspecified length.(ISCINFOREG). The contents of the register are valid only in ISC_ACCESSED mode. This register can be used to store ISC related information as described in section 5.3.1.

Motion By: Alan Herrmann
Second By: Steve Klinger
The motion carried 5-1-2

Spinning Plates.

With the apparent lack of a champion for Spinning Plates it is the group's opinion that the idea, while beneficial, will be put aside until a later time with the clear goal not to implement any prohibitive rules.

Motion : Removal of Spinning plates(Section 5.4) from the standard.

That section 4.5 be removed from the draft.

Motion By: Ted Eaton
Second By: Ken Parker
The motion carried 4 - 0 - 5

Action Item: Neil Jacobson

Due to the result of the previous motion Neil will:

  1. Add Spinning plates to the agenda of the next meeting
  2. Query the group via the reflector searching for a spinning plates champion.

Section 5.1.1.h

Motion: Maximum Burn Times

Permission to allow specification of a maximum duration for ISC device burn times.

Include note describing duration specification guidelines.

Motion By: Ken Parker
Second By: Alan Herrmann
The motion carried 7 - 0 - 2

Action Items: Ken Parker

  1. This section will be edited to remove an unlimited time requirement.
  2. A permission will be added as follows: Permission to allow specification of a maximum duration for ISC device burn time.
  3. Add a note describing duration specification guidelines

Algorithmic Discussion (Programming Flow)

The group moved its focus to the definition of a generic flow that would allow for concurrent programming. As a starting point the group examined the email from Dave Bonnett which attempted to specify a generic flow. The following are the resulting motions and updates programming flow.

Motion: ISC_NOOP instruction

ISC_NOOP instruction which maps onto bypass or clamp instruction as appropriate for the implementation of ISC_ENABLE.

Motion By: Alan Herrmann
Second By: Mark Moyer
The motion carried 9 - 0 - 0

Motion: Post Instruction

A single "POST" instruction for all PGM, ERASE operations (DISCHARGE) .

Motion By: NOT NOTED
Second By: NOT NOTED
The motion carried 8 - 0 - 1

Action Item: Ken Parker

It follows from the previous motion that all other "PRE" and "POST" instructions will be removed.

ISC FLOW

Example of Programming Sequence (taken from email by Dave Bonnett)

Device 1: Type 1: Address and Data in Pairs. Device also requires a discharge(ISC_POST) instruction following each program instruction.

Device 2: Type 2: Initial Address followed by a sequence of data (auto Increment).

Device 3: Type 3: PDATA Register combines address and data.

Device 3
Type 3		 Device 2
Type 2		 Device 1
Type 1
1. IRSCAN ISCENABLE ISCENABLE ISCENABLE
2. DRSCAN ISCCONFIG ISCCONFIG ISCCONFIG
3. RTI wait x(config) wait y(config) wait z(config)
4. IRSCAN ISCNOOP ISCADDRESSSHIFT ISCADDRESSSHIFT
5. DRSCAN x ISCADDRESS
addr.		 ISCADDRESS
addr.
6. IRSCAN ISCPROGRAM ISCPROGRAM ISCPROGRAM
7. DRSCAN ISCPDATA
data and addr		 ISCPDATA
data 		ISCPDATA
data
8. RTI wait x(prog) wait y(prog) wait z(prog)
9. IRSCAN ISCNOOP ISCNOOP ISCPOST
10. DRSCAN X X ISCADDRESS
addr.
11. RTI X X wait z(prog)
12. IRSCAN ISCNOOP ISCNOOP ISCADDRESSSHIFT
13. DRSCAN X X ISCADDRESS
addr.
14. IRSCAN ISCPROGRAM ISCPROGRAM ISCPROGRAM
15. DRSCAN ISCPDATA
data & addr		 ISCPDATA
data		 ISCPDATA
data
16. RTI wait x(prog) wait y(prog) wait z(prog)
17. IRSCAN ISCNOOP ISCNOOP ISCPOST
18. DRSCAN X X ISCPOSTDATA
19. RTI X X wait z(prog)
20. Repeat until
all devices
are complete		 12 - 19 12 - 19 12 - 19
21. IRSCAN ISCDISABLE ISCDISABLE ISCDISABLE
22. RTI wait x(disable) wait y(disable) wait z(disable)

ISC FLOW

Example of Erasure Sequence (taken from email by Dave Bonnett)

Device 1: Type 1: Address and Data in Pairs. Device also requires a discharge(ISC_POST) instruction following each erase instruction.

Device 2: Type 2: Initial Address followed by a sequence of data (auto Increment).

Device 3: Type 3: PDATA Register combines address and data.

Device 3
Type 3		 Device 2
Type 2		 Device 1
Type 1
1. IRSCAN ISCENABLE ISCENABLE ISCENABLE
2. DRSCAN ISCCONFIG ISCCONFIG ISCCONFIG
3. RTI wait x(config) wait y(config) wait z(config)
4. IRSCAN ISCNOOP ISCADDRESSSHIFT ISCADDRESSSHIFT
5. DRSCAN x ISCADDRESS
addr.		 ISCADDRESS
addr.
6. IRSCAN ISCERASE ISCERASE ISCERASE
7. DRSCAN ISCPDATA
data and addr		 ISCPDATA
data 		ISCPDATA
data
8. RTI wait x(erase) wait y(erase) wait z(erase)
9. IRSCAN ISCNOOP ISCNOOP ISCPOST
10. DRSCAN X X ISCPOSTDATA
11. RTI X X wait z(POST)
12. IRSCAN ISCNOOP ISCNOOP ISCADDRESSSHIFT
13. DRSCAN X X ISCADDRESS
addr.
14. IRSCAN ISCERASE ISCERASE ISCERASE
15. DRSCAN ISCPDATA
data & addr		 ISCPDATA
data		 ISCPDATA
data
16. RTI wait x(erase) wait y(erase) wait z(erase)
17. IRSCAN ISCNOOP ISCNOOP ISCPOST
18. DRSCAN X X ISCPOSTDATA
19. RTI X X wait z(POST)
20. Repeat until
all devices
are complete		 12 - 19 12 - 19 12 - 19
21. IRSCAN ISCDISABLE ISCDISABLE ISCDISABLE
22. RTI wait x(disable) wait y(disable) wait z(disable)

ISC FLOW

Example of Read Sequence (taken from email by Dave Bonnett)

NOTE: IN THE MEETING IT WAS DECIDED THAT ALL THAT WAS NEEDED TO IMPLEMENT A READ SEQUENCE WAS TO SWITCH THE RTI AND DRSCAN OPERATIONS OF THE READ CYCLE. IT IS UNCLEAR TO ME IF THIS WILL WORK FOR A DEVICE OF TYPE 1 GIVEN THAT THE ADDRESS TO BE ACCESSED IS NOT KNOWN UNTILL THE DRSCAN OPERATION?

Device 1: Type 1: Address and Data in Pairs

Device 2: Type 2: Initial Address followed by a sequence of data (auto Increment).

Device 3: Type 3: PDATA Register combines address and data.

Device 3
Type 3		 Device 2
Type 2		 Device 1
Type 1
1. IRSCAN ISCENABLE ISCENABLE ISCENABLE
2. DRSCAN ISCCONFIG ISCCONFIG ISCCONFIG
3. RTI wait x(config) wait y(config) wait z(config)
4. IRSCAN ISCNOOP ISCADDRESSSHIFT ISCADDRESSSHIFT
5. DRSCAN x ISCADDRESS
addr.		 ISCADDRESS
addr.
6. IRSCAN ISCREAD ISCREAD ISCREAD
7. RTI wait x(read) wait y(read) wait z(read)
8. DRSCAN ISCPDATA
data and addr		 ISCPDATA
data 		ISCPDATA
data
12. IRSCAN ISCNOOP ISCNOOP ISCADDRESSSHIFT
13. DRSCAN X X ISCADDRESS
addr.
14. IRSCAN ISCREAD ISCREAD ISCREAD
15. RTI wait x(read) wait y(read) wait z(read)
16. DRSCAN ISCPDATA
data & addr		 ISCPDATA
data		 ISCPDATA
data
17. Repeat until
all devices
are complete		 12 - 16 12 - 16 12 - 16
18. IRSCAN ISCDISABLE ISCDISABLE ISCDISABLE
19. RTI wait x(disable) wait y(disable) wait z(disable)

Section 5.2.5.1.a

Change Rule (a) to indicate that only devices which "support electrical erasure" be required to implement ISC_ERASE instruction.

Permission (h) needs to be updated to allow for a status field.

Action Item: Alan Herrmann

Alan will investigate the acceptability of a read requirement for volatile devices.

Motion: Security Bits

That the ISCSECURITY bit shall be programmed(Set) via one of the two following methods :

(i) using the optional ISC_PROGRAMSECURITY instruction
- or -
(ii) using the ISC_PROGRAM instruction to program(set) specified security bit(s) on the device.

Motion By: Brad Ishihara
Second By: Steve Klinger
The motion carried 8 - 0 - 0

Note:
If ISC_READ is performed on a protected address the status will be returned "BAD".

Motion: Done Bit

That the done bit will be programmed(Set) after the security bit(s).

Motion By: Alan Herrmann
Second By: Yadvindra Dhami

Back to Minutes page
Back to IEEE P1532 home page