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
- on application start,
- when switching clocking mode between internal, external/rising or external/falling,
- 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 70kB.
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.
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 likely either in little endian or in mixed endian byte order.
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: Read Channel State ???
This command appears to read data from a streaming source, as there is no apparent address information. The software issues 34 of those in sequence every second when idle, likely in order to read out the state of each input channel.
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
Tentatively, if the message does indeed carry a length field: The response is a sequence of 64-bit words, i.e. 80 bytes for a length of 10.