WO2021122066A1

WO2021122066A1 - A trace handler module system and a method using said system

Info

Publication number: WO2021122066A1
Application number: PCT/EP2020/084687
Authority: WO
Inventors: Daniel Jakschik
Original assignee: Commsolid Gmbh
Priority date: 2019-12-16
Filing date: 2020-12-04
Publication date: 2021-06-24
Also published as: CN114830103A

Abstract

The invention discloses a trace handler module system and a method for generating a trace data stream out of trace messages using a minimum set of processor instructions by using said trace handler module system. The object of the present invention to provide an apparatus and a method that are able to handle trace messages that are extracted out of the firmware flow of the processor consuming minimal controller bandwidth and without introducing runtime variations will be solved by a trace handler module system which is configured to take over a trace message representing an internal state of a firmware running on a processor of a SoC via a chip-internal bus system, wherein the trace message is carried by a bus data signal which is exchanged between a bus master and a bus slave over the chip-internal bus system and a bus address-signal is used to encode additional trace meta data of the trace message, wherein the trace handler module system comprises the bus slave configured to convert specific bus protocol data to strobe-based protocol data, an input logic configured to add timestamps, to do filtering and channel allocation of the converted data from the bus slave, a first-in-first-out (FIFO) shift register configured to decouple a bus transfer speed from a trace data stream speed and to output a FIFO data format, and an output logic configured to convert the FIFO data format to a trace data stream format representing the trace message to reconstruct a system behavior issued by the processor.

Description

A trace handler module system and a method using said system

The invention relates to a trace handler module system and a method for generating a trace data stream out of trace messages using a minimum set of processor instructions by using said trace handler module system.

A System-On-Chip (SoC) integrates system components on a single chip-die; system components can be a power management, analog interfaces, digital interfaces and one or more processors. The processor firmware highly interacts with interfaces and external components.

Chip internal components are typically linked via a standardized bus system (i. e. Advanced High-performance Bus (AHB) see: "Advanced microcontroller bus architecture,"

2019. [Online]. Available: https://en.wikipedia.org/wiki/Advanced_Microcontroller_Bus_A rchitecture or Wishbone see: "Wishbone (computer bus)",

2019. [Online]. Available: https://en .wikipedia.org/wiki/Wishbone_ (computer_bus)).

There are various standards and implementations. All of them have a common minimum set of signals. The name of the signal might vary from standard to standard, the functionality is similar . 'CLK' Clock Line, driven by a clock source,

'ADDR' Address, vector of BUSAWID bits (i. e. 32), driven by bus master, consumed by bus slave,

'WRITE' Read-Write, selects between read or write transfer, driven by bus master, consumed by bus slave,

'TRANS' Transfer, signaling the beginning of a new bus operation, driven by bus master, consumed by bus slave,

'WDATA' Data To Write, vector of BUSDWID bits (i. e. 32), driven by bus master, consumed by bus slave,

'RDATA' Read Data, vector of BUSDWID bits (i. e. 32), driven by bus slave, consumed by bus master, 'READY' Ready, signaling the end of a bus operation, driven by bus slave, consumed by bus master.

Figure 1 depicts a single read transfer. The bus master applies ADDR, WRITE, TRANS and waits for READY to become high. Therewith the read data RDATA is valid. Figure 2 depicts a single write transfer. The bus master applies ADDR, WRITE, TRANS, WDATA and waits for READY to become high.

The exact signal timing varies from standard to standard. Next to the listed signals, there are the following important common facts:

- A transfer always includes an address and is a read or a write operation.

- Read operations transfer data from the slave to the master. - Write operations transfer data from the master to the slave.

- A transfer has a defined start, initiated by the bus master.

- A transfer has a defined end, defined/delayed by the bus slave.

- The most significant bits (MSBs) of the ADDR signal are used to select between slaves.

- The least significant bits (LSBs) of the ADDR signal are used within the slave according to their needs.

Some bus protocols also support transfer sizes different than the data width (BUSDWID). The minimum required transfer granularity for the present invention is BUSDWID.

A chip-internal bus infrastructure has the following attendees:

'Master' modules, which can initiate bus transfers,

'Slave' modules, which respond to bus transfers.

A master module can be i. e. a microcontroller or a Direct Memory Access (DMA) module. A slave module can be a memory which is a full matrix of words readable and/or writable or a register file which is a single vector or vectors of readable and/or writable flip- flops. These flip-flops control or observe hardware signals. These flip-flops are bus-accessible at one or multiple addresses. There are also other slave modules, i. e. a FLASH controller and so on.

Nearly every chip-internal microcontroller of a System-on- Chip (SoC) has a bus master interface, which initiates bus protocol compliant read and write transfers. The firmware just reads and writes an address.

A typical processor instruction set, requires two processor instructions for a read transfer: 1. Load address constant to processor register A.

2. Load from address in processor register A, store read value to processor register B.

Write transfers require three processor instructions: 1. Load address constant to processor register A.

2. Load data constant to processor register B.

3. Store content of processor register B at address of processor register A.

In conclusion, bus transfers always consume a bunch of instructions and depending on the processor architecture consume even more clock cycles. Multiple transfers always require an update instruction of the address register A, before the next load instruction or store instruction. In some cases, even more. There are multiple ways to mitigate these issues: bus burst transfers, processor pipelining, etc.

In burst mode transfers a device is transmitting data repeatedly without going through all the steps required to transmit each piece of data in a separate transaction. The usual reason for having a burst mode capability, or using burst mode, is to increase data throughput.

Processor pipelining attempts to keep every part of the processor busy with some instruction by dividing incoming instructions into a series of sequential steps performed by different processor units with different parts of instructions processed in parallel. It allows faster CPU throughput than would otherwise be possible at a given clock rate, but may increase latency due to the added overhead of the pipelining process itself. The main problem is that firmware, running on a processor, can contain bugs which are difficult to analyze, as they require insight into the firmware state. Any processor stopping and intermediate read-out influences the processor behavior and therewith the system interacting. In a worst- case scenario, the condition to debug just vanishes due to the intermediate read-out. In contrast, tracing dumps internal states unconditionally. The system behavior can be reconstructed based on trace data. A trace message is a data structure with diagnostics information and a static or dynamic length. The trace message comprises trace data and meta data and can be seen as internal firmware state variable values which represents an internal state of a firmware running on a processor of a System-on-Chip. Every trace message has a well-defined data format and is available between every program execution step. Usually, during the software development process, e. g. the development of a firmware running on a processor of a SoC, it is decided that at a specific location in the firmware it might be good to dump the internal state of the processor. But any output formatting with timestamp, trace type and so on and trace filtering, e. g. on trace type, trace level, channel, etc. consumes controller bandwidth and introduces runtime variations.

So, it is an object of the present invention to provide an apparatus and a method that are able to handle trace messages that are extracted out of the firmware flow of the processor consuming minimal controller bandwidth and without introducing runtime variations. At the same time, in order to trace System-On-Chip processors a trace message should have a timestamp, which allows a correlation to the internal timing and a type, to distinguish messages and their interpretation .

The object of the invention will be solved by a trace handler module system which is configured to take over a trace message representing an internal state of a firmware running on a processor of a System-on-Chip via a chip- internal bus system, wherein the trace message is carried by a bus data signal which is exchanged between a bus master and a bus slave over the chip-internal bus system and a bus address-signal, ADDR, is used to encode additional trace meta data of the trace message, wherein the trace handler module system comprises the bus slave configured to convert specific bus protocol data to strobe-based protocol data, an input logic configured to add timestamps, to do filtering and channel allocation of the converted data from the bus slave, a first-in-first-out (FIFO) shift register configured to decouple a bus transfer speed from a trace data stream speed and to output a FIFO data format, and an output logic configured to convert the FIFO data format to a trace data stream format representing the trace message to reconstruct a system behavior issued by the processor.

The trace handler module system offloads the formatting and filtering from the processor. Especially the filtering implies runtime variations (trace or skip). The processor trace overhead is minimal and unconditionally. The system behavior does not depend on the trace message, especially the trace data nor the trace filter.

The bus slave converts the specific bus protocol to a simple strobe-based one. The specific bus address space depends on the design-time constants. The bus slave never inserts wait- cycles (READY is always high).

It is preferred that at design-time of the trace handler module system following symbols are defined assuming a function b(n)= \log_2(ji)], which returns a number of bits required to encode n different values: BUSAWID defining a chip-internal bus address width, BUSDWID defining a chip- internal bus data width, LEVELWID defining a level width of a trace level of the trace message, TYPEWID defining a type width of a trace message type identifier and CHANWID defining a channel width of a trace channel as a transport protocol layer entity to separate different trace messages during transmission between the bus master and the bus slave, b (n) is the rounding up of a log2 operation on n. The above mentioned symbols BUSAWID, bus address width; BUSDWID, Bus data width; LEVELWID, Level width, which is optional and can be 0; TYPEWID, Type width, which is optional and can be 0; and CHANWID, Channel width, define the design-time constants, which influence implementation details and should therefore to be chosen before.

In a variant of the inventive trace handler module system, the trace handler module system uses different slices of the bus ADDR-signal to extract trace meta data of the trace message for generating a trace data stream. The LSBs of the bus ADDR-signal are up to the bus slave to interpret. The trace handler module system uses them for extracting the trace meta data.

In other variants of the inventive trace handler module system, one slice of the bus ADDR-signal defines a data marker (IS_DATA) which specifies the trace message payload bytes. Another slice of the bus ADDR-signal defines an end marker (IS_END) which specifies to close a channel. A further slice of the bus ADDR-signal defines the trace level (LEVEL) which specifies classes relevance of the trace message. Another slice of the bus ADDR-signal defines the trace type (TYPE) which specifies the trace message type identifier. And one slice of the bus ADDR-signal defines the trace channel (CHAN) which specifies a trace channel number. Table 1 in figure 3 describes the slices to be extracted from the bus ADDR-signal.

In a further variant of the inventive trace handler module system, the input logic is fed by a timebase which delivers a header timestamp, which is captured and forwarded to the FIFO shift register. The input logic is responsible for timestamping, filtering and channel allocation. For timestamping a timebase delivers the header timestamp, which is captured and forwarded to the FIFO. A trace header contains meta information for one trace message - a timestamp and a trace type. A trace timestamp is a timestamp of an event, which triggered the trace message.

The filtering can be done in different flavors, which are fully orthogonal to each other.

So, in variant of the inventive trace handler module system, the input logic filters the trace message according to the trace level, whereas depending on a configured minimum trace level, a specific message is discarded or forwarded to the FIFO shift register. Every trace message has a trace level which is fixed and which is defined at design time. A trace level categorizes the trace messages into classes of relevance, i. e. INFO, WARN, ERROR. Depending on a runetime- configured minimum trace level, a specific message is discarded or forwarded.

And in another variant of the inventive trace handler module system, the input logic filters the trace message according to the trace message type identifier, whereas depending on a configured trace message type identifier, a specific message is discarded or forwarded to the FIFO shift register. Every trace message has a trace type which is defined at design time. The trace type identifies the trace message and its content. Depending on a runtime-configured trace type filtering by the trace handler module system, a specific message is discarded or forwarded.

And in another further variant of the inventive trace handler module system, the input logic filters the trace message based on other trace meta data extracted from the bus ADDR-signal. It is possible to encode other trace meta data using the same approach of the TYPE and LEVEL. It is up to the implementation to handle more or less of this data and include it in the filter condition.

In a variant of the inventive trace handler module system, the trace handler module system comprises a trace channel state machine, which handles a defined number of trace channels, whereas the number of trace channels are pre defined by (2^CHANWID-1). The trace handler module is able to handle a defined number of trace channels (2^CHANWID-1). Each channel has its own state. A trace channel is a transport protocol layer entity to separate different trace messages during transmission. In another variant of the inventive trace handler module system, the trace handler module system comprises a counter configured to count a number of lost trace messages, whenever the FIFO shift register is full or the number of trace channels is exceeded. It is also possible to count the number of lost messages. Whenever the FIFO is full, or the number of channels is exceeded, this counter would increment. This quantifies the ratio of trace load to the available trace bandwidth. Trace filtering reduces the trace load. Trace lost analysis and trace filtering can be used to strip down trace data to an appropriate level.

In a further other variant of the inventive trace handler module system, the trace handler module system comprises a counter configured to count a gross trace load, by counting all incoming payload bytes. This quantifies the absolute trace load. Depending on the counter evaluation for a specific timespan or in total. This helps to refine the trace message definitions and their timing. In another further variant of the inventive trace handler module system, the trace handler module system supports multi threading, any number of interrupt contexts and / or interleaved trace streams. The trace channel approach in combination with the channel open and close operations enables multithreading and any number of interrupt contexts. If all channels are allocated, data is safely discarded, without interference to other channels. The channel open and close operations are atomic. Any interrupt or context-switch before or afterwards has no side-effects. It is up to the implementation to choose an appropriate number of channels. The object of the invention will be also solved by a method for generating a trace data stream out of trace messages using a minimum set of processor instructions by using a trace handler module system according to claims 1 to 15, wherein the method comprising the following steps:

- open a channel by reading any address of the trace handler module system, whereas a returned value is a channel base address A used for all successive actions,

- set TYPE bits in address A to a trace message type according to a slice TYPE of a bus ADDR-signal exchanged via a chip-internal bus system,

- set LEVEL bits in address A to a trace message level according to a slice LEVEL of the bus ADDR-signal,

- set IS_DATA bit in address A to 1 for interpreting all successive written words as trace message payload, if slice IS_DATA of the bus ADDR-signal is implemented,

- write the trace message data to address A,

- set IS_END to 1 in address A to prepare channel closing,

- close channel by writing something to address A.

The firmware has to follow a strict sequence for the trace data generation. The entire process relies on the proper handling of the address A. The inventive method offloads the firmware and takes care about timestamping, filtering and output formatting, with a minimum set of processor instructions. It is obvious that every opened channel has to be closed. The close channel operation explicitly ignores any written data. The additional write operation at the end is negligible. The whole sequence has no conditions and therewith a constant execution time. The method step "write the trace message data to address A" can be repeated any time. All other method steps are not allowed to be repeated. In a variant of the inventive method, other trace meta data than TYPE and LEVEL are written to address A. This can be used to introduce additional types of trace meta data for trace filtering and/or transmission. In another variant of the inventive method, if all channels are allocated, a NULL channel is returned on the address A, which is ignored. This ensures in an overload scenario that all trace data is skipped without any interference.

So, in another further variant of the inventive method, the method is performed without any conditions and is performed in a constant execution time.

The invention will be explained in more detail using exemplary embodiments.

The appended drawings show Fig. 1 Bus Read Transfer;

Fig. 2 Bus Write Transfer; Fig. 3 Translation from chip-internal bus to trace according to the invention;

Fig. 4 ADDR-signal interpretation by the bus slave; Fig. 5 Inventive trace handler module system;

Fig. 6 Trace firmware Protocol for a trace message exchanged between the bus master and the bus slave according to the inventive method;

Fig. 7 Trace channel state machine. Figure 3 shows the translation from the chip-internal bus 2 to a trace data stream 5. The trace handler module system 4 offloads the formatting and filtering from the processor. Especially the filtering implies runtime variations (trace or skip). The trace overhead is minimal and unconditionally. The system behavior does not depend on the trace data nor the trace filter setting. The inventive trace handler module system 4 will be described in more detail in figure 5.

Figure 4 shows the bus ADDR-signal interpretation by the bus slaves of the trace handler module system. The bus ADDR- signal is divided into different slices, which are defined at design-time of the inventive system. Slice 'BYTESEL' has a width of b (BUSDWID/8-1), for example bits 1:0. These bits are intended to be ignored, as not all processors support non-word accesses. Slice 'SKIP' has a width of b(BUSDWID/8- 1), for example bits 3:2. This slice marks the number of data bytes to skip. For a BUSDWID = 32, if SKIP = 0, 4 Bytes [31:0] are sent and 0 Bytes are skipped; if SKIP = 1, 3 Bytes [23:0] are sent and 1 Byte are is skipped; if SKIP =

2, 2 Bytes [15:0] are sent and 2 Bytes are skipped; if SKIP = 4, 1 Byte [7:0] is sent and 2 bytes are skipped. The SKIP attribute enables the handling of payload other than BUSDWID. The payload source may be located in the processor memory with any alignment. The SKIP attribute can also be used to dump the bytes before and after word aligned data. Slice 'IS_DATA' has a width of 0 or 1, for example bit 4. This slice is a data marker, if the written data is handled as trace payload. This bit is optional and only needed if there is any other filtering than filtering after TYPE or LEVEL. The slice 'IS_END' has a width of 1, for example bit 5. IS_END is an end marker which is used to close a channel and written data is ignored. The slice 'LEVEL' has a width of LEVELWID, for example 8:6, which is defined at design time of the trace handler module system and then fixed. The trace level categorizes the trace messages into classes of relevance, i. e. INFO, WARN, ERROR. The slice 'TYPE' has a width of TYPEWID, for example 14:9, which is defined at design-time of the trace handler module system. The trace type identifies the trace messages and its content. The slice 'CHAN' has a width of CHANWID, for example 20:15, which is defined at design-time of the trace handler module system. The trace channel is a transport protocol layer entity to separate different trace messages during transmission.

The above mentioned symbols BUSAWID, bus address width, i. e. 32 bits; BUSDWID, Bus data width, i. e. 32 bits;

LEVELWID, Level width, i. e. 3 bits, which is optional and can be 0; TYPEWID, Type width, i. e. 6 bits, which is optional and can be 0; and CHANWID, Channel width, i. e. 6 bits define the design-time constants, which influence implementation details and should therefore to be chosen before.

Figure 5 shows the inventive trace handler module system 4 comprising the bus slave 3, an input logic 6, a FIFO shift register 7, and an output logic 8. The bus slave 3 converts the specific bus protocol to a simple strobe-based one. The specific bus address space depends on the design-time constants. The bus slave 3 never inserts wait-cycles (READY is always high). The input logic 6 is responsible for timestamping, filtering and channel allocation. For timestamping a timebase 9 delivers the header timestamp, which is captured and forwarded to the FIFO 7. The filtering can be done in different flavors, which are fully orthogonal to each other. One option is that the input logic 6 filters the trace message according to the trace level, whereas depending on a runtime-configured minimum trace level, a specific message is discarded or forwarded to the FIFO shift register 7. Another option is that the input logic 7 filters the trace message according to the trace message type identifier, whereas depending on a runtime-configured trace message type identifier filter configuration, a specific message is discarded or forwarded to the FIFO shift register 7. And last but not least, the input logic 7 can filter the trace message based on other trace meta data extracted from the bus ADDR-signal. The FIFO 7 decouples the bus transfer speed from the trace data stream speed. Every entry consists of trace level, trace type, trace channel, data word, timestamp and skip information. The output logic converts the FIFO data format to the trace stream format.

The trace handler is able to handle a defined number of trace channels (2^CHANWID-1). Each channel has its own state as depicted in figure 7, which shows the trace channel state machine. A channel is in IDLE by default. The channel with the lowest number, different from the previous channel is allocated on a bus read, moving to the ALLOC state.

Filtering is done here. The first write with IS_DATA marker moves the state machine to ACTIVE. A write with IS_END marker closes the channel in any case and transits to IDLE again. In case of a not matching the filtering rules during ALLOC or ACTIVE the state machine moves to NULL. In this state, incoming data is not forwarded to the FIFO 7. If an incoming write cannot be stored in the FIFO 7 since it is full, the data is lost and the state machine transits to NULL. If all channels are allocated, the NULL channel is returned on read. The NULL channel (i.e. 2^CHANWID-1) is a pre defined channel number, whose data is always ignored.

Table 2 in figure 6 shows a strict sequence that a firmware has to follow for the trace data generation using the trace handler module system 1. The entire process relies on the proper handling of the address A, which is compliant to table 1 in figure 4. This flow offloads the firmware and takes care about timestamping, filtering and output formatting, with a minimum set of processor instructions. It is obvious that every opened channel has to be closed. If all channels are allocated, the NULL channel is returned on read. The whole sequence has no conditions and therewith a constant execution time. The close channel operation explicitly ignores any written data. The firmware operates faster, if the Send Payload operation can be issued in a standard loop. The additional write operation at the end is negligible.

In another embodiment, it is up to the use-case to choose the design-time constants and vary the implementation. Next to that, it is possible to encode other trace meta data using the approach of the TYPE and LEVEL. They are encoded in the bus address bits and forwarded to the FIFO 7. Filtering on them is optional. In another embodiment, other data used for filtering can be included as already depicted by using other trace meta data than TYPE and LEVEL. It is up to the implementation to handle more or less of this data and include it in the filter condition. It is also possible to count the gross trace load, by counting all incoming payload bytes. This counter would ignore the filter condition.

Furthermore, it is also possible to count the number of lost messages. Whenever the FIFO 7 is full, or the number of channels is exceeded, this counter would increment.

The inventive apparatus and method can be used for all architectures which issue a microcontroller, embedded or not, system-on-chip or not.

List of Reference Signs

Bus master

Bus system Bus slave

Trace handler module system Trace data stream Input logic

First-in-first-out (FIFO) shift register Output logic Time base Filter settings

Claims

1. A trace handler module system which is configured to take over a trace message representing an internal state of a firmware running on a processor of a System-on-Chip via a chip-internal bus system, wherein the trace message is carried by a bus data signal which is exchanged between a bus master and a bus slave over the chip-internal bus system and a bus address-signal, ADDR, is used to encode additional trace meta data of the trace message, wherein the trace handler module system comprises the bus slave configured to convert specific bus protocol data to strobe-based protocol data, an input logic configured to add timestamps, to do filtering and channel allocation of the converted data from the bus slave, a FIFO shift register configured to decouple a bus transfer speed from a trace data stream speed and to output a FIFO data format, and an output logic configured to convert the FIFO data format to a trace data stream format representing the trace message to reconstruct a system behavior issued by the processor.

2. The trace handler module system according to claim 1, wherein at design-time of the trace handler module system following symbols are defined assuming a function b(n)= \log_2(ji)], which returns a number of bits required to encode n different values: BUSAWID defining a chip-internal bus address width, BUSDWID defining a chip-internal bus data width, LEVELWID defining a level width of a trace level of the trace message, TYPEWID defining a type width of a trace message type identifier and CHANWID defining a channel width of a trace channel as a transport protocol layer entity to separate different trace messages during transmission between the bus master and the bus slave.

3. The trace handler module system according to claim 1, wherein the trace handler module system uses different slices of the bus ADDR-signal to extract the trace meta data of the trace message.

4. The trace handler module system according to claim 3, wherein one slice of the bus ADDR-signal defines a data marker, IS_DATA, which specifies the trace message payload bytes.

5. The trace handler module system according to claim 3, wherein one slice of the bus ADDR-signal defines an end marker, IS_END, which specifies a closing of a channel. 6. The trace handler module system according to claim 3, wherein one slice of the bus ADDR-signal defines the trace level, LEVEL, which specifies classes relevance of the trace message.

The trace handler module system according to claim 3, wherein one slice of the bus ADDR-signal defines the trace type, TYPE, which specifies the trace message type identifier.

8. The trace handler module system according to claim 3, wherein one slice of the bus ADDR-signal defines the trace channel, CHAN, which specifies a trace channel number.

9. The trace handler module system according to claim 1, wherein the input logic is fed by a timebase which delivers a header timestamp, which is captured and forwarded to the FIFO shift register.

10. The trace handler module system according to claim 6, wherein the input logic filters the trace message according to the trace level, whereas depending on a runtime-configured minimum trace level, a specific message is discarded or forwarded to the FIFO shift register.

11. The trace handler module system according to claim 7, wherein the input logic filters the trace message according to the trace message type identifier, whereas depending on a runtime-configured trace message type identifier, a specific message is discarded or forwarded to the FIFO shift register. 12. The trace handler module system according to one of the former claims, wherein the input logic filters the trace message based on other trace meta data extracted from the bus ADDR-signal.

13. The trace handler module system according to claim 1, wherein the trace handler module system comprises a trace channel state machine, which handles a defined number of trace channels, whereas the number of trace channels are pre-defined by (2^CHANWID-1).

14. The trace handler module system according to claim 1, wherein the trace handler module system comprises a counter configured to count a number of lost trace messages, whenever the FIFO shift register is full or the number of trace channels is exceeded.

15. The trace handler module system according to claim 1, wherein the trace handler module system comprises a counter configured to count a gross trace load, by counting all incoming payload bytes.

16. A method for generating a trace data stream out of trace messages using a minimum set of processor instructions by using a trace handler module system according to claims 1 to 15, wherein the method comprising the following steps:

- open a channel by reading any address of the trace handler module system, whereas a returned value is a channel base address A used for all successive actions ,

- write the trace message data to address A,

- set IS_END to 1 in address A to prepare channel closing, - close channel by writing something to address A.

17. The method according to claim 16, wherein other trace meta data than TYPE and LEVEL are written to address A. 18. The method according to claim 16, wherein if all channels are allocated, a NULL channel is returned on the address A, which is ignored.

19. The method according to claim 16, wherein the method is performed without any conditions and is performed in a constant execution time.