Difference between revisions of "Sysclk LWLA1034/Protocol"

From sigrok
Jump to navigation Jump to search
(Document more capture state fields)
(Elaborate on mystery command 5)
Line 186: Line 186:
=== Command 0005: Write ??? ===
=== Command 0005: Write ??? ===


This command appears to write 16 32-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.
This command appears to write 16 32-bit words at once. The vendor software issues this after a transfer of captured data to the host has finished, but only for the first three captures. After that, the application needs to be restarted to ever see this command again.
 
The data written varies each time, but it appears that only the lowest 8 bit of each 32-bit word are ever written. No idea what this might do, or if it is even necessary at all. It could be calibration feedback or something, although it is hard to imagine how the host could help the device with that.


==== Command ====
==== Command ====

Revision as of 15:46, 1 January 2014

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 size of the bitstream varies due to compression, but is in the order of 50kB to 80kB. The firmware transfer is split by the vendor software into packets with 15 byte payload each and thus takes quite a bit of time inside VirtualBox. Testing with a libusb-based tool for issuing USB bulk transfers has shown that this does not appear to be necessary: Transferring even the entire firmware blob in a single bulk transfer appears to work without error.

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. The vendor software polls these counters every second to display a live frequency count for the first four channels.

It is not clear yet what time base is being used for those counters: The large error (sometimes by more than 20%, especially for CH1) hints at I/O latency. However, manual testing of single register reads has shown that the values do not seem to scale with the time between reads. This would mean the device is using an internal time base after all, but that makes the large error a bit hard to explain, especially since the error is different for each channel despite being driven by the same signal source.

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

These three registers assume the values listed here after writing 100 (decimal) to register 10B4. This is apparently an identification and self-test sequence, which is performed twice in a row during initialization.

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 into order to start the self test sequence. After that, the magic register values listed in the table for command 0001 become available. So this is kind of a command-triggering register,and there are other command codes, too.

Address Purpose
1094 Bypass clock divider
10B4 ???
10B8 ???
10BC ???

These are written to when a capture is initiated. Register 1094 is set to 0 when using the internal clock with sampling rates of 100 MHz and below. For 125MHz internal clock or the external clock modes, it is set to 1.

Address Init value
1074 00000002
107C 00000000

The vendor software writes these two registers during initialization, and also when initiating a capture.

Command 0005: Write ???

This command appears to write 16 32-bit words at once. The vendor software issues this after a transfer of captured data to the host has finished, but only for the first three captures. After that, the application needs to be restarted to ever see this command again.

The data written varies each time, but it appears that only the lowest 8 bit of each 32-bit word are ever written. No idea what this might do, or if it is even necessary at all. It could be calibration feedback or something, although it is hard to imagine how the host could help the device with that.

Command

Fixed length of 33 words (66 bytes).

ID Data 1 Data 2 ... Data 16
0005 dddd-dddd dddd-dddd ... dddd-dddd

The byte order of each 32-bit word is most likely the usual 2-1-4-3 mixed endianess.

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: Capture Setup

This command prepares a capture operation. Essentially, this command appears to write a slice to an internal memory block with 64-bit granularity. Command 0008 can be used to read from the same memory.

The vendor software issues this command once during start-up, and once for each capture operation as part of the setup sequence. It is also issued when clicking the Stop button to cancel a capture in progress.

Command

Variable length of 3 words (6 bytes) plus length × 8 bytes.

ID Address Length Data ...
0007 aaaa nnnn dddd-dddd-dddd-dddd ...

The two argument words are the start address and the length of the slice to write, in little endian byte order. Both the address and the length refer to quantities of 64 bit (8 byte). Thus, if length is 10 the payload should consist of 80 bytes.

The vendor software always writes a slice of length 10 at address 0, thus completely resetting the channel status as read by command 0008.

Command 0008: Capture Status

This command poll the current status of the input channels. Essentially, this command appears to read a slice from an internal memory block with 64-bit granularity. 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 Address Length
0008 aaaa nnnn

The two argument words are the start address and the length of the slice to read, in little endian byte order. Both the address and the length refer to quantities of 64 bit (8 byte). Thus, if length is 10 the reply will consist of 80 bytes.

Response

The table below shows the response to the command as issued by the vendor software, i.e. with start address 0 and length 10. 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 Clock divider count
2 10 Trigger level mask
3 18 Trigger edge mask
4 20 Trigger enable mask
5 28 Running capture memory size
6 30 ???
7 38 Running capture cycle count × 10−5
8 40 Channel input state
9 48 Capture status flags

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).

Field 1 sets the max value of the counter which divides the internal clock to yield the sampling clock. This applies to all sample rates of 100MHz or less (125MHz is a special case: see control register 1094). The counter max value is calculated as follows: maxcount = 1 / (samplefreq * 10ns) - 1

Field 4 is the trigger enable mask. 1 enables triggering on a channel, 0 disables it. CH1 is mapped to bit 0 and CH34 to bit 33. Bits 34 and 35 are special and configure for external triggering. Bit 34 enables external triggering on the falling edge, bit 35 on the rising edge.

If a trigger channel is enabled, the corresponding bit in field 3 configures whether to trigger on level (0) or edge (1). The corresponding bit in field 2 then selects whether to trigger on low/falling (0) or high/rising (1).

Capture Status Flags

The status flag bits appear to have the following meaning:

Bit 0 Bit 1 Bit 2 Bit 3 Bit 4 Bit 5
??? Capturing ??? ??? Triggered Memory available