Lines Matching refs:PF

41 The Parameter Framework is abreviated as PF in the rest of the document.
46 Specificaly the PF contains 3 stacked abstraction layers:
82 The PF **SHOULD** be reusable between components.
86 PF instances **MUST NOT** mutate each others.
87 <note>This may be implemented by not sharing any mutable data between PF instances.</note>
88 <why>Different PF instances are expected to be completely independent thus accessing one should not…
104 <dd>System controlled by the PF. Not necessary material system. This term was
107  - historically the PF reference implementation was used to abstract hardware
115 A PF **MUST** be able to handle parameters.
116 <why>because the PF aims to abstract hardware and model it by parameters.</why>
124 A PF **MUST** support mutable parameters.
168 A PF **SHOULD** support the following types.
171 <why>All type are not necessary to use the PF. For example any parameter could
183 PF **SHOULD** support signed and unsigned integer parameters
187 PF **MUST** support integer with invariant size.
199 PF **MAY** support constraining the parameter minimum and maximum value.
205 PF **SHOULD** support array of characters.
221 PF **SHOULD** support fix point parameters. I.e. integers divided by a fixed power
230 PF **SHOULD** support at least `0 <= m + n <= 31` for a Signed Qm.n and
236 PF **MAY** support constraining the parameter minimum and maximum value.
243 PF **SHOULD** support floating point parameters .
251 PF **SHOULD** support at least 32 and 64 bit size floats.
256 PF **MAY** support constraining the parameter minimum and maximum value.
263 PF **SHOULD** support 1 or more bit sized integers.
337 A PF **MAY** offer Parameter adaptation composition. I.e. combine multiple parameter
362 The PF philosophy is to map the hardware characteristics to parameters.
370 The aim of the PF is to keep this hardware specific code as light as possible.
377 Entity that keeps synchronised PF parameters and their associated hardware.
396 <why>to retrieve a parameter value at the start of the PF.</why>
421 The PF creates syncer using syncer builder.
424 The PF **MUST** be able to create syncers.
470 Multiple syncer plugins, may depend on each other. The PF should appropriately
494 <why>To always keep synchronise the underlined hardware and the PF
499 set since the PF start.
500 <note>This is usually implemented on PF start, initialize the parameter values
518 When a syncer reports an out-of-sync condition, the PF **MUST** try to resync
525 The PF offers parameters mapped on hardware. This is a good but weak
530 A PF offers a mechanism to abstract the parameters to a higher level concept.
540 "Scenario" are detected through arbitrary criterion provided by the PF host
551 For example, given a PF with 3 integer parameters A,B,C, a configuration can
568 A PF **MUST** offer configurations as described in the Definition chapter.
624 The PF **SHOULD NOT** limit the number of criteria.
627 The PF **SHOULD NOT** limit the number of possible states of any given criterion
674 the hardware can not be abstracted in this state witch defeats the PF purpose.</why>
765 PF data includes:
778 The PF data **MUST** be deserializable.
779 <why>Otherwise a PF instance could only be created empty and then be filled by
783 The PF data **SHOULD** be deserializable from a config file.
788 The PF data **SHOULD** be serializable.
789 <why>In order to save a PF instance state and restore it later. This achieve
793 The PF data **SHOULD** be serializable/deserializable by parts.
805 A PF **MAY** save all data needed to replay it's state evolution.
816 In order to debug the user configuration, allow introspection of PF data at runtime.
818 pretty printing PF data.
823 User **SHOULD** be able to inspect PF data.
836 PF **MAY** offer pretty print of data. Including:
861 Two PF instances with the same parameters **MUST** have the same identifier for
865 <why>Persistence of parameter identifier across PF instances with the same
866 configuration. To identify parameters independently of the host machine and PF
883 Tuning is the ability to modify the PF data structure at runtime.
891 As the PF might model a complex system with its dynamic parameter value engine
900 Users **SHOULD** be able to modify the PF inference engine behaviour (rules,
909 may not disappear on PF restart. This could be implemented in several way, for
912 - exposed in the PF API
913 - changing a config file and sending a signal to the PF
920 Tuning **SHOULD** be possible from the PF native API.
932 A PF tuning capability **MAY** be disabled in a context where no tuning is needed.
940 The PF **MAY** offer a command line interface that binds to its IPC.
941 <why>To have a reference way to interact with a PF without implementing its IPC
957 The PF **SHOULD** expose its API in C.
958 <why>The PF aims to be a hardware abstraction thus middle ware which is often
964 The PF **MAY** expose its API to multiple programing language.
995 PF **MAY** support at least:
1001 <why>As the reference PF implementation leaves its original Android environment,
1020 after a parameter set without having to query the PF.</why>
1031 The PF host API **SHOULD** expose parameter values with the same API syncer use.
1048 The PF host API **SHOULD** be structured.
1049 I.e.: the PF, when requested for a list of domains, should return a list of
1089 <why>To enable a fast modify-update-test cycle on PF configuration.</why>
1092 A PF **MAY** support immutable parameters, i.e. parameters which value is determined
1095 <ko>This is not implemented in the PF reference implementation.</ko>