Embedded Software for SoC - Grupo de Mecatrônica EESC/USP

182 Chapter 14
does not handle I/O. However, nano-kernel is often used exactly to represent
HAL. In the case of OS, nano-kernel is equivalent to HAL [5].
A device driver gives an abstraction of I/O device. Compared to HAL, it
is limited to I/O, not covers context switch, interrupt management, etc. To be
more exact, the entire device driver does not belong to HAL. In the case
of device driver, to identify the portion that depends on the underlying HW
architecture, we need to separate the device driver into two parts: HW independent
and HW dependent parts [6]. Then, the HW dependent part can belong
to HAL.
Though HAL is an abstraction of HW architecture, since it has been mostly
used by OS vendors and each OS vendor defines its own HAL, most of HALs
are also OS dependent. In the case of OS dependent HAL, it is often called
board support package (BSP).
Window CE provides for BSPs for many standard development boards
(SDBs) [3]. The BSP consists of boot loader, OEM abstraction layer (OAL),
device drivers, and configuration files. To enable to meet the designer’s HW
architecture, the BSP can be configured with a configuration tool called
Platform Builder. The device drivers are provided in a library which has three
types of functions: chip support package (CSP) drivers, BSP or platformspecific
drivers, and other common peripheral drivers. In other commercial
OSs, we can find similar configuration tools and device driver libraries.
4. HAL FOR SOC DESIGN
4.1. HAL usage for SW reuse and concurrent HW and SW design
In the context of SoC design, HAL keeps still the original role of enabling
the portability of upper layer SW. However, in SoC design, the portability
impacts on the design productivity in two ways: SW reuse and concurrent HW
and SW design.
Portability enables to port the SW on different HW architectures. In terms
of design reuse, the portability enables to reuse the SW from one SoC design
to another. Easy porting of OS and application SW means easy reuse of OS
and application SW over different HW architectures that support the same
HAL API. Thus, it can reduce the design efforts otherwise necessary to adapt
the SW on the new HW architecture.
In many SoC designs, complete SW reuse may be infeasible (e.g. due to
a new functionality or performance optimisation). Thus, in such cases, both
SW and HW need to be designed. The conventional design flow is that the
HW architecture is designed first, then the SW design is performed based on
the designed HW architecture. In terms of design cycle, this practice takes a
long design cycle since SW and HW design steps are sequential.
HAL serves to enable the SW design early before finishing the HW architecture
design. After fixing a HAL API, we can perform SW and HW design