IKALOGIC ScanaPLUS

IKALOGIC ScanaPLUS

Status	supported
Source code	ikalogic-scanaplus
Channels	9
Samplerate	100MHz
Samplerate (state)	—
Triggers	rising, falling, logic level, pulse width
Min/max voltage	-35V — 35V
Threshold voltage	configurable per channel-group: 1.2V, 1.5V, 1.8V, 2.8V, 3.3V to 5V
Memory	—
Compression	yes
Website	ikalogic.com

The IKALOGIC ScanaPLUS is a USB-based, 9-channel logic analyzer with up to 100MHz sampling rate.

See IKALOGIC ScanaPLUS/Info for more details (such as lsusb -vvv output) about the device.

Hardware

• FPGA with 1Mbit flash memory: Xilinx XC3S50AN (markings: "Xilinx Spartan XC3S50AN QTG144AGQ1301 D4518897A 4C") (datasheet)
• Hi-speed single-channel USB UART/FIFO: FTDI FT232H (markings: "FTDI D5RHQ.1 FT232HL 1230-B") (datasheet)
• 2x 4-bit dual-supply bus transceiver with configurable voltage translation & 3-state outputs: Texas Instruments SN74AVC4T774 (markings: "WT774 09K G4 CLS4") (datasheet)
• Low-power dual op-amp: ST LM358 (markings: "358 ET eZ022") (datasheet)
• 2Kbit Microwire EEPROM: Microchip 93LC56B (markings: "93LC56BI SN e3 1302 PVA") (datasheet)
• Dual 1.8V low-power push-pull output comparator: Microchip MCP6562 (markings: "MCP6562E SN e3 1301 RPH") (datasheet)

Photos

• 

  Package, top

• 

  Package, bottom

• 

  Package, open

• 

  Package, contents

• 

  Device w/ probes

• 

  Device, top

• 

  Device, bottom

• 

  Device, connector

• 

  Device, USB

• 

  Device, open 1

• 

  Device, open 2

• 

  PCB, top

• 

  PCB, bottom

• 

  Xilinx XC3S50AN

• 

  FTDI FT232H

• 

  TI SN74AVC4T774

• 

  TI SN74AVC4T774

• 

  ST LM358

• 

  Microchip 93LC56B

• 

  Microchip MCP6562

Protocol

The IKALOGIC ScanaPLUS always acquires samples at 100MHz (on all 9 channels at once), it is not possible to change that. However, the USB traffic is still reduced a bit due to the use of compression.

The highest supported, continuously-applying frequency of the input signal(s) for the ScanaPLUS is roughly 10MHz (say, a 10MHz SPI clock). For faster signals the USB bandwidth starts to become too limited and samples will be lost, which is (as far as we know) undetectable for the host software, thus the user can see captured data that is not actually correct. Note that it is possible to capture signals faster than 10MHz correctly in some situations, if that data only appears in small bursts (and not continuously).

FTDI chip init

The ScanaPLUS is connected to the PC via an FTDI FT232H chip (we use libftdi to talk to it) that gets configured to "Sync FIFO" mode by the software, allowing theoretical transfer speeds up to 40 Mbyte/second. The FT232H uses the standard VID/PID of 0403:6014, but has an iProduct field that contains the string "SCANAPLUS" so we can reliably say whether a given device with 0403:6014 as VID/PID is a ScanaPLUS or not. The device also has a proper iSerial, allowing to even uniquely distinguish two different ScanaPLUS devices connected to the same PC.

During init, the FT232's "interface A" (the only one in this IC) has to be selected and opened. Then, the RX/TX buffers are purged, to eliminate "old" data (if any) from the buffers.

The chip is then put into "Sync FIFO" mode, by first resetting the so-called "bitmode", then setting it to "Sync FIFO" (as per FTDI datasheet).

The FTDI chip latency timer is set to the lowest-possible value of 2ms (the hardware default is 16ms). What this does is that the IC will send data to the host either when the requested amount of bytes is reached (or buffers are full), or when 2ms have passed since the last time bytes were sent to the host, whichever happens first. This has performance/latency advantages (see AN_107 section 6.3, AN232B-04, and AN232B-03), but it also prevents the device from ever being put into USB suspend.

Finally, the read data chunk size is set to 64kB.

EEPROM

The ScanaPLUS has an I2C EEPROM connected to the FTDI FT232H which contains some parameters the FT232H uses.

Additionally, three bytes in the "user area" of the EEPROM are ScanaPLUS-specific. We're referring to them as the "magic bytes", since they seem to be different in each ScanaPLUS device, probably representing some kind of serial number or such. They have to be read from the EEPROM and sent (slightly modified) to the FPGA via a certain method, in order for the sampling to work later. If they're not sent, or the incorrect bytes are sent, the sampling will basically appear to work, but all probe values will be low (0), no matter which signal is actually applied to the probes.

The three bytes are located at EEPROM index 16 and 17 (the EEPROM is read in 16-bit units, so those two indices will yield 4 bytes, one of which is irrelevant).

Note: Bit 7 of the three bytes must not be used, apparently. Even though the three bits can be either 0 or 1 (we've seen both in actual ScanaPLUS devices), the device ID as sent to the FPGA has bit 7 of each byte zero'd out. It is unknown whether bit 7 of these bytes has any meaning, whether it's used somewhere, or whether it can be simply ignored.

Command format

The commands sent to the FPGA (via the FT232H) seem to always consist of two bytes.

The first byte is probably an identifier for the command to execute and seems to always have the high nibble set to 0x8 and/or bit 7 must always be set (?), i.e., possible commands seem to range from 0x80-0x8f. The second byte is then usually the data byte or parameter belonging to the command, and it seems to always have bit 7 cleared (?)

Initialization

First a 2-byte sequence is sent.

Byte	Description
0x88	?
0x41	?

The following 4-byte sequence probably sets default logic level thresholds for the probes (?)

Byte	Description
0x89	?
0x64	?
0x8a	?
0x64	?

Then the initial 2-byte sequence is sent again.

Byte	Description
0x88	?
0x41	?

It is followed by an 8-byte sequence.

Byte	Description
0x8d	?
0x01	?
0x8d	?
0x05	?
0x8d	?
0x01	?
0x8d	?
0x02	?

Next, a sequence of 57 chunks of 4 bytes each are transferred in a loop. The 4 bytes are:

Byte	Description
0x8d	?
0x06	?
0x8d	?
0x02	?

Finally, another 2-byte sequence finished the initialization.

Byte	Description
0x88	?
0x40	?

Starting an acquisition

An acquisition is started by sending a certain sequence of bytes to the FT232H as follows.

First, 4 bytes are sent which configure the probe group voltage thresholds.

Byte	Description
0x89	This is the "set threshold for probes 1-4" command.
0x7f	TODO.
0x8a	This is the "set threshold for probes 5-9" command.
0x7f	TODO.

Then, two bytes are sent which configure how probes 5/6 and 7/8 should work.

Byte	Description
0x88	This is the "configure probes 5/6 and 7/8" command.
?	TODO.

Before setting the 3 magic bytes, they are first cleared to 0x00.

Byte	Description
0x8c	This is the "set magic byte 1" command.
0x00	Set the magic byte to 0x00.
0x8e	This is the "set magic byte 2" command.
0x00	Set the magic byte to 0x00.
0x8f	This is the "set magic byte 3" command.
0x00	Set the magic byte to 0x00.

Finally, the 3 magic bytes (see above) are set.

Byte	Description
0x8c	This is the "set magic byte 1" command.
0xQQ
0x8e	This is the "set magic byte 2" command.
0xRR
0x8f	This is the "set magic byte 3" command.
0xSS

After the acquisition starts, a bunch of samples will be returned as all-zero, no matter which signals are actually present on the probes. This is probably due to the FPGA reconfiguring some of its internal state/config during this time. As far as we know there is apparently no way for the PC-side to know when this "reconfiguration" starts or ends. The FTDI chip will return all-zero "dummy" samples during this time, which is indistinguishable from actual all-zero samples.

We currently simply ignore the first 64kB of data (in the libsigrok driver) after an acquisition starts. Empirical tests have shown that the "reconfigure" time is a lot less than that usually.

Sample format and compression

After an acquisition has started, compressed samples are streamed to the PC continously.

A compressed chunk consists of two bytes. Bits [7:1] of the high byte encode how many samples this compressed chunk consists of (0-127). Bit 0 of the high byte and bits [7:0] of the low byte encode the states of the 9 probes (high/1 or low/0). Bit 0 of the low byte is the value of probe 1, Bit 7 of the low byte is the value of probe 8, and bit 0 of the high byte is probe 9.

Examples:

• 0xfe 0x00 means "127 sample periods ((0xfe >> 1) = 0x7f = 127) all 9 probes were low (0x00 0x00)".
• 0x30 0x07 means "24 sample periods ((0x30 >> 1) = 0x18 = 24) probes 1,2,3 were high and all others were low (0x00 0x07)".
• 0x31 0x07 means "24 sample periods ((0x31 >> 1) = 0x18 = 24) probes 1,2,3,9 were high and all others were low (0x01 0x07)".

The FPGA will always try to return as many samples as possible in a 2-byte compressed chunk. Let's assume data for 254 sample periods will be gathered. If during this time all probes are of the same value (e.g. low), the returned values will be 0xfe 0x00 0xfe 0x00 (4 bytes). If the probe values are always 0b000101010 during this time (probes 2,4,6 high and all others low), the returned values would be 0xfe 0x2a 0xfe 0x2a (4 bytes).

However, the more transitions occur duing the sampling time, i.e. the fewer sample values are the same for consecutive sample periods, the more bytes are needed to encode the compressed chunks. For example, if probe 3 is high for 50 periods, low for the next 50 periods, high for 50 periods, low for 50 periods, high for 50 periods, and low for the remaining 4 periods (all other probes low), this would yield 0x64 0x04 0x64 0x00 0x64 0x04 0x64 0x00 0x64 0x04 0x08 0x00 (12 bytes). It is easy to see that with increasing number of transitions (worse, if there are transitions on multiple probes even) the number of bytes required to encode the probe values into compressed chunks will increase dramatically. At some point the limited USB bandwidth (together with potential delays in reading and processing the data in software) will no longer be sufficient to transmit the number of bytes that would be required within a certain amount of time.

This is why the vendor states that for continuous input signals of frequencies higher than roughly 10MHz the displayed sample data may no longer be correct in some cases. It could be correct for frequencies even higher than 10MHz though, if that 10MHz data is not continuously applied but rather only in short bursts, with pauses between the bursts.

Triggers

Triggering seems to be a pure software function, the device/protocol doesn't seem to support any hardware-based triggering. Samples are continuously streamed to the PC, which then checks for the trigger conditions in that data "manually" in software.

Resources

• Specification
• Manual
• Vendor software