A protocol for a logical testing interface

The protocol is frame-oriented. In order to simplify the send and receive procedures, all frames conform to the same basic format outlined below.

Different frame types are described further in this document. Some of them make use of the optional data section and may specify its minimum and (or) maximum length, or other constraints. Frames not meeting these constraints should not be sent, and should be responded with a request error: invalid data length frame and otherwise ignored.

The protocol being described is meant to be a simple request-and-response one; as such, no request identifiers were deemed necessary or useful for the frames: the interface’s response frame always relates to the preceding request frame sent to it.

The checksum is included mainly for the purpose of detecting framing errors, such as could arise even in otherwise reliable channel due to software bugs. The frame that fails checksum verification must be ignored by the receiver.

Depending on the error rate of the communication channel in use, the checksum implemented may be as simple as Fletcher-16, or as complex as CRC-16. Moreover, when it can be guaranteed that different checksums result in different frames during handshake, it’s possible to use the same opaque protocol identifier in the initial are you there? frame, with the interface autodetecting supported checksum algorithm based on the checksum field value alone.

The communication is initiated by the controlling host sending to the controlled interface an are you there? frame as follows.

The version of the protocol described herein uses 24 3f 6a 88 as the opaque version identifier. When using Fletcher-16 checksum with modulus 255 and simple checksum being the second of two octets (henceforth: Fletcher-16 checksum), the whole frame will be: 02 04 24 3f 6a 88 cb 5c.

Should the interface be unable to successfully verify the checksum, the frame must be ignored. Otherwise, if the interface recognizes the opaque version identifier as a supported one, it is to configure itself to use this protocol version for the remainder of the session, and respond with the general acknowledgement frame. Otherwise, the interface is to respond with a request error: not supported frame.

Should frame of any other type be received (and pass checksum verification) before an are you there? frame is successfully processed by the interface, the interface is to respond with a request error: frame type not recognized frame.

When using Fletcher-16 checksum, the whole frame will be: 01 00 02 01.

When using Fletcher-16 checksum, the whole frames corresponding to the conditions above will be as follows.

03 01 01 0c 05

Frame type not recognized.

03 01 02 0d 06

Invalid data length.

03 01 03 0e 07

Not supported.

03 01 04 0f 08

Limit exceeded.

03 01 05 10 09

Violation of implementation’s restriction.

It is intended for the interface to be configurable to some extent, such as to support several clock rates for sending data to the device under test and reading its responses.

The length of the data section for this frame must be a multiple of 2, must be at least 2, and must not exceed 254. If these constraints are not met, the interface should respond with a request error: invalid data length frame.

The octets at even offsets in the data section are considered option codes, and the single octet immediately after that code is considered the desired value for the option.

If one (or more) of the option codes in the request are not recognized by the interface, or if one (or more) of the values are not implemented, the interface must stop processing of the request immediately, and respond with a request error: not supported frame. In that case, it is not specified whether the options prior to the offending one will be set or not.

At present, we only define option code 2 to set the divisor for the interface’s IO clock rate, with values 1 to 5 selecting divisors 256, 2048, 16384, 65536, and 262144, respectively. Assuming interface’s primary clock of 7.3728 MHz, that gives IO rates of about 28.8 kHz down to about 28.1 Hz.

When using Fletcher-16 checksum, the whole frames corresponding to the divisors above will be as follows.

04 02 02 01 1b 09

Select 256 as the IO clock divisor.

04 02 02 02 1c 0a

Select 2048 as the IO clock divisor.

04 02 02 03 1d 0b

Select 16384 as the IO clock divisor.

04 02 02 04 1e 0c

Select 65536 as the IO clock divisor.

04 02 02 05 1f 0d

Select 262144 as the IO clock divisor.

The transfer instructions above comprise one octet giving the number of IO clock cycles to read data from the device, according to the reception bitmap given; and zero or more octets giving the data to send to the device, according to the transmission bitmap given.

Given the overall limit of 255 octets for the data section, the bitmaps are not to exceed 253 octets together. The octets not present are assumed to be zero.

The bitmaps are given most significant octet first. The present specification only defines the function of the least significant bit of the least significant octet for each of the bitmaps; all other bits must be set to zero.

The least significant bit in the reception bitmap instructs the interface to read octets from the device under test using interface’s 8 bit wide input parallel port. Similarly, the least significant bit in the transmission bitmap instructs the interface to write octets to the device under test using interface’s 8 bit wide output parallel port.

The number of octets in a single transfer instruction is always one more than the number of bits set in the transmission bitmap given in the frame. The first octet is the number of times, one per IO clock tick, to perform reads from the device; each read resulting in as many octets added to the interface’s device response buffer as there are bits set to one in the reception bitmap, with the least significant bit set corresponding to the first octet in each bundle.

When the reception bitmap has no bits set to one, the first octet of the transfer instruction essentially gives the delay before performing the subsequent transmission to the device.

The subsequent octets are the data to be sent to the device using the interfaces corresponding to the bits set to one in the transmission bitmap, one octet per such bit starting with the least significant bit.

If the length of the transfer instructions portion of the frame is not divisible by one plus the number of bits set in the transmission bitmap given in the frame, the interface must interpret it as if the bits corresponding to the ‘missing’ octets in transmission bitmap were set to zero for the duration of the last transfer instruction. In particular, the last (or only) transfer instruction may contain only the single octet giving the number of times to perform reads from the device, regardless of the bits set in the transmission bitmap.

When using Fletcher-16 checksum, an example frame to read 3 octets from the device, then write 55, then read 2 more octets, could be as follows: 10 07 01 01 01 01 03 55 02 94 75.

The interface must ensure that the data to be read from the device fits the 255 octets limit for the data section of the device’s response frame. If that’s not the case, the interface must respond with a request error: limit exceeded frame.

If the request is deemed valid, the interface responds with the general acknowledgement frame. The interface deasserts the CTS line until the request is completed. After the line is reasserted, the host is free to request the device’s response with the retrieve device’s response frame.

When using Fletcher-16 checksum, the whole frame will be: 12 00 24 12.

When using Fletcher-16 checksum, an example frame containing 5 octets read from the device, could be as follows: 13 05 01 02 03 04 05 c6 27.