-
Notifications
You must be signed in to change notification settings - Fork 2
3 Device Development
This page is for device developers to help them use the PRiME Framework with their devices.
Example device classes are provided with the Framework repository. Quick-start information for a particular device can be found on its specific page:
In the context of the PRiME Framework, the device acts as an interface with the platform hardware and provides drivers to operate any controllable parameters and read any measurable parameters. The device encompasses the entire hardware platform which is considered to operate under a single OS. The device is a slave of the RTM and receives call made by the RTM. A set of handler and return functions are provided to process messages received by the device.
The device's API interface contains vectors structures for its knobs and monitors. These data structures are; knobs_disc, knobs_cont, mons_disc, mons_cont. For them to be visible to the RTM through the framework, devices add their knobs and monitors to these vectors using the following functions. Typically, this should be done during construction of the device process.
| API Function | Inputs | Description |
|---|---|---|
| add_knob_disc | unsigned int id, knob_type_t type, disc_t min, disc_t max, disc_t val, disc_t init, boost::function<void(disc_t)> set_handler | Add a discrete knob to the device. |
| add_knob_cont | unsigned int id, knob_type_t type, cont_t min, cont_t max, cont_t val, cont_t init, boost::function<void(cont_t)> set_handler | Add a continuous knob to the device. |
| add_mon_disc | unsigned int id, mon_type_t type, disc_t val, boost::function<disc_t(void)> get_handler | Add a discrete monitor to the device. |
| add_mon_cont | unsigned int id, mon_type_t type, cont_t val, boost::function<cont_t(void)> get_handler | Add a continuous monitor to the device. |
A type field is included to allow the device to relay some information about the meaning of each knob and monitor. The current list of valid device knob and monitor types are:
| Knob Type | Description/Meaning |
|---|---|
| PRIME_VOLT | A voltage scaling knob |
| PRIME_FREQ | A frequency knob. Normally controlled through a linux frequency governor such as "userspace" |
| PRIME_GOVERNOR | A linux frequency governor knob. These have a device-specific enum of governor names. |
| PRIME_FREQ_EN | A knob to enable or disable control of a frequency knob |
| Monitor Type | Description/Meaning |
|---|---|
| PRIME_POW | A monitor that measures power |
| PRIME_TEMP | A monitor that measures temperature |
| PRIME_CYCLES | A monitor that records the cycle count of a functional unit |
| PRIME_PMC | A monitor that records performance monitoring counters of a functional unit |
Knobs and monitors can also be removed from the framework by the device. Functions to remove knobs and monitors are:
| API Function | Inputs | Description |
|---|---|---|
| remove_knob_disc | unsigned int id | Remove a discrete knob from the device. |
| remove_knob_cont | unsigned int id | Remove a continuous knob from the device. |
| remove_mon_disc | unsigned int id | Remove a discrete monitor from the device. |
| remove_mon_cont | unsigned int id | Remove a continuous monitor from the device. |
The fields for each knob or monitor should be derived from the technical specification of the device. A handler function is bound to each knob and monitor, which is called in the event of a set or get API call from the RTM. These handler functions should be defined per device and contain the actual drivers required to get or set a parameter.
All other operations, such as min, max, type and size requests by the RTM, are handled automatically by the Framework using the device's API interface.
By default, the build environment is configured by cmake to compile the device class for the Odroid XU3. An alternative device can be specified when cmake is invoked if you are building for a different device. This is done by executing "cmake -D DEVICE:STRING= .." rather than "cmake .." in the build process, with replaced by the name of the device you want to use specified in CMakeLists.txt. The device string is case sensitive.
Examples:
- For the Odroid XU4: cmake -D DEVICE:STRING=XU4 ..
- For the c5soc: cmake -D DEVICE:STRING=C5SOC ..
- For the (default) XU3: cmake -D DEVICE:STRING=XU3 ..
Mapping of activity on a particular CPU to the temperature sensor number that is affect:
| CPU ID | Primary Effect | Secondary Effects |
|---|---|---|
| 4 | 0 | 2 & 3 |
| 5 | 3 | 2 |
| 6 | 2 | 3 |
| 7 | 1 |