Mark, Here Is My Initial Attempt to Spec out the Serial Interface for Eval Boards

PSDloadman1.doc Rev 0.90 initial release 12/27/99 tmw

PSDLOAD

PC SOFTWARE FOR WAFERSCALE'S DEVELOPMENT BOARDS

1 PRODUCT OVERVIEW...... 3 Definition of Terms...... 3 Serial Interface...... 3

REFERENCE DOCUMENTS...... 4 Background...... 4 PSD Architecture...... 4 System Considerations...... 4

PRODUCT DEFINITION...... 4 Scope...... 4 Commands...... 5 Description...... 5 User Interface...... 5 Submenus...... 5

PROTOCOL OVERVIEW...... 6 Message Transactions...... 6 Command Scope...... 6 PSDstep Messages...... 6 Implementation Details...... 7 Buffer Size...... 7

APPENDIX...... 8 Appendix A, 8xx Family Resources and Commands...... 9 Product variations within the 8xx family...... 9 Appendix B, Command designations...... 10

2 Product Overview PSDload is a PC application (WIN95/98/NT) which allows serial communications between the PC and the Waferscale's series of Development Boards. This application utilizes the microcontroller UART on the target system side and the standard serial PC channel. The protocol utilizes ASC commands to perform the following functions on the resident PSD 1. Read and write registers 2. Write to the LCD display 3. Download files from the PC to the target system(any system area) 4. Program the downloaded file into the PSD memory in circuit(main or boot areas) 5. Upload files from the PSD 6. Reset the target system.

The connection from the PC to the evaluation board is via a standard 9pin serial cable (straight through). The communications medium is standard 8 bit asynchronous with 8 data bits, 1 stop bit and no parity. Flow control occurs based on a one to one correspondence between the commands issued by PSDload and the responses from the Development board.

The primary target of this interface is flash based PSD’s from the standpoint of in circuit programmability of the PSD. However, the debug capability is also applicable to the OTP family of PSD’s when executing code from external SRAM using the bundled debugger.

The product was developed using Microsoft Visual C++ version 6.0, SP3.

Definition of Terms A few term definitions will ease the understandability of the document. a. PSDLoad is the windows interface running on the PC. b. PSDStep is the protocol used to communicate between the PC and the Development board. (Simple Test and Evaluation Protocol) c. Development Boards. a target system containing a PSD and UART

Serial Interface The serial interface will use simple three wire (TX, Rx and GND) RS-232 with full-duplex operations controlled via software handshaking. The handshaking is non standard and specific to PSDload. The baud rate shall be selectable between 4800 and 56000 baud, with the limits determined by the Development board microcontroller and software. Communication parameters are fixed at eight data bits, one stop bit and no parity (8N1).

PSDload software will acts as a Master station and the Development board responds to each command. This one to one transaction uses common master/slave communications techniques.

Each command received by the Development board will elicit a response. This handshake is used to verify a valid receipt by the target hardware of the PSDload initiated transaction. The time period for awaiting a response may be specified in the Communications Parameters submenu. A setting of 10000(s) indicates no time out. If the Development board does not respond within the given period of time (time out) the master software clears out the communications buffer and all pending operatons as well asand annunciate this action to the user.

This handshake establishes the following; 1. Both the PC and the evaluation board are at the same baud rate 2. Communication parameters are consistent 3. Development board is powered up 4. Proper serial cable connection.

3 Reference Documents PSDstep Communications Language

Background

PSD Architecture The PSD contains several different blocks of memory which vary within each family and between the families. These encompass the following memory types; EPROM, FLASH, EEPROM, SRAM, and registers. Generically these memory blocks are termed a memory “region”.

System Considerations PSDLoad must be aware of how these regions map into the system memory. The mechanism providing this awareness is the *.mmf file generated automatically from PSDsoft. At invocation, PSDload reads and presents this information to the user. Later this information is used to construct the serial commands sent to the target system.

Since the system memory map and microcontroller executing code are utilized to achieve the download, the microcontroller must be executing during the UART operations. For microcontroller operations to occur, the PLD within the PSD must have been programmed prior to a download attempt. PLD programming is accomplished via either the JTAG interface or with a conventional parallel programmer, both of which are external to PSDstep. (Note that the addressing scheme used by PSDload is a different addressing scheme than is used by a conventional parallel programmer and/or FlashLINK. PSDsoft, PSDsoft Express and FlashLINK use direct addressing which only are significant to the PSD and to the programmer. PSDload/Step use system addresses which are significant to the microcontroller.

The flash region is erased by sector and programmed byte by byte. The EEPROM region does not require erase from the microcontroller and may be written by byte or by page.

Product functional descriptions appear in the appendix as do the technology variations of the non- volatile regions.

Product Definition

Scope Following is a list PSD’s which are constructed from flash technology.

8xx family 9xx family While the primary target of PSDLoad/Step is flash based products, certain debug capabilities of the interface are also available using the OTP line. The interface is capable of personality modifications without the recompile of the PC executable by use of the ASP command. This philosophy allows new features to be evaluated and added to the target side without immediate impact on the PC side.

4 Commands The commands shall consist of up to three letter acronyms as follows. These commands, however, shall be hidden from the user by the windows interface except in the case of applications specific commands available from the action/User Defined submenu.

Command Description ASP Application Specific DNL Download to Development Board ERS Erase flash FIL Fill memory RDM Read Memory RST Reset Evaluation Board UPL Upload Data from Development Board WRM Write to memory WRD Write Display Table 1 PSD Step Commands

User Interface

Submenus Menu organization submenu comments

1 File Open Close save Save as exit 2 Action Erase Fill download upload Read Write Write to Display User defined 3 Select Comm Port Baud rate Hex file 4 Help about version Table 2 PSD Eval Menu Structure

5 Protocol Overview See PSDstep Communications Language for details of implementation.

Message Transactions Message transactions are paired request/response messages that constitute a complete communication transaction. No other messages, response or request, are allowed on the communications channel while a response is pending for a previous request. If the response can not be transmitted successfully within the predetermined time period, PSDload shall cancel any potential messages and respond to the next user request.

Command Scope If the address/length combination crosses a region or segment boundary, PSDload shall partition the read/write commands into individual commands that conform to the PSD regional boundaries prior to sending them to the eval board. This will result in each command being limited (in address) to one and only one region. This restriction applies to both read and write type commands.

On a read transaction (read, upload, etc), PSDload shall consolidate the data after receipt from the Development board and prior to presentation to the user. That is, upload may consist of many packets but the user will see only a single file. Similarly, a download event may consist of many communications packets but the source data resides in a single file.

The motivation for the scope restriction is to simplify the embedded code. This way, the PC determines which programming algorithm is appropriate (from the part number and device ID) and orchestrates whatever commands are necessary to carry out the desired action, thus minimizing the embedded code required for implementation.

PSDstep Messages The PSDstep communication language encapsulates commands and data into packages called messages. Each message will consist of a command followed by the area and type fields, the data field, with a simple checksum finishing the message. The byte-sized checksum will be derived from modulo 256 addition of each byte in the message, including the command.

For further detail see PSDstep Communications Language document.

In order to ensure program code integrity, a validation of the entire region is required. The mechanism of this validation is a region checksum. Upon the first write to a region, the initial 16 bits in the data field shall be the region checksum. Thereafter, the data field will contain entirely data. This region checksum will be compared to the programmed area after program operation is complete and, if match, the programmed area will be considered a valid image of the downloaded code. On subsequent writes to the same region these positions are occupied by normal data.

6 Implementation Details

Buffer Size The target system requires some SRAM to act as a communications buffer. Some PSD devices contain this SRAM internally others do not. Following is an initial target for buffer sizes across the family of PSD components.

This storage is generally partitioned into two components as described below.

Primary buffer typically serviced by the interrupt level UART driver routine. For an 813 example, the 512 byte allotment is split into 256 bytes is dedicated to transmit and 256 bytes to receive. This allows one packet to be transferred from the message level to the interrupt level in its entirety.

The secondary buffer is typically used by the message level routines that execute in the background. Similarly, this storage allotment is split into 256 bytes is dedicated to transmit and 256 bytes to receive. This arrangement allows UART servicing to be an asynchronous event, independent from the message level servicing. This arrangement facilitates maximum throughput.

In some cases, external SRAM is required to fill this need.

Following is a general breakdown,

PSD SRAM (bytes) TX Rx PSD813F1 2k 512 512 PSD 813F2 2k 512 512 PSD 813F3 2k 512 512 PSD 813F4 0 512 512 PSD 813F5 0 512 512

PSD913F2 2k 512 512 PSD 934F2 8k 512 512 Figure 1 Communications Buffer sizes vs PSD variation

7 Appendix

8 Appendix A, 8xx Family Resources and Commands

Product variations within the 8xx family

I/O JTAG Memory More Sram comments ( x8) mem (x8)

813F1 27 Yes 128k 32k e2 2k 813F2 27 Yes 128k 32k flash 2k 813F3 27 Yes 128k None 2k 813F4 27 Yes 128k 32k flash 0 813F5 27 Yes 128k None 0 913F2 27 Yes 128k 32k flash 2k 934F2 27 Yes 256k 32k flash 8k Table 3 Product Variations Within the 8xx and 9xx Families

9 Appendix B, Command designations

Type* Description E Eprom F Flash G Eeprom V Volatile Table 4 Primitive Command Designations, Type field Note * This field is determined by the PSD part number in conjunction with the device ID per table 2 above.

The effect of the device ID is expected to impact devices which may choose to emulate eeprom with flash. This field will give PSDload/PSDstep the ability to determine algorithm type in a true sense regardless of the part number that may be stamped on the device