Description

The Altera Nios II is a configurable processor. Using the Altera design suite a system designer can build a custom hardware design. This will involve a Nios II cpu, possibly fine-tuned as appropriate for the application with e.g. appropriate amounts of cache and custom instructions. Next those peripherals needed by the application are added. The resulting design is compiled and programmed into a suitably-sized FPGA. This FPGA will be the heart of a larger circuit containing other devices such as external flash and RAM memories and support chips such as RS232 transceivers. A number of reference hardware designs are included with the design suite. The eCos Nios II architectural HAL package together with supporting HAL packages and device drivers allow eCos to be configured and built for a hardware design. Complete applications can then be built with eCos.

The configurable nature of the Nios II architecture means that the eCos port is implemented somewhat differently from ports to other architectures, although the same basic functionality is available. A conventional eCos port involves an architectural HAL package, a variant HAL, possibly a processor HAL, and a platform HAL. Typically the architectural HAL provides a framework for the lower HALs, interrupt and exception processing, context switch support, and gdb stub debug support. The variant HAL deals with cpu issues which are not common to all members of the basic architecture, for example caches and optional FPU and MMU support. The processor HAL deals with the specific set of devices on one specific chip that implements the basic architecture, for example timers, a uart for diagnostics, and interrupt controllers. Base address for the various devices and their interrupt vectors are also defined here. The platform HAL deals with devices that are off-chip. This includes external flash and RAM, as well as specialized I/O chips on an I²C or SPI bus. Typically the external memory will determine how the system boots up so issues like different startup types are largely handled by the platform HAL.

Exactly what work is done where depends very much on the specific processor, for example an interrupt controller may be supported by the variant HAL instead of the processor HAL if it is expected that all processors implementing that variant will use the same interrupt controller. Typically lower HALs are able to extend or override the behaviour of higher ones as appropriate, for example a platform HAL could redefine the interrupt controller support if the platform includes an external interrupt controller as well as an on-chip one.

The Nios II port still involves an architectural HAL and a platform HAL. The architectural HAL tends to do more of the work than other architectural HALs. For example it provides default implementations of system clock support using an Avalon timer and diagnostics using an Avalon uart. The platform HAL still deals with the off-chip devices such as external flash and RAM. For example the devkit platform HAL CYGPKG_HAL_NIOS2_DEVKIT provides the appropriate support for the Stratix II/2s60_RoHS and the Cyclone II/2c35 boards and compatibles.

There is also a new type of HAL, the hardware design HAL. Typically this does not contain any code, only definitions and eCos configuration support. It contains the information needed by the other HALs and by device drivers to adapt themselves to a specific hardware design, for example the presence of certain cpu instructions, the existence and size of cache, and the base addresses and interrupt vectors assigned to the various on-chip and off-chip devices. Essentially this corresponds to the information manipulated within the SOPC Builder component of the Altera Design Suite. An example of a hardware design HAL is CYGPKG_HAL_NIOS2_CYCLONE2_2C35_TSEPLUS, corresponding to the eCosPro TSEplus hardware design for a Cyclone II/2c35 board.

An eCos target, as defined by an entry in the toplevel ecos.db database, consists of the Nios II architectural HAL, a hardware design HAL, a platform HAL, and a set of device drivers. Typically each target will have its own hardware design HAL, although in some cases multiple targets may use the same hardware design HAL to allow for incompatible device drivers. If a platform HAL is fairly generic then it may be shared between several targets, otherwise a target will need its own platform HAL. Porting eCos to a new Nios II design will typically involve creating a new hardware design HAL, usually by cloning an existing one, and either reusing or cloning an existing platform HAL, followed by creating the appropriate entries in ecos.db.

	Note
	At the time of writing hardware design HALs are manually written or cloned. It is expected that in a future release these HALs will be generated automatically from the output of SOPC Builder, with little or no need for manual intervention. For simple hardware the need for a separate platform HAL may also be eliminated at that time.