Disclosure of Invention
The following presents a simplified summary in order to provide a basic understanding of some aspects of the disclosed embodiments. This summary is not an extensive overview, and is intended to neither identify key/critical elements nor delineate the scope of such embodiments, but is intended as a prelude to the more detailed description that follows.
The embodiment of the disclosure provides a memory access method, a memory access device, a multi-core chip and a storage medium based on MCAL, wherein a unified address processing mechanism is used for directly distributing variables of each core to an internal bus address of a corresponding DCCM so as to realize that each core can access respective DCCM through an internal bus.
In some embodiments, the memory access method based on MCAL is applied to a multi-core chip, where i+1 cores numbered 0 to i are installed on the multi-core chip, where i is a positive integer greater than or equal to 1, and the memory access method includes:
based on the MCAL specification of a microcontroller abstraction layer of an automobile open system architecture AutoSAR, i+1 universal timer variables with the numbers of 0 to i are respectively set for i+1 cores;
setting a memory head address of a core internal memory allocated to a 0 th core of the 0 th general timer variable as an internal bus address accessed through an internal bus;
setting the memory head address of the core internal memory allocated to the ith core of the ith general timer variable as an actual physical address accessed through an external bus;
shifting the memory head address of the core internal memory of the ith core mapped by the ith general timer variable to enable the ith general timer variable to be remapped to an internal bus address accessed through an internal bus;
constructing a structure variable pointer array according to the i+1 universal timer variables;
in the case where the ith core invokes the fabric variable pointer array to access the core internal memory of the ith core, the core internal memory of the ith core is accessed via the internal bus by the ith general purpose timer variable.
Optionally, the setting the i+1 universal timer variables numbered 0 to i for the i+1 cores includes:
setting the 0 th general timer variable of the 0 th Core to Gpt _ChannelStatus_Core0;
the ith general timer variable of the ith core is set to Gpt _ChannelStatus_Corei.
Optionally, the setting the memory head address of the core internal memory allocated to the 0 th core of the 0 th general-purpose timer variable as an internal bus address accessed through the internal bus includes:
searching and acquiring an address range accessed through an internal bus according to a memory mapping table of the multi-core chip;
selecting a target address from an address range accessed through an internal bus as a memory head address of a core internal memory of a 0 th core;
and establishing a mapping relation between the target address allocation and the 0 th universal timer variable.
Optionally, the shifting the memory head address of the core internal memory of the ith core mapped by the ith universal timer variable to remap the ith universal timer variable to an internal bus address accessed through the internal bus includes:
respectively calculating an address offset distance Li between a target address and a memory head address of a core internal memory of an ith core;
and correspondingly shifting the ith universal timer variable according to the address offset distance Li so as to remap the ith universal timer variable to the target address.
Optionally, the constructing a structure variable pointer array according to the i+1 universal timer variables includes:
microcontroller abstract layer MCAL specification based on automotive open system architecture AutoSAR, defining a structure Gpt _channelstatus type;
constructing a structure variable pointer array Gpt _CoreChannelStatus on the basis of the structure Gpt _ChannelStatusType;
the array elements in the structure variable pointer array Gpt _corecannelstatus comprise:
(Gpt_ChannelStatusType*)(((uint32)&Gpt_ChannelStatus_Core0));
(Gpt_ChannelStatusType*)(((uint32)&Gpt_ChannelStatus_Corei)-Li)。
optionally, the memory access method further includes:
respectively counting the number and the number of data channels of the universal timer distributed to each core;
during the process of the ith core calling the structure variable pointer array to access the internal memory of the ith core, searching the ith general-purpose timer variable through the data channel distributed to the ith core.
In some embodiments, the MCAL-based memory access device is disposed on a multi-core chip, where i+1 cores numbered 0 to i are mounted on the multi-core chip, where i is a positive integer greater than or equal to 1, and the memory access device includes:
the variable setting module is configured to set i+1 universal timer variables with the numbers of 0 to i for i+1 cores respectively based on the MCAL specification of a microcontroller abstract layer of an automobile open system architecture (AutoSAR);
a first address allocation module configured to set a memory head address of a core internal memory allocated to a 0 th core of a 0 th general-purpose timer variable as an internal bus address accessed through an internal bus;
a second address allocation module configured to set a memory head address of a core internal memory allocated to an i-th core of the i-th general-purpose timer variable as an actual physical address accessed through the external bus;
an address offset module configured to offset a memory head address of a core internal memory of the ith core mapped by the ith general timer variable to remap the ith general timer variable to an internal bus address accessed through the internal bus;
a structure array construction module configured to construct a structure variable pointer array from i+1 universal timer variables;
and a memory access module configured to access the core internal memory of the ith core via the internal bus by the ith general purpose timer variable, in a case where the ith core invokes the fabric variable pointer array to access the core internal memory of the ith core.
In some embodiments, the MCAL-based memory access device includes a processor and a memory storing program instructions, the processor being configured to perform the MCAL-based memory access method as described herein when the program instructions are executed.
In some embodiments, the multi-core chip includes: a chip body; the MCAL-based memory access device described herein is mounted to the chip body.
In some embodiments, the storage medium stores program instructions that, when executed, perform an MCAL-based memory access method as described herein
The memory access method, the device, the multi-core chip and the storage medium based on the MCAL provided by the embodiment of the disclosure can realize the following technical effects:
the method and the device use a unified address processing mechanism to realize that different cores can access respective core internal memories through an internal bus, correspond to multi-core chips which do not support hardware remapping, and realize that memory data is accessed quickly through the internal bus by intensively storing and uniformly accessing the micro-controller abstract layer MCAL specifications based on an automobile open system architecture AutoSAR in an application scene of the MCAL through a specific access mode.
The foregoing general description and the following description are exemplary and explanatory only and are not restrictive of the application.
Detailed Description
So that the manner in which the features and techniques of the disclosed embodiments can be understood in more detail, a more particular description of the embodiments of the disclosure, briefly summarized below, may be had by reference to the appended drawings, which are not intended to be limiting of the embodiments of the disclosure. In the following description of the technology, for purposes of explanation, numerous details are set forth in order to provide a thorough understanding of the disclosed embodiments. However, one or more embodiments may still be practiced without these details. In other instances, well-known structures and devices may be shown simplified in order to simplify the drawing.
The terms first, second and the like in the description and in the claims of the embodiments of the disclosure and in the above-described figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate in order to describe embodiments of the present disclosure. Furthermore, the terms "comprise" and "have," as well as any variations thereof, are intended to cover a non-exclusive inclusion.
The term "plurality" means two or more, unless otherwise indicated.
In the embodiment of the present disclosure, the character "/" indicates that the front and rear objects are an or relationship. For example, A/B represents: a or B.
The term "and/or" is an associative relationship that describes an object, meaning that there may be three relationships. For example, a and/or B, represent: a or B, or, A and B.
The term "corresponding" may refer to an association or binding relationship, and the correspondence between a and B refers to an association or binding relationship between a and B.
Firstly, it should be noted that the multi-core chip of the present application is suitable for an automobile open system architecture (Aut omotive Open System Architecture, autoSAR), which is a framework for collaborative development of an automobile electronic system jointly participated by global automobile manufacturers, component suppliers, and various research and service institutions, and establishes an open automobile controller (ECU) standard software architecture. AutoSAR is mainly divided into 3 levels: an application layer (Application Softwar e Layer, ASW), a runtime environment (Runtime Environment, RTE), and a base software layer (Basic Software Layer, BSW). To ensure independence of the upper layer from the lower layer, each layer can only use the interface provided by the lower layer and provide a corresponding interface to the upper layer in normal cases. The layered architecture is the key for realizing the separation of software and hardware, and enables an automobile embedded system control software developer to get rid of the dependence on a hardware system during the development and verification of the traditional ECU software.
The application software layer contains several software components (Software Component, SWC) that interact with each other through ports (ports). Each software component may contain one or more Running Entities (REs) in which associated control algorithms are encapsulated, which may be triggered by RTE events (RTE events). In the embodiment of the present application, one SWC file may be regarded as one c file.
The runtime environment is used as a bridge for interaction between the application software layer and the basic software layer, and provides possibility for separation of software and hardware. RTEs can enable communication between software components, between base software, and between software components and base software.
The base software layer contains a number of base software modules that are responsible for the non-application related functions of the ECU. One of the most important functions of the basic software is the communication between ECUs, i.e. the signal interaction. The basic software layers can be further divided into four layers, namely a service Layer (Services Layer), an ECU abstract Layer (ECU Abs traction Layer), a microcontroller abstract Layer (Microcontroller Abstraction Layer, MC AL) and a Complex driver (Complex Drivers).
The micro controller abstract layer MCAL is a special layer for realizing unification of different hardware interfaces. The hardware can be packaged through the abstract layer of the microcontroller, so that upper software is prevented from directly operating registers of the microcontroller.
The service layer may perform the service functions of a memory, a communication network, a system, etc., and the hardware abstraction layer provides a transceiver or interface driver that may use microcontroller abstraction at the microcontroller abstraction layer of the respective devices below. The microcontroller abstraction layer is a part with hardware dependency, and is composed of a communication drive of the data link layer of the OS I, an analog digital I/O drive of ADC, PWM, DIO, and the like, a memory drive of EEPROM, flash, and the like, and a device drive area of the peripheral device microcontroller.
Referring to fig. 1, taking a general timer (General Purpose Timer, GP T) in MCAL as an example, an embodiment of the disclosure provides a memory access method based on MCAL, which is applied to a multi-core chip, where i+1 cores numbered from 0 to i are installed on the multi-core chip, where i is a positive integer greater than or equal to 1, and the memory access method includes:
step 101: based on the MCAL specification of a microcontroller abstraction layer of an automobile open system architecture AutoSAR, i+1 universal timer variables with numbers of 0 to i are respectively set for i+1 cores.
Step 102: the memory head address of the core internal memory allocated to the 0 th core of the 0 th general-purpose timer variable is set as an internal bus address accessed through the internal bus.
Step 103: the memory head address of the core internal memory allocated to the ith core of the ith general-purpose timer variable is set to the actual physical address accessed through the external bus.
Step 104: and offsetting the memory head address of the core internal memory of the ith core mapped by the ith universal timer variable so as to remap the ith universal timer variable to an internal bus address accessed through the internal bus.
Step 105: and constructing a structure variable pointer array according to the i+1 universal timer variables.
Step 106: in the case where the ith core invokes the fabric variable pointer array to access the core internal memory of the ith core, the core internal memory of the ith core is accessed via the internal bus by the ith general purpose timer variable.
In the embodiments of the present application, for multi-core chips, each core accesses a core internal memory (DC CM) only by way of an internal bus or an external bus, which differ significantly in speed. For example, for the DCCM of CORE1, its actual physical address is 0x40000000, which is slower when accessed via the external bus, and when accessed via address 0x10000000, the hardware recognizes as in-CORE memory, which is accessed via the internal bus, which is faster.
Meanwhile, due to the limitation of the Ldf file, one LDF file cannot be allocated to multiple cores at the same time for address 0x 10000000. If all cores are allocated to the address field of 0x10000000, illegal copy fields will also occur, resulting in such a variable for each core, which causes memory waste.
Therefore, the address corresponding to the variable set in the present application may be combined with the core to perform a fixed address offset, so that the variable address is changed to an internal bus area starting from 0x 10000000. In addition, because the MCAL has strict requirements on address field mapping, the application can achieve non-differential use by combining a fixed allocation format without changing the use habit of variables.
By adopting the memory access method based on the MCAL provided by the embodiment of the disclosure, a unified address processing mechanism is used, so that different cores can access respective core internal memories through an internal bus, and the memory data can be accessed quickly through the internal bus mode by corresponding to the multi-core chip which does not support hardware remapping, and by a specific access mode, the micro-controller abstract layer MCAL specification based on the automobile open system architecture AutoSAR is stored in a centralized manner under the application scene of the MCAL and accessed in a unified manner.
Optionally, as shown in fig. 2, the setting, for the i+1 cores, i+1 universal timer variables numbered from 0 to i respectively includes:
step 201: the 0 th general timer variable of the 0 th Core is set to Gpt _ChannelStatus_Core0.
Step 202: the ith general timer variable of the ith core is set to Gpt _ChannelStat us_Corei.
In the embodiment of the present application, for example, i may be 4, that is, 5 cores are installed on the multi-Core chip, namely, the 0 th Core0, the 1 st Core1, the 2 nd Core2, the 3 rd Core3 and the 4 th Core4, respectively, and then the universal timer variable may be represented by a code as: gpt _ChannelStatus_Core0, gpt _ChannelStatus_Core1, gpt _ChannelStatus_Core2, gpt _ChannelStatus_Core3, gpt _ChannelStatus_Core4, respectively, representing the memory head address of each Core.
Optionally, as shown in conjunction with fig. 3, the setting the memory head address of the core internal memory allocated to the 0 th core of the 0 th general-purpose timer variable as the internal bus address accessed through the internal bus includes:
step 301: and searching and acquiring an address range accessed through the internal bus according to the memory mapping table of the multi-core chip.
Step 302: from the address range accessed through the internal bus, the target address is selected as the memory head address of the core internal memory of the 0 th core.
Step 303: and establishing a mapping relation between the target address allocation and the 0 th universal timer variable.
In the embodiment of the present application, i may be, for example, 4, that is, 5 cores are mounted on the multi-Core chip, namely, the 0 th Core0, the 1 st Core1, the 2 nd Core2, the 3 rd Core3 and the 4 th Core4 are respectively allocated to the DCCM actual physical segment 0x40010000 of Core1, the universal timer variable Gpt _channelstatus_core1 is allocated to the DCCM of Core1, and other check strain amounts are allocated to the DCCMs in the same manner. The distribution of the LDF link file to the DCCM except Core0 is distributed to the corresponding actual physical address of the DCCM, and the specific code can be expressed as:
DCCM0:ORIGIN=0x10000000,LENGTH=0x00018000
DCCM1:ORIGIN=0x40010000,LENGTH=0x00040000
DCCM2:ORIGIN=0x50010000,LENGTH=0x00040000
DCCM3:ORIGIN=0x60010000,LENGTH=0x00018000
DCCM4:ORIGIN=0x70010000,LENGTH=0x00018000
optionally, as shown in conjunction with fig. 4, the offsetting the memory first address of the core internal memory of the ith core mapped by the ith universal timer variable to remap the ith universal timer variable to an internal bus address accessed through the internal bus includes:
step 401: and respectively calculating the address offset distance Li between the target address and the memory head address of the core internal memory of the ith core.
Step 402: and correspondingly shifting the ith universal timer variable according to the address offset distance Li so as to remap the ith universal timer variable to the target address.
Optionally, as shown in connection with fig. 5, the constructing a structure variable pointer array according to i+1 universal timer variables includes:
step 501: the micro-controller abstraction layer MCAL specification based on automotive open system architecture AutoSAR defines a structure Gpt _channelstatus type.
Step 502: constructing a structure variable pointer array Gpt _CoreChannelStatus on the basis of the structure Gpt _ChannelStatusType; wherein, the array elements in the structure variable pointer array Gpt _ Core ChannelStatus include:
(Gpt_ChannelStatusType*)(((uint32)&Gpt_ChannelStatus_Core0));
(Gpt_ChannelStatusType*)(((uint32)&Gpt_ChannelStatus_Corei)-Li)。
in the embodiment of the present application, the usage mode of the memory in the MCAL may be represented by a code:
LocalChannelStatusPtr=Gpt_CoreChannelStatus[CoreId];
LocalChannelStatusPtr[Count].NotifyStatus=GPT_FALSE;
in this process, all variables are found based on Gpt _corechannlstatus, so the first addresses of the array elements in Gpt _corechannlstatus are correspondingly offset without changing codes, and the first addresses are directly remapped into the 0x10000000 segment, and the codes can be expressed as:
/*Global array of pointers to store address of core status*/
static Gpt_ChannelStatusType*const Gpt_CoreChannelStatus[MCAL_NUMBER_OF_CORES]=
{
(Gpt_ChannelStatusType*)(((uint32)&Gpt_ChannelStatus_Core0)),
(Gpt_ChannelStatusType*)(((uint32)&Gpt_ChannelStatus_Core1)-0x30010000U),
(Gpt_ChannelStatusType*)(((uint32)&Gpt_ChannelStatus_Core2)-0x40010000U),
(Gpt_ChannelStatusType*)(((uint32)&Gpt_ChannelStatus_Core3)-0x50010000U),
(Gpt_ChannelStatusType*)(((uint32)&Gpt_ChannelStatus_Core4)-0x60010000U),
};
thus, the subsequent accesses are all started from 0x10000000, and the hardware recognizes that the internal bus access is performed, thereby improving the access speed.
Optionally, as shown in fig. 6, the memory access method further includes:
step 601: the number and number of data channels of the universal timer assigned to each core are counted separately.
Step 602: during the process of the ith core calling the structure variable pointer array to access the internal memory of the ith core, searching the ith general-purpose timer variable through the data channel distributed to the ith core.
In the embodiment of the present application, the present application searches the ith general timer variable through the data channels of the timer, so the number and the number of the data channels of each core need to be counted, and the code can be expressed as:
#if(GPT_MAX_CHANNEL_TO_CORE0!=0xFFU)
#if(GPT_MAX_CHANNEL_TO_CORE0!=0U)
#define GPT_START_SEC_VAR_NO_INIT_UNSPECIFIED_CORE0
#include"Gpt_MemMap.h"
static Gpt_ChannelStatusType Gpt_ChannelStatus_Core0[GPT_MAX_CHANNEL_TO_CORE0];
#define GPT_STOP_SEC_VAR_NO_INIT_UNSPECIFIED_CORE0
#include"Gpt_MemMap.h"
#endif
#endif
referring to fig. 7, an embodiment of the present disclosure provides an MCAL-based memory access device, which is disposed on a multi-core chip, and has i+1 cores numbered 0 to i mounted thereon, where i is a positive integer greater than or equal to 1, and includes:
the variable setting module 701 is configured to set i+1 universal timer variables numbered from 0 to i for i+1 cores respectively based on the MCAL specification of the microcontroller abstraction layer of the automotive open system architecture AutoSAR;
a first address allocation module 702 configured to set a memory head address of a core internal memory allocated to the 0 th core of the 0 th general timer variable to an internal bus address accessed through an internal bus;
a second address allocation module 703 configured to set a memory head address of the core internal memory allocated to the ith core of the ith general timer variable to an actual physical address accessed through the external bus;
an address offset module 704 configured to offset a memory head address of a core internal memory of the ith core mapped by the ith general timer variable so that the ith general timer variable is remapped to an internal bus address accessed through the internal bus;
a structure array construction module 705 configured to construct a structure variable pointer array from i+1 universal timer variables;
the memory access module 706 is configured to access the core internal memory of the ith core via the internal bus by way of the ith general purpose timer variable if the ith core invokes the fabric variable pointer array to access the core internal memory of the ith core.
By adopting the memory access device based on the MCAL provided by the embodiment of the disclosure, a unified address processing mechanism is used, so that different cores can access respective core internal memories through an internal bus, and the memory data can be accessed quickly through the internal bus mode by corresponding to the multi-core chip which does not support hardware remapping, and by a specific access mode, the memory access device based on the MCAL specification of the microcontroller abstract layer of the automotive open system architecture AutoSAR is stored in a centralized manner under the application scene of the MCAL and accessed in a unified manner.
As shown in conjunction with fig. 8, an embodiment of the present disclosure provides an MCAL-based memory access device, including a processor (processor) 800 and a memory (memory) 801. Optionally, the apparatus may further comprise a communication interface (Communication Interface) 802 and a bus 803. The processor 800, the communication interface 802, and the memory 801 may communicate with each other via the bus 803. The communication interface 802 may be used for information transfer. The processor 800 may invoke logic instructions in the memory 801 to perform the MCAL-based memory access method of the above-described embodiments.
Further, the logic instructions in the memory 801 described above may be implemented in the form of software functional units and sold or used as a separate product, and may be stored in a computer readable storage medium.
The memory 801 is a computer readable storage medium that may be used to store a software program, a computer executable program, and program instructions/modules corresponding to the methods in the embodiments of the present disclosure. The processor 800 executes the program instructions/modules stored in the memory 801 to perform the functional applications and data processing, i.e., to implement the MCAL-based memory access method in the above-described embodiments.
The memory 801 may include a storage program area that may store an operating system, at least one application program required for functions, and a storage data area; the storage data area may store data created according to the use of the terminal device, etc. In addition, the memory 801 may include a high-speed random access memory, and may also include a nonvolatile memory.
The embodiment of the disclosure provides a multi-core chip, comprising: chip body, and above-mentioned memory access device based on MCAL. The MCAL-based memory access device is installed in the product body. The mounting relationships described herein are not limited to placement within a product, but include mounting connections to other components of a product, including but not limited to physical, electrical, or signal transmission connections, etc. Those skilled in the art will appreciate that MCAL-based memory access devices may be adapted to viable product bodies to implement other viable embodiments.
Embodiments of the present disclosure provide a computer-readable storage medium storing computer-executable instructions configured to perform the MCAL-based memory access method described above.
The computer readable storage medium may be a transitory computer readable storage medium or a non-transitory computer readable storage medium.
Embodiments of the present disclosure may be embodied in a software product stored on a storage medium, including one or more instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of a method according to embodiments of the present disclosure. And the aforementioned storage medium may be a non-transitory storage medium including: a plurality of media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, or an optical disk, or a transitory storage medium.
The above description and the drawings illustrate embodiments of the disclosure sufficiently to enable those skilled in the art to practice them. Other embodiments may involve structural, logical, electrical, process, and other changes. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the sequence of operations may vary. Portions and features of some embodiments may be included in, or substituted for, those of others. Moreover, the terminology used in the present application is for the purpose of describing embodiments only and is not intended to limit the claims. As used in the description of the embodiments and the claims, the singular forms "a," "an," and "the" (the) are intended to include the plural forms as well, unless the context clearly indicates otherwise. Similarly, the term "and/or" as used in this application is meant to encompass any and all possible combinations of one or more of the associated listed. Furthermore, when used in this application, the terms "comprises," "comprising," and/or "includes," and variations thereof, mean that the stated features, integers, steps, operations, elements, and/or components are present, but that the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof is not precluded. Without further limitation, an element defined by the phrase "comprising one …" does not exclude the presence of other like elements in a process, method or apparatus comprising such elements. In this context, each embodiment may be described with emphasis on the differences from the other embodiments, and the same similar parts between the various embodiments may be referred to each other. For the methods, products, etc. disclosed in the embodiments, if they correspond to the method sections disclosed in the embodiments, the description of the method sections may be referred to for relevance.
Those of skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. The skilled artisan may use different methods for each particular application to achieve the described functionality, but such implementation should not be considered to be beyond the scope of the embodiments of the present disclosure. It will be clearly understood by those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, which are not repeated herein.
In the embodiments disclosed herein, the disclosed methods, articles of manufacture (including but not limited to devices, apparatuses, etc.) may be practiced in other ways. For example, the apparatus embodiments described above are merely illustrative, and for example, the division of the units may be merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not performed. In addition, the coupling or direct coupling or communication connection shown or discussed with each other may be through some interface, device or unit indirect coupling or communication connection, which may be in electrical, mechanical or other form. The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to implement the present embodiment. In addition, each functional unit in the embodiments of the present disclosure may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.
The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. In the description corresponding to the flowcharts and block diagrams in the figures, operations or steps corresponding to different blocks may also occur in different orders than that disclosed in the description, and sometimes no specific order exists between different operations or steps. For example, two consecutive operations or steps may actually be performed substantially in parallel, they may sometimes be performed in reverse order, which may be dependent on the functions involved. Each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.