IEEE P1532 Meeting - September 18-19, GenRad

The following individuals attended the meeting:

   Neil Jacobson - Xilinx
   Ken Parker - Agilent
   Dennis Lia - GenRad
   Dave Bonnett – ASSET InterTech
   Brad Ishihara - Altera
   Mark Moyer – Lattice
   Bob Russell – EMC ( Tuesday )

Minutes

   Meeting: IEEE P1532
   Date:  9 / 18 & 19 / 2000
   Location: GenRad -  Westford, MA
   Purpose: Data Format

Agenda:

Welcome and Introductions
Ballot Update
Discussion

Open Issues: Review Draft 3.4

Minutes:

Date: 9-18-00 Monday
Time: 9:00 AM

Neil’s got stuck in Detroit Sunday night. His flight into Manchester was Monday morning. Dave Bonnet assumed chair the meeting until Neil arrives.

Discussion: Approval of the Minutes of the last meeting:
Motion: Approve last meeting minutes.
Motion: Ken
Second: Mark
Vote: 5-0-0

Discussion: IC Vendor Announcement: The discussion revolved around the intent of the announcement that indicates support for the hardware portion and mentions that software(BSDL extension and Data file) will be addressed in the future release. Reference 8.1 A, B, & C as the basis of this announcement. Should this working group formalize a press release.

Action: Working Group will draft an press release announcement. Neil to present to IEEE.

Time: 10 AM Neil Arrived

Discussion: Ballot Update - Neil

Everything is submitted to IEEE.
3 weeks before official Revcom meeting response was affirmative.
Revcom meeting scheduled for Sept 20, 2000.
If approved the specification will be sent on to the Standards committee.
Neil’s presence at Revcom is not needed since everything is so clean.
Friday Sept 22, 2000 the Standards committee gives the final approval.
It will be Monday Sept 25, 2000 when Neil gets the word.
Then Neil will notify the Working Group via the reflector.

Information: Neil

Xilinx will create some “C” code that will read 1532 BSDL extention file and generate program and data files. This will be available in 4 to 6 weeks. “C” source code will be distributed freely. Working group will copied. The purpose will be to have something to work with before the software portion of the standard is finalized.

Discussion: Working Group Announcement Draft

The group drafted the IEEE 1532 specification approval announcement.
Neil created the document. Text appended to these minutes

Action: Dennis

Email the final announcement to the working group via reflector.

Discussion: When is the Hardware portion expected to be approved.

Working Group needs about 6 months of work more (3 meetings).
Then 3 months of IEEE ballot and approval process.
Earliest approval could be Q3 2001. More reasonable estimate for approval would be Q4 2001.

Discussion: Review Changes (draft 3.4 )

The working group reviewed the red high lighted change bar sections in the draft 3.4 prepared by Ken and circulated prior to the meeting.
Ken captured the working group inputs and comments.
Some issues:
- Need over all structure of extension as does 1149.1.
- ISC_Options – should we have 2 separate instructions. Change ISC_Option to ISC_Pin_Behavior and ISC_Status
- 8.4.5.2 need rule that says that “proc_” can not be used by a user.
- In general rules are need in any place there is intent that something is required.
- Optimization: 8.4.6.1: Remove “full” and change “nonconcurring” to “proprietary”.

Time: 12:30PM – Lunch

Time: 1:20PM – Continued

Discussion: Continued Review Changes (draft 3.4 )

Ken to find alternate keyword for optimization and reword the description.

Time: 1:45PM

Discussion: Open Issue – Write a file out using “!” and read in using “?”

Example 12 (writing) and example 1 (reading ).
Interrogate and Copy a device actions.
Suggest adding a data tag capability to actions.
Suggest that data tag be pushed down to data file format.
Need an unprocessed data flag.
Neil and Ken captured the details.

Action Ken – Update the draft specification.

Discussion: Open Issue – Merge BSDL
Motion: Modify sections 7.6 and 7.7, figure 26, rule 6.3.1.1(a) on page 63 to allow formal sharing of ICS_PDATA and ICS_RDATA using a common register name.
Motion: Brad
Second: Mark
Vote: 5,0,0

Discussion: Open Issue – Referencing data in other files and locations.

Time: 5:00 - Adjourn for the Day

Date: Tuesday 9/19/00
Time: 9:00AM

Discussion: Open Issue – Referencing data in other files and locations(Continued).

Example of parameterizing actions and procedures using data tags.

Memory Map
   Logic1
   Usercode
   Logic2

Actions
   program(logic) ( proc_enable,....proc_program(logic),....)
   program(usercode) ( proc_enable,....proc_program(usercode),...)
   program(all) ......

Procedures
   proc_program(logic) ( program(logic(logic1), program(logic2) )
   proc_program(usercode) ( program(usercode) )

Flows
   program(logic1)
      Init
      Repeat
      Terminate
   program(logic2)
   ....
   program(usercode)

Discussion: Open Issue – Multiple output sources

Associate source (file) with abstract data tag such that the source for “?” becomes the specified (file). The tool GUI will bind the ? to stdin (ie.. input file ).
The same goes for “!” except stdout.
Standardize USERCODE data representation as 32 individual data bits, in the Initialize block to provide for USERCODE serialization. Access in 1 bit elements: ie 1:?, 1:?, ......32 times.

Discussion: Open Issue – Data file extension name

“.isc”

Discussion: CRC/Checksum

When calculating a CRC from the device. Is it necessary for the tool to recalculate the value based on the data in the file. Or will the CRC value in the datafile be acceptable.

Example:

data( logic1;
Init
Repeat
Term
Data_crc),

data( logic1;
Init
Repeat
Term
Data_crc),

data( usercode;
Int)

Transmission CRC validates the file content.
Composite CRC
- Composite CRC is a CRC of data_CRC’s calculated by an application.
- Application must zero out calculated_data_CRC when beginning each data_CRC calculation.
- Default device CRC: recommended to be based on full verify action.
- RULE: if a CRC is not calculated in a flow – do not compare against data_CRC in data block and it does not contribute to Composite CRC. If two flows use the same data but calculate CRC differently, then two data blocks must be specified.
- RULE: reported data_CRC must be valid for all flows that use that data block (and calculated a CRC).
- Recommendation: Flow for Usercode and it’s data block should not include CRC.

Action:

Ken Draft updates – By end of October.
PLD Vendors - Provide BSDL and matching Datafiles at the end of October.
Xilinx – Program generator for the next meeting.

Time: 12:15PM - Lunch

Time: 1:00PM

Discussion: Revisit GUI

Data File column may be multiple data files defined by ? and ! by procedure.
Determined that the raw format of the data file is not required. The output can written in the data format syntax.

Time: 3:00PM – Adjourn Meeting

Next Meetings:
Date: Mon-Tue 12/4-5,
Location: Lattice, San Jose
Purpose: Review draft updates of data format and tools pieces that are available.

Secretary: Dennis Lia

Attachments:

IEEE release announcement bullets:

The working group consists of representatives from the following leading technology companies: Agilent Technologies, Altera, ASSET InterTech, Atmel, Cisco Systems, Cypress, Data IO, GenRad, Intellitech, JTAG Technologies, Lattice Semiconductor, Lockheed Martin, Lucent Technologies and Xilinx. This represents the leading manufacturers of programmable integrated circuits, programming tools and end-users.
IEEE Std 1532 represents an extension to IEEE Std 1149.1 designed to standardize access to the In-System-Configurable (ISC) features of modern programmable integrated circuit devices.
1532 takes advantage of 1149.1’s decade of industry experience.
The complete 1532 solution is comprised of both a hardware and software specification.
Today the working group announces the approval of the hardware specification that allows integrated circuit manufacturers to design conformant devices.
The working group continues to actively develop the software specification based on 1149.1’s Boundary-Scan Description Language (BSDL)

Benefits of 1532

Conformance with this standard allows concurrent programming of programmable devices, with the potential for significant time efficiencies, particularly when the devices belong to different device families or come from different vendors.
The standardization of the device behavior before, during and after programming is crucial for board and system designers who need to assure the orderly and predictable operation of their products.
By integrating ISC operations based on 1532 with the 1149.1 test access port (TAP), the same tools used for system test facilitates optimized multi-vendor device programming.

Back to Minutes page
Back to IEEE P1532 home page

IEEE P1532 Meeting - September 18-19, GenRad

Attendees

Minutes

Attachments:

IEEE release announcement bullets: