Sysclk LWLA1034/Protocol

FPGA Configuration

The FPGA bitstream is loaded via bulk transfer to USB end point 4. Each firmware transfer starts with a 4-byte header to announce the transfer size. The payload appears to be a Raw Binary File (.rbf) with compression enabled.

Length	Payload...
nnnn-nnnn	dd...

Unlike the control commands, the firmware transfer is apparently byte-based. The length is a byte count encoded in big endian (1-2-3-4) byte order, and includes the size of the length field (4 bytes) itself.

Application Behavior

The vendor software transfers a new bitstream to the FPGA

1. on application start,
2. when switching clocking mode between internal, external/rising or external/falling,
3. on application exit.

The firmware transfer is split into packets with 15 byte payload each and thus takes quite a bit of time. This hints that the passive serial FPGA configuration is probably bit-banged in software on the FX2. The size of the bitstream varies due to compression, but is in the order of 50kB to 80kB.

Firmware Extraction

The firmware blobs can be extracted directly from the Windows installer executable located on the CD-ROM that ships with the device. The file lwla1034_EN_setup.exe on the CD-ROM from 2012-07-12 has the firmware blobs located at the following offsets:

Offset	Length	Mode
34110338	78398	Internal clock
34266237	78247	External clock (rising edge)
34344484	79145	External clock (falling edge)
34578631	48525	Shutdown

Both offsets and lengths are in bytes. The extracted blobs already include the header with the 32-bit length field.

Control Commands

Control commands are sent via bulk transfer to USB end point 2, with the response (if any) coming in from end point 6.

Command messages sent to the device appear to be a sequence of 16-bit words with little endian byte order. The first word in a message identifies the command type. Different command types have different message lengths. Some command types include a length field and allow for messages of variable length, others are of fixed size.

There are read commands which trigger an immediate response from the device, and write commands without a response.

Command 0001: Read Register

This command appears to read a 32-bit wide control register.

Command

Fixed length of 2 words (4 bytes).

ID	Address
0001	aaaa

Response

The response has a fixed length of 4 bytes. It is the content of a 32-bit register in mixed endian (2-1-4-3) byte order.

Registers

Address	Value
10C0	Channel 1 frequency counter
10C4	Channel 2 frequency counter
10C8	Channel 3 frequency counter
10CC	Channel 4 frequency counter

These registers apparently count the number of rising (or falling?) clock edges on channels 1 to 4. Reading these counters seems to reset them to zero. The vendor software polls these counters every second to display a live frequency count for channels 1 to 4. As the timing is thus apparently dependent on the USB latency, the resulting numbers can be way off (by more than 20%) especially for the first channel.

Address	Init value
10B0	12345678
10BC	12345678
10B8	87654321

These three registers are read during initialization, probably for testing purposes or device identification.

Address	Value
1078	Capture size (number of 36-bit words)

This register appears to contain the size of the captured data. The vendor software retrieves this just before fetching the SRAM content.

Command 0002: Write Register

This command appears to write a 32-bit value to a control register.

Command

Fixed length of 4 words (8 bytes).

ID	Address	Data
0002	aaaa	dddd-dddd

The data is encoded in mixed endian (2-1-4-3) byte order.

Registers

Address	Init value
10B4	00000064

The vendor software writes the value 100 (decimal) to this register during initialization, probably for testing purposes.

Address	Init value
1074	00000200
107C	00000000

The vendor software writes these two registers during initialization.

Command 0005: Write ???

This command appears to write 8 64-bit words at once. It is issued once after a transfer of captured data to the host has finished, but only for immediate (not triggered) captures.

Command

Fixed length of 33 words (66 bytes).

ID	Data 1	Data 2	Data 3	Data 4	Data 5	Data 6	Data 7	Data 8
0005	dddd-dddd-dddd-dddd	dddd-dddd-dddd-dddd	dddd-dddd-dddd-dddd	dddd-dddd-dddd-dddd	dddd-dddd-dddd-dddd	dddd-dddd-dddd-dddd	dddd-dddd-dddd-dddd	dddd-dddd-dddd-dddd

Command 0006: Read Memory at Address

This command appears to read a block from the device memory (probably the SRAM). It allows for random access using a 32-bit start address, and variable length via a 32-bit length field. The software uses this command to read captured data from the device's buffer.

Command

Fixed length of 5 words (10 bytes).

ID	Address	Length
0006	aaaa-aaaa	nnnn-nnnn

Both the address and the length are apparently encoded with mixed endian (2-1-4-3) byte order: MSW (16 bit) followed by LSW (16 bit), with the two bytes making up each individual 16-bit word in little endian order.

Response

The memory is apparently 36 bit wide: The size of the response in bits is 36 times the value in the length field. The software reads chunks of 120 words @ 36 bit at a time, which works out to an integer multiple of 8 (i.e. 4320 bits = 540 bytes). The final six reads are done in chunks of 8 words @ 36 bit, which works out to 36 bytes. Judging from this behavior, it seems that reading partial bytes is likely illegal. The overall amount of memory being read when fetching captured samples hints at the RAM size of 256k×36 bit.

Note that the software always starts reading at address 4 rather than 0. Presumably the firmware uses the first four 36-bit words for internal bookkeeping or some other purpose. Exception to the rule: For some unknown reason, the memory is also being read on start-up right after loading the firmware into the FPGA. In this case, altogether 128000 36-bit words are being read beginning at address 0.

Command 0007: Configure Channels ???

The software issues this command once during start-up, and once for each capture operation as part of the setup sequence. It also issued when clicking the Stop button to cancel a capture in progress. The message format appears similar to command 0008 and its response.

Command

Tentatively: variable length of 3 words (6 bytes), plus length times 8 bytes.

ID	Length?	Data 1?	Data 2?	...
0007	nnnn-nnnn	dddd-dddd-dddd-dddd	dddd-dddd-dddd-dddd	...

The two argument words in the header look like a 32-bit length field in mixed endian (2-1-4-3) byte order. However, the software never uses any value other than 10 for this field, so it could just as well mean something completely different. The header seems to match the format of command 0008, and the payload looks similar to the response to command 0008.

Command 0008: Poll Channel State

This command poll the current status of the input channels. It seems that this command essentially performs a burst read from the register space, which if true would also allow one to access the same data via single Register Read commands (TODO: verify). During idle periods, the software polls the channel state 34 times per second for its live port status display.

Command

Fixed length of 3 words (6 bytes).

ID	Length?
0008	nnnn-nnnn

The two argument words look like a 32-bit length field in mixed endian (2-1-4-3) byte order. However, the software never uses any value other than 10 for this field, so it could just as well mean something completely different.

Response

The table below shows the response to the command as issued by the vendor software, i.e. with 10 (decimal) in the length field (if it is indeed a length field). Each row is a 64-bit word in very much mixed up (6-5-8-7-2-1-4-3) byte order.

Index	Byte offset	Value
0	00	Channel enable mask
1	08	???
2	10	???
3	18	???
4	20	???
5	28	Capture size (lower half apparently the same as register 1078)
6	30	???
7	38	???
8	40	Channel input state
9	48	??? (imperfect copy of #8?)

The channel enable mask and the input state are bit vectors, with bit 0 of the 64-bit word (after unmixing the byte order!) corresponding to CH1 and bit 33 corresponding to CH34. The enable mask shows which channels have been enabled for capturing. The bits in the input state vector signify whether the voltage at the corresponding input channels is currently low (0) or high (1).