Porting
The following sections of this document apply only to licensees of the full benchmark, which comes with firmware for the Arduino, and the Host GUI.
The monitor port code is in the directory “monitor/th_api”. It is recommended to port the software following this progression, starting with performance mode, then switching to energy mode once perf mode is working:
- Create an empty application for your DUT
- Configure a UART on the DUT for 115200 baud 8/N/1. This will change for energy mode.
- Connect the “ee_serial_callback” function to the UART receive function. This may be an interrupt or simply a “getch” in a loop if you are using retargeted IO. A lot of data will be sent down to the DUT during initialization. Typically, Rx bugs appear later on due to improperly sized receive buffers.
- Connect your DUT to your favorite terminal program and reset it. If the Tx is set up correct, you should see a welcome message followed by “m-ready\r\n”. This message is used extensively by the Host to know when the DUT is ready to receive more commands. Here we are just testing Tx.
- Next, send “name%” down to the DUT. The “%” is the command delimiter. The DUT should respond with “m-dut-name…”. If this works, it means the UART is functioning properly.
- Next port the th_timestamp function. This returns a value in microseconds, but the minimum resolution requires is milliseconds. So, if your system’s timer function reports milliseconds, simply multiply by 1000. You can also enable the energy mode GPIO here. In this function, you must pull an open-drain GPIO low for a minimum 2us. Delay using a for-loop, for example.
- Reboot the DUT and type “timestamp%” and it should return “m-lap-us…” with the current counter value.
At this point, the basic communication between the DUT and the Host GUI can be tested. Start the Host GUI. It will do a scan of the USB ports, and will report the discovered DUT in the Devices panel. If the DUT does not appear, try clicking “rescan”. The Host GUI is simply asking every available serial port “name%” and expecting the DUT response from step #5 above.
The profile port layer is in the directory “profile/th_api”. There are quite a few files here, each related to a specific cryptographic primitive. Almost every primitive requires an create, init, deinit, destroy API, and depending on the function there may be more required. The header files “ee_.h” have more details on what is expected in terms of data, key, and curve format. The “Sandbox” mode of the GUI is very helpful for testing the primitives as you port each one.
As stated earlier, the Host GUI will query the serial ports for a DUT. Once a DUT is found, use the “initialize” button to “mount” the device. Mounting the DUT opens the port and prepares the DUT for receiving commands. Switch to “Sandbox” mode in the GUI and experiment with various tests. Here we can test each primitive. EEMBC has a standard that in order for a benchmark to generate stable results, it must run for at least 10 seconds (or a minimum of 10 iterations). By setting the iteration count to zero in the sandbox, the GUI will determine the number of iterations required to achieve 10 seconds of measurement. In the example shown below, approximately 60,000 iterations were required for 10 seconds of runtime. A SHA256 with a 256 message takes 168 microseconds. Since the energy framework was not set up, there is no energy data. Verify all of the functions work, and then run the suites.
