Lines Matching refs:parameter
49 2) hardware parameter abstraction
53 by independent parameters. Ie: When changing one parameter it must not change
64 ### Hardware parameter abstraction
66 the hardware parameter properties (domain of validity, size, human representation...).
92 <note>TODO: add a paragraph/requirement about parameter independences.
93 Ie parameter set order should not impact the final state.
120 A parameter **MUST** have a value.
121 <why>because a parameter without value would not abstract any hardware.</why>
128 This value **MUST** be settable for a mutable parameter.
129 <why>By definition, a mutable parameter that can not be mutated it a immutable parameter.</why>
132 This value **SHOULD** be gettable for a mutable parameter.
133 <why>To dump all parameter value, debug a hardware state,
135 for coherency with the immutable parameter...</why>
144 All parameters have a data type. A data type designates parameter invariants.
161 - pretty display parameter values (not just a as an array of bits)
171 <why>All type are not necessary to use the PF. For example any parameter could
173 check parameter validity (invariants) nor a pretty display of the values.</why>
176 Implementation **MAY** add another API to access a parameter value.
199 PF **MAY** support constraining the parameter minimum and maximum value.
200 <why>To catch user out of valid range errors when changing the parameter
207 be used as a fallback type if no other matches the parameter.</why>
218 ##### Fix point parameter
236 PF **MAY** support constraining the parameter minimum and maximum value.
237 <why>To catch user out of valid range errors when changing the parameter
256 PF **MAY** support constraining the parameter minimum and maximum value.
257 <why>To catch user out of valid range errors when changing the parameter
267 The API to access a bit parameter is implementation defined.
272 A bit field is an ordered set of bit parameter.
275 <note>This bit field may contain only bit parameter.</note>
285 A bijective pure function converting a parameter value between the syncer
286 and other parameter reader/writer (including the inference engine).
293 <why>For coherency a client getting a previously set parameter should return the setted value,
302 <note>For example a hardware integer parameter could have a range 64-128 but it might
305 This transformation can also permits to change the unit of a parameter.
306 <note>For example the hardware could expose a parameter in cm but it might better
310 <note>For example a Q2,2 (see [fix-point-parameter]) when setting 1
313 With parameter adaptation, types can be even further parameterised.
314 <note>For example, Qn,m Fix point parameter could be emulated with a $*2^n$
324 The following parameter adaptation **SHOULD** be supported
337 A PF **MAY** offer Parameter adaptation composition. I.e. combine multiple parameter
341 <why>To avoid combination explosion of parameter adaptations. The idea is to
347 A parameter **SHOULD** be structured in a tree. Each parameter being a distinct
354 characteristics (type, independence...) than a parameter.
385 <why>The hardware minimal access may be bigger than one parameter.</why>
388 One parameter **MUST NOT** be mapped to two or more syncer.
389 Ie: a parameter MUST be mapped to zero or one syncer.
390 <why>Which syncer should be responsible to retrieve the initial parameter value
391 if they are multiple per parameter?</why>
396 <why>to retrieve a parameter value at the start of the PF.</why>
401 <why>to synchronise hardware on parameter change.</why>
404 This API **MAY** be a packed parameter structure, following the C ABI without
411 <why>the parameter structure may be useful for the syncer to communicate with
413 parameter type to send it to the hardware.</why>
442 sound card syncer library. (Each parameter are then individually mapped to a specific syncer.)
480 A parameter not bound to a syncer.
493 Syncer **SHOULD** synchronise the mapped hardware on parameter change.
498 Syncer **SHOULD** retrieve parameter value from the hardware if no value has be
500 <note>This is usually implemented on PF start, initialize the parameter values
507 for instance if a syncer contains more than 1 parameter -- in order to avoid
512 parameter values are not (or no longer) reflecting the last values set by the
526 abstraction as there is often a 1/1 relation between a parameter and the hardware
527 it maps. Ie: parameter abstract how to access hardware and what hardware but
549 values of the same parameter.
569 <note>rule based parameter engine does not manipulate directly values, it
697 multiples configuration of the same parameter could be eligible on the same
707 It has been chosen as the recommended solution (just like parameter tree)
720 for the same parameter.
728 example) global configurations and per parameter priority. It is not a MAY
741 I.e.: parameter values MAY depend on previous selection criterion states.</note>
770 - parameter/value couples
806 <note>Eg: log criterion change, configuration application, parameter
838 - printing parameter value in decimal
840 - pretty print parameter tree (such as the Unix tree command for files)
843 ### Rogue parameter
846 <why>Otherwise, a rogue parameter is of no use.</why>
853 Every parameter **MUST** have an identifier that uniquely identifies it.
854 <why>to identify a parameter outside the framework</why>
858 <why>So that a human user can identify a parameter with ease.</why>
865 <why>Persistence of parameter identifier across PF instances with the same
870 The identifier of each node of a parameter tree **SHOULD** be a combination of its
891 As the PF might model a complex system with its dynamic parameter value engine
924 Users **SHOULD** be able to modify the parameter values at any time.
928 <why>Even if a parameter is managed by the inference engine, it often is useful
1005 ### Get and set multiple parameter values in one request
1008 and when one or more parameter value is invalid (eg. out of range),
1009 no parameter **SHOULD** be set.
1014 <why>To provide parameter mutation atomicity to the client.
1015 This is especially important if the client wants to implement parameter consistency.
1017 if a transaction fail after the first parameter is set but not the second,
1020 after a parameter set without having to query the PF.</why>
1025 <why>For performance reason. Tools often need to update multiple parameter
1026 and having one call per parameter is too slow. (benchmark ?).
1027 This feature permit the client to save and restore from an external database parameter
1031 The PF host API **SHOULD** expose parameter values with the same API syncer use.
1033 parameters. This memory layout is specified in the parameter structure thus
1039 transition state, manual parameter synchronisation is requested.
1069 ### Custom parameter types
1072 parameter contains ie its types. Without this possibility the client has to
1080 For example stocking a parameter with a dynamic type, say either a string or a number
1097 This value **MUST** be gettable for an immutable parameter.
1098 <why>A parameter that can not be accessed (read or write) is of no use.</why>
1101 A parameter or a block of parameters might be presented by the Parameter