EP1611528A2 - Verfahren und vorrichtung für die datenverarbeitung - Google Patents

Verfahren und vorrichtung für die datenverarbeitung

Info

Publication number
EP1611528A2
EP1611528A2 EP04725695A EP04725695A EP1611528A2 EP 1611528 A2 EP1611528 A2 EP 1611528A2 EP 04725695 A EP04725695 A EP 04725695A EP 04725695 A EP04725695 A EP 04725695A EP 1611528 A2 EP1611528 A2 EP 1611528A2
Authority
EP
European Patent Office
Prior art keywords
configuration
data
data processing
logic cell
cache
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP04725695A
Other languages
English (en)
French (fr)
Inventor
Martin Vorbach
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
PACT XPP Technologies AG
Original Assignee
PACT XPP 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 PACT XPP Technologies AG filed Critical PACT XPP Technologies AG
Publication of EP1611528A2 publication Critical patent/EP1611528A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/76Architectures of general purpose stored program computers
    • G06F15/78Architectures of general purpose stored program computers comprising a single central processing unit
    • G06F15/7867Architectures of general purpose stored program computers comprising a single central processing unit with reconfigurable architecture

Definitions

  • the present invention relates to the preamble and thus deals with improvements in the use of reconfigurable processor technologies for data processing.
  • a problem with conventional approaches to reconfigurable technologies is when data processing is primary to be made on a sequential CPU consulting a configurable data processing logic cell array or the like and / or a 'data processing is desired, sequentially permited- in the many and / or large-saving processing steps are present.
  • WO 00/49496 discloses a method for executing a computer program with a processor, which comprises a configurable functional unit which is capable of executing reconfigurable instructions, the effect of which can be redefined at runtime by loading a configuration program, the Method comprising the steps of selecting combinations of reconfigurable instructions, a respective configuration program for. every combination is generated and the computer program is executed.
  • the configuration program for all of the instructions of the combination should be loaded into the configurable functional unit.
  • the configurable functional unit serving to execute an instruction according to a configurable function.
  • the configurable functional unit has a large number of independent configurable logic blocks to perform programmable logic operations to implement the configurable function.
  • Configurable connection circuits are provided between the configurable logic blocks and both the inputs and the outputs of the configurable functional unit. This allows the distribution of logic functions to be optimized via the configurable logic blocks.
  • a problem with conventional architectures is when a connection is to be made and / or technologies such as data streaming, hyperthreading, multithreading and so on are to be used in a meaningful and performance-enhancing manner.
  • a description of an architecture can be found in "Exploiting Choice: Instruction Fetch and Issue on Implementable Simultaneous Multi-Threading Processor", Dean N. Tulson, Susan J. Eggers et al, Proceedings of the 23th annual international Symposium on Computer Architecture, Philadelphia , May 1996.
  • the conventional arrangements as known from the non-registrant's proprietary rights are used among other things for this , Functions in configurable Process data processing logic cell array, DFP, FPGA or the like, which cannot be processed efficiently on the CPU's own ALU.
  • the configurable data processing logic cell array is thus practically used to enable user-defined opcodes that enable algorithms to be processed more efficiently than would be possible on the ALU arithmetic unit of the CPU without configurable data processing logic cell array support.
  • the coupling is therefore usually word-based, but not block-based, as would be necessary for the data flow processing. It is initially desirable to enable more efficient data processing than is the case with a close coupling via registers.
  • logic cell fields consisting of coarse and / or fine-grained logic cells and logic cell elements consists in a very loose coupling of such a field to a conventional CPU and / or a CPU core in embedded systems.
  • a conventional, sequential program can run on a CPU or the like, for example a program written in C, C ++ or the like, whereby calls to a data stream processing on the fine and / or coarse-grained data processing logic cell field are instantiated.
  • the problem then is that when programming for this logic cell field, a program that is not written in C or another sequential high-level language must be provided for data stream processing.
  • partial execution is achieved within a single configuration, for example to save resources, to achieve time optimization and so on, without this already leading to a programmer automatically and easily placing a piece of high-level language code on a data processing logic cell - implement field, as is the case with conventional machine models for sequential processors.
  • the implementation of high-level language code on data processing logic cell fields according to the principles of models for sequentially operating machines remains difficult.
  • Time usage planning control means and methods are therefore known per se from the prior art which, at least with the corresponding assignment of configurations to individual tasks and / or threads to configurations and / or configuration sequences, permit multitasking and / or multithreading.
  • the use of such time-use planning control means, which were used in the prior art for configuration and / or configuration management, for purposes of scheduling tasks, threads, multithreads and hyperthreads is regarded as inventive per se.
  • the basic idea of the invention is to provide something new for commercial use.
  • a first essential aspect of the present invention is therefore to be seen in the fact that data are supplied to the data processing logic cell array in response to the execution of a load configuration by the data processing logic cell array and / or data from this data processing logic cell array are written away (STORE) by a STORE configuration is processed accordingly.
  • This La- In this case, configuration and / or storage configurations are preferably to be designed in such a way that addresses are generated directly or indirectly within the data processing logic cell field of those storage locations which are to be accessed directly and indirectly for loading and / or storage.
  • This configuration of address generators within a configuration makes it possible to load a large amount of data into the data processing logic cell field, where they can be stored in internal memories (iRAM) and / or where they can be stored in internal cells such as EALUs with registers and / or the like can be filed.
  • the loading or storage configuration thus enables a block-wise and almost data stream-like, in particular fast loading of data, in particular comparatively compared to individual access, and such a loading configuration can be carried out before one or more configuration (s) processing and / or actually processing data, with which the preloaded data are processed.
  • Data loading and / or writing can typically take place in large logic cell fields in small areas thereof, while other areas are concerned with other tasks.
  • FIG. 1 In the ping-pong-type data processing described in other published documents by the applicant, in which memory cells are provided on both sides of a data processing field, the data in a first processing step from the memory on one side through the data processing field to the memory on the flow to the other side, there the intermediate results obtained during the first field flow are stored in the second memory, the field is possibly reconfigured, the intermediate results then for for further processing, etc., a memory page can be preloaded with new data by means of a LOAD configuration in one part of the array, while data with a STORE configuration in another part of the array is written away from the opposite side of the memory. This simultaneous LOAD / STORE procedure is also possible without spatial storage area separation.
  • the internal memories can in particular be preloaded beforehand by separate charging configurations using date.nstrom-like access. This corresponds to the use as a vector register, with the result that the internal memories will always be at least partially a part of the externally visible state of the XPP and must therefore be saved or written back when the context changes.
  • the internal memories iRAMs
  • the internal memories can be loaded onto the CPU by separate “loading instructions”. This leads to reduced loading processes through configurations and can result in a broader interface to the memory hierarchy accessed.
  • the precharge can also be a burst of memory by instruction from the cache controller. Furthermore, it is possible, and this is preferred as particularly powerful in many cases, to design the cache in such a way that a specific precharge instruction specifies a specific memory area, which is defined by the start address and size or step size (s) maps internal memory (iRAM). When all internal RAMs are allocated, the next one can Configuration must be activated. Activation entails waiting until all burst-like loading processes have been completed. However, this is transparent insofar as the preload instructions are issued long enough beforehand and the cache localization is not destroyed by interrupts or task changes. In particular, a "preload cleah" instruction can then be used, which prevents data from being loaded from the memory.
  • a synchronization instruction is required to ensure that the content of a specific memory area, which is cached in the IRAM, can be written back to the memory hierarchy, which can be done globally or by specifying the memory area to be accessed; the global access corresponds to a "full write back".
  • the precharging of the IRAM it is possible to do this by simply specifying a base address, possibly one or more step sizes (when accessing multidimensional data fields) and an overall run length to specify and store them in registers or the like and then access these registers to determine how to load.
  • registers are designed as FIFOs.
  • a FIFO can then be provided for a large number of virtual processors in a multithreaded environment.
  • storage locations can be provided for use as TAG storage, as is customary with caches.
  • IRAMs are marked as "dirty" in the cache sense so that the in- can be written back to an external memory as soon as possible if it is not to be used again in the same IRAM.
  • the XPP field and the cache controller can thus be regarded as a single unit since they do not require different instruction streams. Rather, the cache controller can be seen as the implementation of the stages “configuration fetch”, “operand fetch ⁇ > (IRAM preload) and” write back ", ie CF, OF and WB, in the XPP pipeline, with the execution stage also (ex) is triggered. Because of the long latencies and the
  • Unpredictability for example due to cache misses or configurations of different lengths, it is advantageous if the stages are overlapped over several configurations, the configuration and data preloading FIFO (pipeline) being used for loose coupling.
  • the preload may be followed by FILMO, known per se.
  • the preloading can be speculative, whereby the speculation measure can be determined depending on the compiler.
  • a disadvantage due to incorrect preloading does not arise insofar as configurations that have not been carried out but only preloaded can easily be released for overwriting, as well as assigned data.
  • the preloading of the FIFO can precede several configurations and may depend on the properties of the algorithm. It is possible to use hardware for this.
  • this can by a suitable, carried the XPP associated cache controller, but where 'it is pointed out that this is typically prioritize its tasks and executes preferred precharge, on A high due to the assigned execution status Have priority.
  • precharging can also be blocked by a higher-level IRAM instance in another block or the lack of empty IRAM instances in the target IRAM block. In the latter case, the configuration can wait until a configuration and / or a write-back has ended.
  • the IRAM instance in a different block can be in use or "dirty". It can be provided that the clean IRAMs used last are discarded, that is to say are considered "empty”.
  • FIGS. 4a-c Examples of architectures in which an SMT processor is coupled to an XPP thread resource can be found, for example, in FIGS. 4a-c.
  • LRU least recently used
  • IRAMs are defined as local cache copies of the main memory and each IRAM is assigned a start address and modification status information, it is preferred that the IRAM cells are also replicated as for SMT support, so that only the start addresses of the IRAMs saved and. must be reloaded as context.
  • the start addresses for the IRAMs of a current configuration then select the IRAM instances with identical addresses for use. If no address tag of an IRAM instance corresponds to the address of the newly loaded or to be reloaded context, the corresponding memory area can be loaded into an empty IRAM instance, which is to be understood here as a free IRAM area. If one is not available, the procedures described above can be used.
  • the cache is preferably to be understood as an explicit cache and not as a transparent cache to the programmer and / or compiler as usual.
  • configuration preload instructions which precede IRAM preload instructions which are used by that configuration.
  • Such configuration precharge instructions should be provided by the scheduler as early as possible.
  • IRAM precharge instructions can also be provided, which should also be provided by the scheduler at an early stage, and configuration execution instructions can be provided, the IRAM precharge instructions for this configuration follow, and these configuration execution instructions can in particular delay estimated latencies compared to the precharge instructions.
  • a configuration wait statement is executed, followed by a statement that forces a cache write-back, both of which are output by the compiler, especially when a statement from another functional unit such as the load / Memory unit can access a memory area that is potentially “dirty” or is in use in an IRAM. This can be used to force a synchronization of the instruction streams and the cache contents while avoiding data hazards Synchronization instructions are not necessarily common.
  • the data loading and / or storage does not necessarily have to be carried out by a completely logic cell field-based procedure. Rather, it is also possible to provide, for example, one or more separate and / or dedicated DMA units, that is to say in particular DMA controllers, which, for. B. at most can also be configured or prepared for function and / or set up by specifying start address, step size, block size, destination addresses etc., in particular by the CT and / or from the logic cell field.
  • Loading can also take place in particular from and into a cache.
  • This has the advantages that the external communication with larger memory banks is handled via the cache controller, without separate switching arrangements having to be provided within the data processing logic cell field for access to the memory in a read or write manner to be typically very fast and with a low latency at most and that a CPU unit, typically there via a separate LOAD / STORE unit, is also typically connected to this cache, so that access to data and an exchange thereof between the CPU core and data processing logic cell field block by block can be carried out quickly and in such a way that a separate command, for example from the OpCode fetcher of the CPU, does not have to be fetched and processed for each transfer of data.
  • This cache coupling also proves to be considerably cheaper than coupling a data processing logic cell field to the ALU via registers if these registers only communicate with a cache via a LOAD / STORE unit, as is per se from the non-PACT-cited fonts is known.
  • a further data connection to the load / storage unit of the or a sequential CPU unit assigned to the data processing logic cell field and / or to its register can be provided. It should be mentioned that such units can be addressed via separate input / output connections (IO ports) of the data processing logic cell arrangement which can be configured in particular as a VPU or XPP and / or by means of one or more multiplexers connected downstream of an " individual port".
  • IO ports input / output connections
  • access to cache areas takes place in a writing and / or reading manner and / or the LOAD / STORE unit and / or the connection (known per se in the prior art) to the register of the sequential CPU also a connection to an external mass storage device such as a RAM, a hard disk and / or another data exchange port such as an antenna and so on can also be mentioned.
  • a separate port can be provided for this access to storage means different in cache and / or LOAD / STORE unit and / or register unit.
  • Suitable drivers, buffers, signal conditioners for level adjustment and so on can be provided here, e.g.
  • the logic cells of the field ELUs or ELUs can include and become typical of those on the input and / or output side, in particular both on the input side -
  • this is advantageous if a data stream is to get into the cell and is to be subjected to a kind of preprocessing there without blocking larger PAE units.
  • the ALU is designed as a SIMD arithmetic unit, in which case a very wide data input word of, for example, 32 bit data width is split over the upstream FPGA-like strips into several parallel data words of, for example, 4 bit width , which can then be processed in parallel in the SIMD arithmetic units, which can significantly increase the overall performance of the system if the corresponding application is required. It should be pointed out that there was talk above of FPGA-like upstream or downstream structures.
  • FPGA-like does not necessarily refer to 1-bit granular arrangements.
  • hyper-fine-granular structures instead of these hyper-fine-granular structures, it is possible to provide only finer granular structures of, for example, 4-bit width.
  • the FPGA-like input and / or output structures before and / or after an ALU unit, in particular designed as a SIMD arithmetic unit can be configured, for example, such that 4-bit wide data words are always supplied and / or processed.
  • FPGA-like stripe structures as also disclosed in connection with FIG. 3, particularly easily enable the implementation of pseudo-random noise generators, in particular with regard to arrangement in the PAE. If, in doing so, the individual received from a single FPGA cell step by step. Output bits are stored back to the FPGA cell, a pseudo-random noise can also be creatively generated sequentially with a single cell, which is considered to be inventive per se, cf. Fig. 5.
  • the coupling advantages described above for data block streams can be achieved via the cache; However, it is particularly preferred if the cache is built up in strips (slice-like) and then access to several of the slices can take place simultaneously, in particular to all slices simultaneously. This is advantageous if, as will be discussed later, a large number of threads have to be processed on the data processing logic cell array (XPP) and / or the sequential CPU and / or the sequential CPUs, be it by means of hyperthreading , multitasking and / or multithreading.
  • Cache memory means with disk access or disk access enabling control means are therefore preferably provided. It can e.g. B. each thread can be assigned its own disk. This makes it possible
  • the cache does not necessarily have to be divided into slices and that if this is the case, each slice does not necessarily have to be assigned to a separate thread. However, it should be noted that this is by far the preferred method. It should also be pointed out that there may be cases in which not all cache areas are used simultaneously or temporarily at a given time. Rather, it is to be expected that in typical data processing applications, such as will occur in hand-held mobile telephones (cell phones), laptops, cameras and so on, there will often be times when the entire cache is not required. It is therefore particularly preferred if individual cache areas can be separated from the power supply in such a way that their energy consumption drops significantly, in particular to or near zero.
  • a slice-wise configuration of the cache this can be done by slice-wise deactivation of the cache using suitable power disconnection means, cf. for example Fig. 2.
  • the separation can be done either by a down-clocking, clock separation or a power separation.
  • an access recognition can be assigned to an individual cache disk or the like, which is designed to recognize whether a respective cache area or a respective cache disk currently has a thread, hyperthread or task assigned to it, from which it uses becomes. If the access detection means then determines that this is not the case, a separation is typically clock and / or even performance.
  • the cache area can be reactivated immediately, i.e. no significant delay can be expected by switching the power supply on and off, provided that it is implemented in hardware using common suitable semiconductor technologies. This is useful in many applications regardless of the use with logic cell fields.
  • Another particular advantage that arises with the present invention is that, although there is a particularly efficient coupling with regard to the transfer of data or operands, in particular in block form, balancing is nevertheless not necessary in such a way that the exact same processing time in sequential CPU and XPP or data processing logic cell field is required. Rather, the processing takes place in a practically often independent manner, in particular in such a way that the sequential CPU and the data processing logic cell array arrangement can be considered as separate resources for a scheduler or the like.
  • This allows an immediate implementation of known data processing program splitting technologies such as multitasking, multithreading and hyperthreading.
  • path balancing is not required, i.e. balancing between sequential parts (e.g.
  • the advantage of the present invention is that by configuring a loading configuration or a storage configuration into the XPP or other data processing logic cells, the data can be loaded into the field at a speed or can be written out of it, which is no longer determined by the CPU clock speed, the speed at which the OpCode fetcher works, or the like. In other words, the sequence control of the sequential CPU is no longer a bottleneck-like limitation for the data throughput of the data cell logic field without there being only a loose coupling.
  • CT or CM; configuration manager or configuration table
  • CM configuration manager or configuration table
  • the sequential CPU and / or another XPP can instantiate a call which leads to data processing on the XPP.
  • the XPP is then z. B. via the cache coupling described and / or by means of LOAD and / or STORE configurations, the address generators for loading provide for and / or write away data in the XPP or data processing logic cell field, kept in data exchange.
  • a coprocessor-like and / or thread resource-like coupling of a data processing logic cell field is possible, while at the same time a data stream-like data loading takes place by means of cache and / or I / O port coupling.
  • the coprocessor coupling i. H. the coupling of the data processing logic cell field will typically lead to the fact that the scheduling for this logic cell field will also take place on the sequential CPU or on a higher-level scheduler unit or a corresponding scheduler means. In such a case, the threading control and management practically takes place on the scheduler or the sequential CPU. Although this is possible per se, at least with the simplest implementation of the invention, this will not necessarily be the case. Rather, the data processing logic cell array can be used by calling in the conventional manner as with a standard coprocessor, for example with 8086/8087 combinations.
  • a particularly preferred variant consists, at least for certain data processing results and / or intermediate results, as storage or vector register means, in which or which the data obtained are to be stored to use an internal memory in which data about a STORE configuration in the cache or another area, which the sequential CPU or another data processing unit can access, are to be written away, but instead the results are to be written directly into corresponding ones, in particular Access-reserved cache areas, which can be organized like slices.
  • This may have the disadvantage of greater latency, especially if the paths between the XPP or data processing logic cell array unit and the cache are so long that the signal propagation times are significant, but may result in no further STORE configuration being required.
  • the cache controller of a conventional server quenziell CPU addresses a memory area as a cache, which, without serving the data exchange with the data processing logic cell field, is physically located on and / or with it.
  • This has the advantage that if applications are running on the data processing logic cell field which have a small local memory requirement at most and / or if only a few further configurations are required in relation to the available memory quantities, these are used as one or more sequential CPUs Cache can be available.
  • the cache controller can and will be designed for the management of a cache area with a dynamic scope, ie with a varying size.
  • Dynamic cache size management or cache size management means for dynamic cache management will typically take into account the workload and / or the input / output load on the sequential CPU and / or the data processing logic cell field. In other words, it can be analyzed, for example, how many NOPs there are data accesses on the sequential CPU in a given time unit and / or how many configurations are to be stored in the XPP field in the memory areas provided for this purpose, in order to enable quick reconfiguration, be it in the To enable ways of a wave reconfiguration or in another way.
  • the dynamic cache size disclosed hereby is particularly preferably runtime dynamic, i. H . the cache controller manages a current cache size, which can change from cycle to cycle or cycle group.
  • a task or thread and / or hyperthread change using the known CT technology cf. PACT10 (DE 198 07 872.2, WO 99/44147, WO 99/44120) and PACT17 (DE 100 28 397.7, WO 02/13000) can be done in such a way and preferably will also be done that a software-implemented operating system Schedulers or the like are assigned by the CT performance slices and / or time slices, during which it is determined, by which tasks or threads subsequently which parts per se, assuming that resources are free to be processed.
  • An example is given as follows: First, an address sequence is to be generated for a first task, according to which, during the execution of a LOAD configuration, data from a memory and / or cache memory to which a data processing logic cell array is coupled in the manner described, should be loaded. As soon as this data is available, processing of a second, the actual data processing configuration, can begin. This can also be preloaded, since it is certain that this configuration must be carried out unless interrupts or the like force a complete task change. In conventional processors that is now Known problem of the so-called cache miss, in which the data is requested but is not available in the cache for load access.
  • PACT19 (DE 102 02 044.2, WO 2003/060747) and PACT11 (DE 101 39 170.6, WO 03/017095)
  • another configuration as predetermined by the corresponding scheduler, in particular the scheduler close to the operating system, is partially defined, processed and / or the configuration for which the associated LOAD configuration was previously carried out.
  • testing can be carried out in particular, e.g. B. by querying the status of the LOAD configuration or the data loading DMA controller, whether the corresponding data has now flowed into the array, that is, the latency, as it typically occurs, has passed and / or the data is actually available.
  • latencies are when they occur because e.g. B. Configurations have not yet been configured, data has not yet been loaded and / or data has not yet been written off, bridged and / or hidden by
  • Threads, hyperthreads and / or tasks are carried out which are already preconfigured and which work with data which are already available or which can be written off to resources which are already available for the write-off. In this way, latency times are largely covered and, assuming a sufficient number of threads, hyperthreads and / or tasks to be executed per se, a practically 100% utilization of the data processing logic cell field is achieved.
  • real-time-capable systems can in particular be readily implemented realize.
  • incoming data or interrupts which signal the arrival of data in particular, can be responded to within a maximum time that can never be exceeded. This can be done, for example, by a task change in response to an interrupt and / or, for example in the case of prioritized interrupts, by stipulating that a given interrupt should be ignored at the moment, this also having to be determined within a certain time.
  • a task change in such real-time capable systems will typically be possible in three ways, namely either when a task has run for a certain time (timer principle), when a resource is not available, • be it due to its blocking by other access or due to latencies when accessing them, in particular in a writing and / or reading manner, that is to say in the event of latencies in data access and / or when interrupts occur. It is also pointed out that, in particular, a runtime-limited configuration on a resource to be released or changed for interrupt processing can retrigger a watchdog or tracking counter.
  • a first variant consists of a switch to the processing of an interrupt, for example, within a resource that can be addressed by the scheduler or the CT. If the response times to interrupts or other requirements are so long that a configuration can still be processed without interruption during this time, this is not critical, especially during the processing of the currently running configuration on the resource that has to be changed to process the interrupt , a configuration for interrupt processing can be preloaded.
  • the selection of the interrupt-processing configuration to be preloaded ration is z. B. by CT. It is possible to limit the runtime of the configuration to the resource to be released or changed for interrupt processing. Please refer to PACT29 / PCT (PCT / DE03 / 000942).
  • a single resource for example a separate XPP unit and / or parts of an XPP field, for such processing. If an interrupt to be processed quickly occurs, either a configuration that has already been preloaded for particularly critical interrupts can be processed or the loading of an interrupt handling configuration into the reserved resource is started immediately. A selection of the configuration required for the corresponding interrupt is possible by means of appropriate triggering, wave processing, etc.
  • a further, particularly preferred variant of the response to interrupts if at least one of the accessible resources is a sequential CPU, consists in executing an interrupt routine on it, in which code for the data processing logic cell field is again prohibited.
  • a time-critical interrupt routine is only processed on a sequential CPU without XPP data processing steps being called. This guarantees that the processing operation on the data processing logic cell field cannot be interrupted and further processing can then take place on this data processing logic cell field after a task switch.
  • the actual interrupt routine does not have an XPP code, it can nevertheless be ensured that an interrupt at a later, no longer real-time point in time with the XPP leads to a state detected by an interrupt and / or a real-time request and / or Data can be responded using the data processing logic cell array.

Abstract

Die Erfindung betrifft eine Datenverarbeitungsvorrichtung mit einem Datenverarbeitungslogikzellenfeld und zumindest einer Sequenziell-CPU. Hierbei ist vorgesehen, dass eine Ankopplung der Sequenzielll-CPU und des Datenverarbeitungslogikzellenfeldes zum Datenaustausch in insbesondere blockweiser Form durch zu einem Cache-Speicher führende Leitungen möglich ist.

Description

Titel: Verfahren und Vorrichtung für die Datenverarbeitung
Beschreibung
Die vorliegende Erfindung betrifft das oberbegrifflich Beanspruchte und befasst sich somit mit Verbesserungen bei der Verwendung von rekonfigurierbaren Prozessortechnologien für die Datenverarbeitung.
Verwiesen wird bezüglich des bevorzugten Aufbaus von Logikzellenfeldern auf die XPP-Architektur und vorveröffentlichte sowie jüngere Schutzrechtsanmeldungen des vorliegenden Anmelders, die zu Offenbarungszwecken vollumfänglich eingegliedert sind. Erwähnt seien somit insbesondere. die DE 44 16 881 AI, DE 197 81 412 AI, DE 197 81 483 AI, DE 196 54 846 AI, DE 196 54 593 AI, DE 197 04 044.6 AI, DE 198 80 129 AI, DE 198 61 088 AI, DE 199 80 312 AI, PCT/DE 00/01869, DE 100 36 627 AI, DE 100 28 397 AI, DE 101 10 530 AI, DE 101 11 014 AI, PCT/EP 00/10516, EP 01 102 674 AI, DE 198 80 128 AI, DE 101 39 170 AI,. DE 198 09 640 AI, DE 199 26 538.0 AI, DE 100 50 442 AI, sowie die PCT/EP 02/02398, DE.102 40 000, 'DE 102 02 044, DE 102 02 175, DE 101 29 237, DE 101 42 904, DE 101 35 210,
EP 01 129 923, PCT/EP 02/10084, DE 102 12 622, DE 102 36 271, DE 102 12 621, EP 02 009 868, DE 102 36 272, DE 102 41 812, DE 102 36 269, DE 102 43 322, EP 02 022 692, ebenso wie die EP 02 001 331 und die EP 02 027 277.
Ein Problem bei herkömmlichen Ansätzen zu rekonfigurierbaren Technologien besteht dann, wenn die Datenverarbeitung primär auf einer sequenziellen CPU unter Hinzuziehung eines konfigurierbaren Datenverarbeitungslogikzellenfeldes oder dergleichen erfolgen soll und/oder eine' Datenverarbeitung gewünscht ist, in der viele und/oder umfangreiche sequenziell auszufüh- rende Verarbeitungsschritte vorliegen.
Es sind Ansätze bekannt, die sich damit befassen, wie eine Datenverarbeitung sowohl auf einem konfigurierbaren Datenver- arbeitungslogikzellenfeld als auch auf einer CPU erfolgen kann.
So ist aus der WO 00/49496 ein Verfahren zum Ausführen eines Computerprogrammes mit einem Prozessor bekannt, der eine konfigurierbare funktionelle Einheit umfasst, die in der Lage ist, rekonfigurierbare Anweisungen auszuführen, deren Effekt zur Laufzeit durch Laden eines Konfigurationsprogrammes redefiniert werden kann, wobei das Verfahren die Schritte umfasst, daß Kombinationen rekonfigurierbarer Anweisungen ausgewählt, ein respektives Konfigurationsprogramm für. jede Kom- bination erzeugt und das Computerprogramm ausgeführt wird.
Dabei soll jedes Mal, wenn eine Anweisung aus einer der Kombinationen während der Ausführung gebraucht wird und die konfigurierbare funktioneile Einheit nicht mit dem Konfigurationsprogramm für diese Kombination konfiguriert ist, das Kon- figurationsprogramm für alle der Anweisungen der Kombination in die konfigurierbare funktioneile Einheit geladen werden. Weiter ist aus der WO 02/50665 AI eine Datenverarbeitungsvorrichtung mit einer konfigurierbaren funktioneilen Einheit bekannt, wobei die konfigurierbare funktionelle Einheit dazu dient, eine Anweisung gemäß einer konfigurierbaren Funktion auszuführen. Die konfigurierbare funktionelle Einheit weist eine Vielzahl von unabhängigen konfigurierbaren Logikblöcken zum Ausführen programmierbarer Logikoperationen auf, um die konfigurierbare Funktion zu implementieren. Konfigurierbare Verbindungsschaltkreise sind zwischen den konfigurierbaren Logikblöcken und sowohl den Eingängen als auch den Ausgängen der konfigurierbaren funktioneilen Einheit vorgesehen. Dies erlaubt eine Optimalisierung der Verteilung von Logikfunktionen über die konfigurierbaren Logikblöcke.
Ein Problem bei herkömmlichen Architekturen besteht dann, wenn eine Ankopplung erfolgen soll und/oder Technologien wie Datastreaming, Hyperthreading, Multithreading und so weiter, in sinnvoller und Performance steigernder Weise ausgenützt werden sollen. Eine Beschreibung einer Architektur findet sich in „Exploiting Choice: Instruction Fetch and Issue on Implementable Simultaneous Multi-Threading Pröcessor", Dean N. Tulson, Susan J. Eggers et al, Proceedings of the 23th an- nual international Symposium on Computer Architecture, Philadelphia, May 1996.
Die -Hyperthreading- und Mültithreading-Technologien sind im Hinblick darauf entwickelt worden, dass moderne Mikroprozessoren ihre Leistungsfähigkeit aus vielen -spezialisierten und tiefpipelineartig angesteuerten funktioneilen Einheiten und hohen Speicherhierarchien gewinnen, was hohe Frequenzen in den Funktionskernen erlaubt. Durch die streng hierarchischen Speicheranordnungen gibt es jedoch bei Fehlzugriffen auf Caches auf Grund des Unterschieds- zwischen Kern- und Speicherfrequenzen größere Nachteile, da viele Kerntaktzyklen vergehen, bis Daten aus dem Speicher ausgelesen sind. Zudem treten Probleme auf bei Verzweigungen und insbesondere falsch vorhergesagten Verzweigungen. Es ist daher vorgeschlagen worden, al-s sogenanntes SMT, simultaneous multi-threading- Verfahren zwischen verschiedenen Tasks immer dann zu wechseln, wenn eine Anweisung nicht ausgeführt werden kann oder nicht alle funktionellen Einheiten verwendet.
Die beispielhaft erwähnte Technologie der vorzitierten NichtAnmelder-Dokumente zeigt" etwa eine Anordnung, bei der zwar Konfigurationen in ein konfigurierbares Datenverarbeitungslo- gikzellenfeld geladen werden können, bei welchen allerdings der Datenaustausch zwischen der ALU der CPU und dem konfigu- rierbaren Datenverarbeitungslogikzellenfeld, sei es ein FPGA, DSP oder dergleichen, über die Register erfolgt. Mit anderen Worten müssen Daten aus einem Datenstrom zunächst sequenziell in Register geschrieben werden und. dann sequenziell wieder in diesen abgelegt werden. Auch ist ein Problem dann gegeben, wenn ein Zugriff auf Daten von extern erfolgen soll, da selbst dann noch Probleme beim zeitlichen Ablauf der Datenverarbeitung im Vergleich zur ALU und bei der Zuweisung von Konfigurationen und so weiter bestehen. Die herkömmlichen Anordnungen, wie sie aus den Nicht-Änmelder-eigenen Schutzrech- ten bekannt sind, werden unter anderem dazu verwendet, Funktionen im konfigurierbaren Datenverarbeitungslogikzellenfeld, DFP, FPGA oder dergleichen abzuarbeiten, die nicht effizient auf der CPU-eigenen ALU abzuarbeiten sind. Damit wird das konfigurierbare Datenverarbeitungslogikzellenfeld praktisch verwendet, um benutzerdefinierte Opcodes zu ermöglichen, die eine effizientere Abarbeitung von Algorithmen ermöglichen, als dies auf dem ALU-Rechenwerk der CPU ohne konfigurierbare Datenverarbeitungslogikzellenfeldunterstützung möglich wäre.
Im Stand der Technik ist, wie erkannt wurde, die Ankopplung demnach im Regelfall wortbasiert, nicht jedoch blockbasiert, wie es zur datenströmenden Verarbeitung erforderlich wäre. Es ist zunächst wünschenswert, eine effizientere Datenverarbeitung zu ermöglichen, als dies mit einer engen Ankopplung über Register der Fall ist.
Eine weitere Möglichkeit zur Verwendung von Logikzellenfeldern aus grob- und/oder feingranular gebauten Logikzellen und Logikzellenelementen besteht in einer sehr losen Ankopplung eines solchen Feldes an eine herkömmliche CPU und/oder einen CPU-Kern bei eingebetteten Systemen. Hierbei kann ein her- kömmliches, sequenzielles Programm auf einer CPU oder dergleichen laufen, beispielsweise ein in C, C++ oder dergleichen geschriebenes Programm, wobei von diesem Aufrufe einer Datenstromverarbeitung auf dem fein- und/oder grobgranularen Datenverarbeitungslogikzellenfeld instantiiert werden. Pro- blematisch ist dann, dass beim Programmieren für dieses Logikzellenfeld ein nicht in C oder einer anderen sequenziellen Hochsprache geschriebenes Programm für die Datenstromabarbei- tung vorgesehen werden muss. Erwünscht wäre hier, dass sowohl auf der herkömmlichen CPU-Architektur als auch auf einem mit diesen gemeinsam betriebenen Datenverarbeitungslogikzellen- feld C-Programme oder dergleichen abzuarbeiten sind, das heißt, dass insbesondere mit dem Datenverarbeitungslogikzel- lenfeld in quasi sequenzieller Programmabarbeitung dennoch eine Datenstromfähigkeit erhalten, bleibt, während es simultan insbesondere auch möglich bleibt, dass ein CPU-Betrieb in nicht zu loser Ankopplung möglich ist. Es ist auch' bereits bekannt, innerhalb einer Datenverarbeitungslogikzellenfeldan- ordnung, wie sie insbesondere aus PACT02. (DE- 196 51 075.9-53, WO 98/26356), PACT04 (DE 196 54 846.2-5.3, WO 98/29952), PACT08, (DE 197 04 728.9, WO 98/35299) PACT13 (DE 199 26 538.0, WO 00/77652) PACT31 (DE 102 12 621.6-53, PCT/EP 02/10572) wobei bekannt ist, auch eine sequenzielle Datenver- arbeitung innerhalb des Datenverarbeitungslogikzellenfeldes vorzusehen. Hierbei wird dann allerdings innerhalb einer einzelnen Konfiguration, beispielsweise um Ressourcen zu sparen, eine Zeitoptimierung zu erzielen und so weiter, eine partiel- le Abarbeitung erzielt, ohne dass diese bereits dazu führt, dass ein Programmierer ein Stück Hochsprachencode automatisch leicht ohne weiteres auf ein Datenverarbeitungslogikzellen- feld umsetzen kann, wie dies bei herkömmlichen Maschinenmodellen für sequenzielle Prozessoren der Fall ist. Die Umset- zung von Hochsprachencode auf Datenverarbeitungslogikzellen- felder nach Prinzipien der Modelle für sequenziell arbeitende Maschinen ist weiterhin schwierig.
Aus dem Stand der Technik ist weiter bekannt, dass mehrere Konfigurationen, die eine jeweils unterschiedliche Funktionsweise von Arrayteilen bewirken, simultan auf dem Prozessorfeld (PA) abgearbeitet werden können und dass ein Wechsel von einer oder einigen der Konfiguration (en) ohne Störung anderer zur Laufzeit erfolgen kann.. Es sind Verfahren und in Hardware implementierte Mittel zu deren Umsetzung bekannt, wie sicher-' gestellt werden kann, dass dabei ein Abarbeiten von auf das Feld zu ladenden Teilkonfigurationen ohne Deadlock erfolgen kann. Verwiesen wird hierzu insbesondere auf die die Filmo- Technik betreffenden Anmeldungen PACT05 (DE 196 54 593.5-53, WO 98/31102) PACT10 (DE 198 07 872.2, WO 99/44147,
WO 99/44120) PACT13 (DE 199 26 538.0, WO 00/77652), PACT17 (DE 100 28 397.7, WO 02/13000); PACT31 (DE 102 12 621.6, WO 03/036507 ) . Diese Technologie ermöglicht in gewisser Weise bereits eine Parallelisierung und, bei entsprechender Ge- staltung und Zuordnung der Konfigurationen, ' auch eine Art Multitasking/Multithreading und zwar dergestalt, dass eine Planung, das heißt ein Scheduling und/oder eine Zeitnutzungs- planungssteuerung vorgesehen ist. Es sind also aus dem Stand der Technik schon Zeitnutzungsplanungssteuerungsmittel und - verfahren per se bekannt, die, zumindest unter entsprechender Zuordnung von Konfigurationen zu einzelnen Aufgaben und/oder Fäden zu Konfigurationen und/oder Konfigurationsfolgen, ein Multitasking und/oder Multithreading erlauben. Die Verwendung solcher Zeitnutzungsplanungssteuermittel, die im Stand der Technik zur Konfigurierung und/oder Konfigurationsverwaltung verwendet wurden, zu Zwecken des Scheduling von Tasks, Threads, Multi- und Hyperthreads wird per se als erfinderisch angesehen.
Wünschenswert ist auch zumindest gemäß einem Teilaspekt in bevorzugten Varianten, moderne Technologien der Datenverar- beitung und Programmabarbeitung wie Multitasking, Multithreading, Hyperthreading unterstützen zu können, zumindest in bevorzugten Varianten einer Halbleiterarchitektur.
Der Grundgedanke der Erfindung besteht darin, Neues für die gewerbliche Anwendung bereitzustellen.
Die Lösung dieser Aufgabe wird in unabhängiger Form beansprucht. Bevorzugte Ausführungsformen finden sich in den Unteransprüchen.
Ein erster wesentlicher Aspekt der vorliegenden Erfindung ist somit darin zu sehen, dass dem Datenverarbeitungslogikzellen- feld Daten im Ansprechen auf die Ausführung einer Ladekonfiguration durch das Datenverarbeitungslogikzellenfeld zuge- führt werden und/oder Daten aus diesem Datenverarbeitungslo- gikzellenfeld weggeschrieben (STORE) werden, indem eine STORE-Konfiguration entsprechend abgearbeitet wird. Diese La- de- und oder Speicherkonfigurationen sind dabei bevorzugt derart auszugestalten, dass innerhalb des Datenverarbeitungs- logikzellenfeldes direkt oder indirekt Adressen jener Speicherstellen generiert werden, auf welche ladend und/oder speichernd direkt oder indirekt zugegriffen werden soll. Es ist durch diese Einkonfiguration von Adressgeneratoren innerhalb einer Konfiguration möglich, eine Vielzahl von Daten in das Datenverarbeitungslogikzellenfeld einzuladen, wo sie gegebenenfalls in internen Speichern (iRAM) ablegbar sind und/oder wo sie in internen Zellen wie EALUs mit Registern und/oder dergleichen eigenen Speichermitteln abgelegt werden können. Die Lade- beziehungsweise Speicherkonfiguration ermöglicht somit ein blockweises und nahezu datenstromartiges, insbesondere gegenüber Einzelzugriff vergleichsweises schnel- les Laden von Daten und es kann eine solche Lade-Konfiguration ausgeführt werden vor einer oder mehreren tatsächlich Daten auswertend und/oder verändernd abarbeitenden Konfiguration (en), mit welcher/n die vorab geladenen Daten verarbeitet werden. Das .Datenladen und/oder -schreiben kann dabei typisch bei großen Logikzellenfeldern in kleinen Teilbereichen derselben geschehen, während andere Teilbereiche mit anderen Aufgaben befaßt sind. Bezüglich dieser und anderer Besonderheiten der Erfindung wird auf Fig. 1 verwiesen. Bei der in anderen veröffentlichten Dokumenten des Anmelders beschriebe- nen Ping-Pong-artigen Datenverarbeitung, bei der auf beiden Seiten eines Datenverarbeitungsfeldes Speicherzellen vorgesehen sind, wobei die Daten in einem ersten Verarbeitungsschritt von dem Speicher auf der einen Seite durch das Datenverarbeitungsfeld zum Speicher auf der anderen Seite strömen, dort die beim ersten Felddürchströmen erhaltenen Zwischenergebnisse im zweiten Speicher abgelegt werden, gegebenenfalls das Feld umkonfiguriert wird, die Zwischenergebnisse dann für die Weiterverarbeitung zurückströmen usw., kann etwa eine Speicherseite durch eine LOAD-Konfiguration in einem Array- Teil mit neuen Daten vorgeladen werden, während aus der gegenüberliegenden Speicherseite Daten mit einer STORE- Konfiguration in einem anderen Array-Teil weggeschrieben werden. Dieses simultane LOAD/STORE-Vorgehen ist im übrigen auch ohne räumliche Speicherbereichstrennung möglich.
Es sei noch einmal erwähnt, dass es verschiedene Möglichkei- ten gibt, interne Speicher mit Daten zu füllen. Die internen Speicher können insbesondere vorher durch separate Ladekonfigurationen unter Verwendung von date.nstromartigem Zugreifen vorgeladen werden. Dies entsprichte dem Gebrauch als Vektorregister, wobei es zu Folge hat, dass die internen Speicher immer zumindest partiell ein Teil des nach außen sichtbaren Zustandes der XPP sein werden und daher bei Kontextwechseln gespeichert bzw. zurückgeschrieben werden müssen. Alternativ und/oder zusätzlich können die internen Speicher (iRAMs) durch separate „Lade-Instruktionen" auf die CPU geladen wer- den. Dies führt zu verringerten Ladevorgängen durch Konfigurationen und . kann eine breitere Schnittstelle zur Speicherhierarchie bewirken. Wiederum wird wie' auf Vektorregister zugegriffen.
Das Vorladen kann auch als Burst aus dem Speicher durch eine Anweisung des Cache-Kontrollers bestehen. Überdies ist es möglich, und dies ist als besonders leistungsfähig in vielen Fällen bevorzugt, den Cache dahingehend so auszubilden, dass eine bestimmte Vorladeanweisung eine bestimmte Speicherflä- ehe, die durch die Startadresse und -große bzw. Schrittweite (n) definiert ist, auf den internen Speicher (iRAM) abbildet. Wenn alle internen RAMs zugeordnet sind, kann die nächste Konfiguration aktiviert werden. Die Aktivierung bringt ein Abwarten mit sich, bis alle burst-artigen Ladevorgänge abgeschlossen sind. Dies ist jedoch insoweit transparent, -wenn die Vorladeanweisungen lange genug vorher ausgegeben werden und die Cache-Lokalisierung nicht durch Interrupts oder Taskwechsel zerstört wird. Es kann dann insbesondere eine „Preload cleah" -Anweisung verwendet werden, mit der vermieden wird, dass Daten aus dem Speicher geladen werden.
Eine Synchronisierungsanweisung wird benötigt, um sicherzustellen, dass der Inhalt eines spezifischen Speicherbereiches, der cacheartig im IRAM abgelegt ist, an die Speicherhierarchie zurückgeschrieben werden kann, was global oder durch Spezifizierung des Speicherbereiches, auf welchen zuge- griffen wird, erfolgen kann; der globale Zugriff entspricht einem „f ll write back" . Um das Vorladen des IRAMs zu vereinfachen, ist es möglich, dies durch einfache Angabe einer Basisadresse, ggf. einer bzw. mehrerer Schrittweiten (beim Zugriff auf multidimensionale Datenfelder) sowie einer Gesamt- lauflänge zu spezifizieren und diese in Registern oder dergleichen abzulegen und dann, zur Bestimmung, wie geladen werden soll, auf diese Register zuzugreifen.
Besonders bevorzugt ist es, wenn die Register als FIFOs aus- gebildet werden. Es kann dann für eine Vielzahl auch virtueller Prozessoren in einer Multithreadumgebung jeweils ein FIFO vorgesehen werden. Überdies können Speicher.stellen zum Gebrauch als TAG-Speicher wie bei Caches üblich vorgesehen werden.
Es sei auch erwähnt, dass die Markierung des Inhaltes von IRAMs als im Cache-Sinne „dirty" hilfreich ist, damit der In- halt so schnell wie möglich an einen externen Speicher zurückgeschrieben werden kann, wenn er nicht im gleichen IRAM wieder verwendet werden soll. Damit können das XPP-Feld und der Cache-Controller als eine einzige Einheit betrachtet wer- den, da sie keine unterschiedlichen Anweisungsströme benötigen. Vielmehr kann der Cache-Controller als die Implementierung der Stufen „configuration fetch" , „Operand fetchΛ> (IRAM preload) und „write back", also CF, OF und WB, in der XPP- Pipeline angesehen werden, wobei auch die Ausführungsstufe (ex) ausgelöst wird. Auf Grund der langen Latenzen und der
Nichtvorhersehbarkeit etwa durch Cache-Fehlzugriffe oder Konfigurationen mit unterschiedlicher Länge ist es vorteilhaft, wenn die Stufen mehrere Konfigurationen breit überlappt werden, wobei zwecks loser Ankopplung das Konfigurations- und Datenvorlade-FIFO (Pipeline) verwendet wird. Es sei erwähnt, dass dem Preload der per se bekannte FILMO nachgeordnet sein kann. Es sei auch erwähnt, dass das Vorladen spekulativ sein kann, wobei das Spekulationsmaß compilerabhängig bestimmt werden kann. Ein Nachteil durch falsches Vorladen entsteht aber insofern nicht, als nicht ausgeführte, sondern nur vorgeladene Konfigurationen ohne weiteres für ein Überschreiben freigebbar sind, genauso wie zugeordnete Daten. Die Vorladung des FIFOs kann mehrere Konfigurationen weit vorausgehen und etwa abhängig von Eigenschaften des Algorithmus sein. Es ist möglich, eine Hardware hierfür zu verwenden.
Was das Zurückschreiben von verwendeten Daten aus dem IRAM in externe Speicher angeht, so kann dies durch einen geeigneten, der XPP zugeordneten Cache-Controller erfolgen, wobei aber darauf hingewiesen' wird, dass dieser typisch seine Aufgaben priorisieren wird und bevorzugt Vorladeoperationen ausführt, die auf Grund des zugeordneten Ausführungsstatusses eine hohe Priorität besitzen. Andererseits kann auch ein Vorladen durch eine überlagerte IRAM-Instanz in einem anderen Block oder den Mangel an leeren IRAM-Instanzen im Ziel-IRAM-Block blockiert werden. In letzerem Fall kann die Konfiguration warten, bis eine Konfiguration und/oder ein Zurückschreiben beendet ist. Die IRAM-Instanz in einem unterschiedlichen Block kann dabei im Gebrauch befindlich oder „dirty" sein. Es kann vorgesehen werden, dass die zuletzt verwendeten sauberen IRAMs verworfen werden, also als „leer" betrachtet werden. Wenn weder leere noch saubere IRAM-Instanzen vorliegen, muss ein „dirty"--IRÄM- Teil bzw. ein nichtleerer an die Speicherhierarchie zurückgeschrieben werden. Da sich immer nur .eine Instanz im Gebrauch befinden kann, und es mehr als eine Instanz in einem IRAM- Block geben soll, damit ein Cache-Effekt erreicht wird, kann es nicht passieren, dass weder leere noch saubere noch „dirty" -IRAM-Instanzen existieren.
Beispiele von Architekturen, bei denen ein SMT-Prozessor mit einer XPP-Thread-Resource gekoppelt ist, finden sich bei- spielhaft in Fig. 4a - c.
Auch bei der hier vorgestellten und bevorzugten Variante ist es erforderlich, ggf. den Speicherverkehr zu, beschränken, was während Kontextwechseln auf verschiedene Weisen möglich ist. So brauchen reine Lesedaten nicht gespeichert werden, wie dies etwa bei Konfigurationen der Fall ist. Bei nicht unterbrechbaren (nicht präemptiven) Konfigurationen brauchen die lokalen Zustände von Bussen und PAE's nicht gespeichert werden.
Es kann vorgesehen werden, dass nur modifizierte Daten gespeichert werden und es können Cache-Strategien verwendet werden, um den Speicherverkehr zu verringern. Hierzu kann insbesondere bei häufigen Kontextwechseln eine LRU-Strategie (LRU = least recently used) insbesondere zusätzlich zu einem Vorlademechanismus implementiert werden.
Wenn IRAMs als lokale Cache-Kopien des Hauptspeichers definiert werden und jedem IRAM eine Startadresse und Modifizie- rungszustandsinformation zugeordnet ist, ist es bevorzugt, dass die IRAM-Zellen auch wie für die SMT-Unterstützung re- pliziert sind, so dass nur die Startadressen der IRAMs gespeichert und. als Kontext wieder geladen werden müssen. Die Startadressen für die IRAMs einer augenblicklichen Konfiguration wählen dann die IRAM-Instanzen mit identischen Adressen zum Gebrauch aus. Wenn kein Adress-TAG einer IRAM-Instanz der Adresse des neu geladenen bzw. neu zu ladenden Kontexts entspricht, kann der entsprechende Speicherbereich in eine leere IRAM-Instanz geladen werden, wobei dies hier zu verstehen ist als freier IRAM-Bereich. Wenn ein solcher nicht verfügbar ist, kann auf die vorbeschriebenen Verfahren zurückgegriffen werden.
Es sei im übrigen darauf hingewiesen, dass durch Rückschreiben bedingte Verzögerungen unter Verwendung' einer insbesondere separaten Statemachine (Cache-Controller) vermieden werden können, mit welcher versucht wird, momentan inaktive IRAM- Instanzen während nicht benötigter Speicherzyklen zurückzuschreiben.
Es sei darauf hingewiesen, dass, wie aus dem oben Stehenden ersichtlich ist, bevorzugt der Cache als expliziter Cache und nicht als wie gewöhnlich dem Programmierer und/oder Compiler transparenter Cache aufzufassen ist. Um hier die entsprechen- de Ansteuerung vorzusehen, können, etwa durch den Compiler, folgende Anweisungen ausgegeben werden: Konfigurationsvorla- deanweisungen, die IRAM-Vorladeanweisungen vorausgehen, welche von jener Konfiguration verwendet werden. Derartige Kon- figurationsvorladeinstruktionen sollten so früh wie möglich vom Scheduler vorgesehen" werden. Weiter, das heißt alternativ und/oder zusätzlich, können IRAM-Vorladeinstruktionen vorgesehen werden, die gleichfalls frühzeitig vom Scheduler vorgesehen werden sollten, und es können Konfigurationsausfüh- rungsanweisungen vorgesehen werden, die IRAM- Vorladeanweisungen für diese Konfiguration folgen, wobei diese Konfigurationsausführungsanweisungen insbesondere um abgeschätzte Latenzzeiten gegenüber den Vorladeanweisungen verzögern können.
Es kann auch vorgesehen werden, dass eine Konfigurationswarteanweisung ausgeführt wird, gefolgt von einer Anweisung, die ein Cache-Zurückschreiben erzwingt, wobei beides vom Compiler ausgegeben wird, und zwar insbesondere dann, wenn eine Anwei- sung einer anderen funktioneilen Einheit wie der Lade-/Spei- chereinheit auf einen Speicherbereich zugreifen kann, der potenziell „dirty" oder in einem IRAM in Gebrauch befindlich ist. Damit kann eine Synchronisierung der Anweisungsströme und der Cache-Inhalte unter Vermeidung von Daten-Hazards er- zwungen werden. Durch entsprechende Handhabung sind derartige Synchronisationsanweisungen nicht notwendigerweise häufig.
Es sei erwähnt, dass das Datenladen und/oder -ablegen nicht zwingend durch vollständig logikzellenfeldbasiertes Vorgehen erfolgen muss. Vielmehr ist es auch möglich, etwa eine oder mehrere separate und/oder dedizierte DMA-Einheiten, das heißt insbesondere DMA-Controller vorzusehen, die z. B. allenfalls noch durch Vorgaben bezüglich Startadresse, Schrittweite, Blockgröße, Zieladressen etc. insbesondere von der CT und/ oder aus dem Logikzellenfeld konfiguriert bzw. funktionsvor- bereitet und/oder eingerichtet werden.
Das Laden auch kann insbesondere aus einem Cache und in diesen hinein erfolgen. Dies hat die Vorteile, dass die externe Kommunikation mit größeren Speicherbänken über den Cachecontroller gehandhabt wird, ohne dass innerhalb des Datenverar- beitungslogikzellenfeldes separate Schaltanordnungen dafür vorgesehen sein müssen, dass der Zugriff in lesender oder schreibender Weise bei Cache-Speiche.rmitteln typisch sehr schnell und mit allenfalls geringer Latenzzeit erfolgen wird und dass auch typisch eine CPU-Einheit, dort typisch über ei- ne separate LOAD/STORE-Einheit, an diesen Cache angebunden ist, sodass ein Zugriff auf Daten und ein Austausch derselben zwischen CPU-Kern und Datenverarbeitungslogikzellenfeld blockweise schnell und derart erfolgen kann, dass nicht für jedes Übergeben von Daten ein separater Befehl etwa aus dem OpCode-Fetcher der CPU abgeholt und verarbeitet werden muss.
Es erweist sich diese Cacheankoppelung auch als wesentlich günstiger als eine Ankopplung eines Datenverarbeitungslogikzellenfeldes an die ALU über , Register, wenn diese Register nur über eine LOAD/STORE-Einheit mit einem Cache kommunizieren, wie dies aus den Nicht-PACT-eigenen zitierten Schriften per se bekannt ist.
Es kann eine weitere Datenverbindung zu der Lade/Speicher- einheit der oder einer dem Datenverarbeitungslogikzellenfeld zugeordneten Sequenziell-CPU-Einheit vorgesehen sein und/oder zu deren Register. Es sei erwähnt, dass ein Ansprechen derartiger Einheiten über separate Eingangs-/Ausgangsanschlüsse (IO-Ports) der insbesondere als VPU beziehungsweise XPP ausgestaltbaren Datenver- arbeitungslogikzellenanordnung erfolgen kann und/oder durch einen oder mehrere einem" Einzelport nachgeschaltete Multiple- xer .
Dass neben dem insbesondere blockweisen und/oder strea enden und/oder im Random-Access, insbesondere im RMW-Modus (Read- Modify-Write-Modus) erfolgenden Zugriff auf Cache-Bereiche in schreibender und/oder lesender Weise und/oder die LOAD/STORE- Einheit und/oder die (per se im Stand der Technik bekannte) Verbindung mit dem Register der Sequenziell-CPU auch eine Verbindung mit einem externen Massenspeicher wie einem RAM, einer Festplatte und/oder einem anderen Datenaustauschport wie einer Antenne und so weiter erfolgen kann, sei auch erwähnt. Es kann für diesen Zugriff auf Cache- und/oder LOAD/ STORE-Einheit- und/oder registereinheitverschiedene Speicher- mittel ein separater Port vorgesehen sein. Dass hier geeignete Treiber, Buffer, Signalaufbereiter für Pegelanpassung und so weiter vorgesehen sein können, z. B. LS 74244, LS74245, sei erwähnt. Im Übrigen sei erwähnt, dass insbesondere, jedoch nicht ausschließlich zur Aufbereitung eines in das Da- tenverarbeitungslogikzellenfeld hineinströmenden oder in diesem strömenden Datenstromes die Logikzellen des Feldes ÄLUs bzw. EALUs umfassen können und typisch werden, denen eingangs- und/oder ausgangsseitig, insbesondere sowohl eingangs- als auch ausgangsseitig kurze, feingranular konfigurierbare, FPGA-artige Schaltkreise vorgesetzt sein können und/oder in die PAE-ALU integriert sein können, um etwa aus einem kontinuierlichen Datenstrom Bitblöcke herauszuschneiden, wie dies für die MPEG-4-Dekodierung erforderlich ist. Es ist dies zum einen vorteilhaft, wenn ein Datenstrom in die Zelle hineingelangen soll und dort ohne Blockierung von größeren PAE- Einheiten einer Art Vorverarbeitung zu unterwerfen ist. Dies ist auch dann von ganz besonderem Vorteil, wenn die ALU als SIMD-Rechenwerk ausgestaltet wird, wobei dann ein sehr breites Dateneingangswort von zum Beispiel 32 Bit Datenbreite über die vorgeschalteten FPGA-artigen Streifen aufgespalten wird in mehrere parallele Datenwörter von zum Beispiel 4 Bit Breite, die dann in den SIMD-Rechenwerken parallel abgearbeitet werden können, was die Gesamtperformance des Systems signifikant zu erhöhen vermag, sofern .entsprechende Anwendung benötigt werden. Es sei darauf hingewiesen, dass vorstehend von FPGA-artigen vor- beziehungsweise nachgeschalteten Struk- turen die Rede war. Mit FPGA-artig muss aber, was explizit erwähnt sei, nicht zwingend Bezug genommen sein auf 1-Bit- granulare Anordnungen. Es ist insbesondere möglich, statt dieser hyperfeingranularen Strukturen lediglich feiner granuläre Strukturen von zum Beispiel 4 Bit Breite vorzusehen. Das heißt, die FPGA-artigen Eingangs- und/oder Ausgangsstrukturen vor und/oder nach einer insbesondere als SIMD-Rechenwerk ausgestalteten ALU-Einheit sind z.B. so konfigurierbar, dass immer 4 Bit breite Datenwörter zugeführt und/oder verarbeitet werden. Es ist möglich, hier eine Kaskadierung vorzusehen, so dass zum Beispiel die einkommenden 32 Bit breiten Datenwörter in 4 separierte bzw. separierende 8-Bit-FPGA-artige, nebeneinander angeordnete Strukturen strömen, diesen 4 Stück 8 Bit breiten FPGA-artigen Strukturen ein zweiter Streifen mit 8 Stück 4 Bit breiten FPGA-artigen Strukturen nachgesetzt ist, und gegebenenfalls nach einem weiteren derartigen Streifen dann, sofern dies für den jeweiligen Zweck als erforderlich erachtet wird, zum Beispiel 16 Stück parallel nebeneinander angeordnete 2 Bit breite FPGA-artige Strukturen vorgesehen werden. Wenn dies der Fall ist, kann gegenüber rein hyper- feingranular FPGA-artigen Strukturen eine beträchtliche Verringerung des Konfigurationsaufwandes erzielt werden. Dass dies überdies dazu führt, dass der Konfigurationsspeicher und so weiter der FPGA-artigen Struktur wesentlich kleiner ausfallen kann und somit eine Einsparung an Chipfläche erzielt wird, sei erwähnt. Auch sei erwähnt, dass FPGA-artige Streifenstrukturen wie auch in Verbindung mit Fig. 3 offenbart, insbesondere bezüglich Anordnung in der PAE, besonders leicht die Implementierung von Pseudozufallsrauschgeneratoren ermöglichen. Wenn dabei schrittweise immer wieder aus einer einzigen FPGA-Zelle erhaltene einzelne. Ausgangsbits an die FPGA- Zelle zurückgespeichert werden, kann auch mit einer einzigen Zelle sequenziell ein Pseudozufallsrauschen kreativ generiert werden, was als für sich erfinderisch betrachtet wird, vgl. Fig. 5.
Prinzipiell sind die vorstehend beschriebenen Kopplungsvor- teile bei Datenblockströmen über den Cache erreichbar; besonders bevorzugt ist es jedoch, wenn der Cache streifenweise (slice-artig) aufgebaut ist und dann ein Zugriff auf mehrere der Slices simultan erfolgen kann, insbesondere auf alle Sli- ces gleichzeitig. Dies ist dann vorteilhaft, wenn, was noch erörtert werden wird, auf dem Datenverarbeitungslogikzellen- feld (XPP) und/oder der Sequenziell-CPU und/oder den Sequen- ziell-CPUs eine Vielzahl von Threads abzuarbeiten sind, sei es im Wege des Hyperthreadings, des Multitaskings und/oder des Multithreadings . Es sind also bevorzugt Cachespeichermit- tel mit Scheibenzugriff bzw. Scheibenzugriffsermöglichungs- steuermitteln vorgesehen. Es kann dabei z. B. jedem Thread eine eigene Scheibe zugeordnet werden. Dies ermöglicht es
- 1E später, beim Abarbeiten der Threads sicherzustellen, dass jeweils auf die entsprechenden Cachebereiche bei Wiederaufnahme der mit dem Thread abzuarbeitenden Befehlsgruppe zugegriffen wird.
Es sei noch einmal erwähnt, dass der Cache, nicht zwingend in Slices unterteilt sein muss, und dass, wenn dies der Fall ist, nicht zwingend jeder Slice einem eigenen Thread zugewiesen werden muss. Es sei allerdings darauf hingewiesen, dass dies die bei weitem bevorzugte Methode ist. Es sei weiter darauf hingewiesen, dass es Fälle geben kann, in denen nicht alle Cache-Bereiche simultan oder zu einer gegebenen Zeit temporär benützt werden. Vielmehr ist zu erwarten, dass bei typischen Datenverarbeitungsanwendungen, wie sie in handge- haltenen mobilen Telefonen (Handys) , Laptops, Kameras und so weiter auftreten werden, häufig Zeiten vorliegen werden, in denen nicht der gesamte Cache benötigt wird. Es ist daher besonders bevorzugt, wenn einzelne Cache-Bereiche von der Leistungsversorgung derart trennbar sind, dass ihr Energiever- brauch signifikant absinkt, insbesondere auf oder nahe null. Dies kann bei sliceweiser Ausgestaltung des Caches durch sli- ceweise Abschaltung derselben über geeignete Leistungsabtrennmittel geschehen, vgl. zum Beispiel Fig. 2. Die Abtrennung kann entweder über eine Heruntertaktung, Taktabtrennung oder eine Leistungsabtrennung erfolgen. Es kann insbesondere einer einzelnen Cache-Scheibe oder dergleichen eine Zugriffserkennung zugeordnet sein, welche dazu ausgebildet ist, zu erkennen, ob ein jeweiliger Cache-Bereich beziehungsweise eine jeweilige Cache-Scheibe momentan einen ihm zugeordneten Thread, Hyperthread oder Task hat, von welchem er benützt wird. Sofern dann vom Zugriffserkennungsmittel festgestellt wird, dass dies nicht der Fall ist, wird typisch eine Abtren- nung vom Takt und/oder sogar der Leistung möglich sein. Es sei erwähnt, dass bei Wiedereinschalten der Leistung nach einem Abtrennen ein sofortiges Wiederansprechen des Cachebereiches möglich ist, also keine signifikante Verzögerung durch das An- und Ausschalten der Leistungszufuhr zu erwarten ist, sofern mit gängigen geeigneten Halbleitertechnologien eine Implementierung in Hardware erfolgt. Dies ist unabhängig von der Verwendung mit Logikzellenfeldern in vielen Anwendungen sinnvoll.
Ein weiterer besonderer Vorteil, der sich bei der vorliegenden Erfindung ergibt, besteht darin,, dass zwar eine besonders effiziente Kopplung bezüglich des Übertrags von Daten beziehungsweise Operanden in insbesondere blockweiser Form gegeben ist, dass aber dennoch ein Balancing nicht in der Weise erforderlich ist, dass die exakt gleiche Verarbeitungszeit in Sequenziell-CPU und XPP beziehungsweise Datenverarbeitungslo- gikzellenfeld erforderlich ist. Vielmehr erfolgt die Verarbeitung in einer praktisch oftmals unabhängigen Weise, insbe- sondere derart, dass die Sequenziell-CPU und die Datenverar- beitungslogikzellenfeldanordnung für einen Scheduler oder dergleichen als separate Ressourcen betrachtbar sind. Dies erlaubt eine sofortige Umsetzung bekannter Datenverarbeitungsprogrammaufspaltungstechnologien wie Multitasking, Mul- tithreading und Hyperthreading. Der sich ergebende Vorteil, dass ein Pfadbalancing nicht erforderlich ist, das heißt Ausbalancieren zwischen sequenziellen Teilen (z. B. auf einer RISC-Einheit) und Datenflussteilen (z. B. auf einer XPP) führt dazu, dass beispielsweise innerhalb der Sequenziell-CPU (also z. B. den RISC functional units) beliebige Anzahlen von Pipelinestufen durchlaufen werden können, Taktungen in unterschiedlicher Weise möglich sind und so weiter. Ein weiterer Vorteil der vorliegenden Erfindung besteht darin, dass durch das Hineinkqnfigurieren einer Ladekonfiguration beziehungsweise einer Storekonfiguration in die XPP oder andere Daten- verarbeitungslogikzellenfeider die Daten in das Feld mit ei- ner Geschwindigkeit hineingeladen werden oder aus diesem herausgeschrieben werden können, die nicht mehr bestimmt ist durch die Taktgeschwindigkeit der CPU, die Geschwindigkeit, mit welcher der OpCode-Fetcher arbeitet, oder dergleichen. Mit anderen Worten ist die Ablaufsteuerung der Sequenziell- CPU nicht mehr flaschenhalsartig begrenzend für den Datendurchsatz des Datenzellenlogikfeldes, ohne dass eine nur noch lose Ankopplung besteht.
Während es in einer besonders bevorzugten Variante der Erfin- düng möglich ist, die für eine XPP-Einheit bekannte CT (bzw. CM; Konfigurationsmanager bzw. Konfigurationstabelle) zu verwenden, um sowohl das Konfigurieren eines oder mehrerer, auch hierarchisch mit mehreren CTs angeordneter XPP-Felder und gleichzeitig eines oder mehrerer Sequenziell-CPUs, dort quasi als Multithreading-Scheduler- und -Hardwareverwaltung zu verwenden, was den inhärenten Vorteil hat, daß bekannte Technologien wie z. B. FILMO usw. für die hardwareunterstützte Verwaltung beim Multithreading einsetzbar werden, ist es alternativ und/oder, insbesondere in hierarchischer Anordnung, zu- sätzlich möglich, dass ein Datenverarbeitungslogikzellenfeld wie eine XPP Konfigurationen vom OpCode-Fetcher einer Sequenziell-CPU über das Koprozessor-Interface erhält. Dies führt dazu, daß von der Sequenziell-CPU und/oder einer anderen XPP ein Aufruf instantiiert werden kann, der zu einer Datenabar- beitung auf der XPP führt. Die XPP wird dabei dann z. B. über die beschriebene Cache-Ankopplung und/oder mittels LOAD- und/oder STORE-Konfigurationen, die Adressgeneratoren für La- den und/oder Wegschreiben von Daten im XPP- bzw. Datenverar- beitungslogikzellenfeld vorsehen, im Datenaustausch gehalten. Mit anderen Worten wird eine coprozessorartige und/oder Thread-Ressourcen-artige Ankopplung eines Datenverarbeitungs- logikzellenfeldes möglich, während gleichzeitig ein daten- stromartiges Datenladen durch Cache- und/oder I/O-Port- Kopplung erfolgt.
Es sei erwähnt, daß die Koprozessor-Ankopplung, d. h. die An- kopplung des Datenverarbeitungslogikzellenfeldes typisch dazu führen wird, daß das Scheduling auch für dieses Logikzellenfeld auf der Sequenziell-CPU oder einer dieser übergeordneten Schedulereinheit bzw. einem entsprechenden Schedulermittel erfolgen wird. In einem solchen Fall findet praktisch die Threading-Kontrolle und -Verwaltung auf dem Scheduler bzw. der Sequenziell-CPU statt. Obwohl dies per se möglich ist, wird dies, zumindest bei einfachster Implementierung der Erfindung, nicht zwingend der Fall sein. Vielmehr kann eine Verwendung des Datenverarbeitungslogikzellenfeldes durch Auf- ruf in herkömmlicher Weise wie bei einem Standard-Coprozessor, etwa bei 8086/8087-Kombinationen erfolgen.
Weiter sei erwähnt, daß es in einer besonders bevorzugten Variante, unabhängig von der Art der Konfiguration, sei es über das Coprozessor-Interface, den als Scheduler mitdienenden Konfigurationsmanager (CT) der XPP bzw. des Datenverarbei- tungslogikzellenfeldes oder dergleichen oder auf andere Weise, möglich ist, im bzw. unmittelbar am Datenverarbeitungslo- gikzellenfeld bzw. unter Verwaltung des Datenverarbeitungslo- gikzellenfeldes Speicher, insbesondere interne Speicher, insbesondere bei der XPP-Architektur, wie sie aus den diversen Voranmeldungen und den Veröffentlichungen des Anmelders be- kannt ist, RAM-PAEs, oder andere entsprechend verwaltete oder interne Speicher wie ein Vektorregister anzusprechen, d. h. die über die LOAD-Konfiguration eingeladenen Datenmengen vektorartig wie in Vektorregistern in die internen Speicher ab- zulegen, dann, nach Umkonfigurieren der XPP bzw. des Daten- verarbeitungslogikzellenfeldes, also Überschreiben bzw. Nachladen und/oder Aktivieren einer neuen Konfiguration, die die eigentliche Verarbeitung der Daten durchführt (in diesem Zusammenhang sei darauf hingewiesen, daß für eine solche Verar- beitungskonfiguration auch Bezug genommen werden kann auf eine Mehrzahl von Konfigurationen, die z. B. im Wave-Modus und/oder sequenziell nacheinander abzuarbeiten sind) zuzugreifen wie bei einem Vektorregister und dann die dabei erhaltenen Ergebnisse und/oder Zwischenergebnisse wiederum in die internen oder über die XPP wie interne Speicher verwalteten externen Speicher, um dort diese Ergebnisse abzulegen. Die so vektorregisterartig mit Verarbeitungsergebnissen beschriebenen Speichermittel unter XPP-Zugriff sind dann, nach Rekonfigurieren der Verarbeitungskonfiguration durch Laden der STORE-Konfiguration in geeigneter Weise weggeschrieben, was wiederum datenstromartig geschieht, sei es über den I/O- Port direkt in externe Speicherbereiche und/oder, wie besonders bevorzugt, in Cache-Speicherbereiche, auf welche dann zu einem späteren Zeitpunkt die Sequenziell-CPU und/oder andere Konfigurationen auf der zuvor die Daten erzeugt habenden XPP oder einer anderen entsprechenden Datenverarbeitungseinheit zugreifen können.
Eine besonders bevorzugte Variante besteht darin, zumindest für bestimmte Datenverarbeitungsergebnisse und/oder Zwischenergebnisse als Speicher- bzw. Vektorregistermittel, in welchem bzw. welches die erhaltenen Daten abzulegen sind, nicht einen internen Speicher zu benutzen, in welchen Daten über eine STORE-Konfiguration in den Cache- oder einen anderen Bereich, auf welchen die Sequenziell-CPU oder eine andere Datenverarbeitungseinheit zugreifen können, wegzuschreiben sind, sondern statt dessen unmittelbar die Ergebnisse wegzuschreiben in entsprechende, insbesondere zugriffsreservierte Cachebereiche, die insbesondere Slice-artig organisiert sein können. Dies kann gegebenenfalls den Nachteil einer größeren Latenz haben, insbesondere, wenn die Wege zwischen der XPP- oder Datenverarbeitungslogikzellenfeldeinheit und dem Cache so lang sind, daß die Signallaufzeiten ins Gewicht fallen, führt aber dazu, daß gegebenenfalls .keine weitere STORE- Konfiguration benötigt wird. Es sei im übrigen erwähnt, daß eine derartige Abspeicherung von Daten in Cache-Bereiche ei- nerseits, wie vorstehend beschrieben, dadurch möglich ist, daß der Speicher, in welchen geschrieben wird, physikalisch nahe beim Cache-Controller liegt und als Cache ausgestaltet ist, dass aber alternativ und/oder zusätzlich auch die Möglichkeit besteht, einen Teil eines XPP-Speicherbereiches, XPP^internen Speichers oder dergleichen, insbesondere bei RAM über PAEs, vgl. PACT31 (DE 102 12 621.6, WO 03/036507), unter die Verwaltung eines oder, nacheinander mehrerer Cache- Speichercontroller zu stellen. Dies hat dann Vorteile, wenn die Latenz beim Abspeichern der Verarbeitungsergebnisse, wel- ehe innerhalb des Datenverarbeitungslogikzellenfeldes bestimmt werden, gering gehalten werden soll, während die Latenz beim Zugriff auf den dann nur noch als „Quasi-Cache" dienenden Speicherbereich durch andere Einheiten nicht oder nicht signifikant ins Gewicht fällt.
Es sei im übrigen erwähnt, daß auch eine Ausgestaltung derart möglich ist, daß der Cache-Controller einer herkömmlichen Se- quenziell-CPU einen Speicherbereich als Cache anspricht, der, ohne dem Datenaustausch mit dem Datenverarbeitungslogikzel- lenfeld zu dienen, auf und/oder bei diesem physikalisch liegt. Dies hat den Vorteil, daß dann, wenn Anwendungen auf dem Datenverarbeitungslogikzellenfeld laufen, die einen allenfalls geringen lokalen Speicherbedarf haben, und/oder wenn auch nur wenige weitere Konfigurationen bezogen auf die zur Verfügung stehenden Speichermengen benötigt werden, diese einer oder mehreren Sequenziell-CPUs als Cache zur Verfügung stehen können. Es sei erwähnt, daß dann der Cache-Controller für die Verwaltung eines Cache-Bereiches mit dynamischem Umfang, d. h. variierender Größe ausgebildet sein kann und wird. Eine dynamische Cache-Umfangsverwaltung bzw. Cache- Umfangsverwaltungsmittel für die dynamische Cache-Verwaltung wird typisch die Arbeitslast und/oder die Input-/Output-Last auf der Sequenziell-CPU und/oder dem Datenverarbeitungslo- gikzellenfeld berücksichtigen. Mit anderen Worten kann beispielsweise analysiert werden, wie viele NOPs Datenzugriffe in einer gegebenen Zeiteinheit auf der Sequenziell-CPU vor- liegen und/oder wie viele Konfigurationen im XPP-Feld in dafür vorgesehenen Speicherbereichen vorabgelegt sein sollen, um eine schnelle Umkonfiguration, sei es im Wege einer Wel- lenrekonfiguration oder auf andere Weise ermöglichen zu können. Die hiermit offenbarte dynamische Cachegrösse ist dabei insbesondere bevorzugt laufzeitdynamisch, d. h . der Cachecontroller verwaltet jeweils eine aktuelle Cachegrösse, die sich von Takt zu Takt oder Taktgruppe ändern kann. Es sei im übrigen darauf hingewiesen, daß die Zugriffsverwaltung eines XPP- bzw. Datenverarbeitungslogikzellenfeldes mit Zugriff als interner Speicher wie bei einem Vektorregister und als Cache- artiger Speicher für den externen Zugriff was die Speicherzugriffe angeht bereits beschrieben wurde in der DE 196 54 595 und der PC /DE 97/03013 (PACT03) . Die genannten Schriften sind durch Bezugnahme zu Offenbarungszwecken hiermit vollumfänglich eingegliedert.
Vorstehend wurde auf Datenverarbeitungslogikzellenfelder Bezug genommen, die insbesondere zur Laufzeit rekonfigurierbar sind. Es wurde diskutiert, dass bei diesen eine Konfigurati- onsverwaltungseinheit (CT bzw. CM) vorgesehen werden kann. Aus den diversen, zu Offenbarungszwecken unter Bezug genomme- nen Schutzrechten des Anmelders sowie seinen weiteren Veröffentlichungen ist die Verwaltung von Konfigurationen per se bekannt. Es sei nun explizit darauf hingewiesen, dass derartige Einheiten und deren Wirkungsweise, mit der insbesondere unabhängig von Ankopplungen an Sequenziell-CPUs etc. aktuell noch nicht benötigte Konfigurationen vorladbar sind, auch sehr gut nutzbar sind, um im Multitaskingbetrieb und/oder bei Hyperthreading und/oder Multithreading einen Task- beziehungsweise einen Thread- und/oder Hyperthreadwechsel zu bewirken, vgl. zum Beispiel 6a - 6c. Dazu kann ausgenützt wer- den, dass während der Laufzeit eines Threads oder Tasks in die Konfigurationsspeicher bei einer einzelnen oder einer Gruppe von Zellen des Datenverarbeitungslogikzellenfeldes, also beispielsweise einer PAE eines PAE-Feldes (PA) auch Konfigurationen für unterschiedliche Aufgaben, das heißt Tasks oder Threads beziehungsweise Hyperthreads geladen werden können. Dies führt dann dazu, dass bei einer Blockade eines Tasks oder Threads, etwa wenn auf Daten gewartet werden muss, weil diese noch nicht verfügbar sind, sei es, da sie von einer anderen Einheit noch nicht generiert oder empfangen wur- den, beispielsweise auf Grund von Latenzen, sei es, weil eine Resource derzeit noch durch einen anderen Zugriff blockiert ist, dann Konfigurationen für einen anderen Task oder Thread vorladbar und/oder vorgeladen sind und auf diese gewechselt werden kann, ohne dass der
Zeitoverhead für einen Konfigurationswechsel bei der insbesondere schattengeladenen Konfiguration abgewartet werden muss. Während es prinzipiell möglich ist, diese Technik auch dann zu verwenden, wenn innerhalb eines Tasks die wahrscheinlichste Weiterführung vorhergesagt wird und eine Vorhersage nicht zutrifft (prediction miss), wird diese Art des Betriebs bei vorhersagefreiem Betrieb bevorzugt sein. Bei Verwendung mit einer rein sequentiellen CPU und/oder mehreren rein sequentiellen CPUs, insbesondere ausschließlich mit solchen, wird somit durch die Zuschaltung eines Konfigurationsmanagers eine Multithreadingverwaltungshardware realisiert. Verwiesen sei hinsichtlich dessen insbesondere auf PACT10 (DE 198 07 872.2, WO 99/44147, WO 99/44120) und PACT17 (DE 100 28 397.7, WO 02/13000) . Dabei kann es als ausreichend erachtet werden, insbesondere dann, wenn nur für eine CPU und/oder einige wenige Sequenziell-CPUs eine Hyperthreadingverwaltung gewünscht ist, auf bestimmte, in den speziell unter Bezug genommenen Schutzrechten beschriebene Teilschaltungen wie den FILMO zu verzichten. Insbesondere wird damit die Verwendung der dort beschriebenen Konfigurationsmanager mit und/oder ohne FILMO für die Hyperthreadingverwaltung für eine und/oder mehrere rein sequenziell arbeitende CPUs mit oder ohne Ankopplung an eine XPP oder ein anderes Datenverarbeitungslogikzellenfeld offenbart und hiermit für sich beansprucht. Es wird hierin eine für sich erfinderische Besonderheit gesehen. Es sei im Übrigen erwähnt, dass eine Vielzahl von CPUs realisiert werden kann mit den bekannten Techniken, wie sie insbesondere aus PACT31 (DE 102 12 621.6-53, PCT/EP 02/10572) und PACT34 (DE 102 41 812.8, PCT/EP 03/09957) bekannt sind, bei welchen innerhalb eines Arrays eine oder mehrere Sequenziell-CPUs aufgebaut werden unter Ausnutzung eines oder mehrerer Speicherbereiche insbesondere im Datenverarbeitungslogikzellen- feld für den Aufbau der sequenziellen CPU, insbesondere als Befehls- und/oder Datenregister. Auch sei darauf verwiesen, dass bereits in früheren Anmeldungen wie PACT02, (DE 196 51 075.9-53, WO 98/26356), PACT04 (DE 196 54 846.2-53, WO 98/29952), PACT08, (DE 197 04 728.9, WO 98/35299) offenbart wurde, wie Sequenzer mit Ring- und/oder Wahlfrei-Zugriff- Speic ern aufgebaut werden können.
Es sei darauf .hingewiesen, dass ein Task- beziehungsweise Thread- und/oder Hyperthreadwechsel .unter Verwendung der bekannten CT-Technologie, vgl. PACT10 (DE 198 07 872.2, WO 99/44147, WO 99/44120) und PACT17 (DE 100 28 397.7, WO 02/13000) derart erfolgen kann und bevorzugt auch erfolgen wird, dass einem per se bekannten, Software-implementierten Betriebssystem-Scheduler oder dergleichen von der CT Performance-Scheiben und/oder Zeitscheiben zugeordnet werden, während welchen bestimmt wird, von welchen Tasks oder Threads nachfolgend welche Teile per se, unterstellt, dass Resourcen frei sind, abzuarbeiten sind. Dazu sei ein Beispiel wie folgt gegeben: Zunächst soll für einen ersten Task eine Adressfolge generiert werden, gemäß welcher während der Ausführung einer LOAD-Konfiguration Daten aus einem Speicher und/oder Cache- Speicher, an dem ein Datenverarbeitungslogikzellenfeld in der beschriebenen Weise angekoppelt ist, geladen werden sollen. Sobald diese Daten vorliegen, kann mit der Abarbeitung einer zweiten, der eigentlichen Datenverarbeitungskonfiguration, begonnen werden. Auch diese kann vorgeladen werden, da sicher feststeht, dass diese Konfiguration, sofern keine Interrupts oder dergleichen einen vollständigen Taskwechsel erzwingen, auszuführen ist. In herkömmlichen Prozessoren ist nun das Problem des sogenannten Cache-Miss bekannt, bei dem die Daten zwar angefordert werden, aber nicht im Cache für den Ladezugriff bereit liegen. Tritt ein solcher Fall in einer Kopplung gemäß der vorliegenden Erfindung auf, kann bevorzugt auf ei- nen anderen Thread, Hyperthread und/oder Task gewechselt werden, der insbesondere zuvor von dem insbesondere softwareimplementierten Betriebssystem-Scheduler und/oder einer anderen hard- und/oder softwareimplementierten, entsprechend wirkenden Einheit für eine nächstmögliche Ausführung bestimmt wurde und demgemäß bevorzugt vorab in einen der verfügbaren Konfigurationsspeicher des Datenverarbeitungslogikzellenfeldes insbesondere im Hintergrund während der Ausführung einer anderen Konfiguration, beispielsweise der LOAD-Konfiguration, welche das Laden jener Daten, auf die nun gewartet wird, be- wirkt hat, geladen wurde. Dass für die Vorabkonfiguration ungestört von der tatsächlichen Verschaltung der insbesondere grobgranular ausgebildeten Datenverarbeitungslogikzellen des Datenverarbeitungslogikzellenfeldes separate Konfigurationsleitungen von der konfigurierenden Einheit zu den jeweiligen Zellen direkt und/oder über geeignete Bussysteme geführt sein können wie per se im Stand der Technik bekannt, sei hier noch einmal explizit erwähnt, da diese Ausbildung hier besonders bevorzugt ist, um ein ungestörtes Vorabkonfigurieren ohne Störung einer anderen, gerade laufenden Konfiguration zu er- möglichen. Erwähnt seien hier u. a. die PACT10 (DE 198 07 872.2, WO 99/44147, WO 99/44120), PACT17 (DE 100 28 397.7, WO 02/13000) PACT13 (DE 199 26 538.0, WO 00/77652), PACT02 (DE 196 51 075.9, WO 98/26356) und PACT08 (DE 197 04 728.9, WO 98/35299) . Wenn dann die Konfiguration, auf welche während beziehungsweise auf Grund des Task-Thread- und/oder Hyper- threadwechsels gewechselt wurde, abgearbeitet wurde, und zwar, bei bevorzugten nicht teilbaren, ununterbrechbaren und somit quasi atomaren Konfigurationen bis zum Ende abgearbeitet wurde, vgl. PACT19 (DE 102 02 044.2, WO 2003/060747) und PACT11 (DE 101 39 170.6, WO 03/017095), wird teilweise eine weitere andere Konfiguration wie vorbestimmt durch die ent- sprechenden Scheduler, insbesondere den betriebssystemnahen Scheduler festgelegt, abgearbeitet und/oder jene Konfiguration, zu welcher zuvor die zugehörige LOAD-Konfiguration ausgeführt wurde. Vor der Ausführung einer Verarbeitungskonfiguration, zu welcher zuvor eine LOAD-Konfiguration ausgeführt wurde, kann insbesondere abgetestet werden, z. B. durch Abfrage des Status der LOAD-Konfiguration oder des datenladenden DMA-Kontrollers, ob mittlerweile die entsprechenden Daten in das Array eingeströmt sind, also die Latenzzeit, wie sie typisch auftritt, verstrichen ist und/oder die Daten tatsäch- lieh vorliegen.
Mit anderen Worten werden dann Latenzzeiten, wenn sie auftreten, weil z. B. Konfigurationen noch nicht einkonfiguriert sind, Daten noch nicht geladen und/oder Daten noch nicht weg- geschrieben wurden, überbrückt und/oder verdeckt, indem
Threads, Hyperthreads und/oder Tasks ausgeführt werden, welche schon vorkonfiguriert sind und welche mit Daten arbeiten, die schon verfügbar sind beziehungsweise die an Ressourcen weggeschrieben werden können, die für das Wegschreiben be- reits zur Verfügung stehen. Auf diese Weise werden Latenzzeiten weitgehend überdeckt und es wird, eine hinreichende Anzahl von per se auszuführenden Threads, Hyperthreads und/oder Tasks unterstellt, eine praktisch 100%-ige Ausnutzung des Da- tenverarbeitungslogikzellenfeldes erreicht .
Es sei besonders erwähnt, dass durch das Vorsehen hinreichend vieler XPP-interner Speicherresourcen, die frei - z. B. durch den Scheduler oder die CT - Threads zugeordnet werden, zugleich und/oder überlagernd die Cache- und/oder Schreiboperationen mehrerer Threads durchgeführt werden können, was sich besonders positiv auf die Überbrückung eventueller Latenzen auswirkt.
Mit dem beschriebenen System bezüglich Datenstrom-Fähigkeit bei gleichzeitiger Ankopplung an eine Sequenziell-CPU und/ oder bezüglich der Ankopplung eines XPP-Array beziehungsweise Datenverarbeitungslogikzellenfeldes und simultan einer Sequenziell-CPU an eine geeignete Schedulereinheit wie einen Konfigurationsmanager oder dergleichen lassen sich insbesondere ohne weiteres echtzeitfähige Systeme realisieren. Zur Echtzeitfähigkeit muss gewährleistet sein, dass auf eintref- fende Daten beziehungsweise Interrupts, die insbesondere das Dateneintreffen signalisieren, innerhalb einer in keinem Fall zu überschreitenden Maximalzeit reagiert werden kann. Dies kann beispielsweise geschehen durch einen Taskwechsel auf einen Interrupt hin und/oder, beispielsweise bei priorisierten Interrupts, durch Festlegung, dass ein gegebener Interrupt momentan zu ignorieren ist, wobei auch dies innerhalb einer bestimmten Zeit festzulegen ist. Ein Taskwechsel bei derartigen echtzeitfähigen Systemen wird typisch auf drei Arten erfolgen können, nämlich entweder dann, wenn ein Task eine be- stimmte Zeit gelaufen ist (Timer-Prinzip) , bei Nichtzurverfü- • gungstehen einer Resource, sei es durch deren Blockade durch anderen Zugriff oder aufgrund von Latenzen beim Zugriff darauf, insbesondere in schreibender und/oder lesender Weise, das heißt bei Latenzen von Datenzugriffen und/oder beim Auf- treten von Interrupts. Es wird im übrigen darauf hingewiesen, dass insbesondere auch eine laufzeitbegrenzte Konfiguration auf einer für die Interruptbearbeitung freizugebenden bzw. zu wechselnden Resource einen Watchdog bzw. MitlaufZähler neu antriggern kann.
Während ansonsten explizit ausgeführt wurde, vgl. auch PACT 29 (DE 102 12 622.4, WO 03/081454), dass das Neuantrig- gern des MitlaufZählers bzw. Watchdogs zur Laufzeiterhöhung durch einen Task-switch unterbindbar ist, wird vorliegend ex- plizit offenbart, dass ein Interrupt gleichfalls, das heißt entsprechend einem Taskswitch, MitlaufZähler - bzw. Watchdog - und Neutrigger blockierend wirken .kann, d. h. es kann in einem solchen Fall unterbunden werden, dass die Konfiguration durch Neuantriggern selbst ihre maximal mögliche Laufzeit er- höht.
Mit der vorliegenden Erfindung kann die Echtzeitfähigkeit eines Datenverarbeitungslogikzellenfeldes nunmehr erreicht werden, indem eine oder mehrere von drei möglichen Varianten im- plementiert wird.
Eine erste Variante besteht darin, dass innerhalb einer von dem Scheduler beziehungsweise der CT ansprechbaren Ressource ein Wechsel zur Abarbeitung beispielsweise eines Interrupts erfolgt. Sofern die Ansprechzeiten auf Interrupts oder andere Anforderungen so groß sind, dass während dieser Zeit eine Konfiguration ohne Unterbrechung noch abgearbeitet werden kann, ist dies unkritisch, zumal während der Abarbeitung der aktuell laufenden Konfiguration auf jener Ressource, die für die Abarbeitung des Interrupts zu wechseln ist, eine Konfiguration zur Interruptabärbeitung vorgeladen werden kann. Die Auswahl der vorabzuladenden Interrupt-bearbeitenden Konfigu- ration ist z. B. durch die CT durchzuführen. Es ist möglich, die Laufzeit der Konfiguration auf der für die Interruptbearbeitung freizugebenden bzw. zu wechselnden Ressource zu begrenzen. Verwiesen wird dazu auf PACT29/PCT (PCT/DE03/000942) .
Bei Systemen, die schneller auf Interrupts reagieren müssen, kann es bevorzugt sein, eine einzelne Ressource, also beispielsweise eine separate XPP-Einheit und/oder Teile eines XPP-Feldes für eine solche Abarbeitung zu reservieren. Wenn dann ein schnell abzuarbeitender Interrupt auftritt, kann entweder eine für besonders kritische Interrupts schon vorab vorgeladene Konfiguration abgearbeitet werden oder es wird sofort mit dem Laden einer Interrupt behandelnden Konfiguration in die reservierte Ressource begonnen. Eine Auswahl der jeweils für den entsprechenden Interrupt erforderlichen Konfiguration ist durch entsprechende Triggerung, Waveabarbei- tung usw. möglich.
Es sei im übrigen erwähnt, dass es mit den schon beschriebe- nen Methoden ohne weiteres möglich ist, eine instantane Reaktion auf einen Interrupt zu erhalten, indem über die Verwendung von LOAD/STORE-Konfigurationen eine Code-Reentranz erreicht wird. Hierbei wird nach jeder datenbearbeitenden Konfiguration oder zu gegebenen Zeiten, beispielsweise alle fünf oder zehn Konfigurationen eine STORE-Konfiguration ausgeführt und dann eine LOAD-Konfiguration unter Zugriff auf jene Speicherbereiche ausgeführt, in die zuvor weggeschrieben wurde. Wenn sichergestellt wird, dass die von der STORE-Konfiguration benutzten Speicherbereiche so lange unberührt bleiben, bis durch Fortschreiten im Task eine weitere Konfiguration sämtliche relevanten Informationen (Zustände, Daten) weggeschrieben hat, ist sichergestellt, dass bei Wiederladen, also Wiedereintritt in eine zuvor bereits begonnene, aber nicht zu Ende geführte Konfiguration oder Konfigurationskette wieder dieselben Bedingungen erhalten werden. Eine solche Zwischenschaltung von LOAD/STORE-Konfigurationen unter simultanem Schutz von noch nicht veralteten STORE-Speicherbereichen lässt sich automatisch ohne zusätzlichen Programmieraufwand sehr einfach generieren, z. B. von einem Compiler.- Dort kann die Ressourcenreservierung gegebenenfalls vorteilhaft sein. Das bei der Ressourcenreservierung und/oder in anderen Fällen auf zumindest eine Menge hochpriorisierter Interrupts durch Vorabladen von bestimmten Konfigurationen reagiert werden kann, sei noch einmal erwähnt.
Eine weitere, besonders bevorzugte Variante der Reaktion auf Interrupts besteht dann, wenn zumindest eine der ansprechbaren Ressourcen eine Sequenziell-CPU ist, darin, auf dieser eine Interrupt-Routine abzuarbeiten, in welcher wiederum Code für das Datenverarbeitungslogikzellenfeld verboten ist. Mit anderen Worten wird eine zeitkritische Interrupt-Routine aus- schließlich auf einer Sequenziell-CPU abgearbeitet, ohne dass XPP-Datenverarbeitungsschritte aufgerufen werden. Dies garantiert, dass der Verarbeitungsvorgang auf dem Datenverarbei- tungslogikzellenfeld nicht zu unterbrechen ist und es kann dann eine Weiterabarbeitung auf diesem Datenverarbeitungslo- gikzellenfeld nach einem Taskswitch erfolgen. Obwohl damit die eigentliche Interrupt-Routine keinen XPP-Code besitzt, kann dennoch dafür gesorgt werden, dass auf einen Interrupt hin zu einem späteren, nicht mehr echtzeitrelevanten Zeitpunkt mit der XPP auf einen durch einen Interrupt und/oder eine Echtzeitanforderung erfassten Zustand und/oder Daten unter Verwendung des Datenverarbeitungslogikzellenfeldes reagiert werden kann.

Claims

Patentansprüche
1. Datenverarbeitungsvorrichtung mit einem Datenverarbei- tungslogikzellenfeld und zumindest einer Sequenziell-CPU, dadurch gekennzeichnet, dass eine Ankopplung der Sequenziell-CPU und des Datenverarbeitungslogikzellenfeldes zum Datenaustausch in insbesondere blockweiser Form durch zu einem Cache-Speicher führende Leitungen möglich ist.
2. Verfahren zum Betrieb einer rekonfigurierbaren Einheit mit Laufzeit beschränkten Konfigurationen, worin die Konfigurationen ihre maximal zulässige Laufzeit erhöhen können insbesondere durch Antriggern eines MitlaufZählers, dadurch gekennzeichnet, dass eine Konfigurationslaufzei- terhöhung durch die Konfiguration im Ansprechen auf einen Interrupt unterbunden wird.
EP04725695A 2003-04-04 2004-04-05 Verfahren und vorrichtung für die datenverarbeitung Withdrawn EP1611528A2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10315295 2003-04-04
DE10321834 2003-05-15
PCT/EP2004/003603 WO2004088502A2 (de) 2003-04-04 2004-04-05 Verfahren und vorrichtung für die datenverarbeitung

Publications (1)

Publication Number Publication Date
EP1611528A2 true EP1611528A2 (de) 2006-01-04

Family

ID=33132675

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04725695A Withdrawn EP1611528A2 (de) 2003-04-04 2004-04-05 Verfahren und vorrichtung für die datenverarbeitung

Country Status (5)

Country Link
US (2) US20070011433A1 (de)
EP (1) EP1611528A2 (de)
JP (1) JP2006524850A (de)
DE (1) DE112004000026D2 (de)
WO (1) WO2004088502A2 (de)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9086973B2 (en) 2009-06-09 2015-07-21 Hyperion Core, Inc. System and method for a cache in a multi-core processor
CN102737007B (zh) * 2011-04-07 2015-01-28 中兴通讯股份有限公司 一种支持多个数据单元任意置换的方法和装置
JP2012243086A (ja) * 2011-05-19 2012-12-10 Renesas Electronics Corp 半導体集積回路装置
CN106708753B (zh) * 2012-03-30 2021-04-02 英特尔公司 在使用共享虚拟存储器的处理器中加速操作的装置和方法
US9003218B2 (en) 2012-05-21 2015-04-07 International Business Machines Corporation Power shifting in multicore platforms by varying SMT levels
EP2840503A1 (de) * 2013-08-22 2015-02-25 Continental Automotive GmbH Verfahren zum Betreiben eines Pufferspeichers einer Datenverarbeitungsanlage und Datenverarbeitungsanlage
JP2016178229A (ja) 2015-03-20 2016-10-06 株式会社東芝 再構成可能な回路
CN108108191A (zh) * 2018-01-09 2018-06-01 湖南国科微电子股份有限公司 一种soc芯片及soc芯片cpu指令集的配置方法
DE102018215139A1 (de) * 2018-09-06 2020-03-12 Robert Bosch Gmbh Betriebsverfahren und Steuereinheit für ein Daten-/Signalauswertesystem, Daten-/Signalauswertesystem, Ultraschallbetriebsassistenzsystem und Arbeitsvorrichtung
US11803507B2 (en) 2018-10-29 2023-10-31 Secturion Systems, Inc. Data stream protocol field decoding by a systolic array

Family Cites Families (180)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US2067477A (en) * 1931-03-20 1937-01-12 Allis Chalmers Mfg Co Gearing
GB971191A (en) * 1962-05-28 1964-09-30 Wolf Electric Tools Ltd Improvements relating to electrically driven equipment
US3564506A (en) * 1968-01-17 1971-02-16 Ibm Instruction retry byte counter
US5459846A (en) * 1988-12-02 1995-10-17 Hyatt; Gilbert P. Computer architecture system having an imporved memory
US3956589A (en) * 1973-11-26 1976-05-11 Paradyne Corporation Data telecommunication system
DE2713648A1 (de) * 1976-03-26 1977-10-06 Tokyo Shibaura Electric Co Stromzufuhr-steuervorrichtung fuer speichervorrichtungen
US4498134A (en) * 1982-01-26 1985-02-05 Hughes Aircraft Company Segregator functional plane for use in a modular array processor
US4498172A (en) * 1982-07-26 1985-02-05 General Electric Company System for polynomial division self-testing of digital networks
US4594682A (en) * 1982-12-22 1986-06-10 Ibm Corporation Vector processing
US4566102A (en) * 1983-04-18 1986-01-21 International Business Machines Corporation Parallel-shift error reconfiguration
US4646300A (en) * 1983-11-14 1987-02-24 Tandem Computers Incorporated Communications method
US4720778A (en) * 1985-01-31 1988-01-19 Hewlett Packard Company Software debugging analyzer
US5225719A (en) * 1985-03-29 1993-07-06 Advanced Micro Devices, Inc. Family of multiple segmented programmable logic blocks interconnected by a high speed centralized switch matrix
US4748580A (en) * 1985-08-30 1988-05-31 Advanced Micro Devices, Inc. Multi-precision fixed/floating-point processor
US4720780A (en) * 1985-09-17 1988-01-19 The Johns Hopkins University Memory-linked wavefront array processor
US4760525A (en) * 1986-06-10 1988-07-26 The United States Of America As Represented By The Secretary Of The Air Force Complex arithmetic vector processor for performing control function, scalar operation, and set-up of vector signal processing instruction
US4910665A (en) * 1986-09-02 1990-03-20 General Electric Company Distributed processing system including reconfigurable elements
US5367208A (en) * 1986-09-19 1994-11-22 Actel Corporation Reconfigurable programmable interconnect architecture
GB2211638A (en) * 1987-10-27 1989-07-05 Ibm Simd array processor
FR2606184B1 (fr) * 1986-10-31 1991-11-29 Thomson Csf Dispositif de calcul reconfigurable
US4811214A (en) * 1986-11-14 1989-03-07 Princeton University Multinode reconfigurable pipeline computer
US5119290A (en) * 1987-10-02 1992-06-02 Sun Microsystems, Inc. Alias address support
US5081575A (en) * 1987-11-06 1992-01-14 Oryx Corporation Highly parallel computer architecture employing crossbar switch with selectable pipeline delay
NL8800053A (nl) * 1988-01-11 1989-08-01 Philips Nv Videoprocessorsysteem, alsmede afbeeldingssysteem en beeldopslagsysteem, voorzien van een dergelijk videoprocessorsysteem.
EP0325421B1 (de) * 1988-01-20 1994-08-10 Advanced Micro Devices, Inc. Organisation eines integrierten Cachespeichers zur flexiblen Anwendung zur Unterstützung von Multiprozessor-Operationen
US5287511A (en) * 1988-07-11 1994-02-15 Star Semiconductor Corporation Architectures and methods for dividing processing tasks into tasks for a programmable real time signal processor and tasks for a decision making microprocessor interfacing therewith
US4901268A (en) * 1988-08-19 1990-02-13 General Electric Company Multiple function data processor
US5081375A (en) * 1989-01-19 1992-01-14 National Semiconductor Corp. Method for operating a multiple page programmable logic device
GB8906145D0 (en) * 1989-03-17 1989-05-04 Algotronix Ltd Configurable cellular array
US5203005A (en) * 1989-05-02 1993-04-13 Horst Robert W Cell structure for linear array wafer scale integration architecture with capability to open boundary i/o bus without neighbor acknowledgement
CA2021192A1 (en) * 1989-07-28 1991-01-29 Malcolm A. Mumme Simplified synchronous mesh processor
US5489857A (en) * 1992-08-03 1996-02-06 Advanced Micro Devices, Inc. Flexible synchronous/asynchronous cell structure for a high density programmable logic device
GB8925723D0 (en) * 1989-11-14 1990-01-04 Amt Holdings Processor array system
US5212777A (en) * 1989-11-17 1993-05-18 Texas Instruments Incorporated Multi-processor reconfigurable in single instruction multiple data (SIMD) and multiple instruction multiple data (MIMD) modes and method of operation
JP3118266B2 (ja) * 1990-03-06 2000-12-18 ゼロックス コーポレイション 同期セグメントバスとバス通信方法
US5483620A (en) * 1990-05-22 1996-01-09 International Business Machines Corp. Learning machine synapse processor system apparatus
US5193202A (en) * 1990-05-29 1993-03-09 Wavetracer, Inc. Processor array with relocated operand physical address generator capable of data transfer to distant physical processor for each virtual processor while simulating dimensionally larger array processor
US5734921A (en) * 1990-11-13 1998-03-31 International Business Machines Corporation Advanced parallel array processor computer package
US5713037A (en) * 1990-11-13 1998-01-27 International Business Machines Corporation Slide bus communication functions for SIMD/MIMD array processor
US5590345A (en) * 1990-11-13 1996-12-31 International Business Machines Corporation Advanced parallel array processor(APAP)
US5617577A (en) * 1990-11-13 1997-04-01 International Business Machines Corporation Advanced parallel array processor I/O connection
US5218302A (en) * 1991-02-06 1993-06-08 Sun Electric Corporation Interface for coupling an analyzer to a distributorless ignition system
JPH04328657A (ja) * 1991-04-30 1992-11-17 Toshiba Corp キャッシュメモリ
US5260610A (en) * 1991-09-03 1993-11-09 Altera Corporation Programmable logic element interconnections for programmable logic array integrated circuits
FR2681791B1 (fr) * 1991-09-27 1994-05-06 Salomon Sa Dispositif d'amortissement des vibrations pour club de golf.
JP2791243B2 (ja) * 1992-03-13 1998-08-27 株式会社東芝 階層間同期化システムおよびこれを用いた大規模集積回路
JP2647327B2 (ja) * 1992-04-06 1997-08-27 インターナショナル・ビジネス・マシーンズ・コーポレイション 大規模並列コンピューティング・システム装置
US5493663A (en) * 1992-04-22 1996-02-20 International Business Machines Corporation Method and apparatus for predetermining pages for swapping from physical memory in accordance with the number of accesses
US5611049A (en) * 1992-06-03 1997-03-11 Pitts; William M. System for accessing distributed data cache channel at each network node to pass requests and data
US5386154A (en) * 1992-07-23 1995-01-31 Xilinx, Inc. Compact logic cell for field programmable gate array chip
US5581778A (en) * 1992-08-05 1996-12-03 David Sarnoff Researach Center Advanced massively parallel computer using a field of the instruction to selectively enable the profiling counter to increase its value in response to the system clock
US5857109A (en) * 1992-11-05 1999-01-05 Giga Operations Corporation Programmable logic device for real time video processing
US5497498A (en) * 1992-11-05 1996-03-05 Giga Operations Corporation Video processing module using a second programmable logic device which reconfigures a first programmable logic device for data transformation
US5392437A (en) * 1992-11-06 1995-02-21 Intel Corporation Method and apparatus for independently stopping and restarting functional units
US5386518A (en) * 1993-02-12 1995-01-31 Hughes Aircraft Company Reconfigurable computer interface and method
US5596742A (en) * 1993-04-02 1997-01-21 Massachusetts Institute Of Technology Virtual interconnections for reconfigurable logic systems
AU6774894A (en) * 1993-04-26 1994-11-21 Comdisco Systems, Inc. Method for scheduling synchronous data flow graphs
US5502838A (en) * 1994-04-28 1996-03-26 Consilium Overseas Limited Temperature management for integrated circuits
JP2927160B2 (ja) * 1993-11-17 1999-07-28 松下電器産業株式会社 レジスタ装置
US6064819A (en) * 1993-12-08 2000-05-16 Imec Control flow and memory management optimization
WO1995025306A2 (en) * 1994-03-14 1995-09-21 Stanford University Distributed shared-cache for multi-processors
US5515107A (en) * 1994-03-30 1996-05-07 Sigma Designs, Incorporated Method of encoding a stream of motion picture data
US5504439A (en) * 1994-04-01 1996-04-02 Xilinx, Inc. I/O interface cell for use with optional pad
US5896551A (en) * 1994-04-15 1999-04-20 Micron Technology, Inc. Initializing and reprogramming circuitry for state independent memory array burst operations control
US5600845A (en) * 1994-07-27 1997-02-04 Metalithic Systems Incorporated Integrated circuit computing device comprising a dynamically configurable gate array having a microprocessor and reconfigurable instruction execution means and method therefor
US5798719A (en) * 1994-07-29 1998-08-25 Discovision Associates Parallel Huffman decoder
US5513366A (en) * 1994-09-28 1996-04-30 International Business Machines Corporation Method and system for dynamically reconfiguring a register file in a vector processor
US5619720A (en) * 1994-10-04 1997-04-08 Analog Devices, Inc. Digital signal processor having link ports for point-to-point communication
US5603005A (en) * 1994-12-27 1997-02-11 Unisys Corporation Cache coherency scheme for XBAR storage structure with delayed invalidates until associated write request is executed
JP3598139B2 (ja) * 1994-12-28 2004-12-08 株式会社日立製作所 データ処理装置
US5493239A (en) * 1995-01-31 1996-02-20 Motorola, Inc. Circuit and method of configuring a field programmable gate array
US5757207A (en) * 1995-03-22 1998-05-26 Altera Corporation Programmable logic array integrated circuit incorporating a first-in first-out memory
JP3391624B2 (ja) * 1995-03-31 2003-03-31 川崎マイクロエレクトロニクス株式会社 回路システム
US6077315A (en) * 1995-04-17 2000-06-20 Ricoh Company Ltd. Compiling system and method for partially reconfigurable computing
JP3948494B2 (ja) * 1995-04-28 2007-07-25 ザイリンクス,インコーポレイテッド プログラム可能論理装置によってアクセス可能な分散レジスタを有するマイクロプロセサ
GB9508931D0 (en) * 1995-05-02 1995-06-21 Xilinx Inc Programmable switch for FPGA input/output signals
US5600597A (en) * 1995-05-02 1997-02-04 Xilinx, Inc. Register protection structure for FPGA
JP3677315B2 (ja) * 1995-06-01 2005-07-27 シャープ株式会社 データ駆動型情報処理装置
US5671432A (en) * 1995-06-02 1997-09-23 International Business Machines Corporation Programmable array I/O-routing resource
ZA965340B (en) * 1995-06-30 1997-01-27 Interdigital Tech Corp Code division multiple access (cdma) communication system
US5889982A (en) * 1995-07-01 1999-03-30 Intel Corporation Method and apparatus for generating event handler vectors based on both operating mode and event type
US5784313A (en) * 1995-08-18 1998-07-21 Xilinx, Inc. Programmable logic device including configuration data or user data memory slices
US5734869A (en) * 1995-09-06 1998-03-31 Chen; Duan-Ping High speed logic circuit simulator
US5642058A (en) * 1995-10-16 1997-06-24 Xilinx , Inc. Periphery input/output interconnect structure
US5608342A (en) * 1995-10-23 1997-03-04 Xilinx, Inc. Hierarchical programming of electrically configurable integrated circuits
US5943242A (en) * 1995-11-17 1999-08-24 Pact Gmbh Dynamically reconfigurable data processing system
US5732209A (en) * 1995-11-29 1998-03-24 Exponential Technology, Inc. Self-testing multi-processor die with internal compare points
CA2166369C (en) * 1995-12-29 2004-10-19 Robert J. Blainey Method and system for determining inter-compilation unit alias information
US7266725B2 (en) * 2001-09-03 2007-09-04 Pact Xpp Technologies Ag Method for debugging reconfigurable architectures
US5898602A (en) * 1996-01-25 1999-04-27 Xilinx, Inc. Carry chain circuit with flexible carry function for implementing arithmetic and logical functions
US5635851A (en) * 1996-02-02 1997-06-03 Xilinx, Inc. Read and writable data bus particularly for programmable logic devices
US5727229A (en) * 1996-02-05 1998-03-10 Motorola, Inc. Method and apparatus for moving data in a parallel processor
US6020758A (en) * 1996-03-11 2000-02-01 Altera Corporation Partially reconfigurable programmable logic device
US6173434B1 (en) * 1996-04-22 2001-01-09 Brigham Young University Dynamically-configurable digital processor using method for relocating logic array modules
US5894565A (en) * 1996-05-20 1999-04-13 Atmel Corporation Field programmable gate array with distributed RAM and increased cell utilization
EP0978051A1 (de) * 1996-06-21 2000-02-09 Mirage Technologies, Inc. Dynamisch rekonfigurierbares hardwaresystem zur echtzeitsteuerung von prozessen
US6023742A (en) * 1996-07-18 2000-02-08 University Of Washington Reconfigurable computing architecture for providing pipelined data paths
US6023564A (en) * 1996-07-19 2000-02-08 Xilinx, Inc. Data processing system using a flash reconfigurable logic device as a dynamic execution unit for a sequence of instructions
US6624658B2 (en) * 1999-02-04 2003-09-23 Advantage Logic, Inc. Method and apparatus for universal program controlled bus architecture
US5859544A (en) * 1996-09-05 1999-01-12 Altera Corporation Dynamic configurable elements for programmable logic devices
US6049866A (en) * 1996-09-06 2000-04-11 Silicon Graphics, Inc. Method and system for an efficient user mode cache manipulation using a simulated instruction
JP3934710B2 (ja) * 1996-09-13 2007-06-20 株式会社ルネサステクノロジ マイクロプロセッサ
US6178494B1 (en) * 1996-09-23 2001-01-23 Virtual Computer Corporation Modular, hybrid processor and method for producing a modular, hybrid processor
US5895487A (en) * 1996-11-13 1999-04-20 International Business Machines Corporation Integrated processing and L2 DRAM cache
US5913925A (en) * 1996-12-16 1999-06-22 International Business Machines Corporation Method and system for constructing a program including out-of-order threads and processor and method for executing threads out-of-order
US6338106B1 (en) * 1996-12-20 2002-01-08 Pact Gmbh I/O and memory bus system for DFPS and units with two or multi-dimensional programmable cell architectures
DE19654595A1 (de) * 1996-12-20 1998-07-02 Pact Inf Tech Gmbh I0- und Speicherbussystem für DFPs sowie Bausteinen mit zwei- oder mehrdimensionaler programmierbaren Zellstrukturen
DE19654593A1 (de) * 1996-12-20 1998-07-02 Pact Inf Tech Gmbh Umkonfigurierungs-Verfahren für programmierbare Bausteine zur Laufzeit
DE19704044A1 (de) * 1997-02-04 1998-08-13 Pact Inf Tech Gmbh Verfahren zur automatischen Adressgenerierung von Bausteinen innerhalb Clustern aus einer Vielzahl dieser Bausteine
US5865239A (en) * 1997-02-05 1999-02-02 Micropump, Inc. Method for making herringbone gears
DE19704728A1 (de) * 1997-02-08 1998-08-13 Pact Inf Tech Gmbh Verfahren zur Selbstsynchronisation von konfigurierbaren Elementen eines programmierbaren Bausteines
US5884075A (en) * 1997-03-10 1999-03-16 Compaq Computer Corporation Conflict resolution using self-contained virtual devices
GB2323188B (en) * 1997-03-14 2002-02-06 Nokia Mobile Phones Ltd Enabling and disabling clocking signals to elements
US6035371A (en) * 1997-05-28 2000-03-07 3Com Corporation Method and apparatus for addressing a static random access memory device based on signals for addressing a dynamic memory access device
US6011407A (en) * 1997-06-13 2000-01-04 Xilinx, Inc. Field programmable gate array with dedicated computer bus interface and method for configuring both
US6058266A (en) * 1997-06-24 2000-05-02 International Business Machines Corporation Method of, system for, and computer program product for performing weighted loop fusion by an optimizing compiler
US5966534A (en) * 1997-06-27 1999-10-12 Cooke; Laurence H. Method for compiling high level programming languages into an integrated processor with reconfigurable logic
US6072348A (en) * 1997-07-09 2000-06-06 Xilinx, Inc. Programmable power reduction in a clock-distribution circuit
US6026478A (en) * 1997-08-01 2000-02-15 Micron Technology, Inc. Split embedded DRAM processor
US6170051B1 (en) * 1997-08-01 2001-01-02 Micron Technology, Inc. Apparatus and method for program level parallelism in a VLIW processor
US6078736A (en) * 1997-08-28 2000-06-20 Xilinx, Inc. Method of designing FPGAs for dynamically reconfigurable computing
US6038656A (en) * 1997-09-12 2000-03-14 California Institute Of Technology Pipelined completion for asynchronous communication
JP3719570B2 (ja) * 1997-10-20 2005-11-24 株式会社パワーシステム 電気二重層コンデンサ
US6212544B1 (en) * 1997-10-23 2001-04-03 International Business Machines Corporation Altering thread priorities in a multithreaded processor
US5915123A (en) * 1997-10-31 1999-06-22 Silicon Spice Method and apparatus for controlling configuration memory contexts of processing elements in a network of multiple context processing elements
JPH11147335A (ja) * 1997-11-18 1999-06-02 Fuji Xerox Co Ltd 描画処理装置
US6075935A (en) * 1997-12-01 2000-06-13 Improv Systems, Inc. Method of generating application specific integrated circuits using a programmable hardware architecture
JP3878307B2 (ja) * 1997-12-19 2007-02-07 松下電器産業株式会社 プログラマブルなデータ処理装置
DE19861088A1 (de) * 1997-12-22 2000-02-10 Pact Inf Tech Gmbh Verfahren zur Reparatur von integrierten Schaltkreisen
US6172520B1 (en) * 1997-12-30 2001-01-09 Xilinx, Inc. FPGA system with user-programmable configuration ports and method for reconfiguring the FPGA
US6034538A (en) * 1998-01-21 2000-03-07 Lucent Technologies Inc. Virtual logic system for reconfigurable hardware
DE19807872A1 (de) * 1998-02-25 1999-08-26 Pact Inf Tech Gmbh Verfahren zur Verwaltung von Konfigurationsdaten in Datenflußprozessoren sowie Bausteinen mit zwei- oder mehrdimensionalen programmierbaren Zellstruktur (FPGAs, DPGAs, o. dgl.
US6052524A (en) * 1998-05-14 2000-04-18 Software Development Systems, Inc. System and method for simulation of integrated hardware and software components
US6173419B1 (en) * 1998-05-14 2001-01-09 Advanced Technology Materials, Inc. Field programmable gate array (FPGA) emulator for debugging software
JP3123977B2 (ja) * 1998-06-04 2001-01-15 日本電気株式会社 プログラマブル機能ブロック
US6202182B1 (en) * 1998-06-30 2001-03-13 Lucent Technologies Inc. Method and apparatus for testing field programmable gate arrays
US7100026B2 (en) * 2001-05-30 2006-08-29 The Massachusetts Institute Of Technology System and method for performing efficient conditional vector operations for data parallel architectures involving both input and conditional vector values
JP3551353B2 (ja) * 1998-10-02 2004-08-04 株式会社日立製作所 データ再配置方法
US6249756B1 (en) * 1998-12-07 2001-06-19 Compaq Computer Corp. Hybrid flow control
WO2000034858A2 (en) * 1998-12-11 2000-06-15 Microsoft Corporation Accelerating a distributed component architecture over a network using a modified rpc communication
US6694434B1 (en) * 1998-12-23 2004-02-17 Entrust Technologies Limited Method and apparatus for controlling program execution and program distribution
JP3142268B2 (ja) * 1999-02-23 2001-03-07 株式会社エイ・ティ・アール環境適応通信研究所 通信サービス品質制御方法及び装置
US6191614B1 (en) * 1999-04-05 2001-02-20 Xilinx, Inc. FPGA configuration circuit including bus-based CRC register
US6512804B1 (en) * 1999-04-07 2003-01-28 Applied Micro Circuits Corporation Apparatus and method for multiple serial data synchronization using channel-lock FIFO buffers optimized for jitter
US6341347B1 (en) * 1999-05-11 2002-01-22 Sun Microsystems, Inc. Thread switch logic in a multiple-thread processor
US6211697B1 (en) * 1999-05-25 2001-04-03 Actel Integrated circuit that includes a field-programmable gate array and a hard gate array having the same underlying structure
US6347346B1 (en) * 1999-06-30 2002-02-12 Chameleon Systems, Inc. Local memory unit system with global access for use on reconfigurable chips
US6745317B1 (en) * 1999-07-30 2004-06-01 Broadcom Corporation Three level direct communication connections between neighboring multiple context processing elements
US6341318B1 (en) * 1999-08-10 2002-01-22 Chameleon Systems, Inc. DMA data streaming
US6972798B1 (en) * 1999-08-31 2005-12-06 Canon Kabushiki Kaisha Focusing device and method
US6349346B1 (en) * 1999-09-23 2002-02-19 Chameleon Systems, Inc. Control fabric unit including associated configuration memory and PSOP state machine adapted to provide configuration address to reconfigurable functional unit
JP2001167066A (ja) * 1999-12-08 2001-06-22 Nec Corp プロセッサ間通信方法及びマルチプロセッサシステム
US6625654B1 (en) * 1999-12-28 2003-09-23 Intel Corporation Thread signaling in multi-threaded network processor
US6519674B1 (en) * 2000-02-18 2003-02-11 Chameleon Systems, Inc. Configuration bits layout
US6845445B2 (en) * 2000-05-12 2005-01-18 Pts Corporation Methods and apparatus for power control in a scalable array of processor elements
US6725334B2 (en) * 2000-06-09 2004-04-20 Hewlett-Packard Development Company, L.P. Method and system for exclusive two-level caching in a chip-multiprocessor
ATE476700T1 (de) * 2000-06-13 2010-08-15 Richter Thomas Pipeline ct-protokolle und -kommunikation
US7164422B1 (en) * 2000-07-28 2007-01-16 Ab Initio Software Corporation Parameterized graphs with conditional components
EP1182559B1 (de) * 2000-08-21 2009-01-21 Texas Instruments Incorporated Mikroprozessor
JP2002108702A (ja) * 2000-10-03 2002-04-12 Hitachi Ltd マイクロコンピュータ及びデータ処理装置
US20040015899A1 (en) * 2000-10-06 2004-01-22 Frank May Method for processing data
US20020087828A1 (en) * 2000-12-28 2002-07-04 International Business Machines Corporation Symmetric multiprocessing (SMP) system with fully-interconnected heterogenous microprocessors
JP3501761B2 (ja) * 2001-01-30 2004-03-02 株式会社半導体理工学研究センター 大規模データパス・アーキテクチャの実行機構
US6976239B1 (en) * 2001-06-12 2005-12-13 Altera Corporation Methods and apparatus for implementing parameterizable processors and peripherals
JP2004533691A (ja) * 2001-06-20 2004-11-04 ペーアーツェーテー イクスペーペー テクノロジーズ アクチエンゲゼルシャフト データを処理するための方法
JP3580785B2 (ja) * 2001-06-29 2004-10-27 株式会社半導体理工学研究センター ルックアップテーブル、ルックアップテーブルを備えるプログラマブル論理回路装置、および、ルックアップテーブルの構成方法
US7036114B2 (en) * 2001-08-17 2006-04-25 Sun Microsystems, Inc. Method and apparatus for cycle-based computation
US7472230B2 (en) * 2001-09-14 2008-12-30 Hewlett-Packard Development Company, L.P. Preemptive write back controller
US7000161B1 (en) * 2001-10-15 2006-02-14 Altera Corporation Reconfigurable programmable logic system with configuration recovery mode
US20030108046A1 (en) * 2001-12-06 2003-06-12 Simeone John B. Interface device
WO2005010632A2 (en) * 2003-06-17 2005-02-03 Pact Xpp Technologies Ag Data processing device and method
WO2004021176A2 (de) * 2002-08-07 2004-03-11 Pact Xpp Technologies Ag Verfahren und vorrichtung zur datenverarbeitung
US6976131B2 (en) * 2002-08-23 2005-12-13 Intel Corporation Method and apparatus for shared cache coherency for a chip multiprocessor or multiprocessor system
US7571303B2 (en) * 2002-10-16 2009-08-04 Akya (Holdings) Limited Reconfigurable integrated circuit
US7155708B2 (en) * 2002-10-31 2006-12-26 Src Computers, Inc. Debugging and performance profiling using control-dataflow graph representations with reconfigurable hardware emulation
US7299458B2 (en) * 2002-10-31 2007-11-20 Src Computers, Inc. System and method for converting control flow graph representations to control-dataflow graph representations
US7873811B1 (en) * 2003-03-10 2011-01-18 The United States Of America As Represented By The United States Department Of Energy Polymorphous computing fabric
US7412581B2 (en) * 2003-10-28 2008-08-12 Renesas Technology America, Inc. Processor for virtual machines and method therefor
US7299339B2 (en) * 2004-08-30 2007-11-20 The Boeing Company Super-reconfigurable fabric architecture (SURFA): a multi-FPGA parallel processing architecture for COTS hybrid computing framework
US20060112226A1 (en) * 2004-11-19 2006-05-25 Hady Frank T Heterogeneous processors sharing a common cache

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None *

Also Published As

Publication number Publication date
WO2004088502A3 (de) 2005-01-13
WO2004088502A2 (de) 2004-10-14
JP2006524850A (ja) 2006-11-02
US20100122064A1 (en) 2010-05-13
DE112004000026D2 (de) 2006-06-14
US20070011433A1 (en) 2007-01-11

Similar Documents

Publication Publication Date Title
DE112005000706B4 (de) Verfahren und System zum Bereitstellen von Multi-Threading auf Nutzerebene
DE60002200T2 (de) Umschaltungsverfahren in einem multithreadprozessor
DE60013115T2 (de) Prozessor mit vertikal-threaded pipeline mit mehreren thread und betriebsverfahren dafür
DE60005002T2 (de) Vertikal-threaded prozessor mit multidimensionalem speicher
DE112011100743B4 (de) Datenverarbeitungsvorrichtung und -verfahren zum Übertragen einer Arbeitslast zwischen Quell- und Zielverarbeitungsschaltkreisen
DE102010034555A1 (de) Bereitstellen von Zustandsspeicher in einem Prozessor für Systemmanagement-Modus
DE112005002672B4 (de) Dynamische Neukonfiguration eines Cache-Speichers
DE69727773T2 (de) Verbesserte Verzweigungsvorhersage in einem Pipelinemikroprozessor
DE112017000721T5 (de) Verfahren, einrichtung und befehle für thread-aussetzung auf benutzerebene
CN100555227C (zh) 用于控制多内核处理器的方法
DE102018130441A1 (de) Einrichtung, Verfahren und Systeme mit konfigurierbarem räumlichem Beschleuniger
DE102008062692B4 (de) Eingebettetes Mikrocontrollersystem und Verfahren zur Konfiguration eines eingebetteten Mikrocontrollersystems mit gesteuertem Schaltmodus
DE112013004751T5 (de) Prozessor mit mehreren Kernen, gemeinsam genutzter Kernerweiterungslogik und gemeinsam genutzten Kernerweiterungsnutzungsbefehlen
DE102014003671A1 (de) Prozessoren, verfahren und systeme zum entspannen der synchronisation von zugriffen auf einen gemeinsam genutzten speicher
DE112011100715T5 (de) Hardware-hilfs-thread
DE60316774T2 (de) Verkettung von mehrfadenprozessorkernen zur bearbeitung von datenpaketen
US20100122064A1 (en) Method for increasing configuration runtime of time-sliced configurations
DE112015004983T5 (de) Parallel-Slice-Prozessor mit einer Lade-Speicher-Umlaufwarteschlange für eine schnelle Freigabe von Einträgen in einer Ausgabewarteschlange
WO2004021176A2 (de) Verfahren und vorrichtung zur datenverarbeitung
DE102015002383A1 (de) Verfahren und Vorrichtung zum Implementieren einer dynamischen Out-of-order-Prozessorpipeline
DE112010005821T5 (de) Kontextwechsel
DE102012216567A1 (de) Verwalten eines register-cachespeichers auf grundlage eines architekturdefinierten computeranweisungssatzes
DE112013000654T5 (de) Verzweigungsvorhersagelogik
DE10297596T5 (de) Verfahren und Vorrichtung zum Suspendieren der Ausführung eines Threads, bis ein spezifizierter Speicherzugriff auftritt
DE112012005058T5 (de) Variablenübertragungsnetzwerk mit geringer Latenzzeit für feingranulierte Parallelität virtueller Threads zwischen mehreren Hardware-Threads

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20050907

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL HR LT LV MK

DAX Request for extension of the european patent (deleted)
RIN1 Information on inventor provided before grant (corrected)

Inventor name: VORBACH, MARTIN

17Q First examination report despatched

Effective date: 20080905

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: RICHTER, THOMAS

Owner name: KRASS, MAREN

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: PACT XPP TECHNOLOGIES AG

111L Licence recorded

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR

Name of requester: XILINX, INC., US

Effective date: 20141010

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20181101