Nios® V Processor Software Developer Handbook

ID 743810
Date 10/12/2024
Public
Document Table of Contents

4.4.3.1.1. System Clock Timer

The system clock timer resource is used to trigger periodic events (alarms), and as a timekeeping device that counts system clock ticks. The default system clock timer in a Nios® V processor subsystem is the Nios® V processor built-in internal timer. You may configure the system clock timer to other timer peripherals in the Platform Designer system.

Note: Only one system clock timer service may be identified in the BSP library. Only HAL supplied routines access the timer.

The hal.sys_clk_timer setting controls the BSP project configuration for the system clock timer. This setting configures one of the timers available in your Platform Designer design as the system clock timer.

Intel provides separate APIs for application-level system clock functionality and for generating alarms.

Application-level system clock functionality is provided by two separate classes of APIs, one HAL specific and the other Unix-like. The Intel function alt_nticks() returns the number of clock ticks that have elapsed. You can convert this value to seconds by dividing by the value returned by the alt_ticks_per_second() function. For most embedded applications, this function is sufficient for rudimentary time keeping.

The POSIX-like gettimeofday()function behaves differently in the HAL than on a Unix workstation. On a workstation, with a battery backed-up, real-time clock, this function returns an absolute time value, with the value zero representing 00:00 Coordinated Universal Time (UTC), January 1, 1970, whereas in the HAL, this function returns a time value starting from system power-up. By default, the function assumes system power-up to have occurred on January 1, 1970. Use the settimeofday() function to correct the HAL gettimeofday() response. The times() function exhibits the same behavior difference.

Consider the following common issues and important points before you implement a system clock timer:

  • System Clock Resolution—The timer’s period value specifies the rate at which the HAL BSP project increments the internal variable for the system clock counter. If the system clock increases too slowly for your application, you can decrease the timer's period in Platform Designer.
  • Rollover—The internal, global variable that stores the number of system clock counts (since reset) is a 64-bit unsigned integer. No rollover protection is offered for this variable. Therefore, calculate when the rollover event occurs in your system and plan the application accordingly.
  • Performance Impact—Every clock tick causes the execution of an interrupt service routine. Executing this routine leads to a minor performance penalty. If your system hardware specifies a short timer period, the cumulative interrupt latency impacts your overall system performance.

The alarm API allows you to schedule events based on the system clock timer, in the same way an alarm clock operates. The API consists of the alt_alarm_start() function, which registers an alarm, and the alt_alarm_stop() function, which disables a registered alarm.

Consider the following common issues and important points before you implement an alarm:

  • Interrupt Service Routine (ISR) context—A common mistake is to program the alarm call-back function to call a service that depends on interrupts being enabled (such as the printf() function). This mistake causes the system to deadlock, because the alarm call-back function occurs in an interrupt context, while interrupts are disabled.
  • Resetting the alarm—The callback function can reset the alarm by returning a nonzero value. Internally, the alt_alarm_start() function is called by the call-back function with this value.
  • Chaining—The alt_alarm_start() function is capable of handling one or more registered events, each with its own call-back function and number of system clock ticks to the alarm.
  • Rollover—The alarm API handles clock rollover conditions for registered alarms seamlessly.

A good timer period for most embedded systems is 50 milliseconds. This value provides enough resolution for most system events but does not seriously impact performance nor roll over the system clock counter too quickly. Choosing a timer period that is too short might overwhelm the Nios® V processor to continuously servicing the timer interrupt handler, and neglect other tasks.