Difference between revisions of "Kingst LA Series"
(background colour for supported state) |
(Add wikilink for 5032) |
||
| (2 intermediate revisions by one other user not shown) | |||
| Line 18: | Line 18: | ||
Several devices share the same USB VID:PID identification. It even appears as if these values are not specific to the logic analyzers: Linux' lsusb command "mistakes" these as a camera (though this is just a matter of display text presentation, neither a functional limitation nor a conflict). | Several devices share the same USB VID:PID identification. It even appears as if these values are not specific to the logic analyzers: Linux' lsusb command "mistakes" these as a camera (though this is just a matter of display text presentation, neither a functional limitation nor a conflict). | ||
Kingst LA models can either capture to local memory first and upload sample data to the host afterwards (when the model has local memory). Or alternatively can stream samples to the host while the capture is being taken (the USB channel limits the product of samplerate and enabled channels that can get communicated). | |||
== Devices == | == Devices == | ||
| Line 58: | Line 60: | ||
|- | |- | ||
| Kingst LA5032 | | [[Kingst LA5032]] | ||
| style="text-align:center" | 500 MHz | | style="text-align:center" | 500 MHz | ||
| style="text-align:center" | 32 ch | | style="text-align:center" | 32 ch | ||
| style="text-align:center" | 512 MiB | | style="text-align:center" | 512 MiB | ||
| bgcolor=" | | bgcolor="lime" style="text-align:center" | tested | ||
|} | |} | ||
Most of the support became available in 2022-02, versions before that date may only support individual models. | Most of the support became available in 2022-02, versions before that date may only support individual models. LA5032 support got unbroken in 2022-10. | ||
== Hardware == | == Hardware == | ||
| Line 85: | Line 87: | ||
The LA1016 and LA2016 devices are said to have identical hardware, only their FPGA firmware differs. TODO The LA1010 may or may not share the LA1016 hardware, the base clock could be an internal implementation detail of the FPGA. The LA5016 and LA5032 devices may or may not share hardware (input protection for the upper 16 channels and additional memory may reside on the bottom layer). These details need verification when these models are seen in the field. | The LA1016 and LA2016 devices are said to have identical hardware, only their FPGA firmware differs. TODO The LA1010 may or may not share the LA1016 hardware, the base clock could be an internal implementation detail of the FPGA. The LA5016 and LA5032 devices may or may not share hardware (input protection for the upper 16 channels and additional memory may reside on the bottom layer). These details need verification when these models are seen in the field. | ||
The internal implementation of clocks differs across models. The LA1010 uses an 800MHz base clock and supports up to 100MHz samplerate. The LA1016 and LA2016 devices use a base clock which is identical to their 100MHz/200MHz maximum samplerate. The LA5016 | The internal implementation of clocks differs across models. The LA1010 uses an 800MHz base clock and supports up to 100MHz samplerate. The LA1016 and LA2016 devices use a base clock which is identical to their 100MHz/200MHz maximum samplerate. The LA5016 and LA5032 use an 800MHz base clock to derive their samplerates from, while a divider of 1 will result in a 500MHz samplerate, divider 4 is used for 200MHz samplerate. | ||
For images which show the cases, connectors, and PCBs see the individual devices' pages. The models up to 200MHz come in a plastic case with a smaller outline and a 20pin connector for the logic probes and PWM. The 500MHz models have a larger PCB and a 40pin connector in a metal case. | For images which show the cases, connectors, and PCBs see the individual devices' pages. The models up to 200MHz come in a plastic case with a smaller outline and a 20pin connector for the logic probes and PWM. The 500MHz models have a larger PCB and a 40pin connector in a metal case. | ||
== Photos == | |||
<gallery> | |||
File:Kingst la2016 mugshot.png|<small>LA2016 mugshot</small> | |||
File:Kingst-la5016-mugshot.png|<small>LA5016 mugshot</small> | |||
File:Kingst-la5016-size-compared.png|<small>LA5016 and LA2016 side by side</small> | |||
File:Kingst-la5016-connectors.png|<small>LA5016 and LA2016 probe connectors</small> | |||
</gallery> | |||
== Protocol == | == Protocol == | ||
| Line 97: | Line 108: | ||
Acquisition is completely driven by the device's hardware. A configuration gets sent to the device, specifying enabled channels, samplerate, samples count, trigger parameters. The hardware acquires data from the logic probes and writes it to local RAM. After the acquisition has completed, the host can download the captured data. Hardware compression is transparent, some 50MSa are guaranteed (model dependent). Oversampling and slowly changing input data can result in the ability to squeeze a few hundred MSa into RAM before the memory capacity is exhausted, this heavily depends on the input signal's pattern. The announced 10GSa capacity with compression enabled is a theoretical value that is hardly seen in practice. | Acquisition is completely driven by the device's hardware. A configuration gets sent to the device, specifying enabled channels, samplerate, samples count, trigger parameters. The hardware acquires data from the logic probes and writes it to local RAM. After the acquisition has completed, the host can download the captured data. Hardware compression is transparent, some 50MSa are guaranteed (model dependent). Oversampling and slowly changing input data can result in the ability to squeeze a few hundred MSa into RAM before the memory capacity is exhausted, this heavily depends on the input signal's pattern. The announced 10GSa capacity with compression enabled is a theoretical value that is hardly seen in practice. | ||
All devices in the family support streaming mode. Most of them in addition to or as an alternative to local storage before download, the memory-less LA1010 as the only supported mode of operation. All of the preparation (device identification, firmware download, acquisition setup, sample data upload from USB endpoint 6) is identical to "normal mode" as the vendor calls it. But sample data upload immediately starts when the acquisition gets initiated. The device will neither use local memory for buffering, to compensate for bursts in the input data and slow USB communication to the PC. Nor will the device apply RLE compression on the sample data | All devices in the family support streaming mode. Most of them in addition to or as an alternative to local storage before download, the memory-less LA1010 as the only supported mode of operation. All of the preparation (device identification, firmware download, acquisition setup, sample data upload from USB endpoint 6) is identical to "normal mode" as the vendor calls it. But sample data upload immediately starts when the acquisition gets initiated. The device will neither use local memory for buffering, to compensate for bursts in the input data and slow USB communication to the PC. Nor will the device apply RLE compression on the sample data. Bits only get shifted in ways similar to Saleae-Logic16 to reduce the amount of USB traffic while uncompressed data gets communicated (disabled channels need not get sent, but enabled channels' data is not compressed). Successful reception of sample data in streaming mode heavily depends on the whole chain from the device to the host application and its capability to process the steady USB communication at high Mbps rates. The vendor software assumes a limit of some 300Mbps (sample rate multiplied by the number of enabled channels). | ||
Many of the FPGA registers are read-only or write only, which prevents reading back a configuration that previously was written to the device. When registers support read and write, their meaning differs depending on the direction of data exchange. This means that sigrok software cannot re-use a previous configuration across sessions, instead always needs to start from default values. This is a limitation of the vendor firmware, not the sigrok driver. | Many of the FPGA registers are read-only or write only, which prevents reading back a configuration that previously was written to the device. When registers support read and write, their meaning differs depending on the direction of data exchange. This means that sigrok software cannot re-use a previous configuration across sessions, instead always needs to start from default values. This is a limitation of the vendor firmware, not the sigrok driver. | ||
Latest revision as of 08:18, 12 January 2023
 | |
| Status | supported |
|---|---|
| Source code | kingst-la2016 |
| Channels | 16 — 32 |
| Samplerate | 100MHz — 500MHz |
| Samplerate (state) | — |
| Triggers |
Level (multiple channels) Edge (one channel) |
| Min/max voltage | -50V — 50V tolerant |
| Threshold voltage | -4.0V—+4.0V, min step 0.01V |
| Memory | 0Gib — 4Gib RAM (0-512MiB) |
| Compression | Yes |
| Website | qdkingst.com |
The Kingst LA Series spans across a set of USB based, 16 or 32 channel logic analyzers with 100MHz to 500MHz maximum samplerate and up to 1Gib to 4Gib (128MiB to 512KiB) sample memory, one of the models without any local memory. One common kingst-la2016 sigrok driver supports all devices in the series.
Several devices share the same USB VID:PID identification. It even appears as if these values are not specific to the logic analyzers: Linux' lsusb command "mistakes" these as a camera (though this is just a matter of display text presentation, neither a functional limitation nor a conflict).
Kingst LA models can either capture to local memory first and upload sample data to the host afterwards (when the model has local memory). Or alternatively can stream samples to the host while the capture is being taken (the USB channel limits the product of samplerate and enabled channels that can get communicated).
Devices
| Device name | samplerate | channels | memory | supported |
|---|---|---|---|---|
| Kingst LA1010 | 100 MHz | 16 ch | — | untested |
| Kingst LA1016 | 100 MHz | 16 ch | 128 MiB | tested |
| Kingst LA2016 | 200 MHz | 16 ch | 128 MiB | tested |
| Kingst LA5016 | 500 MHz | 16 ch | 256 MiB | tested |
| Kingst LA5032 | 500 MHz | 32 ch | 512 MiB | tested |
Most of the support became available in 2022-02, versions before that date may only support individual models. LA5032 support got unbroken in 2022-10.
Hardware
TODO Move the common part of the hardware from Kingst LA2016 here.
Most devices share some fundamental properties. Differences are few.
- Cypress FX2 MCU
- Cyclone IV FPGA
- Samsung(?) DRAM
- AT24 EEPROM
- U10 "hardware dongle"
- voltage regulation
- opamp, input threshold control
- TVS diodes
The LA1016 and LA2016 devices are said to have identical hardware, only their FPGA firmware differs. TODO The LA1010 may or may not share the LA1016 hardware, the base clock could be an internal implementation detail of the FPGA. The LA5016 and LA5032 devices may or may not share hardware (input protection for the upper 16 channels and additional memory may reside on the bottom layer). These details need verification when these models are seen in the field.
The internal implementation of clocks differs across models. The LA1010 uses an 800MHz base clock and supports up to 100MHz samplerate. The LA1016 and LA2016 devices use a base clock which is identical to their 100MHz/200MHz maximum samplerate. The LA5016 and LA5032 use an 800MHz base clock to derive their samplerates from, while a divider of 1 will result in a 500MHz samplerate, divider 4 is used for 200MHz samplerate.
For images which show the cases, connectors, and PCBs see the individual devices' pages. The models up to 200MHz come in a plastic case with a smaller outline and a 20pin connector for the logic probes and PWM. The 500MHz models have a larger PCB and a 40pin connector in a metal case.
Photos
LA2016 mugshot
LA5016 mugshot
LA5016 and LA2016 side by side
LA5016 and LA2016 probe connectors
Protocol
Several devices share the same USB identification (VID and PID). The PID determines which FX2 MCU firmware to upload to the device. Once the MCU firmware is in place (which involves USB renumeration), USB communication can access EEPROM content, which allows to identify the device type. Which determines the device's capabilities (maximum samplerate, channel count, memory depth), and the FPGA bitstream to upload to the device. The FPGA logic will automatically verify its matching the device hardware by communicating to IC U10, loading non-matching bitstreams will not enable features which the device does not provide in its proper configuration.
The device's firmware provides two (three) USB endpoints. EP2 is write only and is used to upload FPGA bitstreams. EP6 is read only and downloads captured sample data by means of USB bulk transfers. EP0 supports USB control transfers to configure the device and supervise its operation.
Acquisition is completely driven by the device's hardware. A configuration gets sent to the device, specifying enabled channels, samplerate, samples count, trigger parameters. The hardware acquires data from the logic probes and writes it to local RAM. After the acquisition has completed, the host can download the captured data. Hardware compression is transparent, some 50MSa are guaranteed (model dependent). Oversampling and slowly changing input data can result in the ability to squeeze a few hundred MSa into RAM before the memory capacity is exhausted, this heavily depends on the input signal's pattern. The announced 10GSa capacity with compression enabled is a theoretical value that is hardly seen in practice.
All devices in the family support streaming mode. Most of them in addition to or as an alternative to local storage before download, the memory-less LA1010 as the only supported mode of operation. All of the preparation (device identification, firmware download, acquisition setup, sample data upload from USB endpoint 6) is identical to "normal mode" as the vendor calls it. But sample data upload immediately starts when the acquisition gets initiated. The device will neither use local memory for buffering, to compensate for bursts in the input data and slow USB communication to the PC. Nor will the device apply RLE compression on the sample data. Bits only get shifted in ways similar to Saleae-Logic16 to reduce the amount of USB traffic while uncompressed data gets communicated (disabled channels need not get sent, but enabled channels' data is not compressed). Successful reception of sample data in streaming mode heavily depends on the whole chain from the device to the host application and its capability to process the steady USB communication at high Mbps rates. The vendor software assumes a limit of some 300Mbps (sample rate multiplied by the number of enabled channels).
Many of the FPGA registers are read-only or write only, which prevents reading back a configuration that previously was written to the device. When registers support read and write, their meaning differs depending on the direction of data exchange. This means that sigrok software cannot re-use a previous configuration across sessions, instead always needs to start from default values. This is a limitation of the vendor firmware, not the sigrok driver.
See Kingst LA2016/Protocol for more developer notes and captures that were taken during protocol research.
Firmware
In order to use this device you need to extract the firmware/FPGA files from the vendor software (Linux download) using the sigrok-fwextract-kingst-la2016 script from the sigrok-util repo and place them in one of the usual places where libsigrok expects firmware files:
$ ./sigrok-fwextract-kingst-la2016 KingstVIS/KingstVIS saved 5430 bytes to kingst-la-01a2.fw (crc32=720551a9) saved 178362 bytes to kingst-la2016a1-fpga.bitstream (crc32=7cc894fa) saved 178542 bytes to kingst-la2016-fpga.bitstream (crc32=20694ff1) ...