-
Notifications
You must be signed in to change notification settings - Fork 3
Basic Concepts
In performance mode, the DUT connects to the host computer via a USB port two possible ways:
- Through an on-board debugger that exposes a UART from the DUT to the host OS as a serial port
- Through a USB/TTL cable that connects directly to the Tx/Rx UART pins on the DUT
In performance mode, the DUT UART runs at 115200 baud, 8N1. How the Host GUI detects and communicates with the DUT, and the protocol, is explained later.
Energy mode measures the total energy used by the DUT by using an energy monitor (EMON) that supplies an input VCC from 3.3V to 1.8V. The supported energy monitor is the STMicroelectronics LPM01A. In order to supply power, the DUT must be electrically isolated from the host. This is accomplished by using an “IO Manager” which is an Arduino that passes the serial messages from/to the Host to/from the DUT through level shifters. This way, the EMON can power cycle the DUT in conjunction with the IO Manager to prevent disturbing the USB connection to the host.
In energy mode, the DUT UART must be set to 9600 baud, because that is the maximum speed of the proxy through the IO Manager.
The benchmark consists of the core functions and the port layer functions. Core functions start with “ee_” and cannot be edited. Port-layer functions start with “th_” and must be edited. The “th_” functions are located in files under “th_api” directories to help keep the code segregated. For example, a core function “ee_bench_sha” will ultimately call “th_sha_init” and “th_sha_update”. The high-level bench function coordinates execution by using the underlying SHA implementation, whatever it may be.
The code is split into two main sections: the monitor and the profile. The monitor contains the primary interface function “ee_main”, the callback required to parse the UART instructions, and the timestamp function. It also contains a layer of LIBC functions used by the benchmark in case there is a need to modify them. The profile contains the code specific to the benchmark, which in this case are the cryptographic primitive functions.
After the DUT boots, the benchmark waits for UART input from the Host. Each character received by the UART is processed by “ee_main:ee_serial_callback()”. Once a command terminator is parsed, the command is sent to “ee_main:ee_serial_command_parser_callback()” function. This way the Host GUI can configure the DUT and trigger execution.
The DUT requires a small 5K buffer. This buffer is used to load keys, ciphertext, and plaintext from the Host. The host does this in order to verify operation of the benchmark to prevent cheating. It treats the DUT as if it were an external crypto accelerator. It never asks for private keys, and assumes that the DUT is a black box.
The Host will test one primitive at a time (SHA, ECC, RSA, etc.). The middle functions between the host command and the port-layer are described in the header files. As stated earlier, ultimately all of these middle functions resolve to a simple set of cryptographic primitive functions that are aligned with all modern crypto libraries.
In performance mode, the DUT port-layer requires a minimum 1 ms timer interface for measuring performance. This is the “th_timestamp” function. In energy mode, this function also produces a falling edge on a GPIO (for ~2us) which is used to synchronize the EMON for energy measurement.
Scoring, verification, and configuration is all performed by the Host GUI, described in the next section.
The Host GUI application coordinates execution of the benchmark suites and testing via the sandbox. It will detect and configure devices for performance and energy mode. It is provided as an executable for Windows 11, MacOS and Ubuntu Linux.