WO2003048965A2 - Basisband-chip mit integrierter echtzeit-betriebssystem-funktionalität und verfahren zum betreiben eines basisband-chips - Google Patents

Basisband-chip mit integrierter echtzeit-betriebssystem-funktionalität und verfahren zum betreiben eines basisband-chips Download PDF

Info

Publication number
WO2003048965A2
WO2003048965A2 PCT/DE2002/004272 DE0204272W WO03048965A2 WO 2003048965 A2 WO2003048965 A2 WO 2003048965A2 DE 0204272 W DE0204272 W DE 0204272W WO 03048965 A2 WO03048965 A2 WO 03048965A2
Authority
WO
WIPO (PCT)
Prior art keywords
baseband chip
mobile radio
rtos
task
radio systems
Prior art date
Application number
PCT/DE2002/004272
Other languages
English (en)
French (fr)
Other versions
WO2003048965A3 (de
Inventor
Gerhard Forster
Original Assignee
Infineon Technologies Ag
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Infineon Technologies Ag filed Critical Infineon Technologies Ag
Publication of WO2003048965A2 publication Critical patent/WO2003048965A2/de
Publication of WO2003048965A3 publication Critical patent/WO2003048965A3/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/78—Architectures of general purpose stored program computers comprising a single central processing unit
    • G06F15/7807—System on chip, i.e. computer system on a single chip; System in package, i.e. computer system on one or more chips in a single package
    • G06F15/7814—Specially adapted for real time processing, e.g. comprising hardware timers

Definitions

  • Baseband chip with integrated real-time operating system functionality and method for operating a baseband chip
  • the invention relates to a baseband chip for mobile radio systems, which contains at least one controller using a real-time operating system and a digital signal processor.
  • the invention further relates to a method for operating such a baseband chip.
  • Such circuits In mobile radio systems, single-band baseband signal processing circuits are becoming increasingly attractive. Such circuits always include a controller or processor and at least one digital signal processor (DSP) as well as various peripherals which perform task-specific data processing tasks.
  • the controller or processor is responsible for the chip-wide process control, i.e. the administration and delegation of tasks to the DSP or the peripherals and the starting, monitoring and ending of the execution of the tasks.
  • the DSP carries out certain tasks typical for mobile communications such as interleaving / deinterleaving, source coding / decoding, channel coding / decoding, equalization, encryption / decryption etc., partly in cooperation with the peripherals.
  • the processing of these tasks in the DSP is software-controlled.
  • peripherals are fast hardware modules that implement certain arithmetic operations that occur continuously, such as the ACS (Add Compare Select) operation in Viterbi channel decoding and / or Viterbi equalization, in hardware alone.
  • ACS Add Compare Select
  • Other examples of peripherals are GMSK (Gaussian Minimum Shift Keying) modulators, digital baseband filters, etc.
  • Such a baseband processing circuit designed as a single chip is known from US Pat. No. 5,923,761. It is also known that modern chip designs such as the chips of the baseband chip family E-GOLD + manufactured by Infineon have such a structure.
  • a baseband chip is a multiprocessor module with scarce resources in internal memory (due to lack of space) and high real-time requirements. For these reasons, baseband chips are often operated with real-time operating systems (RTOS: Real Time Operating System).
  • RTOS Real Time Operating System
  • the RTOS usually runs on the controller and, like every operating system, implements a kind of "permanently running basic program" whose task is to keep the non-application-specific tasks out of the various application programs and to make them available "centrally” for them.
  • the application programs use this functionality of the RTOS.
  • the special feature of RTOS compared to conventional operating systems is that on the one hand they only have a very small space requirement for the kernel (the part of the program that is loaded into the volatile memory area of the processor during booting and remains there) and on the other hand low latency and high latency Data throughput must enable.
  • RTOS contain only a few powerful system calls and, in contrast to conventional operating systems such as Windows from Microsoft or the organizer operating system Windows CE from Microsoft, which is also used for mobile radio systems, no applications.
  • the conventional way to make RTOS available on the baseband chip is to assemble, compile, bind the program containing the applications (application program) with the RTOS and then in a non-volatile external (with respect to the baseband- Chip) to store the board memory of the mobile radio system.
  • This Non-volatile board memory (“board memory”) is, for example, a FLASH memory with a few MByte storage capacity.
  • RTOS Baseband chips loaded. These have an order of magnitude smaller memory size in the range of a few kbytes than the board memory.
  • the kernel of the RTOS which embodies the basic functionality of the RTOS, remains in the internal RAM area of the RTOS
  • RTOS RTOS
  • Some system manufacturers write the RTOS themselves and use it for their application programs.
  • RTOS e.g. the products OSE and Nucleus +.
  • These RTOS programs can be obtained directly from these companies and then integrated into the application program in the manner already described.
  • the invention has for its object to provide a baseband chip for mobile radio systems with an alternative concept for making available and in particular for localizing the RTOS.
  • the invention further aims to provide a method for operating such a baseband chip for mobile radio systems.
  • the object is solved by the features of claims 1, 14 and 15.
  • a baseband chip according to the invention for mobile radio systems accordingly has, in a manner known per se, at least one controller using an RTOS and a digital signal processor.
  • the functionality assigned to the kernel of the RTOS ie the basic functionality of the RTOS
  • at least part of it is permanently implemented on the baseband chip.
  • a first advantageous embodiment of the invention is characterized in that the kernel of the RTOS is at least partially stored in a non-volatile memory on the baseband chip. This means that at least part of the kernel (preferably the entire kernel) of the RTOS is permanently present on the RTOS, even when the baseband chip is deactivated.
  • Non-volatile ROM memory areas can be implemented in a space-saving manner with comparable memory content than RAM memory areas in the baseband chip.
  • the controller can directly process the machine code stored in the non-volatile memory.
  • An alternative, also useful Design variant is characterized in that the controller is a nano-code implementation.
  • commands received from the controller in machine code are first resolved into sub-machine code (so-called nano-codes) and the sub-machine codes are converted into physical signals in the controller. This enables greater flexibility with regard to the interaction between software (application program and RTOS) and controller hardware.
  • a further advantageous embodiment of the invention is characterized in that at least part of the functionality assigned to the kernel of the real-time operating system is implemented in the form of a hardware state machine on the baseband chip.
  • the implementation of the "real-time operating system as hardware state machine" significantly accelerates the processing speed compared to a software implementation.
  • Another advantage is that there are no license fees for proprietary RTOS software products.
  • the hardware state machine preferably comprises a task buffer for storing task information and priority information assigned to the tasks.
  • the task buffer enables tasks to be managed much more quickly and easily in terms of time and priority requirements than software-only tasks.
  • a particularly preferred dimensioning of the task buffer is that it is designed with two ports. This enables the simultaneous input (write) and output (read) of tasks from the task buffer, which enables application programs to be processed with little delay.
  • the RTOS-typical administrative task of re-sorting tasks is completely implemented in hardware. Since the software-based re-sorting of tasks for an RTOS is a relatively time-consuming administration activity, the measure according to the invention achieves a considerable saving of time in the context of task administration.
  • the sorting circuit is preferably designed such that it cannot be influenced or programmed by application programs. This means that the tasks supplied by the application programs are always fed to a fixed input register of the task buffer, so that the application programs have no influence on the storage location where the task (task
  • Another advantageous variant of the hardware state machine is characterized in that it has bit registers which implement hardware semaphores.
  • semaphores that are used in RTOS for communication between processes are also implemented in hardware.
  • the hardware state machine further comprises (at least) one timer which controls one another in time comprehensive processing of multiple tasks.
  • the implementation of a timer in the hardware state machine enables a time-oriented task management to be implemented in addition to or instead of the priority-based task management. Individual time slots are assigned to the tasks, each time slot reserving the CPU time for a specific task. This ensures that several tasks can be managed and processed in the same period, possibly without taking their priority information into account.
  • Fig. 1 is a simplified, schematic representation of the
  • FIG. 2 shows a simplified, schematic representation of the structure of a hardware state machine which, according to the second exemplary embodiment, can be used in the baseband chip shown in FIG. 1.
  • the chip 1 shows an example of the (greatly simplified) structure of a baseband chip 1, as used in modern mobile radio systems (in particular mobile stations).
  • the chip 1 comprises a controller 2, known as an MCU (memory control unit), which is connected to a first bus structure 3, a digital signal processor (DSP) 4, which is connected to a second bus structure 5, and one Number of internal hardware modules 6.1, 6.2, 6.3 and 6.4, which are connected to the second bus structure 5.
  • the hardware modules are, for example, a GMSK modulator 6.1, a digital voice band filter 6.2, a digital and / or analog baseband filter 6.3 and one
  • Viterbi module 6.4 These hardware modules are constructed in the form of fast hardware data paths, which Process certain computing processes that are to be carried out continuously in operation in hardware. These hardware modules known as peripherals 6.1, 6.2, 6.3 and 6.4 can be connected directly to external modules via connections 7.1, 7.2 and 7.3 or (like the Viterbi module 6.4) do not provide a direct connection to the outside.
  • the two bus structures 3 and 5 consist in the usual way of a data bus, an address bus and a control bus, and are in communication with one another via a bus interface 8
  • bus structures 3 and 5 are coupled to timers 10 and 11, respectively, which deliver time signals for the controller 2 and the DSP 4, respectively.
  • the first bus structure 3 connected to the controller 2 is also coupled to a SIM card interface 13 and some I / O control units, of which an I / O controller 12 is shown as an example in FIG. 1.
  • I / O controller 12 Via the (exemplary) I / O controller 12, a variety of external devices such as a keypad, further input elements, a serial cable connection can be used
  • the SIM card interface 13 provides an interface for a SIM card connection.
  • Both the controller 2 and the DSP 4 can be controlled via internal interrupts 14a, 15a and external interrupts 14b and 15b.
  • the controller 2 has an internal interrupt controller (IR-C) 16 and the DSP 4 has a usually external interrupt controller (IR-C) 17 (ie the interrupt control of the DSP 4 takes place via the second bus Structure 5).
  • the baseband chip 1 further comprises a RAM area 18a which, together with a controller-internal volatile memory IRAM 18b, forms the volatile program memory area (“working memory”) of the controller 2.
  • a non-volatile internal memory area ROM 19 represents the boot block for the controller 2 and serves to initialize it when the controller 2 is started up. Its size is typically only about 2 kbytes.
  • the hardware structure represented by reference numeral 20 is a further non-volatile memory area.
  • the structure designated by reference numeral 20 is a hardware state machine, as will be explained in more detail later in connection with FIG. 2.
  • the on-chip RAM area 18a, the on-chip ROM memory 19 and the hardware structure 20 can be connected to the controller 2 via a common bus 21.
  • the controller-internal IRAM area 18b is connected to a controller-internal bus 22.
  • the hardware structure 20 can now be connected to the controller 2 via a data connection 25 and the common bus 21 or can also be connected directly to the controller-internal bus 22. The latter is indicated by the dashed data connection 23.
  • connection 24, shown in dashed lines, via which the internal RAM area 18a is connected to the first bus structure 3 is also optional.
  • the baseband chip 1 can have significantly more functional elements, such as digital-to-analog converters, analog-to-digital converters, hardware modules for power management,
  • the controller 2 and the DSP 4 are intended to perform different tasks. While the controller 2 essentially performs administrative tasks in the course of processing application programs, the DSP 4 is assigned the essential computationally intensive signal processing functions. For example, the DSP 4 performs the calculation steps for the source coding / decoding, the channel coding / decoding, the equalization and the interleaving / deinterleaving.
  • the monitoring and control of the computing processes carried out in the DSP 4 and the interaction between the computing steps carried out in the DSP 4 in software and the hardware modules 6.1, 6.2 and 6.3 in hardware is carried out by the controller 2.
  • the hardware module 6.4 is e.g. controlled exclusively by DSP 4.
  • the controller 2 also takes over the mapping of logical traffic and control channels onto physical GSM (Global System for Mobile Communications) channels in the case of reception, the bundling of physical GSM channels, data transmission functions at the protocol level and the provision of the bursts customary in the GSM standard. formats.
  • GSM Global System for Mobile Communications
  • RTOS In principle, it is possible to operate controller 2 without an operating system. Since such an application program requires too much memory space, RTOS are used as operating systems.
  • An RTOS provides a limited number of processes and system calls, which are used by the application programs. The CPU time is assigned by the processes. Examples of (RTOS) processes are interrupt processes (hardware interrupt or in response to a software condition), timer interrupt processes, background processes which are processed continuously with the lowest priority and processes which are assigned a desired priority can be. Communication between processes is handled via so-called messages and semaphores. Messages enable extensive data exchange between different processes, while semaphores allow faster but less flexible interactions between processes.
  • RTOS The processing of an application program in the presence of an RTOS takes place in such a way that the processes and system calls made available by the RTOS are used when processing the tasks of the application program.
  • These RTOS program functions must therefore be kept permanently available (in machine code) in the internal RAM memory area 18a of the baseband chip 1 or in the IRAM 18b of the controller 2.
  • these parts of the RTOS which are referred to as kernels, are therefore loaded from an external memory into the internal RAM memory area 18a or IRAM 18b and remain there over the entire area
  • the kernel of the RTOS is permanently implemented on the baseband chip 1.
  • the kernel of the RTOS is stored in the internal ROM memory 20.
  • the ROM mask physically contains the machine code of the RTOS, which is included in the kernel.
  • Machine code of the application programs to be processed is loaded in the usual way into the internal memory area RAM 18a or IRAM 18b and swapped out again as required.
  • the non-volatile ROM memory 20 has a smaller area than a volatile RAM memory of corresponding memory size needed.
  • the required storage capacity of the ROM memory 20 is typically in the range of 40-80 kbytes.
  • the application program required for the chip 1 according to the invention differs from the application program used with conventional chips with integrated RTOS only in that the integration of the RTOS is omitted.
  • Application program (retrievable from the RAM 18a / IRAM 18b) by an internal decoder of the controller 2 is first resolved into nano code and this nano code is then used by the
  • Controller 2 processed, i.e. converted into physical signals.
  • At least part of the RTOS is assigned to the kernel
  • FIG. 2 The structure of such a hardware state machine 200 is shown in FIG. 2.
  • the hardware state machine 200 can be implemented instead of the structure 20 or in combination with the ROM memory 20, in which case the memory size of the ROM memory 20 can be reduced.
  • the hardware state machine 200 comprises a task buffer 201, which is designed in the form of a RAM stack.
  • the memory width of the task buffer 201 is divided into two sections 201a and 201b. Section 201a is provided for the entry of task information, while the priority information associated with the task information is entered in the adjacent section 201b.
  • the memory width of section 201a can be 4 bytes, for example and the memory width of section 201b may be 1 byte.
  • the stack number of the task buffer 201 is 256, for example.
  • the task buffer 201 preferably has 2 ports, i.e. via an input 202 and an output 203.
  • the input 202 always points to the same lowest memory word with a given address, while the output 203 is directed to the uppermost filled memory word via a pointer (filled memory words of the task buffer 201 are shown in FIG. 2 hatched).
  • the tasks currently to be processed are successively entered into the task buffer 201 via the input 202.
  • the tasks (task information plus priority information) are shifted "up" in the stack.
  • the pointer for output 203 is incremented, so that the latter always points to the uppermost task.
  • the pointer can, for example, be designed as a counter (not shown).
  • the task buffer 201 is read out via the output 203. After reading out a task, the pointer is decremented so that it remains directed at the "top" task.
  • the task information and the priority information are fed to the controller 2 for processing via the data lines shown in FIG. 2.
  • the RTOS management functionality of “stacking” task information and priority information in hardware is implemented by the task buffer 201.
  • This functionality corresponds to the following C function of an RTOS: // struct to hold RT scheduling INFO struct stRTInfo
  • the above C function declares a C structure and defines the variable stRTVar.
  • the total stack width of 5 bytes does not correspond to the data format of the instruction set in the TriCore chip, so that a widening to 6 or 8 bytes or a reduction to 4 bytes is more efficient with this chip.
  • the hardware state machine 200 can also have a sorting data path 204.
  • the sorting data path 204 carries out an automatic re-sorting of all tasks (task information plus priority information) as soon as a new task is entered into the task buffer 201 via the input 202.
  • the functionality of the sort data path 204 corresponds to the following C functions: vlNIT_TASK_BUFFER: initializes the task buffer 200 and sets the RT management control to the idle state ("idle mode") swADD_TASK_2_BUFFER: adds a new task to the task buffer 200 vSORT_TASK_BUFFER: compares the priority information of 2 tasks with each other and decides on each comparison whether a position change should be activated or not vSWAP_POSITION: performs a position change
  • the C function swADD_TASK_2_BUFFER also monitors overflow of the task buffer 201 and, if appropriate, indicates this by an error message, and the pointer position is also updated by vSORT_TASK_BUFFER after a change of position has been carried out.
  • Sort data path 204 implements the C function vSORT_TASK_BUFFER in hardware.
  • the sorting data path 204 is activated without the involvement of the controller 2 whenever a new task data record is entered in the task buffer 201.
  • the structure of the hardware state machine 200 also depends on the structure and capabilities of the underlying baseband chip 1, in particular on its interrupt system and its context switching management
  • _MTCR (CPUSRCO_ADDR, (_mfcr (CPUSRCO_ADDR) & OxFFFFOOOO) I LOCAL_INT_ENABLE); _MTCR (CPUSRCO_ADDR, Cmfcr (CPUSRCO_ADDR) & OxFFFFOO) I (AX_xxSRPN-uwCount)) _MTCR (CPUSRCO_ADDR, (_mfcr (CPUSRCO_ADDR) & OxFFFFOOFF) I LOCAL_FIRE_INT); uwCount ++ ; break; case 1:
  • _MTCR (CPUSRC1_ADDR, (_mfcr (CPUSRCl_ADDR) & OxFFFFOOOO) I LOCALJNT.ENABLE); _MTCR (CPUSRC1_ADDR, (_mfcr (CPUSRCl_ADDR) & OxFFFFOO) I (MAX_xxSRPN-uwCount)) _MTCR (CPUSRC1_ADDR, (_mfcr (CPUSRCl_ADDR) & OxFFFFOOFF) I LOCAL_FIRE_INT); uwCount ++ ; break; case 2: _MTCR (CPUSRC2_ADDR, (_mfcr (CPUSRC2_ADDR) & OxFFFFOOOO) I LOCAL_INT_ENABLE); _MTCR (CPUSRC2_ADDR, C_mfcr (CPUSRC2_ADDR) & OxFFFFOO) I (AX_xxSRPN-uwCount)); _ TCR
  • the C function swMCU_RT_PROCESSING makes full use of the TriCore interrupt system. The following steps are carried out.
  • the interrupts are activated, whereby the execution of the first four tasks is initiated while maintaining their upper and lower context (the TriCore architecture offers the option of outsourcing the lower and / or upper part of the register bank separately).
  • CCPN Current CPU Priority Number
  • ICR Interrupt Control Register
  • Tasks that have been entered in the task buffer 201 in the meantime are rearranged depending on their priority information and then processed in the same way.
  • a control register 205 is provided in the hardware state machine 200 for the activation or deactivation of the tri-core functionality described by the swMCU_RT_PROCESSING function.
  • the control register 205 comprises at least one memory location for a start / stop bit.
  • the priority-oriented RT management process already described is started or ended in the hardware state machine 200 by a 1/0 change of this start / stop bit.
  • bit registers 207 can also be provided as hardware semaphores in the hardware state machine 200.
  • the hardware state machine 200 comprises an additional timer 206.
  • the sequence control i.e. the control of the pointer 203 is now carried out via the timer 206 according to a specific time slot scheme, the priority information being ignored.
  • the timer 206 assigns each task to be processed a specific time slot, in which it processes for the duration of the time slot, is suspended at the end of the time slot and is continued later when this time slot occurs again. In this way, several tasks can be processed in parallel on their "virtual processor" in a same period of time.
  • the priority-oriented and time-oriented RT task administrations can also be used in a suitable manner in combination, as a result of which both priority and time information are taken into account when managing the tasks.
  • the hardware state machine 200 can include further data paths, registers, timers etc.
  • An external interrupt can be triggered, for example, by a request for a SIM card data transfer, which requires the controller 2 to respond immediately.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephone Function (AREA)

Abstract

Ein Basisband-Chip (1) für Mobilfunksysteme enthält mindestens einen ein Echtzeit-Betriebssystem (RTOS) nutzenden Controller (2) und einen digitalen Signalprozessor (4). Die dem Kernel des Echtzeit-Betriebssystems (RTOS) zugeordnete Funktionalität oder zumindest ein Teil derselben ist mittels eines nichtflüchtigen Speichers (20) oder eines Hardware-Zustandsautomaten permanent auf dem Basisband-Chip (1) implementiert.

Description

Beschreibung
Basisband-Chip mit integrierter Echtzeit-Betriebssystem- Funktionalität und Verfahren zum Betreiben eines Basisband- Chips
Die Erfindung betrifft einen Basisband-Chip für Mobilfunksysteme, welcher mindestens einen ein Echtzeit- Betriebssystem nutzenden Controller und einen digitalen Signalprozessor beinhaltet. Ferner betrifft die Erfindung ein Verfahren zum Betreiben eines derartigen Basisband-Chips.
In Mobilfunksystemen gewinnen als Einzelchip ausgeführte Basisband-Signalverarbeitungsschaltungen zunehmend an Attraktivität. Derartige Schaltungen umfassen stets einen Controller oder Prozessor und mindestens einen digitalen Signalprozessor (DSP) sowie verschiedene Peripherals, welche aufgabenspezifische Datenverarbeitungsaufgaben vornehmen. Dem Controller bzw. Prozessor obliegt die chipweite Ablaufsteuerung, d.h. die Verwaltung und Delegierung von Tasks an den DSP oder die Peripherals und das Starten, Überwachen und Beenden der Ausführungen der Tasks. Der DSP führt, teilweise im Zusammenwirken mit den Peripherals, bestimmte Mobilfunk-typische Aufgaben wie Interleaving/Dein- terleaving, Quellenkodierung/-dekodierung, Kanalkodierung/- dekodierung, Entzerrung, Verschlüsselung/Entschlüsselung usw. durch. Die Abarbeitung dieser Aufgaben im DSP ist Softwaregesteuert. Demgegenüber sind die Peripherals schnelle Hardware-Module, welche bestimmte, in ständiger Wiederholung auftretende Rechenoperationen wie beispielsweise die ACS- (Add Compare Select-) Operation bei der Viterbi-Kanaldekodierung und/oder Viterbi-Entzerrung allein in Hardware realisieren. Weitere Beispiele für Peripherals sind GMSK- (Gaussian Minimum Shift Keying-) Modulatoren, digitale Basisband-Filter usw.
Eine solche als Einzelchip konzipierte Basisband-Verarbeitungsschaltung ist aus dem U.S. -Patent 5,923,761 bekannt. Ferner ist bekannt, dass moderne Chip-Designs wie beispielsweise die von Infineon hergestellten Chips der Basisband-Chipfamilie E-GOLD+ einen solchen Aufbau aufweisen.
Unter Software-Gesichtspunkten ist ein solcher Basisband-Chip ein Mehrprozessor-Baustein mit knappen Resourcen an internem Speicherplatz (aufgrund Platzmangel) und hohen Echtzeit-Anforderungen. Aus diesen Gründen werden Basisband-Chips häufig mit Echtzeit-Betriebssystemen (RTOS: Real Time Operating System) betrieben.
Das RTOS läuft üblicherweise auf dem Controller und realisiert, wie jedes Betriebssystem, eine Art "permanent laufendes Grundprogramm" dessen Aufgabe darin besteht, die nicht anwendungsspezifischen Aufgaben aus den verschiedenen Anwendungsprogrammen heraus zu halten und für diese "zentral" zur Verfügung zu stellen. Die Anwendungsprogramme nutzen diese Funktionalität des RTOS. Die Besonderheit von RTOS im Vergleich zu üblichen Betriebssystemen besteht darin, dass sie einerseits nur einen sehr kleinen Speicherplatzbedarf für den Kernel (der Programmteil, der beim Booten in den flüchtigen Speicherbereich des Prozessors geladen wird und dort verbleibt) haben dürfen und andererseits geringe Latenzzeiten und hohe Datendurchsätze ermöglichen müssen. Als Folge davon enthalten RTOS nur wenige leistungsfähige Systemaufrufe (System calls) und im Gegensatz zu herkömmlichen Betriebssystemen wie beispielsweise Windows von Microsoft oder das auch für Mobilfunksysteme verwendete Organizer-Betriebssystem Windows CE von Microsoft keine Anwendungen.
Die herkömmliche Vorgehensweise, um RTOS auf dem Basisband- Chip verfügbar zu machen, besteht darin, das die Anwendungen enthaltende Programm (Anwendungsprogramm) mit dem RTOS zusammenzufügen, zu kompilieren, zu binden und dann in einem nichtflüchtigen, externen (in Bezug auf den Basisband-Chip) Platinen-Speicher des Mobilfunk-Systems abzulegen. Bei diesem nicht flüchtigen Platinen-Speicher ("board memory") handelt es sich z.B. um einen FLASH-Speicher mit einigen MByte Speicherkapazität . Beim Booten des Systems wird dann der Kernel des RTOS sowie aktuell benötigte Programmteile des Anwendungsprogramms in die internen RAM-Bereiche des
Basisband-Chips geladen. Diese weisen eine um Größenordnungen geringere Speichergröße im Bereich von einigen kByte als der Platinen-Speicher auf. Der Kernel des RTOS, welcher die Grundfunktionalität des RTOS verkörpert, verbleibt über die gesamte Betriebsdauer in dem internen RAM-Bereich des
Basisband-Chips, während die restlichen Programmteile des RTOS sowie auch die anwendungspezifischen Programmteile bei Bedarf nachgeladen und anschließend wieder ausgelagert werden.
Für den Bezug des RTOS stehen verschiedene Möglichkeiten zur Wahl. Einige Systemhersteller schreiben das RTOS selber und benutzen es für ihre Anwendungsprogramme. Daneben besteht die Möglichkeit, RTOS über Spezialanbieter zu beziehen, bekannt sind z.B. die Produkte OSE und Nucleus+. Diese RTOS-Programme können direkt von diesen Firmen bezogen und dann in der bereits beschriebenen Weise in das Anwendungsprogramm eingebunden werden.
In dem U.S. -Patent 6,029,000 ist eine Mehrprozessorplattform beschrieben, welche einen DSP und einen Controller umfasst. DSP und Controller weisen jeweils ein eigenes RTOS auf. Ein auf einem der Prozessoren laufender Cross-Compiler kompiliert Code für den anderen Prozessor in Maschinencode.
Der Erfindung liegt die Aufgabe zugrunde, einen Basisband- Chip für Mobilfunksysteme mit einem alternativen Konzept zur Verfügbarmachung und insbesondere zur Lokalisierung des RTOS zu schaffen. Ferner zielt die Erfindung darauf ab, ein Verfahren zum Betreiben eines solchen Basisband-Chips für Mobilfunksysteme anzugeben. Die Aufgabe wird durch die Merkmale der Ansprüche 1, 14 und 15 gelöst. Ein erfindungsgemäßer Basisband-Chip für Mobilfunksysteme weist demnach in an sich bekannter Weise mindestens einen ein RTOS nutzenden Controller und einen digitalen Signalprozessor auf. Erfindungsgemäß ist die dem Kernel des RTOS zugeordnete Funktionalität (d.h. die Grundfunktionalität des RTOS) oder zumindest ein Teil derselben permanent auf dem Basisband-Chip implementiert .
Durch die Implementierung der Funktionalität des Kernels
(oder auch nur eines Teils desselben) auf dem Basisband-Chip kann eine Erhöhung der Verarbeitungsgeschwindigkeit erreicht werden und es besteht die Möglichkeit, Lizenzkosten, die bei der herkömmlichen Lösung für die Benutzung von RTOS zu zahlen sind, einzusparen. Darüber hinaus kann eine Platzersparnis infolge einer möglich werdenden Reduzierung des internen RAM- Bereiches erzielt werden.
Eine erste vorteilhafte Ausführungsform der Erfindung kennzeichnet sich dadurch, dass der Kernel des RTOS zumindest teilweise in einem nichtflüchtigen Speicher auf dem Basisband-Chip gespeichert ist. Damit ist zumindest ein Teil des Kernels (vorzugsweise der gesamte Kernel) des RTOS permanent, auch bei deaktiviertem Basisband-Chip, auf demselben vorhanden. Bei der Abarbeitung von
Anwendungsprogrammen, welche sich des RTOS bedienen, werden die entsprechenden Systemaufrufe von dem in dem nichtflüchtigen Speicher gespeicherten RTOS-Maschinencode bewirkt. Ein 'Vorzug dieser Lösung gegenüber der herkömmlichen Vorgehensweise besteht darin, dass nichtflüchtige ROM- Speicherbereiche bei vergleichbarem Speicherinhalt platzsparender als RAM-Speicherbereiche im Basisband-Chip zu realisieren sind.
Grundsätzlich kann der Controller eine Direktverarbeitung des in dem nichtflüchtigen Speicher gespeicherten Maschinencodes vornehmen. Eine alternative, ebenfalls zweckmäßige Ausführungsvariante kennzeichnet sich dadurch, dass der Controller eine Nano-Code-Implementierung ist. Bei einer Nano-Code-Implementierung des Controllers werden vom Controller in Maschinencode erhaltene Befehle zunächst in Submaschinencode (sogenannte Nano-Codes) aufgelöst und die Submaschinencodes werden in dem Controller in physikalische Signale umgesetzt. Dadurch wird eine höhere Flexibilität hinsichtlich des Zusammenwirkens zwischen Software (Anwendungsprogramm und RTOS) und Controller-Hardware ermöglicht.
Eine weitere vorteilhafte Ausführungsform der Erfindung kennzeichnet sich dadurch, dass zumindest ein Teil der dem Kernel des Echtzeit-Betriebssystems zugeordneten Funktionalität in Form eines Hardware-Zustandautomaten auf dem Basisband-Chip implementiert ist. Durch die Implementierung des "Echtzeit-Betriebssystems als Hardware- Zustandsautomaten" wird eine deutliche Beschleunigung der Verarbeitungsgeschwindigkeit im Vergleich zu einer Software- Realisierung erreicht. Ferner besteht der Vorteil, dass Lizenzgebühren für proprietäre RTOS-Softwareprodukte entfallen.
Vorzugsweise umfasst der Hardware-Zustandsautomat einen Task- Buffer zur Speicherung von Task-Informationen und den Tasks zugeordneten PrioritätInformationen. Der Task-Buffer ermöglicht eine wesentlich schnellere und unkompliziertere Verwaltung von Tasks in Bezug auf Zeit- und Prioritätserfordernisse als eine allein über Software erfolgende Verwaltung von Tasks.
Eine besonders bevorzugte Dimensionierung des Task-Buffers besteht darin, dass dieser mit zwei Ports ausgeführt ist. Dies ermöglicht die zeitgleiche Eingabe (Schreiben) und Ausgabe (Lesen) von Tasks aus dem Task-Buffer, wodurch eine verzögerungsarme Abarbeitung von Anwendungsprogrammen ermöglicht wird. Bei einer weiteren, ebenfalls besonders bevorzugten Ausgestaltung des Hardware-Zustandsautomaten umfasst dieser eine Sortierschaltung, welche ausgelegt ist, die in dem Task- Buffer enthaltenen Task- und Prioritätsinformationen gemäß der Prioritätsinformationen umzusortieren. Die RTOS-typische Verwaltungstätigkeit des Umsortierens von Tasks wird dadurch vollständig in Hardware realisiert. Da das Software-basierte Umsortieren von Tasks für ein RTOS eine relativ zeitaufwändige Verwaltungstätigkeit ist, wird durch die erfindungsgemäße Maßnahme ein beträchtlicher Zeitgewinn im Rahmen der Task-Verwaltung erreichbar.
Die Sortierschaltung ist dabei vorzugsweise so ausgelegt, dass sie nicht seitens Anwendungsprogrammen beeinflussbar oder programmierbar ist. D.h., die von den Anwendungsprogrammen gelieferten Tasks werden stets einem fest vorgegebenen Eingangsregister des Task-Buffers zugeführt, so dass die Anwendungsprogramme keinen Einfluss auf den Speicherort haben, an welchem der Task (Task-
Information und Prioritätsinformation) in dem Task-Speicher abgelegt wird. Da der Umsortierungsalgorithmus allein durch die "Verdrahtung" der Sortierschaltung bestimmt ist, wird auf diese Weise eine Entkopplung zwischen der Funktionalität von Anwendungen und der Verwaltung der Tasks dieser Anwendungen geschaffen.
Eine weitere vorteilhafte Ausführungsvariante des Hardware- Zustandsautomaten kennzeichnet sich dadurch, dass er Bitregister aufweist, welche Hardware-Semaphoren realisieren. Semaphoren, die in RTOS zur Kommunikation zwischen Prozessen eingesetzt werden, sind in diesem Fall ebenfalls in Hardware realisiert .
Nach einer weiteren vorteilhaften Ausführungsvariante umfasst der Hardware-Zustandsautomat ferner (mindestens) einen Zeitgeber, welcher zur Steuerung einer zeitlich ineinander greifenden Abarbeitung mehrerer Tasks ausgelegt ist. Die Implementierung eines Timers in dem Hardware-Zustandsautomat ermöglicht, dass neben oder anstelle der prioritätsorientierten Task-Verwaltung eine zeitorientierte Task-Verwaltung realisierbar ist. Dabei werden den Tasks einzelne Zeitschlitze zugeteilt, wobei jeder Zeitschlitz die CPU-Zeit für einen bestimmten Task reserviert. Dadurch wird erreicht, dass mehrere Tasks, gegebenenfalls ohne Berücksichtigung ihrer Prioritätsinformationen, im gleichen Zeitraum verwaltet und abgewickelt werden können.
Die Erfindung wird nachfolgend anhand von zwei Ausführungsbeispielen unter Bezugnahme auf die Zeichnung näher erläutert; in dieser zeigt:
Fig. 1 eine vereinfachte, schematische Darstellung der
Struktur eines erfindungsgemäßen Basisband-Chips; und
Fig. 2 eine vereinfachte, schematische Darstellung der Struktur eines Hardware-Zustandsautomaten, der gemäß dem zweiten Ausführungsbeispiel in den in Fig. 1 gezeigten Basisband-Chip eingesetzt werden kann.
Fig. 1 zeigt exemplarisch den (stark vereinfachten) Aufbau eines Basisband-Chips 1, wie er in modernen Mobilfunksystemen (insbesondere Mobilstationen) eingesetzt wird. Der Chip 1 umfasst einen als MCU (memory control unit) bezeichneten Controller 2, welcher mit einer ersten Bus-Struktur 3 in Verbindung steht, einen digitalen Signalprozessor (DSP) 4, welcher mit einer zweiten Bus-Struktur 5 in Verbindung steht, sowie eine Anzahl von internen Hardware-Modulen 6.1, 6.2, 6.3 und 6.4, welche mit der zweiten Bus-Struktur 5 in Verbindung stehen. Die Hardware-Module sind beispielsweise ein GMSK- Modulator 6.1, ein digitaler Sprachband-Filter 6.2, ein digitaler und/oder analoger Basisband-Filter 6.3 und ein
Viterbi-Modul 6.4. Konstruktiv sind diese Hardware-Module in Form schneller Hardware-Datenpfade realisiert, welche bestimmte Rechenabläufe, die im Betrieb in ständiger Wiederholung durchzuführen sind, in Hardware abarbeiten. Diese als Peripherals bezeichneten Hardware-Module 6.1, 6.2, 6.3 und 6.4 können über Verbindungen 7.1, 7.2 und 7.3 direkt an externe Baugruppen angebunden sein oder (wie das Viterbi- Modul 6.4) keine direkte Verbindung nach außen vorsehen.
Die beiden Bus-Strukturen 3 und 5 bestehen in üblicher Weise aus einem Datenbus, einem Adressbus und einem Steuerbus und stehen über ein Bus-Interface 8 miteinander in
Datenaustauschverbindung. Ferner können ein gemeinsamer Speicherbereich 9 sowie (in nicht dargestellter Weise) individuelle Busspeicher in Form von RAM vorgesehen sein.
Ferner sind die Bus-Strukturen 3 und 5 mit Timern 10 bzw. 11 gekoppelt, welche Zeitsignale für den Controller 2 bzw. den DSP 4 liefern.
Die mit dem Controller 2 in Verbindung stehende erste Bus- Struktur 3 ist ferner mit einem SIM-Card-Interface 13 und einigen I/O Steuereinheiten gekoppelt, von denen in Fig. 1 exemplarisch ein I/O Controller 12 dargestellt ist. Über den (exemplarischen) I/O Controller 12 können eine Vielzahl von externen Geräten wie beispielsweise ein Keypad, weitere Eingabeelemente, eine serielle Kabelverbindung zur
Mobilstation usw. mit dem Basisband-Chip 1 in Verbindung gebracht werden. Das SIM-Card-Interface 13 stellt eine Schnittstelle für eine SIM-Card Anbindung zur Verfügung.
Sowohl der Controller 2 als auch der DSP 4 können über interne Interrupts 14a, 15a und externe Interrupts 14b bzw. 15b gesteuert werden. Zu diesem Zweck weist der Controller 2 einen internen Interrupt-Controller (IR-C) 16 und der DSP 4 einen üblicherweise externen Interrupt-Controller (IR-C) 17 auf (d.h. die Interrupt-Steuerung des DSP 4 erfolgt über die zweite Bus-Struktur 5) . Der Basisband-Chip 1 umfasst ferner einen RAM-Bereich 18a, der zusammen mit einem Controller-internen flüchtigen Speicher IRAM 18b den flüchtigen Programmspeicherbereich ("Arbeitsspeicher") des Controllers 2 bildet. Ein nichtflüchtiger interner Speicherbereich ROM 19 stellt den Boot-Block für den Controller 2 dar und dient bei Inbetriebnahme der Anfangsinitialisierung desselben. Seine Größe beträgt typischerweise lediglich etwa 2kByte.
Bei der mit dem Bezugszeichen 20 dargestellten Hardware- Struktur handelt es sich bei einem ersten Ausführungsbeispiel um einen weiteren nichtflüchtigen Speicherbereich. Bei einem zweiten Ausführungsbeispiel ist die mit dem Bezugszeichen 20 bezeichnete Struktur ein Hardware-Zustandsautomat, wie er später in Verbindung mit der Fig. 2 noch näher erläutert wird.
Der Chip-interne RAM-Bereich 18a, der Chip-interne ROM- Speicher 19 und die Hardware-Struktur 20 können über einen gemeinsamen Bus 21 mit dem Controller 2 in Verbindung stehen. Der Controller-interne IRAM-Bereich 18b ist an einen Controller-internen Bus 22 angebunden. Die Hardware-Struktur 20 kann nun wie dargestellt über eine Datenverbindung 25 und den gemeinsamen Bus 21 mit dem Controller 2 in Verbindung stehen oder auch direkt an den Controller-internen Bus 22 angebunden sein. Letzteres ist durch die gestrichelte Datenverbindung 23 angedeutet.
Ebenfalls optional ist die gestrichelt dargestellte Verbindung 24, über welche der interne RAM-Bereich 18a mit der ersten Bus-Struktur 3 in Verbindung steht.
Der Basisband-Chip 1 kann wesentlich mehr Funktionselemente, wie beispielsweise Digital-Analog-Umsetzer, Analog-Digital- Umsetzer, Hardware-Module für das Leistungsmanagement,
Adress-Berechnung usw. enthalten. Nicht dargestellt sind ferner Funktionselemente zur Erzeugung des Systemtaktes ("local oscillator") , die ebenfalls auf dem Chip 1 integriert sind.
Dem Controller 2 und dem DSP 4 sind unterschiedliche Aufgaben zugedacht. ährend der Controller 2 im wesentlichen Verwaltungsaufgaben im Rahmen der Abwicklung von Anwendungsprogrammen wahrnimmt, sind dem DSP 4 die wesentlichen rechenintensiven Signalverarbeitungsfunktionen zugeteilt. Beispielsweise nimmt der DSP 4 die Berechnungsschritte für die Quellenkodierung/-Dekodierung, die Kanalkodierung/-Dekodierung, die Entzerrung und die Ver- /Entschachtelung vor. Die Überwachung und Steuerung der im DSP 4 durchgeführten Rechenabläufe sowie das Zusammenwirken zwischen der im DSP 4 in Software und den Hardware-Modulen 6.1, 6.2, und 6.3 in Hardware durchgeführten Rechenschritte wird von dem Controller 2 übernommen. Das Hardware-Modul 6.4 wird z.B. ausschließlich vom DSP 4 gesteuert. Der Controller 2 übernimmt ferner das Abbilden von logischen Verkehrs- und Steuerkanälen auf physikalische GSM- (Global System for Mobile Communications-) Kanäle im Empfangsfall, das Bündeln physikalischer GSM-Kanäle, Datenübertragungsfunktionen auf Protokollebene sowie die Bereitstellung der im GSM-Standard üblichen Burst-Formate.
Prinzipiell ist es möglich, den Controller 2 ohne Betriebssystem zu betreiben. Da ein solches Anwendungsprogramm einen zu großen Speicherplatzbedarf benötigt, werden RTOS als Betriebssysteme verwendet. Ein RTOS stellt eine begrenzte Anzahl von Prozessen und Systemaufrufen zur Verfügung, welche von den Anwendungsprogrammen genutzt werden. Durch die Prozesse wird die CPU-Zeit zugewiesen. Beispiele für (RTOS-) Prozesse sind Interrupt-Prozesse (Hardware-Interrupt oder in Reaktion auf eine Software- Bedingung) , Timer-Interrupt-Prozesse, Hintergrund-Prozesse, welche mit niedrigster Priorität ununterbrochen abgearbeitet werden und Prozesse, denen eine gewünschte Priorität zugeordnet werden kann. Die Kommunikation zwischen Prozessen wird über sogenannte Messages (Mitteilungen) und Semaphoren (Ampeln) abgewickelt . Messages ermöglichen einen umfassenden Datenaustausch zwischen unterschiedlichen Prozessen, während Semaphoren schnellere aber weniger flexible Interaktivitäten zwischen Prozessen zulassen.
Die Abarbeitung eines Anwendungsprogramms bei Vorhandensein eines RTOS erfolgt in der Weise, dass bei Abarbeitung der Tasks des Anwendungsprogramms auf die von dem RTOS zur Verfügung gestellten Prozesse und Systemaufrufe zurückgegriffen wird. Diese RTOS-Programmfunktionen müssen daher (in Maschinencode) im internen RAM-Speicherbereich 18a des Basisband-Chips 1 oder im IRAM 18b des Controllers 2 ständig verfügbar gehalten werden. Bei konventionellen Systemen werden daher diese als Kernel bezeichneten Teile des RTOS von einem externen Speicher in den internen RAM- Speicherbereich 18a oder IRAM 18b geladen und verbleiben dort über die gesamte
Betriebsdauer des Basisband-Chips 1.
Im Gegensatz dazu ist bei dem erfindungsgemäßen Basisband- Chip 1 der Kernel des RTOS permanent auf dem Basisband-Chip 1 implementiert.
Nach einer ersten bevorzugten Ausführungsvariante ist der Kernel des RTOS in dem internen ROM-Speicher 20 abgelegt. D.h., physikalisch enthält die ROM-Maske den vom Kernel umfassten Maschinencode des RTOS. Maschinencode der abzuarbeitenden Anwendungsprogramme wird in üblicher Weise je nach Bedarf in den internen Speicherbereich RAM 18a bzw. IRAM 18b geladen und wieder ausgelagert .
Gegenüber der konventionellen Lösung ist vorteilhaft, dass der nichtflüchtige ROM-Speicher 20 eine geringere Fläche als ein flüchtiger RAM-Speicher entsprechender Speichergröße benötigt. Die benötigte Speicherkapazität des ROM-Speichers 20 liegt typischerweise im Bereich von 40-80 kByte.
Das für den erfindungsgemäßen Chip 1 benötigte Anwendungsprogramm unterscheidet sich lediglich dadurch von dem bei konventionellen Chips eingesetzten Anwendungsprogramm mit eingebundenen RTOS, dass das Einbinden des RTOS entfällt.
Alternativ zu einem unmittelbar Maschinencode verarbeitenden Controller 2 kann dieser auch als Nano-Code-Implementierung realisiert sein. In diesem Fall werden Maschinencodesequenzen des RTOS (abrufbar aus dem ROM 20) und des
Anwendungsprogramms (abrufbar aus dem RAM 18a/IRAM 18b) durch einen internen Dekodierer des Controllers 2 zunächst in Nano- Code aufgelöst und dieser Nano-Code wird dann von dem
Controller 2 verarbeitet, d.h. in physikalische Signale umgesetzt .
Bei einer zweiten Ausführungsvariante der Erfindung ist zumindest ein Teil der dem Kernel des RTOS zugeordneten
Funktionalität in Form eines Hardware-Zustandsautomaten auf dem Basisband-Chip 1 implementiert.
Die Struktur eines solchen Hardware-Zustandsautomaten 200 ist in Fig. 2 dargestellt. Der Hardware-Zustandsautomat 200 kann anstelle der Struktur 20 oder in Kombination mit dem ROM- Speicher 20 implementiert sein, wobei im letzteren Fall die Speichergröße des ROM-Speichers 20 reduziert werden kann.
Der Hardware-Zustandsautomat 200 umfasst einen Task-Buffer 201, welcher in Form eines RAM-Stapelspeichers ausgeführt ist. Die Speicherbreite des Task-Buffers 201 ist in zwei Abschnitte 201a und 201b unterteilt. Der Abschnitt 201a ist zum Eintrag von Task-Informationen vorgesehen, während in dem benachbarten Abschnitt 201b die der Task-Information zugeordnete Prioritätsinformation eingetragen wird. Die Speicherbreite des Abschnitts 201a kann beispielsweise 4 Byte und die Speicherbreite des Abschnitts 201b kann 1 Byte betragen. Die Stapelanzahl des Task-Buffers 201 beträgt beispielsweise 256.
Der Task-Buffer 201 verfügt vorzugsweise über 2 Ports, d.h. über einen Eingang 202 und einen Ausgang 203. Der Eingang 202 weist mit vorgegebener Adresse stets auf das gleiche unterste Speicherwort, während der Ausgang 203 über einen Zeiger jeweils auf das oberste gefüllte Speicherwort gerichtet ist (gefüllte Speicherwörter des Task-Buffers 201 sind in Fig. 2 schraffiert dargestellt) .
Bei der Abarbeitung des Anwendungsprogramms werden die aktuell zu verarbeitenden Tasks über den Eingang 202 nacheinander in den Task-Buffer 201 eingetragen. In Art eines FIFO-Speichers werden dabei die Tasks (Task-Informationen plus Prioritätsinformationen) im Stapelspeicher "nach oben" verschoben. Gleichzeitig wird beim Eintrag eines neuen Tasks der Zeiger für den Ausgang 203 inkrementiert, so dass Letzterer stets auf den obersten Task zeigt. Der Zeiger kann beispielsweise als Zähler (nicht dargestellt) ausgeführt sein.
Für die Abarbeitung der Tasks wird der Task-Buffer 201 über den Ausgang 203 ausgelesen. Nach dem Auslesen eines Tasks wird der Zeiger dekrementiert , so dass er weiterhin auf den "obersten" Task gerichtet bleibt. Die Task-Information sowie die Prioritätsinformation wird über die in Fig. 2 dargestellten Datenleitungen dem Controller 2 zur Abarbeitung zugeleitet.
Durch den Task-Buffer 201 wird die RTOS-Verwaltungs- funktionalität des "Stapeins" von Task-Informationen und Prioritätsinformationen in Hardware realisiert. Diese Funktionalität entspricht der folgenden C-Funktion eines RTOS: // struct to hold RT-Scheduling INFO struct stRTInfo
uword uwTaskBufferfMAXTASK]; ubyte ubPrioBuffer[MAXTASK]; sword uwTaskBufferlndex; r stRTVar; struct stRTInfo *pstRTPtr = NULL;
Die obige C-Funktion deklariert eine C-Struktur und definiert die Variable stRTVar. Die Variable stRTVar umfasst die Definition des Abschnitts 201a des Task-Buffers 201 mit der Breite uword und Höhe MAXTASK, die Definition des Abschnitts 201b mit der Breite ubyte und mit der Höhe MAXTASK, und des Zeigers (TaskBufferlndex) . Z.B. wird MAXTASK = 256, uword = 32 Bit und ubyte = 8 Bit gewählt . In der untersten Programmzeile wird der Zeiger zunächst auf NULL gesetzt.
Die Auslegung des Task-Buffers 201 mit der Höhe MAXTASK = 256 ist auf den TriCore-Chip zugeschnitten, da dessen Interrupt- System eine maximale Anzahl von 256 Prioritätsstufen verarbeiten kann. Die Stapelbreite von insgesamt 5 Byte entspricht allerdings nicht dem Datenformat des Befehlssatzes in dem TriCore-Chip, so dass eine Verbreiterung auf 6 oder 8 Byte oder eine Reduzierung auf 4 Byte bei diesem Chip effizienter ist.
Der Hardware-Zustandsautomat 200 kann ferner einen Sortier- Datenpfad 204 aufweisen. Der Sortier-Datenpfad 204 führt eine automatische Umsortierung sämtlicher Tasks (Task-Informa- tionen plus Prioritätsinformationen) durch, sobald ein neuer Task über den Eingang 202 in den Task-Buffer 201 eingetragen wird.
Die Funktionalität des Sortier-Datenpfads 204 entspricht den folgenden C-Funktionen: vlNIT_TASK_BUFFER: initialisiert den Task-Buffer 200 und setzt die RT- Verwaltungssteuerung in den Leerlaufzustand ("idle mode") swADD_TASK_2_BUFFER: trägt einen neuen Task in den Task-Buffer 200 ein vSORT_TASK_BUFFER: vergleicht die Prioritätsinformation von 2 Tasks miteinander und entscheidet bei jedem Vergleich, ob ein Positionswechsel aktiviert werden soll oder nicht vSWAP_POSITION: führt einen Positionswechsel durch
Durch die C-Funktion swADD_TASK_2_BUFFER wird ferner ein Überlaufen des Task-Buffers 201 überwacht und gegebenenfalls durch eine Fehlermeldung angezeigt, und durch vSORT_TASK_BUFFER wird ferner die Zeigerposition nach Vornahme eines Positionswechsels aktualisiert.
Der Sortier-Datenpfad 204 implementiert die C-Funktion vSORT_TASK_BUFFER in Hardware. Die Aktivierung des Sortier- Datenpfads 204 erfolgt ohne Mitwirkung des Controllers 2 immer dann, wenn ein neuer Task-Datensatz in den Task-Buffer 201 eingetragen wird.
Die Struktur des Hardware-Zustandsautomaten 200 hängt in der Praxis auch von dem Aufbau und den Fähigkeiten des zugrundeliegenden Basisband-Chips 1 ab, und zwar insbesondere von dessen Interrupt-System und seinem Context-Switching Management
Das folgende Beispiel erläutert die Verwendung des Interrupt- Systems des TriCore-Chips durch eine erfindungsgemäße RTOS on-Chip Implementierung anhand der Verwendung der Funktion swMCU_RT_PROCESSING. CPUSRCO/l/2/3 (CPU Service Request
Control) bezeichnen die vier im TriCore verfügbaren Register, deren Aufgabe es ist, CPU-Interrupts zu verwalten. Mit ihrer Hilfe werden den Task-Prioritäten entsprechende CPU-Prioritäten zugewiesen. Die Möglichkeit, diese (bereits vorhandenen) Register zur Verwaltung der Task-Prioritäten zu nutzen, bildet einen spezifischen Vorteil der TriCore Architektur für die vorliegende Erfindung. sword swMCU_RT_PROCESSING (void) <
uword uwCount; sword swRetValue; uwCount = 0; swRetvalue = 0;
while (l) i
//'process' the whole available Task Buffer if ( (pstRTPtr->swTaskBufferlπdex>0) && (uwCount<) )
\ // disable Interrupts globally
// -> no RT-Scheduling while this function is performed!
_DISABLE();
// pre-decrement TaskBufferlndex -> point to first valid entry pstRTPtr->(-swTaskBufferlndex);
// set SRPN in Reg. CPUSRCO and launch SW-posted Interrupt: // •> start with Top of Task Buffer' and go downwards... switch (uwCount)
case 0:
_MTCR(CPUSRCO_ADDR, (_mfcr(CPUSRCO_ADDR) & OxFFFFOOOO) I LOCAL_INT_ENABLE); _MTCR(CPUSRCO_ADDR, Cmfcr(CPUSRCO_ADDR) & OxFFFFFFOO) I ( AX_xxSRPN-uwCount)) _MTCR(CPUSRCO_ADDR, (_mfcr(CPUSRCO_ADDR) & OxFFFFOOFF) I LOCAL_FIRE_INT); uwCount++; break; case 1:
_MTCR(CPUSRC1_ADDR, (_mfcr(CPUSRCl_ADDR) & OxFFFFOOOO) I LOCALJNT.ENABLE); _MTCR(CPUSRC1_ADDR, (_mfcr(CPUSRCl_ADDR) & OxFFFFFFOO) I (MAX_xxSRPN-uwCount)) _MTCR(CPUSRC1_ADDR, (_mfcr(CPUSRCl_ADDR) & OxFFFFOOFF) I LOCAL_FIRE_INT); uwCount++; break; case 2: _MTCR(CPUSRC2_ADDR, (_mfcr(CPUSRC2_ADDR) & OxFFFFOOOO) I LOCAL_INT_ENABLE); _MTCR(CPUSRC2_ADDR, C_mfcr(CPUSRC2_ADDR) & OxFFFFFFOO) I ( AX_xxSRPN-uwCount)); _ TCR(CPUSRC2_ADDR, (_mfcr(CPUSRC2_ADDR) & OxFFFFOOFF) I LOCAL_FIRE_INT); uwCount++, break; case 3.
_MTCR(CPUSRC3_ADDR, (_mfcr(CPUSRC3_ADDR) & OxFFFFOOOO) I LOCAL_IIMT_ENABLE), _ TCR(CPUSRC3_ADDR, (_mfcr(CPUSRC3_ADDR) & OxFFFFFFOO) I (MAX_xxSRPN uwCount)); _MTCR(CPUSRC3_ADDR, Lmfcr(CPUSRC3_ADDR) & OxFFFFOOFF) I LOCAL.FIREJNT); uwCount++, break; r //end of switch // remove Task Buffer entπes pstRTPtr->uwTaskBuffer[pstRTPtr >swTaskBufferlndex] = 0; pstRTPtr >ubPπoBuffer[pstRTPtr >swTaskBufferlndex]= 0, r //end of if eise i swRetValue = 1 ; // exit endless loop break; r // set CPU-Pπo to 1 and .. _MTCR(ICR, (_mfcr(ICR) & OxFFFFFFOO) I 0x01), // . . enable Interrupts globally // -> RT Scheduling in 'idle' Tasks are PRECESSED now !
_ENABLE(); r//end of endless loop return (swRetValue); r // end of function swMCU RT_PROCESSING()
Die C-Funktion swMCU_RT_PROCESSING greift im vollen Umfang auf das TriCore-interrupt-System zurück. Folgende Schritte werden durchgeführt .
1. Sämtliche Interrupts werden deaktiviert. 2. Der Task mit der höchsten Prioritätsinformation wird mit SRPN = 255 (SRPN: Service Request Priority Number) in das TriCore-Register CPUSRCO eingetragen und nachfolgend wird der entsprechende Software-Interrupt über Software ausgelöst .
3. Der Task mit der zweit höchsten Prioritätsinformation erhält SRPN = 254, wird in das TriCore-Register CPUSRC1 eingetragen und der (Software-) Interrupt wird anschließend ausgelöst . 4. Mit den beiden folgenden Tasks wird in derselben Weise unter Verwendung der verbleibenden zwei TriCore-Register CPUSRC2 und CPUSRC3 verfahren.
5. Nachdem die Verwaltungssteuerung in den Leerlaufmodus zurückgekehrt ist (der Wert 1 wird in das Bit-Feld CCPN (Current CPU Priority Number) des Core-Registers ICR (Interrupt Control Register) des TriCore-Chip geschrieben) , werden die Interrupts aktiviert, wodurch die Ausführung der ersten vier Tasks unter Wahrung ihres oberen und unteren Kontextes initiiert wird (die TriCore Architektur bietet die Möglichkeit, separat den unteren und/oder oberen Teil der Registerbank auszulagern) .
6. Dieser Prozess wird solange weitergeführt, bis alle Tasks abgearbeitet sind.
Tasks, die zwischenzeitlich in den Task-Buffer 201 eingetragen wurden, werden in Abhhängigkeit von ihrer Prioritätsinformation umsortiert und dann in gleicher Weise prozessiert .
Für die Aktivierung bzw. Deaktivierung der durch die Funktion swMCU_RT_PROCESSING beschriebenen TriCore-Funktionalität ist in dem Hardware-Zustandsautomaten 200 ein Steuerregister 205 vorgesehen. Das Steuerregister 205 umfasst zumindest einen Speicherplatz für ein Start-/Stop-Bit . Durch einen 1/0 Wechsel dieses Start-/Stop-Bits wird der bereits beschriebene prioritätsorientierte RT-Verwaltungsprozess in dem Hardware- Zustandsautomaten 200 gestartet bzw. beendet. Zur Steuerung einer Interaktivität zwischen Prozessen des RTOS können ferner Bit-Register 207 als Hardware-Semaphoren im Hardware-Zustandsautomaten 200 vorgesehen sein.
Aufgrund des umfassenden Interrupt-Systems im TriCore-Chip und der Möglichkeit, bestimmte Bitmuster in die Core-Register CPUSRCO/1/2/3 des TriCore-Chip einzutragen, werden ausser der in Fig. 2 dargestellten Hardware für eine prioritätsorientierte RT-Task-Verwaltung im TriCore-Chip keine weiteren zusätzlichen Hardware-Komponenten benötigt.
Eine weitere Möglichkeit besteht darin, neben oder anstelle der prioritätsorientierten RT-Task-Verwaltung eine zeitorientierte RT-Task-Verwaltung vorzusehen. In diesem Fall umfasst der Hardware-Zustandsautomat 200 einen zusätzlichen Timer 206. Die Ablaufsteuerung (d.h. die Steuerung des Zeigers 203) erfolgt nun über den Timer 206 nach einem bestimmten Zeitschlitzschema, wobei die Prioritätsinformation ignoriert wird. Der Timer 206 teilt jedem abzuarbeitenden Task einen bestimmten Zeitschlitz zu, in welchem dieser für die Dauer des Zeitschlitzes prozessiert, am Ende des Zeitschlitzes ausgesetzt und später, beim nächsten Auftreten dieses Zeitschlitzes, weitergeführt wird. Auf diese Weise können mehrere Tasks in einem gleichen Zeitraum auf ihrem "virtuellen Prozessor" parallel prozessiert werden.
Bei Vorsehen eines Timers 206 können die prioritätsorientierte und die zeitorientierte RT-Task- Verwaltungen auch in geeigneter Weise kombiniert genutzt werden, wodurch sowohl Prioritäts- als auch Zeitinformation bei der Verwaltung der Tasks berücksichtigt wird.
Je nach Basisband-Chip 1 und dessen Interrupt-Fähigkeit kann der Hardware-Zustandsautomat 200 weitere Datenpfade, Register, Timer usw. umfassen. Darüber hinaus sind vielfältige Varianten der vorstehend beschriebenen RT- Verwaltung der Tasks möglich. Beispielsweise kann vorgesehen sein, die Ausführung von Tasks durch externe Interrupts oder sogar externe Interrupt-Gruppen zu unterbrechen ("preemptive RT-scheduling" ) . Dies kann beispielsweise dadurch erreicht werden, dass die im Task-Buffer 201 zur Ausführung anstehenden Tasks nicht an die höchsten Speicherplätzen bzw. Interrupt-Stufen gesetzt werden sondern stattdessen tiefer liegende Interrupt-Stufen gewählt werden (z.B. SRPN = 200, 199, 198, 197 für die vier zur Ausführung anstehenden Tasks statt SRPN = 255, 254, 253, 252).
Ein externer Interrupt kann beispielsweise durch eine Anforderung für einen SIM-Card-Datentransfer ausgelöst werden, welcher eine sofortige Reaktion des Controllers 2 erforderlich macht.

Claims

Patentansprüche
1. Basisband-Chip für Mobilfunksysteme, welcher mindestens einen ein Echtzeit-Betriebssystem (RTOS) nutzenden Controller (2) und einen digitalen Signalprozessor (4) beinhaltet, d a d u r c h g e k e n n z e i c hn e t, dass die dem Kernel des Echtzeit-Betriebssystems (RTOS) zugeordnete Funktionalität oder zumindest ein Teil derselben permanent auf dem Basisband-Chip (1) implementiert ist.
2. Basisband-Chip für Mobilfunksysteme nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t, dass der Kernel des Echtzeit-Betriebssystems (RTOS) zumindest teilweise in einem nichtfluchtigen Speicher (20) auf dem Basisband-Chip (1) gespeichert ist.
3. Basisband-Chip für Mobilfunksysteme nach Anspruch 1 oder 2, d a d u r c h g e k e n n z e i c h n e t, dass der Basisband-Chip (2) eine Nano-Code-Implementierung ist .
4. Basisband-Chip für Mobilfunksysteme nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass zumindest ein Teil der dem Kernel des Echtzeit-Betriebssystems zugeordneten Funktionalität in Form eines Hardware- Zustandsautomaten (200) auf dem Basisband-Chip (1) implementiert ist.
5. Basisband-Chip für Mobilfunksysteme nach Anspruch 4, d a d u r c h g e k e n n z e i c h n e t, dass der Hardware-Zustandsautomat (200) einen Task-Buffer (201) zur Speicherung von Taskinformationen und den Tasks zugeordneten Prioritätsinformationen umfasst.
6. Basisband-Chip für Mobilfunksysteme nach Anspruch 5, d a d u r c h g e k e n n z e i c h n e t, dass der Task-Buffer (201) mit zwei Ports (202, 203) ausgeführt ist.
7. Basisband-Chip für Mobilfunksysteme nach Anspruch 5 oder 6, d a d u r c h g e k e n n z e i c h n e t, dass ein Task-Buffer-Zeiger (203) als Hardware-Zähler implementiert ist, der bei Eintrag einer neuen Taskinformation inkrementiert und bei Auslesen einer
Taskinformation zur Abarbeitung derselben dekrementiert wird.
8. Basisband-Chip für Mobilfunksysteme nach einem der Ansprüche 5 bis 7, d a d u r c h g e k e n n z e i c h n e t, dass der Hardware-Zustandsautomat (200) eine Sortierschaltung (204) umfasst, welche ausgelegt ist, die in dem Task-Buffer (201) enthaltenen Task- und Prioritätsinformationen gemäß den Prioritätsinformationen umzusortieren.
9. Basisband-Chip für Mobilfunkanwendungen nach Anspruch 8, d a d u r c h g e k e n n z e i c h n e t, dass der Hardware-Zustandsautomat (200) ein Ein- oder Mehrbit-Steuerregister (205) zum Aktivieren und Deaktivieren der Sortierschaltung (204) umfasst.
10. Basisband-Chip für Mobilfunksysteme nach Anspruch 9, d a d u r c h g e k e n n z e i c h n e t, dass die Sortierschaltung (204) nicht seitens Anwendungsprogrammen beeinflussbar oder programmierbar ist.
11. Basisband-Chip für Mobilfunksysteme nach einem der Ansprüche 5 bis 10, d a d u r c h g e k e n n z e i c h n e t, dass der Hardware-Zustandsautomat (200) Bitregister (207) aufweist, welche Hardware-Semaphoren realisieren.
12. Basisband-Chip für Mobilfunksysteme nach einem der Ansprüche 5 bis 11, d a d u r c h g e k e n n z e i c h n e t, dass der Hardware-Zustandsautomat (200) einen Zeitgeber (206) aufweist, welcher zur Steuerung einer zeitlich ineinandergreifenden Abarbeitung mehrerer Tasks ausgelegt ist.
13. Basisband-Chip für Mobilfunkanwendungen nach Anspruch 12, d a d u r c h g e k e n n z e i c h n e t, dass der Controller (2) der TriCore-Chip der Firma Infineon ist .
14. Verfahren zum Betreiben eines Basisband-Chips für Mobilfunksysteme, welcher mindestens einen ein Echtzeit- Betriebssystem (RTOS) nutzenden Controller (2) und einen digitalen Signalprozessor (4) beinhaltet, d a d u r c h g e k e n n z e i c h n e t - dass bei der Abarbeitung von Anwendungsprogrammen die dem Kernel des Echtzeit-Betriebssystems (RTOS) zugeordnete Funktionalität zumindest teilweise von einem auf dem Basisband-Chip (1) lokalisierten nichtflüchtigen Speicher (20) bezogen wird.
15. Verfahren zum Betreiben eines Basisband-Chips für
Mobilfunksysteme, welcher mindestens einen ein Echtzeit-Betriebssystem (RTOS) nutzenden Controller (2) und einen digitalen Signalprozessor (4) beinhaltet, d a du r c h g e k e n n z e i c h n e t - dass bei der Abarbeitung von Anwendungsprogrammen ein auf dem Basisband-Chip (1) angeordneter Hardware-Zustandsautomat (200) Funktionen ausführt, welche zumindest teilweise der Funktionalität eines Echtzeit-Betriebssystems (RTOS) entsprechen.
16. Verfahren nach Anspruch 15, d a d u r c h g e k e n n z e i c h n e t dass eine Funktion ausgeführt wird, welche eine Sortierung von Taskinformationen und Prioritätsinformationen in Abhängigkeit von den den Taskinformationen zugeordneten Prioritätsinformationen vornimmt .
17. Verfahren nach Anspruch 15 oder 16, d a d u r c h g e k e n n z e i c h n e t dass eine Funktion ausgeführt wird, welche eine Steuerung einer zeitlich ineinandergreifenden Abarbeitung mehrerer Tasks vornimmt.
PCT/DE2002/004272 2001-11-30 2002-11-20 Basisband-chip mit integrierter echtzeit-betriebssystem-funktionalität und verfahren zum betreiben eines basisband-chips WO2003048965A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE2001158774 DE10158774A1 (de) 2001-11-30 2001-11-30 Basisband-Chip mit integrierter Echtzeit-Betriebssystem-Funktionalität und Verfahren zum Betreiben eines Basisband-Chips
DE10158774.0 2001-11-30

Publications (2)

Publication Number Publication Date
WO2003048965A2 true WO2003048965A2 (de) 2003-06-12
WO2003048965A3 WO2003048965A3 (de) 2004-07-22

Family

ID=7707518

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2002/004272 WO2003048965A2 (de) 2001-11-30 2002-11-20 Basisband-chip mit integrierter echtzeit-betriebssystem-funktionalität und verfahren zum betreiben eines basisband-chips

Country Status (2)

Country Link
DE (1) DE10158774A1 (de)
WO (1) WO2003048965A2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106470175A (zh) * 2015-08-20 2017-03-01 深圳市中兴微电子技术有限公司 一种基带芯片及信号处理方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0627100A1 (de) * 1992-12-23 1994-12-07 Centre Electronique Horloger S.A. Multi-tasking-steuerungsgerät mit geringem energieverbrauch
US5923761A (en) * 1996-05-24 1999-07-13 Lsi Logic Corporation Single chip solution for multimedia GSM mobile station systems
WO2001031474A2 (en) * 1999-10-26 2001-05-03 Siemens Energy & Automation, Inc. Micro ocontroller with re-programmable flash memory

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6029000A (en) * 1997-12-22 2000-02-22 Texas Instruments Incorporated Mobile communication system with cross compiler and cross linker

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0627100A1 (de) * 1992-12-23 1994-12-07 Centre Electronique Horloger S.A. Multi-tasking-steuerungsgerät mit geringem energieverbrauch
US5923761A (en) * 1996-05-24 1999-07-13 Lsi Logic Corporation Single chip solution for multimedia GSM mobile station systems
WO2001031474A2 (en) * 1999-10-26 2001-05-03 Siemens Energy & Automation, Inc. Micro ocontroller with re-programmable flash memory

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ORTIZ D ET AL: "A preliminary performance study of architectural support for multithreading" PROCEEDINGS OF THE HAWAII INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES, XX, XX, Bd. 1, 7. Januar 1997 (1997-01-07), Seiten 227-233, XP002109960 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106470175A (zh) * 2015-08-20 2017-03-01 深圳市中兴微电子技术有限公司 一种基带芯片及信号处理方法

Also Published As

Publication number Publication date
DE10158774A1 (de) 2003-06-18
WO2003048965A3 (de) 2004-07-22

Similar Documents

Publication Publication Date Title
EP0333123B1 (de) Modular strukturiertes ISDN-Kommunikationssystem
DE4215063C2 (de) Einrichtung und Verfahren zum Seitenwechsel bei einem nicht-flüchtigen Speicher
DE69822221T2 (de) Umleitung von interruptzielen unterstützende transaktionen sowie niveauabhängigeinterruptsemantik
EP1146432B1 (de) Umkonfigurierungs-Verfahren für programmierbare Bausteine während der Laufzeit
EP0948842B1 (de) VERFAHREN ZUM SELBSTÄNDIGEN DYNAMISCHEN UMLADEN VON DATENFLUSSPROZESSOREN (DFPs) SOWIE BAUSTEINEN MIT ZWEI- ODER MEHRDIMENSIONALEN PROGRAMMIERBAREN ZELLSTRUKTUREN (FPGAs, DPGAs, o.dgl.)
DE2756768C2 (de) Mikroprozessor
DE4410775C2 (de) Steuergerät und Arbeitsverfahren eines Betriebssystems für dieses Steuergerät
EP0011685B1 (de) Programmierbare Speicherschutzeinrichtung für Mikroprozessorsysteme und Schaltungsanordnung mit einer derartigen Einrichtung
CH620779A5 (de)
DE2801563C2 (de)
DE4438975A1 (de) Gemeinsam benutzter Mikroprozessor-Datenspeicher
DE1299145B (de) Schaltungsanordnung zum Steuern von peripheren Ein- und Ausgabegeraeten von Datenverarbeitungssystemen
EP0006164A1 (de) Multiprozessorsystem mit gemeinsam benutzbaren Speichern
DE102013113262A1 (de) Auslöser-Leitwegeinheit
EP0185260B1 (de) Schnittstelle für direkten Nachrichtenaustausch
DE4429764C2 (de) Zeitgebereinrichtung für einen Mikrocomputer
DE60104848T2 (de) Programmierbare einzelchip-vorrichtung und entsprechende entwicklungsumgebung
EP0433350A1 (de) Betriebsprogramm für eine datenverarbeitungsanlage
WO2003048965A2 (de) Basisband-chip mit integrierter echtzeit-betriebssystem-funktionalität und verfahren zum betreiben eines basisband-chips
EP1308846B1 (de) Datenübertragungseinrichtung
DE2756767C2 (de) Mikroprozessor auf einem Halbleiterchip
EP0528060B1 (de) Verfahren zur Durchführung von Ein-/Ausgabeoperationen in Datenverarbeitungssystemen
DE60307172T2 (de) Ein Verfahren und Netzwerkvorrichtung bestehend aus einem flexiblem EEPROM um Konfigurationseinstellungen einzustellen
EP0360900B1 (de) Verfahren zur Behandlung der von den einzelnen Prozessen einer Datenverarbeitungsanlage verursachten Arbeitsaufrufe an einen der Prozesse
EP0360897B1 (de) Verfahren und Anordnung zur Behandlung von Unterbrechungsanforderungen und Prozessaufrufen in einem kombinierten Unterbrechungs- und Ablaufsteuersystem für wenigstens zum Teil im Echtzeitbetrieb arbeitende Datenverarbeitungsanlagen

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): CN JP US

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): DE DK FI FR GB IT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP