ArticlesSoft Core Firmware-Based Board Management Module for High Performance Blockchain/Fintech Servers
As blockchain and fintech technologies are in the spotlight recently, the need for high-performance computing server management technology is increasing. A baseboard management controller (BMC) can communicate with remote sites through Ethernet/LAN and is designed to connect with external devices through various methods. In this study, we have researched BMC technology architecture operating on top of NIOS soft core. TheBMCadoptsvarious intellectual propertiessuchaspower management,PMBus,inter-integrated circuit(I2C),DRAM,flash controllers,andpulse width modulation(PWM)which modulates the duty ratio according to the ADC-related temperature scope dependingon user commands. We aimed at implementing BMC with stability and better transient response usingPMBus. The PMBus command processing and implementation methods for power management integrated circuit (PMIC) control in BMC firmware, such as VOUT_COMMAND and POWER ON/OFF commands. As a result of the experiment, we compared to conventional OpenBMC platform in terms of startup time. The time required for initial boot-up was reduced by about half. Therefore, this research is meaningful that we construct our own BMC which operates on a special purpose/board through a customized BMC.
Board Management Module, Blockchain Server, Fintech Server, IPMI, PMBus, Embedded System
A baseboard management controller (BMC) performs intelligent management, monitoring, and recovery for high-performance servers using the IPMI standard[1–3]. The BMC is extremely labor efficient. The administrator no longer needs to physically connect with each server in the rack to perform maintenance tasks. In modern data-centers, which could have hundreds of racks and thousands of servers, it would be impossible to live without BMC[4, 5]. As a result, all modern servers, and other devices used in a data center, now have a BMC. Its key advantage is that it allows a system administrator to perform variety of monitoring and management tasks remotely, without having to stay physically near the system or connected to it. The BMC will also notify the administrator if there is hardware failure or another kind of fault[6, 7].
While high-performance server makers for blockchain and fintech platform such as HP, Sun, IBM, and Dell are expanding their markets centered on system software for server management, BMC chipset developers such as AMI and ASPEED are focusing on hardware for server management. Intel, which dominates the PC market rather than the server market, uses AMT technology, which is a hardware platform that applies BMC server-management technology to the PC market. The server interface through BMC is structurally relatively simple, and management efficiency has excellent advantages in terms of cost and performance. Therefore, the application of BMC for remote management will expand in the future. The hardware system-management technology based on the IPMI standard is expected to increase system interoperability. It is also expected to further improve the functions, management structure, and types of BMCs[8, 9].
There is a solution for platform management. The BMC power-module test bed developed in this study can work as a basic platform for full-scale hardware and software architecture design in BMC firmware development. This study is meaningful in the following ways: higher demand for BMC in terms of remote/autonomous management related to performance/cost/energy/thermal efficiency for high performance data center servers in field of blockchain/fintech;improvement of hardware system-management technology level based on the IPMI standard;securing potential for development of management/policy-based resource management;utilized as a preliminary study for firmware technology development in future BMC technology;utilization of base technology for power management/monitoring-related firmware analysis/implementation in future BMCs;verification and implementation of the power management bus  protocol operation of the BMC firmware according to the technology acquisition through implementation of the power management bus (PMBus) protocol of the FPGA-based BMC HW/SW;and development of power-capping technology on BMC firmware using DCMI technology[11–13].
The rest of the paper is structured as follows. In Section 2, we discuss related work in this field. In Section 3, we present the proposed methodology. In Section 4, we describe the performance evaluation of the proposed system. Finally, we present the conclusions of our research in Section 5.
In overseas markets, various projects are being carried out mainly in the United States, Europe, and Asia. Most of the business is to collaborate with finance companies and pinch companies related to block chains to provide a new financial business model. Most of them do not go through exchanges but users can conveniently use financial services such as remittance and securities will be. As card-oriented products, card-shaped products are currently being marketed mainly by motherboard makers, and major server companies are making their own boards. In the case of ASUS, which is mainly a leader of PC board makers, a card-type management board is manufactured under the product name ASMB3-SOL and mounted on its own server board. This card supports IPMI 2.0, SO-DIMM interface, and remote real-time monitoring and control functions with serial-over-LAN (SOL) function. It includes platform event trap (PET) and system event log (SEL). It has remote power control function[14, 15].
Emulex Corporation provides network connectivity, monitoring and management hardware and software. I/O connectivity products, including Ethernet and Fiber Channel-based connectivity products, were used in server and storage products from OEMs such as Cisco, Dell, EMC, Fujitsu, Hitachi, HP, Huawei and IBM, and were acquired by Broadcom Limited. In 2016, ASPEED Technology Inc. acquired Broadcom's Emulex Pilot. The BMC is a key element in reducing the costs associated with server management. The Pilot 3 controller integrates BMC, Super I/O, graphics controller and remote keyboard, video, mouse and storage (KVMS) functions into a single ASIC, which provides significant cost savings for data center managers. The integrated BMC (iBMC), Like BMC, when embedded in a server system or appliance, reduces TCO by simplifying the management of remote server systems and appliances, whether physical or virtual. Fig. 1 and Table 1 show the ASPEED Technology’s AST2500 board and peripheral devices.
Nuvoton Technology Corporation is a semiconductor established semiconductor company in China, a wholly owned subsidiary of Winbond Electronics Corp., spun off from Winbond, commenced operations in 2008, and went public in 2010. Nuvoton’s baseboard management controllers include Virtual Media and Keyboard, Keyboard/Video/Mouse They also combined 2D/VGA compatible PCI interface with redirection module. Nuvoton interfaces with the host system via PCI to communicate with the graphics core, and supports USB 2.0 and 1.1. It also provides an LPC interface to control the Super I/O function and connects to the network through an external Ethernet PHY module or shared NCSI connection.
Fig. 1. Board management module on a commercial PC platform.
Example platform specification
||800 MHz ARM11
||DDR3/1600Mbps DDR4 SDRAM
||SPI flash memory
||Video Redirection up to 1920×1200
||Video Compression, 24 bits video compression quality
||USB 2.0 virtual hub controller with 5 devices supported
||USB 1.1 HID device controller
Renesas Electronics Corporation is a Japanese semiconductor manufacturer headquartered in Tokyo, with manufacturing, design and sales operations in approximately 20 countries. Renesas Electronics Corporation, known as a manufacturer of automotive semiconductors and microcontrollers, also implements mixed-signal integrated circuits and systems on chip semiconductors. Renesas’ BMC products include the H8S engine family[19
The BMC chip constituting the server's main board monitors the status through communication with the sensors installed in each hardware. It performs functions such as event logging and recovery control. However, if the physical specifications of each hardware or protocol/port number do not match, communication between the BMC and the sensor is impossible. In addition, the trend of using clusters and distributed systems rather than building large-capacity servers has increased, resulting in increased operational costs, and increased demands for common standards required to operate heterogeneous servers. Therefore, various server management standards such as IPMI, WBEM, SMASH, and WS-MAN have been developed to solve this problem. Investigation and comparison/analysis of specifications and functions were performed[22
]. IPMI has a BMC chip as a core element, and functions such as hardware monitoring, recovery control, logging, and inventory independently of the server’s CPU or BIOS and operating system. It also controls servers existing in the local and remote locations in the in-band method and out-of-band method, respectively. Although there are various companies that manufacture BMC chips, we conducted an analysis on well-known companies[25
Proposed Methodology for Board Management Module
Board Management Controller using FPGA
We built a test-bed environment using a field programmable gate array (FPGA)-based BMC controller for a stable digital power supply by server-voltage regulation. We utilized a DC-DC voltage regulator (converter) and a digital power conversion/control evaluation environment using Altera FPGAs, FDMF5823, and ED810 chips. This research establishes a power module evaluation environment that connects the FPGA BMC board and PMbus. BMC was written using Verilog HDL, a hardware-design language. It is compiled(synthesized) using the Altera Quartus. The BMC developed in this research performs various functions such as chassis control, fan control, sensor management, event logging, and fan-motor control. These functions are performed according to temperature changes through various interfaces such as GPIO and I2C (inter-integrated circuit). The study performs basic fan control, sensor management, and communication between the FPGA board and the power module board using PMBus over the I2C protocol. This section shows how to use the PMBus interface to control power-up sequencing using the MAX10 device as a BMC. The MAX10 FPGA development board does not contain a DC fan or PMBus-based power module. Therefore, we implemented through an external hardware chipset[26
]. Figs. 2 and 3 show the FPGA hardware RTL (register transfer level) design and IP used.
Fig. 2. FPGA hardware RTL design and used IP.
Fig. 3. Verification of the operation between the MAX10 FPGA and power module connections.
BMC Daughter Board for Power Control
The power module controller in this research provides a power stage solution optimized for high current and high frequency. It is a driver IC with a reduced dead time and propagation delay for performance improvement. It also provides temperature sensing and warning functions monitor and warn of potentially overheating conditions. In the event of overheating, a thermal shutdown function stops the driver.
Fig. 4 shows the top and bottom views of the PCB layout of our daughter board. It comprises a power management integrated circuit for voltage regulation; DC-DC switching controller, which utilizes Altera Semiconductor’s ED8101P00QI chipset, for power management through scalable current and programmable sequencing; and multiple buck regulators for high-efficiency conversion through continuous current flow when driving a square wave switch based on PWM and then switching it off.
Fig. 4. PCB layout (single phase board): (a) top view and (b) bottom view.
The power module has a dedicated set of PMBus registers that enable advanced power management with extensive monitoring functions. The PMBus master can verify the normal operation of the power converter by reading various warnings and fault flags or monitoring the converter over its lifetime. The PMBus commands supported by the power module are as follows. The OPERATION command is used to turn the device on and off with input from the CONTROL pin. The device remains in the commanded mode of operation until a subsequent OPERATION command or change in the CONTROL pin state instructs the device to change to another mode. Some supported operating modes are listed as follows:
CLEAR_FAULTS: This is used to clear the error bit set in the status register.
VOUT_MODE VOUT_MODE: This is used to retrieve information about the data format for all output voltage related commands.
STATUS_BYTE STATUS_BYTE: This returns a summary of the most significant errors in one byte.
STATUS_WORD STATUS_WORD: This returns a summary of the device status information in the form of two data-bytes.
BMC Firmware Architecture
The board support package (BSP) is a device driver for the minimum device for loading the operating system as a bundle of software enabling the target board to be used. It also has a bootloader or a program for boot management. It initializes various systems such as processors, communication buses, and clocks to operate the board, as shown in Fig. 5. The peripheral devices of the target board can be initialized, and various environmental variables can be set for working with the operating system. In this study, a BSP based on NIOS II (an SW processor) was used as the target board in Altera’s MAX10 FPGA board.
The features of the implemented test PMBus firmware are as follows:
(1) BSP HAL: BSP hardware abstraction layer is designed to directly access specific parts of the platform and hardware resources. It is also a structure that calls the “main” function of the application (External) while this firmware is running (Implemented at HAL/src/alt_main.c of bmc_bsp).
(2) On target CPU, the C/C++ add-on are executed as shown in Figs. 5 and 6. For the firmware development environment we make use of the Eclipse integrated development environment as shown in Fig. 7. The Altera Quartus is used to enable Qsys port/address linkage. The environment variables for system setting of BSP are presented in Table 2.
Fig. 5. Abstraction diagram for BSP.
Fig. 6. The process of invoking in NIOS II platform applications.
Fig. 7. (a) BSP development environment setup (Eclipse based) and (b) the firmware execution on NIOS II hardware using Eclipse.
The firmware is driven by an assembly program loaded at address 0. The assembly firmware is initiated by the RESET signal of the NIOS processor on the FPGA BMC board. The firmware starts from the BSP and calls the application's main function. The memory map for the hardware resources to be used in the NIOS II platform is shown in Table 3.
BSP major setting environment variable
||Enable driver ioctl() support. This feature is not compatible with the 'small' driver; ioctl() support will not be compiled if either the UART 'enable_small_driver' or HAL 'enable_reduced_device_drivers' settings are enabled.
||Small-footprint (polled mode) driver
||When your application exits, close file descriptors, call C++ destructors, etc. Code footprint can be reduced by disabling clean exit. If disabled, adds -DALT_NO_CLEAN_EXIT to ALT_CPPFLAGS -D'exit(a)=_exit(a)' in public.mk.
||Add exit() support. This option increases code footprint if your "main()" routine does "return" or call "exit()". If false, adds -DALT_NO_EXIT to ALT_CPPFLAGS in public.mk, and reduces footprint.
||Enables lightweight device driver API. This reduces code and data footprint by removing the HAL layer that maps device names (e.g. /dev/uart0) to file descriptors. Instead, driver routines are called directly. The open(), close(), and lseek() routines will always fail if called. The read(), write(), fstat(), ioctl(), and isatty() routines only work for the stdio devices. If true, adds -DALT_USE_DIRECT_DRIVERS to ALT_CPPFLAGS in public.mk.
||Enables use of a separate exception stack. If true, defines the macro ALT_EXCEPTION_STACK in linker.h, adds a memory region called exception_stack to linker.x, and provides the symbols __alt_exception_stack_pointer and __alt_exception_stack_limit in linker.x.
||Enables use of a separate interrupt stack. If true, defines the macro ALT_INTERRUPT_STACK in linker.h, adds a memory region called interrupt_stack to linker.x, and provides the symbols __alt_interrupt_stack_pointer and __alt_interrupt_stack_limit in linker.x.
||Size of the exception stack in bytes.
||Size of the interrupt stack in bytes.
||Slave descriptor of the system clock timer device. This device provides a periodic interrupt ("tick") and is typically required for RTOS use. This setting defines the value of ALT_SYS_CLK in system.h.
The assembly source code, crt0.S, for hardware initialization and memory setting is executed. Examples include device initialization, BSS area, stack area acquisition, etc. Then, the alt_main() function defined in the C program is finally called. As a result, it starts executing the main() function defined in the main.c file in the eclipse integrated development environment.
The NIOS II processor architecture used in this study provides functions similar to those of ARM processors that are widely used in the embedded field. If you use an Intel (Altera) FPGA board, one can easily use it without a license burden. In addition, Fig. 8 shows the configurations of the processor that comprises the register file, arithmetic logic unit, interface to custom instruction logic, exception controller, internal or external interrupt controller, instruction bus, data bus, memory management unit, memory protection unit, instruction/data cache memories, tightly-coupled memory interfaces for instructions and data, JTAG debug module, and other modules.
Memory map of MAX10 device based on NIOS II
Fig. 8. Memory map checking in Altera Quartus.
||0x004415E8 - 0x004415EF
||0x004415E0 - 0x004415E7
||0x004415D8 - 0x004415DF
||0x004415B0 - 0x004415BF
||0x004415A0 - 0x004415AF
||0x00441560 - 0x0044157F
||0x00441540 - 0x0044155F
||0x00441520 - 0x0044153F
||0x00441500 - 0x0044151F
||0x00441440 - 0x0044147F
||0x00441200 - 0x004413FF
||0x00420000 - 0x0043DFFF
||0x00200000 - 0x0035FFFF
||flash, memory, non-volatile
BMC Application Design using PMBus
In this study, we examined various data for input/output in the MAX10 devices used as the target board with PMBus BMC application. For this purpose, when BMC was executed, it was necessary to initialize the system and hardware resources required for the target board. This process occurs in the main function of the application executed by the BSP. The main initialization functions are as follows:
variable_init(): This function initializes the variables used in the PMBus. Variables initialized here include voltage, information about the output LED, temperature, FAN speed, flash memory, ADC voltage, threshold voltage for each channel, ADC channel, and UART transmission/reception information.
peripheral_init(): This function initializes various peripheral devices required for PMBus. The built-in functions that access a specific memory area of NIOS II are wrapped with macro functions such as IOWR() and IOWR_I2C_OPENCORES_TXR(), and used in the process. These functions are performed using the offset and bit of each peripheral device as the parameters. Peripheral devices to initialize include ADC, power module, LED, FAN, user flash memory, voltage, temperature, and timer. Macro functions such as IOWR are defined in the BSP source code.
interrupt_init(): This function initializes the interrupts used in PMBus and registers the interrupt service routine (ISR). The corresponding interrupts are three PMBus alerts, a button interrupt, a UART interrupt (RX/TX), and a voltage- and temperature-timer interrupt.
powerup(): For each power module group, proceed with an ADC until the ramp voltage is satisfied. After ADC for all in progress power modules, if the power of each group is turned on normally, it is notified through the LED and UI (standard output).
voltage_n_temperature_timer_alarm_start(): Looking at the memory map of NIOS II in Fig. 9, the memory area for voltage_n_temperature_timer is 0×00441440–0×0044147F. Bits are set in the memory areas according to the register number, such as ALTERA_AVALON_TIMER_SNAP_0_REG from the Timer’s base offset 0×00441440. ALTERA_AVALON_TIMER_SNAP_0_REG is information on the hardware resources provided by the BSP.
In the main() function of PMBus BMC application, the while(1) infinite loop is executed, as shown in Fig. 6. Several functions are called according to conditions, and finally, a specific command is input from the user. The program proceeds as described in the following BMC functions: Power-up/Power-down flow of the PMBus-based external power module, Monitoring of external power module rails, Record data on voltages and temperatures above defined (set) thresholds, Controlling the DC fan based on temperature received from the temperature-sensor diode. Fig. 9 shows the interconnection network among IPs. Fig. 10 also describes information about I/O address mapping.
Fig. 9. I/O address mapping.
Fig. 10. IP interconnections.
The functions are called according to each condition and the functions are called according to the command input from the user:
1) Voltage checking for channels: This is a routine for checking and processing voltage sensed for each power rails. The nodes of each channel are connected to the BMC board for measurement of the voltage by using the bits in the register of each ADC channel. It is processed in the firmware as “adc_raw = adc_sample_read(ADC1_SAMPLE_SLOT); voltage = voltage_process();”. If the voltage is lower than the LOW threshold voltage or higher than the HIGH threshold voltage, the voltage value exceeded by the corresponding channel is written to the flash memory by setting bits in the register accessible to the flash memory through the ufm_write_data() function. Owing to a problem in the voltage of the corresponding channel, a power-down sequence is performed.
2) Temperature & process temperature and control fan: The following is to control the speed of the DC fan after measuring the current temperature based on the bit-setting of the register controlling the temperature sensor diode (TSD) in the board operating the BMC. Temporarily, the current DC fan speed is saved through fan_speed_previous = fan_speed_current. The current temperature value measured from the TSD was measured using the adc_sample_read(TSD_SAMPLE_SLOT) function. It is divided into a case where the temperature is lower than the LOW critical temperature, and when it is higher than the HIGH critical temperature, but not exceeding the critical point. When the temperature is outside the critical area, it is recorded in the flash memory. The speed of the DC fan is also adjusted so that the temperature value measured by the current board can be brought into the critical area. The fan control function controls the temperature faster or slower.
3) Stream & process stream of data: The following source code is used when the user wants to check the temperature or voltage in real time through the UI. As in the above-described source code, the temperature value received from the TSD register or the voltage for the selected group (channel) is calculated through the ADC register and output as a standard output (UART).
4) Command & user command decode and process: The following source code measures the voltage for each group mentioned above and performs a power-down sequence by checking whether it is out of the threshold range of the voltage. When not doing so, it measures the temperature and controls the speed of the DC fan by checking whether it is out of the critical temperature-range. In addition, it is a routine that provides additional information by receiving a specified command from the user through the UI.
Table 4 shows the commands provided by the firmware on top of our evaluation power management platform. Fig. 11 is a PMBus communication interface debugger for the ED8101 chipset used by this team when implementing the BMC power module. The debugger calculates the PID-value setting for the chipset to operate and record the flash memory through OTP. Before the firmware controls the power management of the BMC board, it is necessary to set the initial PID settings through this debugger.
In addition, the debugger can control the power management function of the ED8101 chipset mounted on the power module PCB through the GUI interface before loading/executing the BMC firmware. This is estimated, so it is expected that the purpose of reducing errors/mistakes in implementing the PMBus protocol in firmware can be achieved by using such a debugger in the firmware-development stage later.
HPC server companies such as HP, Sun, IBM, and Dell are expanding the market centering on system software for server management. BMC chipset developers, such as AMI and ASPEED, are expanding the market centering on hardware for server management. In addition, Intel dominates the PC market rather than the server market by using AMT technology, a hardware platform that applies BMC server-management technology to the PC market.
As shown in Fig. 12, the server interface through BMC is structurally relatively simple, and management efficiency has excellent advantages in terms of cost and performance, so the application of BMC in the direction of remote management will be further expanded in the future. Hardware system management technology based on the IPMI standard is expected to expand the system interoperability in the future and further improve the functions, management structure, and types of BMC.
Table 4. Firmware commands
||Reads the ADC channel voltage or temperature.
|- ADC ALL: reads all ADC channels.
|- ADC 00: reads ADC Channel 0.
|-ADC 01: reads ADC Channel 1.
|- ADC TSD: reads temperature.
||Turns on the power groups.
|- POWER 1 ON: turns on the power for Group 1.
|-POWER 1 OFF: turns off the power for Group 1.
|- POWER 2 ON: turns on the power for Group 2.
||Powers on or off all power groups based on the predefined sequence.
|- SEQ ON: turns on the power from Group 1 to Group 3 in sequence.
|- SEQ OFF: turns off the power from Group 3 to Group 1 in sequence.
||Reads all the data stored in the UFM.
||Erases all the data stored in the UFM.
||Checks the available space left in the UFM.
||Updates the upper or lower threshold value for each channel. Data is logged into the UFM when the value detected on each channel is beyond thethreshold value.
|- THRESHOLD 1 H 1.2: sets the upper threshold for Channel 1 to 1.2V.
|- THRESHOLD 1 L 0.95: sets the lower threshold for Channel 1 to 0.95V.
|- THRESHOLD 15 H 1.6: sets the upper threshold for Channel 15 to 1.6V.
||Updates the threshold value for the ramp-up or ramp-down voltage. During the power-up operation, the controller checks if the voltages on a power group have reached the threshold value (high) before turning on the next power group. During the power-down operation, the controller checks if the voltages on a power group is below the threshold value (low) before turning off the power module group. RAMP H 1 0.8 command sets the high threshold value to 0.8V for Group 1.RAMP L 1 0.05 command sets the low threshold value to 0.05V for Group 1.
||Updates the lower or upper threshold value for the TSD. Data is logged into the UFM when the temperature detected by the TSD is beyond the threshold value.
|This does not impact the fan speed.
|- TEMP H 80: sets the high threshold value to 80ºC.
|- TEMP L 20: sets the low threshold value to 20ºC.
||Shows all limits set in the board management controller.
||Resets all limits to the default values defined in main.h.
||Changes the DC fan speed by changing the duty cycle of the PWM.
|- FAN 1: changes the fan speed to 1, where the duty cycle is 33.33%.
|- FAN 3: changes the fan speed to 3, where the duty cycle is 100%.
||Enables or disables data log to the UFM.
|- LOG UFM ON: enables data log to the UFM.
|- LOG UFM OFF: disables data log to the UFM.
||Displays the interval to check the ADC or TSD.
||Updates the interval to check the ADC or TSD.
|- UPDATE TIMER 5: updates the interval to five minutes. The controllerchecks the ADC or TSD on the interval of every 5 minutes.
||Displays the summary of all the supported commands on the terminal.
Fig. 11. (a) PMBus communication interface debugger and (b) PMBus communication interface debugger HW.
Fig. 12. FPGA RTL (register transfer level) download.
Fig. 13. PMBus measurement on power modules.
In this work, we designed and implemented the BMC evaluation platform using the Intel (Altera) FPGA board. After that we synthesis the RTL on the MAX10 FPGA Board (10M50DAF484ES) board, the binary was downloaded and executed. Ports such as ALERT, SDA, SCL, VCC, GND, etc., and power module (DC-DC converter) board were wired from the FPGA board to the port designated by RTL. Fig. 13 shows the measurement of the output signal using an oscilloscope. It checks whether the PMBus interface signal connected to the power module from the FPGA BMC board is normally transmitted.
The wiring (especially the power supply/output part) of the power module board is as follows. The main function of BMC is the aspect of managing the power supply to the server. Mains power to the power supply through the VCC/GND terminal (VIN+/VIN-) is connected to the upper right of each power module board, as shown in Fig. 14. The output through DC-DC voltage/current conversion is output through the upper left terminal (VOUT+/VOUT-) of each power-module board. At this time, the output VOUT+/VOUT- voltage/current is always measured through the ADC of the BMC hardware implemented in the FPGA board. It monitors whether the voltage/current range is within a predetermined threshold range. At this time, the firmware can measure the amount of voltage/current for each channel through PMBus using commands such as ADC ALL. Fig. 15 shows the results of this execution, and the screen of executing CLI command by connecting to FPGA BMC firmware through UART emulator (ttermpro.exe). The data displayed on the screen is the voltage value measured from each channel through the ADC. Fig. 16 is the interface between the FPGA board and the manufactured power module board. In the FPGA BMC board, I2C (SDA, SCL, GND) connections are provided for PMBus protocol as well as SMALERT signals to recognize various states of power modules. Fig. 17 shows the situation in which the BMC evaluation platform operates normally. The power-module board in the picture was controlled by an FPGA BMC board. Administrators can use CLI commands by accessing the FPGA BMC board with a UART emulator, such as Terratum.
Fig. 14. VOUT terminals and connections.
Fig. 15. Execution result of ADC read.
Fig. 16. PMBus connection consisting of SDA, SCL, and SMALERT.
Fig. 17. Capture screen when performing (a) VOUT_COMMAND 1, (b) POWER 1 ON Command, and (c) POWER 1 OFF Command on power module board 1 (https://youtu.be/vhuV9FwMFoQ).
Fig. 18. Overall composition.
At this time, the VOUT_COMMAND is to set the output voltage. This command can be set via PMBus on the ED8101 chipset. (Through the ED8101’s OTP memory, various settings other than VOUT_COMMAND are supported in the configuration phase.) This is a screen to set to output 1 V. Fig.17(c) shows the operation of turning OFF (power down) the output of the corresponding power module board that allows server administrators to remotely control the power supply of specific server nodes. In addition, the BMC continuously senses or feeds back the voltage/current of the output terminal by ADC or similar convertor. Moreover, through the PWM control signal connected between the FDMF5820 and ED8101, the output is reliably supplied within the preset threshold range and adjusted/monitored. As shown in Fig. 18, this research team built an FPGA-based BMC testing platform in this study. In this process, a subset of BMC functions was acquired in terms of implementation techniques in terms of HW/SW. The artwork of the power-module evaluation board, combining the FDMF5823 and ED810 chipset, was performed. In the process of creating an evaluation board and interfacing with the FPGA BMC, the HW/SW operating characteristics of the PMBus were closely grasped. In addition, the operating characteristics of the BMC board firmware were identified through the firmware running on the NIOS processor, mounted on the FPGA BMC board. Essential programming elements for BMC firmware include VOUT command, POWER ON/OFF command, temperature measurement, voltage/current measurement, PWM control, etc.
The PMBus is a free and open standard communications protocol for power management devices. This application report provides a software implementation of the PMBus protocol over the I2C hardware. The underlying hardware protocol for PMBus is I2C, a widespread 2-wire protocol. In addition, PMBus specifies two more optional lines: control and alert. The alert line is used by the slave to notify the master of a fault, and the control line is used by the master as a chip select line to turn the slave on or off. These lines are optional; PMBus can operate as a 2-wire protocol if required with just clock and data lines. The send byte commands simply command the slave to perform an action as shown in Fig. 19. The master simply transmits one byte over I2C.
Fig. 19. Send and read command format. S=start, W=write, A=acknowledgement, P=stop, Sr=repeated start, R=read.
Read byte commands are used to read one byte of information from the slave. The master uses I2C to transmit one byte for the command, and then receive one byte from the slave. In general, read byte commands are used to access read-only registers or parameters in the slave device. Fig. 20 is the screen shot to check the data through the debugger when reading data through the I2C Read command. The figure shows an example of exchanging data with the board through the PMBus by connecting the PMBus and executing the send byte and read byte commands.
Fig. 20. Send and read command codes.
Fig. 21. Oscilloscope view of data payload and acknowledge on PMBus (because the measuring instrument is set to display characters in Korean, non-English characters are displayed on the screen): (a) enlarged view and(b) collapsed view.
Fig. 21 depicts the captured screen measured through the oscilloscope of the data transmission/reception process through PMBus. Data payload and acknowledge signal are showing transmission/reception status. RMS is 2.12V, average 2.11V, standard deviation 3.31m. The frequency is 99.97kHz, average 99.99kHz, standard deviation 24.69kHz.
We compared the BMC and OpenBMC platforms developed through this study. OpenBMC is a Linux distribution for management controllers used in devices such as servers, top of rack switches or RAID appliances. The OpenBMC image includes a bootloader (u-boot), a Linux kernel, open source packages, and board-specific packages: the BMC SoC, including an i2c driver, USB driver, PWM driver, and SPI driver. The board-specific packages include initialization scripts and tools for a particular board.
Of course, since OpenBMC was developed based on a general general-purpose Linux operating system, it takes time to boot the system. OpenBMC provides various functions and supports various boards. Therefore, OpenBMC is superior in terms of functionality/extensibility. However, if you want to develop your own BMC that operates only on a special purpose/board through a small BMC, the approach taken in this study is meaningful.
Fig. 22(a) and (b) show the progress time of the event sequence that appears in the initial stage of each BMC operation. As can be seen from the results, the BMC developed in this study took about 11 seconds, whereas in the case of OpenBMC, it is necessary to wait about 32 seconds at the beginning.
Fig. 22. Oscilloscope view of data payload and acknowledge on PMBus (because the measuring instrument (oscilloscope) is set to display characters in Korean, non-English characters are displayed on the screen): (a)conventional platform and (b) our approach
In this paper, The BMC + power module test bed developed in this study is expected to be used as a basic platform for understanding the basic HW/SW architecture. With the increased demand for BMC in terms of remote/autonomous management in terms of performance/cost/energy/heating efficiency in blockchain and fintech data center, we improved hardware system management technology level based on BMC module. We secured the possibility of developing management/policy-based resource management functions. We make use of a base technology for analysis/implementation of firmware related to power management/monitoring. We also used for verification and implementation of PMBus protocol operation for next generation BMC on FPGA-based BMC HW/SW. Furthermore, in the future, it is expected that management and policy-based resource management functions that support auto healing will be added as basic functions of BMC. In addition, the functions for achieving energy efficiency are expected to develop further along with the basic functions of BMC.
Conceptualization, MC. Funding acquisition, MC. Investigation and methodology, SS, SE, MC.Project administration, MC. Resources, MC. Supervision, MC. Writing of the original draft, SS, SE, MC. Writing of the review and editing, MC. Software, SS, SE. Validation, SS, SE, MC. Formal analysis, MC. Data curation, SS, SE, MC. Visualization, MC. All the authors have proofread the final version.
This work was jointly supported by Strategic Research Program through the National Research Foundation of Korea(NRF) funded by the Science and ICT (No. NRF-2017R1E1A1A01075128), and supported by BK21+ and Grand ICT program.
The authors declare that they have no competing interests.
Name : Seokjin Shin
Affiliation : Department of Information and Communication of Chungbuk National University
He received the B.S. degree in Computer Science from Chungbuk National University, Korea, in 2019 and he is persuing his master degree at Chungbuk National University. He is M.S. candidatein Dept.ofInformationandCommunicationEngineering. His current research interests include blockchain, cloud computing, Human-centric Computing.
Name : SeonyongEom
Affiliation : Department of Information and Communication of Chungbuk National University
He received the B.S. degree in Computer Engineering from PaiChai University, Korea, in 2020. and he is persuing his master degree at Chungbuk National University. He is M.S. candidatein Dept.ofInformationandCommunicationEngineering.His current research interests include blockchain, cloud computing, Human-centric Computing.
Name : Min Choi
Affiliation : Department of Information and Communication of Chungbuk National University
He received the B.S. degree in Computer Science from Kwangwoon University, Korea, in 2001, and the M.S. and Ph.D. degrees in Computer Science from Korea Advanced Institute of Science and Technology (KAIST) in 2003 and 2009, respectively. From 2008 to 2010, he worked for Samsung Electronics as a Senior Engineer. Since 2011 he has been a faculty member of Department of Information and Communication of Chungbuk National University. His current research interests include blockchain, high performance computing, cloud computing, Human-centric Computing.
 E. Hojati, Y. Chen, and A. Sill, “Benchmarking automated hardware management technologies for modern data centers and cloud environments,” in Proceedings of the 10th International Conference on Utility and Cloud Computing, Austin, TX, 2017, pp. 195-196.
 P. Kumari, F. Saleem, A. Sill, Y. Chen, “Validation of redfish: the scalable platform management standard,” in Proceedings of the 10th International Conference on Utility and Cloud Computing, Austin, TX, 2017, pp. 113-117.
 J. H. An, Y. Kim, and C. W. Park, “Design of Framework supporting IPMI and DCMI based on Open BMC,” in Proceedings of the International Conference on Research in Adaptive and Convergent Systems, Krakow, Poland, 2017, pp. 298-299.
 D. E. Hudak, T. Bitterman, P. Carey, D. Johnson, E. Franz, S. Brady, and P. Diwan, “OSC OnDemand: a web platform integrating access to HPC systems, web and VNC applications,” in Proceedings of the Conference on Extreme Science and Engineering Discovery Environment: Gateway to Discovery, San Diego,CA, 2013, pp. 1-6.
 C. L. Chen, P. T. Huang, Y. Y. Deng, H. C. Chen, and Y. C. Wang, “A secure electronic medical record authorization system for smart device application in cloud computing environments,” Human-centric Computing and Information Sciences, vol. 10, article no. 21, 2020. https://doi.org/10.1186/s13673-020-00221-1
 L. Megouache, A. Zitouni, and M. Djoudi, “Ensuring user authentication and data integrity in multi-cloud environment,” Human-centric Computing and Information Sciences, vol. 10, article no. 15, 2020. https://doi.org/10.1186/s13673-020-00224-y
 C. Peng, Q. Chen, L. Zhang, L. Wan, and X. Yuan, “Research on fault diagnosis of wind power generator blade based on SC-SMOTE and kNN,” Journal of Information Processing Systems, vol. 16, no. 4, pp. 870-881, 2020.
 H. Jiao, X. Wang, and W. Ding, “Service oriented cloud computing trusted evaluation model,” Journal of Information Processing Systems, vol. 16, no. 6, pp. 1281-1292, 2020.
 W. B. Kim and I. Y. Lee, “Survey on data deduplication in cloud storage environments,” Journal of Information Processing Systems, vol. 17, no. 3, pp. 658-673, 2021.
 P. Mei, G. Ding, Q. Jin, and F. Zhang, “Research on emotion simulation method of large-scale crowd evacuation under particle model,” Human-centric Computing and Information Sciences, vol. 11, article no. 1, 2021. https://doi.org/10.22967/HCIS.2021.11.001
 C. H. Lee and J. S. Park, “An SDN-based packet scheduling scheme for transmitting emergency data in mobile edge computing environments,” Human-centric Computing and Information Sciences, vol. 11, article no. 28, 2021. https://doi.org/10.22967/HCIS.2021.11.028
 N. B. Thaker, R. Ashok, S. Manikandan, N. Nambath, and S. Gupta, “A cost-effective solution for testing high-performance integrated circuits,” IEEE Transactions on Components, Packaging and Manufacturing Technology, vol. 11, no. 4, pp. 557-564, 2021.
 R. Li, T. Song, B. Mei, H. Li, X. Cheng, and L. Sun, “Blockchain for large-scale internet of things data storage and protection,” IEEE Transactions on Services Computing, vol. 12, no. 5, pp. 762-771, 2019.
 W. Sun, J. Liu, Y. Yue, and P. Wang, “Joint resource allocation and incentive design for blockchain-based mobile edge computing,” IEEE Transactions on Wireless Communications, vol. 19, no. 9, pp. 6050-6064, 2020.
 C. V. B. Murthy, M. L. Shri, S. Kadry, and S. Lim, “Blockchain based cloud computing: architecture and research challenges,” IEEE Access, vol. 8, pp. 205190-205205, 2020.
 X. Zheng, M. Li, Y. Chen, J. Guo, M. Alam, and W. Hu, “Blockchain-based secure computation offloading in vehicular networks,” IEEE Transactions on Intelligent Transportation Systems, vol. 22, no. 7, pp. 4073-7087, 2021.
 M. Babar, M. S. Khan, U. Habib, B. Shah, F. Ali, and D. Song, “Scalable edge computing for IoT and multimedia applications using machine learning,” Human-centric Computing and Information Sciences, Vol. 11, article no. 41, 2021. https://doi.org/10.22967/HCIS.2021.11.041
 Z. Jiao, B. Zhang, L. Zhang, M. Liu, W. Gong, and C. Li, “A blockchain-based computing architecture for mobile ad hoc cloud,” IEEE Network, vol. 34, no. 4, pp. 140-149, 2020.
 D. Geneiatakis, Y. Soupionis, G. Steri, I. Kounelis, R. Neisse, and I. Nai-Fovino, “Blockchain performance analysis for supporting cross-border E-government services,”IEEE Transactions on Engineering Management,vol. 67, no. 4, pp. 1310-1322, 2020.
 D. M. Han and J. H. Lim, “Design and implementation of smart home energy management systems based on zigbee,” IEEE Transactions on Consumer Electronics, vol. 56, no. 3, pp. 1417-1425, 2010.
 D. M. Han and J. H. Lim, “Smart home energy management system using IEEE 802.15.4 and zigbee,” IEEE Transactions on Consumer Electronics, vol. 56, no. 3, pp. 1403-1410, 2010.
About this article
Cite this article
Seokjin Shin, SeonyongEom, and Min Choi*, Soft Core Firmware-Based Board Management Module for High Performance Blockchain/Fintech Servers, Article number: 12:03 (2022) Cite this article 2 Accesses
- Recived14 September 2021
- Accepted3 January 2022
- Published30 January 2022
Share this article
Anyone you share the following link with will be able to read this content:
Provided by the Springer Nature SharedIt content-sharing initiative