WO2003023616A2 - Verfahren zum debuggen rekonfigurierbarer architekturen - Google Patents

Verfahren zum debuggen rekonfigurierbarer architekturen Download PDF

Info

Publication number
WO2003023616A2
WO2003023616A2 PCT/DE2002/003278 DE0203278W WO03023616A2 WO 2003023616 A2 WO2003023616 A2 WO 2003023616A2 DE 0203278 W DE0203278 W DE 0203278W WO 03023616 A2 WO03023616 A2 WO 03023616A2
Authority
WO
WIPO (PCT)
Prior art keywords
debugging
information
debug
configuration
memory
Prior art date
Application number
PCT/DE2002/003278
Other languages
English (en)
French (fr)
Other versions
WO2003023616A3 (de
WO2003023616A8 (de
Inventor
Martin Vorbach
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
Priority claimed from US09/967,497 external-priority patent/US7266725B2/en
Priority to EP02772041A priority Critical patent/EP1449083B1/de
Priority to AU2002336896A priority patent/AU2002336896A1/en
Priority to US10/487,687 priority patent/US7480825B2/en
Priority to DE10297719T priority patent/DE10297719D2/de
Priority to DE50210212T priority patent/DE50210212D1/de
Application filed by Pact Xpp Technologies Ag filed Critical Pact Xpp Technologies Ag
Priority to AU2002338729A priority patent/AU2002338729A1/en
Priority to EP02777144A priority patent/EP1466264B1/de
Priority to PCT/EP2002/010479 priority patent/WO2003025781A2/de
Priority to AU2002357982A priority patent/AU2002357982A1/en
Priority to EP02791644A priority patent/EP1472616B8/de
Priority to PCT/EP2002/010572 priority patent/WO2003036507A2/de
Priority to JP2003538928A priority patent/JP4456864B2/ja
Priority to AT02791644T priority patent/ATE533111T1/de
Publication of WO2003023616A2 publication Critical patent/WO2003023616A2/de
Priority to PCT/DE2003/000942 priority patent/WO2003081454A2/de
Priority to US10/508,559 priority patent/US20060075211A1/en
Priority to EP03720231A priority patent/EP1518186A2/de
Priority to AU2003223892A priority patent/AU2003223892A1/en
Priority to EP03776856.1A priority patent/EP1537501B1/de
Priority to AU2003286131A priority patent/AU2003286131A1/en
Priority to PCT/EP2003/008081 priority patent/WO2004021176A2/de
Priority to PCT/EP2003/008080 priority patent/WO2004015568A2/en
Priority to JP2005506110A priority patent/JP2005535055A/ja
Priority to AU2003260323A priority patent/AU2003260323A1/en
Priority to EP03784053A priority patent/EP1535190B1/de
Priority to US10/523,764 priority patent/US8156284B2/en
Publication of WO2003023616A8 publication Critical patent/WO2003023616A8/de
Publication of WO2003023616A3 publication Critical patent/WO2003023616A3/de
Priority to US12/247,076 priority patent/US8209653B2/en
Priority to US12/354,590 priority patent/US8069373B2/en
Priority to US12/570,943 priority patent/US8914590B2/en
Priority to US12/621,860 priority patent/US8281265B2/en
Priority to JP2009271120A priority patent/JP2010079923A/ja
Priority to US12/729,090 priority patent/US20100174868A1/en
Priority to US12/729,932 priority patent/US20110161977A1/en
Priority to US12/947,167 priority patent/US20110238948A1/en
Priority to US13/023,796 priority patent/US8686475B2/en
Priority to US13/279,561 priority patent/US8407525B2/en
Priority to US13/796,215 priority patent/US20130339797A1/en
Priority to US14/162,704 priority patent/US20140143509A1/en
Priority to US14/540,782 priority patent/US20150074352A1/en
Priority to US14/923,702 priority patent/US10579584B2/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/26—Functional testing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3648—Software debugging using additional hardware
    • G06F11/3656—Software debugging using additional hardware using a specific debug interface
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/26—Functional testing
    • G06F11/267—Reconfiguring circuits for testing, e.g. LSSD, partitioning

Definitions

  • the present invention is concerned with methods for debugging programs on configurable architectures.
  • a reconfigurable architecture u. a.
  • Modules (VPU) with configurable function and / or networking understood, in particular integrated modules with a plurality of one- or multi-dimensionally arranged arithmetic and / or logical and / or analog and / or storing and / or networking modules (hereinafter referred to as PAEs) ) and / or communicative / peripheral modules (10), which are connected to one another directly or by one or more bus system (s).
  • PAEs are arranged in any configuration, mix and hierarchy. This arrangement is referred to in the rest of the PAE array or PA.
  • modules include systolic arrays, neural networks, multiprocessor systems, processors with several arithmetic units and / or logical cells, networking and network modules such as crossbar switches, as well as known modules of the FPGA, DPGA, XPUTER, etc
  • the object of the present invention is to provide something new for commercial use.
  • debugging is carried out either by using a microcontroller correspondingly connected to a VPU or the module, or by charging logic according to the patents P 44 16 881.0-53, DE 196 51 075.9-53, DE 196 54 846.2-53, DE 196 54 593.5-53, DE 197 57 200.6-33, DE 198 07 872.2, DE 101 39 170.6, DE 199 26 538.0, DE 100 28 397.7, which are fully incorporated by reference.
  • other hardware variants can also be used. The following basic procedures should alternatively and / or be used together:
  • the programmer defines, for example, one or more conditions within the debug tool that start debugging (cf. breakpoint according to the prior art).
  • the occurrence of the conditions is determined at runtime in the VPU and / or in any device that exchanges data with the VPU. This happens, for example, through the occurrence of certain data values for certain variables and / or certain trigger values for certain PAEs.
  • Method A For compilers that generate code based on instantiated modules of a hardware description language (or similar language), this can be particularly useful Method A described below are suitable.
  • Method B described below is particularly suitable for compilers similar to DE 101 39 170.6 and additional applications that generate complex instructions and generate them according to a VLIW-like method. In principle, method B is required for operating a VPU or a corresponding module as a processor or coprocessor the preferred one.
  • debugging can first be carried out using the fast debugging method B and, after the error has been adequately localized, method A can then be used to analyze the details in depth.
  • a debug processor for example a CT or loading logic, another externally connected (host) processor or a reserved array area, the internal Read back data registers and / or status registers and / or status registers and, depending on the implementation, further relevant registers and / or signals from the PAEs and / or the network or do this only for selected registers or signals (summarized below as Debug information).
  • DB debug processor
  • Such a possibility is e.g. B. with the connection created in PCT / DE 98/00334 between the
  • Charging logic and the data bus of a PAE (PCT / DE 98/00334 0403, Fig. 4) can be implemented.
  • serial methods can also be used to read the registers.
  • JTAG can be selected and the DB can also be connected via this method, if necessary, as an external separate and possibly also commercially available device (e.g. company Hitex, Düsseldorf).
  • registers can preferably be accessed by the debugger for writing and / or reading, optionally and preferably a substantial part of the (serial) chaining of the registers for test purposes (scan chain) for the production tests of the
  • the scan chain is normally used to preload all registers within a chip with test data during production tests and / or read the contents of the register back for test purposes.
  • the preloading and / or reading back is typically done by test systems (eg SZ Test Systems, Amerang) and / or according to the methods described in DE 197 57 200.6-33.
  • test systems eg SZ Test Systems, Amerang
  • the scan chain requires additional, not inconsiderable, hardware and space requirements for each register. This can now be omitted, at least for the registers that can be debugged, if - as proposed according to the invention - the production test systems have access to the registers via suitable interfaces (for example parallel, serial, JTAG, etc.).
  • the cycle can either be stopped or slowed down in order to provide sufficient time for reading out.
  • This start of debugging is triggered either directly by a PAE which calculates the (pre) condition (s) or by a higher-level unit (e.g. loading logic / CT, host processor) based on any actions, for example by the information that a PAE a (pre) condition occurred and / or by an action within the debug processor and / or by any program and / or any external / peripheral source.
  • a PAE which calculates the (pre) condition (s) or by a higher-level unit (e.g. loading logic / CT, host processor) based on any actions, for example by the information that a PAE a (pre) condition occurred and / or by an action within the debug processor and / or by any program and / or any external / peripheral source.
  • trigger mechanisms corresponding to P 44 16 881.0-53, DE 196 51 075.9-53, DE 197 04 728.9, DE 198 07 872.2, DE 198 09 640.2, DE 100 28 397.7 are available.
  • the clock can generally be slowed down when debugging. If only parts of the array are to be debugged, a partial downclocking can be provided. If the clock is slowed down, all relevant debug information must be read from the PAEs by the debug processor within the slowed down cycle of the processing clock. For this purpose, it is sensible and preferred to slow down the clock rate only in part, ie to reduce or stop the clock rate, but to continue the clock cycle for the readout mechanism. Furthermore, it is sensible and preferred to generally supply the registers with clocks for data retention.
  • the debug processor stops the processing clock until it has read all the debug information. Then it starts the processing cycle again for one cycle and stops it again until all relevant debug information has been read out.
  • the reading clock and the clock of the debug processor are preferably independent of the processing clock of the PAEs, so that data processing is separate from debugging and, in particular, reading out the debug information.
  • the clock is stopped or slowed down by methods according to the prior art, such as, for example, gated clocks and / or PLLs and / or dividers or other methods. These means are preferably inserted at suitable points (nodes) within the clock tree, so that global clock control of the respective lower branches can be implemented. Downclocking only selected portions of the array is disclosed in the referenced applications of the present applicant.
  • clock control information from a higher-level unit (for example, charging station gik / CT, host processor) to all or all of the PAEs to be debugged. This can preferably be done via the configuration bus system.
  • the clock control information is typically broadcast broadcast, ie all PAEs receive the same information.
  • clock control information can be implemented:
  • STEP Exactly one processing step (single step mode) is carried out and then the work cycle is stopped again.
  • GO The work cycle continues as normal.
  • the method of clock shutdown and / or deceleration can also be used to reduce the power consumption.
  • a "sleep mode" can be implemented, for example, by switching off the operating cycle (STOP) or using special commands (SLEEP).
  • STOP operating cycle
  • SLEEP special commands
  • the clock can be slowed down by using SLOW and / or temporarily suspended by STEP (s).
  • the method can be used optionally and / or in addition to the methods described in DE 102 06 653.1 for reducing the power loss.
  • a problem with broadcasting clock control information is the transmission time of the broadcast through the array PAEs. At higher clock frequencies, the transmission cannot take place within one work cycle. However, it is imperative that all PAEs react to the clock control information at the same time.
  • the clock control information is therefore preferably transmitted via a pipelined bus system similar to the CT bus system described in DE 100 28 397.7.
  • a numerical value (LATVAL) is added to the clock control information, which is equal to or greater than the maximum length of the pipeline of the bus system. In each pipeline stage, the numerical value is decremented in cycles (subtraction from 1).
  • Each PAE that receives the clock control information further decrements the numerical value with each clock.
  • the described method creates a further latency.
  • This can, for example, be intercepted additionally by the register pipeline described below, or, as is particularly preferred, intercepted by defining the (pre) condition by presetting the (pre) condition to such an extent that the latency time has already been taken into account.
  • the latency in single-step mode is negligible, since it only plays a role in switching off the clock (STOP). Since the STEP command only executes one step at a time, it occurs during single-step operation due to no falsification (delay) of the debug data due to the latency.
  • the latency shifts the information made available to the debug processor in such a way that the correct debug information can no longer be read out.
  • This is preferably solved by the programmer setting the (pre) condition accordingly.
  • the debug processor can access as many cycles of debug information as the register pipeline is long.
  • the length of the register pipeline must be designed so that it corresponds to the maximum expected latency. Due to the exact predictability of the latency, it is now possible for the debug program to read the correct, relevant debug information from the register pipeline.
  • debugging occurs essentially after the (pre-) condition occurs, since only then the clock is slowed down or stopped and the debug information is read out. Debug information that is prior to the occurrence of the (precondition) condition is therefore initially not visible.
  • Different data and / or states are stored in the storage units in such a way that they can be clearly assigned to the algorithm. This enables the debugger to clearly identify the relevant data and / or states (debug information).
  • the relevant debug information can be specified by the programmer within the debug program, especially in advance. This debug information is read from the storage units. Different methods are available for this; some options are described in more detail below. After reading out all relevant debug information, the next configuration cycle and the relevant debug information read out again. This is repeated until the programmer / debugger cancels the debugging process.
  • the relevant data and / or status information is transmitted to the debugger rather than in cycles, but rather in configurations. This is done from the memory units that are comparable to the registers of a CPU.
  • the debugger is the ability to read the internal working memory of the VPU, for example, by the CT or another externally connected processor (hereinafter referred to as the debug processor (DB)).
  • the CT or another externally connected processor
  • DB debug processor
  • Such a possibility is e.g. by connecting the CT to the main memory for preloading and reading the data and / or by using the one described in DE 199 26 538.0
  • working memory can be accessed by the debug processor using various state-of-the-art methods (e.g. shared memory, bank switching) in such a way that the data exchange with the DB can take place largely independently of any further data processing in the VPU.
  • state-of-the-art methods e.g. shared memory, bank switching
  • the clock of the VPU for reading out the memories may be either slowed down or stopped and / or possibly operated in single-step mode by one or more of the measures described above become.
  • the working memory e.g. B. in the bank switch process
  • a special intervention in the clock can be dispensed with.
  • the clock is stopped or slowed down according to method B and the reading and / or copying and / or switching of the working memory only takes place when a data processing cycle or configuration cycle has ended.
  • Method B a major advantage of Method B is that no special hardware support is required.
  • a DB only needs to have access to the working memory.
  • the access to the working memory takes place through a suitable configuration of the VPU, which thereby reads the working memory independently and without modification and transfers it to a DB.
  • P 44 16 881.0-53, DE 196 54 846.2-53, DE 101 39 170.6, DE 199 26 538.0 describe data processing methods in which a number of operations are cyclically mapped to a reconfigurable data processing module. A plurality of data is calculated in each cycle, which originate from a peripheral source and / or an internal / external working memory and are written to a peripheral source and / or an internal / external working memory. Different and / or above all several independent working memories can be used simultaneously. For example, in this data processing drive the working memory or part of the working memory serve as a register set.
  • the status information of a comparison is essential, for example, for the further processing of the data, since this determines the functions to be carried out.
  • a sequential divider is created, for example, by mapping a division command onto hardware that only supports sequential division. This creates a state that identifies the calculation step within the division. This state is irrelevant since the algorithm only requires the result (ie the division performed). In this case, only the result and the time information (i.e. availability) are required.
  • the time information is available, for example, in the VPU technology according to P 44 16 881.0-53, DE 196 51 075.9-53, DE 199 26 538.0 through the RDY / ACK handshake. It should be noted, however, that the handshake also does not represents the current state, since it only signals the validity of the data, which in turn reduces the remaining relevant information to the existence of valid data.
  • the status is only relevant within a single completed configuration. Therefore, the status does not have to be saved.
  • global The status information is required for several configurations. The status must be saved.
  • the programmer wants to debug a locally relevant state that is not stored in the memories.
  • the application can be modified in such a way that a debug configuration is created (equivalent to the debug code of processors), which has a modification to the "normal" code of the application in such a way that this state is also written into the memory unit and so that it is made available to the debugger.
  • no debug configuration is used. Rather, the configuration to be debugged is terminated in such a way that the data additionally required for debugging purposes survive the termination, ie continue to remain valid in the corresponding memory locations (REG) (eg registers, counters, memory). If the configuration to be debugged is terminated in such a way that the additional data required for debugging purposes survive the termination, it is possible to carry out debugging simply by not loading the next configuration required in normal program execution, but instead a configuration, Via which the data required for debugging purposes are transferred to the debug unit or the debugging means.
  • REG memory locations
  • a configuration is loaded, this connects the REG in a suitable and defined sequence with one or more global memory (s) to which the DB has access (e.g. main memory).
  • s global memory
  • a configuration be loaded, that it connects the REG in a suitable manner and connects it in a defined order with one or more global memories to which the DB has access (eg main memory).
  • the configuration can use address generators, for example, to access the global memory (s).
  • the configuration can use address generators, for example, to access REGs configured as memories. According to the configured connection between the REG The contents of the REG are written to the global memory in a defined order, the respective addresses being specified by address generators.
  • the address generator generates the addresses for the global memory (s) in such a way that the described memory areas (DEBUGINFO) can be uniquely assigned to the remote configuration to be debugged.
  • the method corresponds to the context switch in DE 102 06 653.1 and DE 101 39 170.6, which are fully incorporated for disclosure purposes.
  • the DB can now access the data within a memory area accessible to it (DEBUGINFO).
  • DEBUGINFO a memory area accessible to it
  • a context switch can be carried out after each single step of a configuration to be debugged in such a way that all data is retained and the information to be debugged is written from the REG to a working memory. Then the configuration to be debugged is again configured while receiving the data and carried out for a further single step. This happens for each single step of the configuration to be debugged. Attention is drawn to the possibility of debugging using the principles known as “wave reconfiguration”.
  • Debugging before the (pre) condition can be carried out comparatively easily and without major performance losses, since the required debug information is available in working memories.
  • the debug information can be easily secured.
  • An even faster method is to switch the working memory between the individual configurations using a bank switching method (according to the prior art) in such a way that the debug information is in a new bank in each case. Switching can be done in a very time-optimizing manner, ideally even without affecting the processing power.
  • the debugger program itself can run on a DB outside the PA.
  • a VPU can itself represent the DB, according to the methods used with processors.
  • a task or context switch (SWITCH) can be executed in accordance with the explanations in PACT11.
  • SWITCH task or context switch
  • the debug information of the program to be debugged is saved at SWITCH together with the relevant data and the debugger program is loaded, which evaluates the information and / or processes it interactively with the programmer. Then a SWITCH is carried out again (in which the relevant information of the debugger is saved) and the program to be debugged is continued.
  • a processor sub-area can be provided as a debugger.
  • the debug information is read by the debugger according to methods A and / or B and stored in a memory and / or memory area separate from the data processing, to which the DB preferably has direct access.
  • the breakpoints and (pre) conditions are defined by the debugger program.
  • the debugger program can also take control of the execution of the application, in particular the start and end of execution.
  • the debugger provides the programmer with a suitable working environment with a graphical user interface if necessary.
  • the debugger is integrated in a complex development environment and exchanges data and / or control information with it.
  • the debugger can save the data read from the working memories to a data carrier (hard disk, CDROM) for any further processing and / or run within a network (such as Ethernet).
  • the debugger according to the invention can also communicate with other tools and in particular also debuggers within a development environment; in a preferred embodiment, the control and / or definition of the debug parameters can be taken over by another debugger.
  • the debugger can make the debug information generated by it available to another debugger and / or receive its debug information from it.
  • the detection of the occurrence of breakpoints and / or (pre) condition can be carried out by another debugger or the units that this other debugger is debugging. The debugger according to the invention and the VPU then react accordingly.
  • the other debugger can in particular be the debugger of another processor coupled to a VPU (CT or ARC at Chameleon, Pentium, AMD etc.).
  • VPU CPU
  • ARC at Chameleon, Pentium, AMD etc.
  • the other debugger can run on a processor assigned and / or coupled to the VPU and / or the assigned processor can be the DB, for example a CT or ARC at Chameleon.
  • the assigned processor can be a host processor, as described, for example, in 60 / 317,876 and / or DE 102 06 856.9.
  • Method A is considerably more time and resource intensive than Method B, which hardly requires any additional hardware and, in addition, the time-consuming reading of the debug information from the start of the application may not be necessary. Method B is therefore generally preferable. Method B is clearly preferred for compilers according to DE 101 39 170.6 and their additional applications.
  • PREINFO visible debug information
  • POSTINFO visible debug information
  • a software simulator is started that simulates the configuration (s) to be debugged.
  • the simulator can determine and output any value within the PAEs " and the bus systems (possibly also graphically and / or textually), which gives a detailed insight into the sequence of the algorithm at the time the error occurs. In particular, it is possible to compare the simulated values with the values of POSTINFO in order to quickly recognize differences.
  • the mixed-mode debugger enables detailed analysis of the processes within a module.
  • the possibility according to method B of working at full speed up to a set breakpoint and then possibly stopping, slowing down and / or possibly going into a single-step mode makes debugging time-efficient, which makes testing large amounts of data and / or complex algorithms is made possible.
  • the preferred placement of a simulator after the breakpoint occurs on the basis of the current data and status enables a precise insight into the hardware.
  • Figures 1 and 2 correspond to patent application DE 101 39 170.6.
  • the different approaches of methods A and B were drawn in the figures (A, B)
  • Figure lb shows a representation of the finite automaton by a reconfigurable architecture according to P 44 16 881.0-53 and DE 196 54 846.2-53 (DE 196 54 846.2-53, Fig. 12-15).
  • the combinatorial network from FIG. 1a (0101) is replaced by an arrangement of PAEs 0107 (0101b).
  • the register (0102) is executed by a memory (0102b) which can store several cycles.
  • the feedback according to 0105 is carried out by 0105b.
  • the inputs (0103b or 0104b) are equivalent to 0103 or 0104. Direct access to 0102b can be realized via a bus through the array 0101b.
  • Output 0106b is again equivalent to 0106.
  • FIG. 2 shows the mapping of a finite automaton onto a reconfigurable architecture.
  • 0201 (x) represent the combinatorial network (which can be designed as PAEs according to FIG. 1b).
  • An address generator (0204, 0205) is assigned to each of the memories.
  • the operand and result memories (0202, 0203) are physically or virtually linked in such a way that, for example, the results of a function other than
  • Operands can serve and / or results and operands of one function of another can serve as operands.
  • Such a coupling can be established, for example, by bus systems or by a (re) configuration, by means of which the function and networking of the memories with the 0201 are reconfigured.
  • FIG. 3 shows a possible schematic structure of debugging using method B. Reference is made in particular to FIGS. 19, 20, 21 of patent application DE 199 26 538.0, in which the basis of the memory is described. DE 199 26 538.0 is hereby fully incorporated for the purposes of disclosure.
  • 0101b and 0102b are shown as already described.
  • an external memory unit is shown (0302), which may possibly be connected to 0102b (0307) similar to DE 199 26 538.0. It should be particularly noted that both 0102b and 0302 can be external or internal storage units.
  • a storage unit should also be defined as at least one register, a set of registers or a memory (RAM, flash, etc.) or mass storage (hard disk, tape, etc.).
  • Debugging unit 0301 can set breakpoints within 0101b (0303), on the basis of which the actual debugging process is triggered. When a breakpoint is reached, information (0304) is sent to 0301, which starts the debugging process; At the same time, all 0101b internal precautions for debugging (e.g. stopping and / or slowing down the clock) are triggered. Alternatively, the information can also be generated by 0301 and sent to 0101b.
  • 0301 can access the data and / or states from memory 0102b and / or memory 0302. Access can be, for example
  • a memory coupling block move, ie copying the memory into another area controlled by 0301
  • a line serial or parallel line via which one or more memory area (s) is / are transmitted, for example JTAG
  • Bus couplings of any kind are arbitrated in a manner similar to a DMA procedure and processed by 0301).
  • FIGS. 4a and 4b show further possible configurations and were taken from patent application DE 102 06 856.9, which is incorporated in full for the purposes of disclosure.
  • FIG. 4a The structure of a particularly preferred ' VPU is shown in Figure 4a.
  • CT's Preferably hierarchical configuration managers (CT's) (0401) control and manage an arrangement of reconfigurable elements (PACs) (0402).
  • a local memory for the configurations is assigned to the CT's (0403).
  • the memory also has an interface (0404) to a global memory that provides the configuration data.
  • the configuration process can be controlled via an interface (0405).
  • An interface of the reconfigurable elements (0402) for sequence control and event management (0406) is available, as is an interface for data exchange (0407).
  • one of the CTs can act as a DB.
  • FIG. 4b shows a section from an exemplary CPU system, for example a DSP of the type C6000 from Texas Instruments (0451).
  • Program memory (0452), data memory (0453), any peripherals (0454) and EMIF (0455) are shown.
  • a VPU is integrated as a coprocessor (0458) via a memory bus (0456) and a peripheral bus (0457).
  • a DMA controller (EDMA) (0459) can perform any DMA transfers, for example between memory (0453) and VPU (0458) or memory (0453) and peripherals (0454).
  • 0451 can work as a DB and, in particular, the debugger according to the invention can also be coupled to and / or integrated into its debugger.
  • FIG. 5a shows an exemplary hardware structure that can be used for debugging reconfigurable processors.
  • a pipelined configuration bus 0501 is used, similar to that known from DE 100 28 397.7.
  • the pipeline is constructed over several register stages (0502) in the horizontal and / or vertical direction in order to achieve higher clock frequencies.
  • the gepipelin 'te configuration bus resulting in the elements to be configured (PAEs) (0503) for this to be provided with configuration data.
  • FIG. 5b shows an example of the required expansion in accordance with the present invention.
  • Each register level (0502) decrements the numerical value (LATVAL) to compensate for the latency by 1 (indicated by -1).
  • each PAE (0503) that has already received clock control information decrements this by 1 (indicated by -1 / T) per clock.
  • the PAEs and in particular their internal registers can now be accessed not only for writing but also for reading, for example via a special control line (RD), in order to read out debug data. Data to be written and read is passed through in In this example, the bus system through the array of PAEs from left to right and in the bottom line in the reverse direction.
  • the configuration bus is still pipeline-like via register stages (0505) (0504).
  • a higher-level unit (CT / loading logic, host processor) (0506) can read and write the bus as well as a dedicated test interface (0507).
  • the test interface can have its own test controller and in particular be compatible with one or more test interfaces available on the market (eg JTAG, Tektronix, Rhode & Schwarz, etc.).
  • the bus controlling unit is selected using a multiplexer / demultiplexer unit (0508).
  • a circuit can be provided for the backward calculation of the origin address (0509) of debug data that arrive via 0504.
  • the address calculations within the system shown are done as follows: First the address is through
  • the address is decremented similarly to the processing of the numerical values (LATVAL) for latency calculation in each register level (0502 and O505). As soon as the address is 0, the PAE after the register level is selected. In the subsequent register level, the address becomes negative, so that no further PAEs are activated. If data is read from a PAE, it will be transferred back together with the address. The address is decremented further in each register level. A retroactive calculation in 0509 or 0506 and / or
  • register stages 0502 in FIG. 5b are slightly different from register stages 0502 in FIG. 5a. are. In FIG. 5b, these additionally have a circuit (eg multiplexer) for selecting the data to be forwarded, which either switches the data of the bus 0501 on or the output of the assigned PAE (0503) and thus the debug data.
  • the address value 0 can be used to control the circuit.
  • the dedicated test interface (0507) corresponds to the industry standards. It can be used for tests during the software debugging process and / or for tests during the assembly of hardware components and systems (e.g. the assembly of the circuits on the board) and / or for functional tests of the semiconductor module (chips) in the context of semiconductor production , In particular, this allows the usual scan chain to test the
  • Registers during the functional test of the semiconductor are omitted or at least minimized accordingly, since only those registers that cannot be controlled by the bus system (0501) then have to be guided through the scan chain.
  • Irrelevant state State that is irrelevant for the actual algorithm and is also not described in the algorithm, but which is required by the executing hardware depending on the implementation.

Abstract

Die Erfindung betrifft ein Verfahren zum Debuggen von rekonfigurierbarer Hardware. Hierbei ist u. a. vorgesehen, dass sämtliche notwendige Debug-Information je Konfigurationszyklus in einen Speicher geschrieben wird, der dann vom Debugger ausgewertet wird.

Description

Titel: Verfahren zum Debuggen rekonfigurierbarer Architekturen
Beschreibung
Die vorliegende Erfindung befaßt sich mit Verfahren für das Debuggen von Programmen auf konfigurierbaren Architekturen. Unter einer rekonfigurierbaren Architektur werden u. a. Bau- steine (VPU) mit konfigurierbarer Funktion und/oder Vernetzung verstanden, insbesondere integrierte Bausteine mit einer Mehrzahl von ein- oder mehrdimensional angeordneten arithmetischen und/oder logischen und/oder analogen und/oder speichernden und/oder vernetzenden Baugruppen (im Folgenden PAEs genannt) und/oder kommunikativen/peripheren Baugruppen (10), die direkt oder durch ein oder mehrere Bussystem (e) miteinander verbunden sind. PAEs sind in beliebiger Ausgestaltung, Mischung und Hierarchie angeordnet. Diese Anordnung wird im weiteren PAE-Array oder PA genannt.
Zur Gattung dieser Bausteine zählen systolische Arrays, neuronale Netze, Mehrprozessor-Systeme, Prozessoren mit mehreren Rechenwerken und/oder logischen Zellen, Vernetzungs- und Netzwerkbausteine wie z.B. Crossbar-Schalter, ebenso wie be- kannte Bausteine der Gattung FPGA, DPGA, XPUTER, etc. Hingewiesen wird insbesondere in diesem Zusammenhang auf die folgenden Schutzrechte desselben Anmelders: P 44 16 881.0-53, DE 197 81 412.3, DE 197 81 483.2, DE 196 54 846.2-53, DE 196 54 593.5-53, DE 197 04 044.6-53, DE 198 80 129.7, DE 198 61 088.2-53, DE 199 80 312.9, PCT/DE 00/01869, DE 100 36 627.9-33, DE 100 28 397.7, DE 101 10 530.4, DE 101 11 014.6, PCT/EP 00/10516, EP 01 102 674.7, DE 102 06 856.9, 60/317,876, DE 102 02 044.2, DE 101 29 237.6-53, DE 101 39 170.6. Diese sind hiermit zu Offenbarungszwecken vollumfänglich eingegliedert.
Weiterhin soll angemerkt werden, daß die zu beschreibenden Verfahren auch auf Gruppen von mehreren Bausteinen angewendet werden können. Dennoch wird nachfolgend auf VPU und/oder auf „Bausteine" Bezug genommen. Diese Bauteile und deren Betrieb sind noch zu verbessern.
Die Aufgabe der vorliegenden Erfindung besteht darin, Neues für die gewerbliche Anwendung bereitzustellen.
Die Lösung der Aufgabe wird unabhängig beansprucht. Bevorzug- te Ausführungsformen befinden sich in den Unteransprüchen.
1. Erfindungsgemäßes Verfahren
Es werden nachfolgend mehrere Verfahren und Hardwareimplementierungen vorgestellt, die ein effizientes Debuggen von VPU- Systemen ermöglichen.
Das Debuggen erfolgt in einer bevorzugten Variante entweder durch die Verwendung eines entsprechend an eine VPU oder den Baustein angeschlossenen Microcontrollers oder durch eine Ladelogik nach den Patenten P 44 16 881.0-53, DE 196 51 075.9-53, DE 196 54 846.2-53, DE 196 54 593.5-53, DE 197 57 200.6-33, DE 198 07 872.2, DE 101 39 170.6, DE 199 26 538.0, DE 100 28 397.7, die durch Bezugnahme vollumfänglich eingegliedert sind. Wie ersichtlich sein wird, sind aber auch andere Hardware-Varianten verwendbar. Folgende grundlegende Verfahren sollen alternativ und/oder gemeinsam dabei angewendet werden:
1.1 Erkennen einer Debug-Bedingung
1.1.1 Bedingung
Durch den Programmierer wird beispielsweise innerhalb des De- bug-Tools eine oder mehrere Bedingungen festgelegt, die das Debugging starten (vgl. Breakpoint nach dem Stand der Technik) . Das Auftreten der Bedingungen wird zur Laufzeit in der VPU und/oder einem beliebigen mit der VPU datenaustauschenden Gerät festgestellt. Dies geschieht beispielsweise durch das Auftreten von bestimmten Datenwerten bei bestimmten Variablen und/oder bestimmten Triggerwerten bei bestimmten PAEs.
1.1.2 Vorbedingung
Im Optimalfall kann eine bestimmte Bedingung gemäß o.g. Defi- nition bereits mehrere Takte vor dem Eintreffen der Debug- Bedingung durch den Programmierer festgelegt werden. Dadurch werden bestimmte Latenz-Probleme, die im folgenden diskutiert werden, von vornherein ausgeschlossen.
Es sollen im folgenden zwei grundlegende Arten des Debuggings für VPUs diskutiert werden, wobei die jeweils bevorzugt anzuwendende Methode von der Wahl des Compilers abhängt: Für Compiler, die Code auf Basis von instantiierten Modulen einer Hardwarebeschreibungssprache (oder ähnlichen Sprache) generieren, kann sich besonders die im folgenden beschriebene Methode A eignen. Für Compiler ähnlich DE 101 39 170.6 und Zusatzanmeldungen, die komplexe Instruktionen erzeugen und nach einem VLIW- ähnlichen Verfahren generieren, eignet sich besonders die im folgenden beschriebene Methode B. Grundsätzlich ist für den Betrieb einer VPU oder eines entsprechenden Bausteins als Prozessor oder Coprozessor Methode B die bevorzugt anzuwendende.
Es wurde erkannt, dass insbesondere die Verwendung beider Me- thoden A und B gemeinsam zu den besten und transparentesten Debuggingergebnissen führt. Insbesondere kann je nach Tiefe des zu debuggenden Fehlers zunächst unter Zuhilfenahme der schnellen Debuggingmethode B debuggt werden und nach hinreichende Lokalisierung des Fehlers sodann per Methode A die De- tails in der "Tiefe" analysiert werden.
2. Methode A
2.1 Grundprinzip
Nach dem Auftreten einer (Vor) Bedingung wird die VPU angehalten. Danach werden die relevanten Debug-Informationen aus den PAEs an das Debug-Programm übertragen. Die relevanten Debug- Informationen wurden zuvor durch den Programmierer innerhalb des Debug-Programmes festgelegt. Nach Auslesen aller relevanter Debug-Informationen wird der nächste Takt ausgeführt und erneut die relevanten Debug-Informationen ausgelesen. Dies wiederholt sich solange, bis der Programmierer den Debug- Vorgang abbricht. Anstelle des Anhaltens der VPU sind eventu- eil andere Verfahren denkbar. So können für eine gegebene Abfolge von Takten wiederholt Daten zum Auslesen bereitgestellt werden, sofern dies schnell genug möglich ist. 2.2 Unterstützung durch die Hardware
2.2.1 Auslesen der Register
Wesentlich für die Funktionsweise des Debuggers ist die Mög- lichkeit, durch eine übergeordnete Einheit (im folgenden De- bugProzessor (DB) genannt), also beispielsweise eine CT oder Ladelogik, einen anderen extern angeschlossenen (Host) Prozessor oder einen reservierten Arraybereich, die internen Datenregister und/oder Statusregister und/oder Zustandsregister und ggf. je nach Implementierung weitere relevante Register und/oder Signale aus den PAEs und/oder dem Netzwerk zurückzu- lesen bzw. dies nur für ausgewählte Register bzw. Signale zu tun (zusammengefaßt im folgenden als Debuginformation bezeichnet) . Eine derartige Möglichkeit ist z. B. mit der in der PCT/DE 98/00334 geschaffenen Verbindung zwischen der
Ladelogik und dem Datenbus einer PAE (PCT/DE 98/00334 0403, Fig.4) realisierbar.
Es soll ausdrücklich angemerkt sein, daß auch serielle Ver- fahren zum Auslesen der Register verwendet werden können.
Beispielsweise kann JTAG gewählt werden und der DB über dieses Verfahren ggf. auch als externes seperates und evtl. auch marktübliches Gerät (z. B. Firma Hitex, Karlsruhe) angeschlossen sein.
Da bevorzugt auf sämtliche Register, oder zumindest eine erheblich Anzahl derer, durch den Debugger schreibend und/oder lesend zugegriffen werden kann, kann optional und bevorzugt ein wesentlicher Teil der (seriellen) Verkettung der Register zu Testzwecken (Scan-Chain) für die Produktionstests des
Chips entfallen. Die Scan-Chain wird normalerweise dafür verwendet, um alle Register innerhalb eines Chips während der Produktionstests mit Testdaten vorladen zu können und/oder die Inhalte der Register zu Testzwecken wieder zurückzulesen. Das Vorladen und/oder Zurücklesen geschieht dabei typischerweise durch Testsysteme (z.B. SZ Testsysteme, Amerang) und/oder gemäß den in der DE 197 57 200.6-33 beschriebenen Verfahren. Die Scan-Chain benötigt dazu einen zusätzlichen nicht unerheblichen Hardware- und Flächenaufwand für jedes Register. Dieser kann nunmehr, zumindest für die Register, die debugbar sind, entfallen, wenn - wie erfindungsgemäß vorgeschlagen - die Produktionstestanlagen über geeignete Schnittstellen (z.B. parallel, seriell, JTAG, etc.) Zugriff auf die Register erhalten.
2.2.2 Anhalten oder Verlangsamen des Taktes Durch das Auftreten von Bedingung und/oder Vorbedingung kann der Takt entweder angehalten oder verlangsamt werden, um hinreichend Zeit zum Auslesen zur Verfügung zu stellen. Ausgelöst wird dieser Debugbeginn insbesondere entweder direkt durch eine PAE-, die die (Vor) Bedingung (en) berechnete oder durch eine übergeordnete Einheit (z. B. Ladelogik/CT, Hostprozessor) aufgrund beliebiger Aktionen, beispielsweise durch die Information, daß an einer PAE eine (Vor) Bedingung auftrat und/oder durch eine Aktion innerhalb des DebugProzessors und/oder durch ein beliebiges Programm und/oder eine beliebi- ge externe/periphere Quelle. Zum Informieren stehen Triggermechanismen entsprechend P 44 16 881.0-53, DE 196 51 075.9- 53, DE 197 04 728.9, DE 198 07 872.2, DE 198 09 640.2, DE 100 28 397.7 zur Verfügung. Alternativ kann beim Debuggen der Takt generell verlangsamt werden. Sollen nur Arrayteile de- buggt werden, kann eine partielle Heruntertaktung vorgesehen werden. Sofern der Takt verlangsamt wird, muss durch den Debugprozes- sor innerhalb des verlangsamten Zyklus des Verarbeitungstaktes alle relevante Debug-Information aus den PAEs ausgelesen werden. Dazu ist es sinnvoll und bevorzugt, den Takt nur par- tiell zu verlangsamen, also den Arbeitstakt zu senken oder anzuhalten, aber den Takt für den Auslesemechanismus weiter fortzufahren. Des weiteren ist es sinnvoll und bevorzugt, generell die Register zum Datenerhalt mit Takt zu versorgen.
Nach dem Anhalten des Taktes kann ein Single-Step Modus realisiert werden, d.h. der Debugprozessor hält den Verarbeitungstakt so lange an, bis er alle Debug-Information ausgelesen hat. Danach startet er den Verarbeitungstakt wieder für einen Zyklus und hält ihn erneut bis nach dem Auslesen aller relevanten Debug-Informationen an.
Der Auslesetakt und der Takt des Debug-Prozessors sind bevorzugt unabhängig vom Verarbeitungstakt der PAEs, so daß die Datenverarbeitung vom Debugging und insbesondere Auslesen der Debug-Information getrennt ist.
Hardwaretechnisch wird das Anhalten oder Verlangsamen des Taktes durch Methoden nach dem Stand der Technik, wie beispielsweise Gated-Clocks und/oder PLLs und/oder Teiler oder andere Verfahren erreicht. Diese Mittel werden bevorzugt an geeigneten Stellen (Knoten) innerhalb des Clock-Trees eingefügt, so daß eine globale Taktsteuerungen der jeweils tieferliegenden Zweige realisierbar ist. Die Heruntertaktung nur von ausgewählten Arrayteilen ist in den unter Bezug genomme- nen Anmeldungen des vorliegenden Anmelders offenbart.
Besonders bevorzugt ist das Versenden einer Taktsteuer- Information von einer übergeordneten Einheit (z.B. Ladelo- gik/CT, Hostprozessor) an sämtliche bzw. sämtliche zu debug- genden PAEs. Dies kann bevorzugt über das Konfigurationsbussystem erfolgen. Die Taktsteuerinformation wird dabei typischerweise gebroadcastet übertragen, d.h. alle PAEs erhalten dieselbe Information.
Beispielsweise können folgende Taktsteuerinformationen implementiert sein:
STOP: Der Arbeitstakt wird angehalten. SLOW: Der Arbeitstakt wird verlangsamt.
STEP: Exakt ein Verarbeitungsschritt (Single Step Modus) wird ausgeführt und dann der Arbeitstakt wieder angehalten. STEP(n): n Verarbeitungsschritte werden ausgeführt und dann der Arbeitstakt wieder angehalten. GO: Der Arbeitstakt läuft normal weiter.
Es soll insbesondere erwähnt sein, dass das Verfahren der Taktabschaltung und/oder Verlangsamung ebenso eingesetzt werden kann, um den Stromverbrauch zu reduzieren. Sofern temporär keine Rechenleistung benötigt wird, kann ein "Sleepmode" beispielsweise durch das Abschalten des Arbeitstaktes (STOP) oder durch spezielle Befehle (SLEEP) realisiert werden. Wird nicht die volle Rechenleistung benötigt, kann der Takt durch die Verwendung von SLOW verlangsamt werden und/oder temporär durch STEP(n) ausgesetzt werden. Insoweit ist das Verfahren optional und/oder zusätzlich zu den in der DE 102 06 653.1 beschriebenen Verfahren zur Reduzierung der Verlustleistung einsetzbar.
Ein Problem des Broadcastings von Taktsteuerinformationen ist die Übertragungszeit des Broadcastes durch das Array aus PAEs. Die Übertragung kann bei höheren Taktfrequenzen nicht innerhalb eines Arbeitstaktes erfolgen. Es ist aber zwingend notwendig, dass sämtliche PAEs zur gleichen Zeit auf die Taktsteuerinformationen reagieren. Bevorzugt wird die Takt- Steuerinformation daher über ein gepipelintes Bussystem ähnlich des in DE 100 28 397.7 beschriebenen CT-Bussystems übertragen. Weiterhin wird ein Zahlenwert (LATVAL) den Taktsteuerinformationen hinzugefügt der gleich oder größer der maximalen Länge der Pipeline des Bussystems ist. In jeder Pipeli- nestufe wird taktweise der Zahlenwert dekrementiert (Subtraktion von 1) . Jede PAE, die die Taktsteuerinformation erhält, dekrementiert im weiteren den Zahlenwert mit jedem Takt. Damit ist sichergestellt, dass der Zahlenwert in dem gepipelin- ten Bussystem und den PAEs, die die Taktsteuerinformation be- reits empfangen haben, immer exakt gleich ist. Erreicht der Zahlenwert den Wert 0, ist sichergestellt, daß alle PAEs die Taktsteuerinformation erhalten haben. Jetzt tritt die Taktsteuerinformation in Kraft und das Verhalten des Taktes wird entsprechend modifiziert.
Durch das beschriebene Verfahren entsteht eine weitere Latenzzeit (Latency) . Diese kann beispielsweise durch die nachfolgend beschriebene Registerpipeline zusätzlich abgefangen werden, oder, wie besonders bevorzugt, durch die Definition der (Vor) Bedingung abgefangen werden, indem die (Vor) Bedingung soweit vorgesetzt wird, daß die Latenzzeit bereits berücksichtigt ist.
Es soll besonders erwähnt werden, daß die Latenzzeit im Sin- gle-Step Modus vernachlässigbar ist, da sie nur bei der Abschaltung es Taktes (STOP) eine Rolle spielt. Da der Befehl STEP immer nur exakt einen Schritt ausführt, kommt es während des Single-Step Betriebes durch keinerlei Verfälschung (Verzögerung) der Debugdaten durch die Latenzzeit.
2.2.3 Registerpipeline zum Ausgleichen der Latency
Bei höheren Betriebsfrequenzen kann es zu einer Latenzzeit zwischen dem Erkennen des Debugbeginns und dem Anhalten oder Verlangsamen des Taktes kommen. Diese Latenzzeit ist exakt vorherbestimmbar, da die Position der verzögernden Register in der VPU durch Hardware und/oder den zu debuggenden Algorithmus definiert und durch den Debugger daher exakt berechenbar ist.
Durch die Latenzzeit verschieben sich jedoch die dem Debug- Prozessor zur Verfügung gestellten Informationen derart, daß nicht mehr die korrekten Debuginformationen ausgelesen werden können. Bevorzugt wird dies durch ein entsprechendes Festlegen der (Vor) Bedingung durch den Programmierer gelöst. Optional kann durch das Einfügen einer mehrstufigen Registerpipe- line, die die Debuginformation in jedem Takt um ein Register weiter überträgt, der Debugprozessor auf so viele Takte an Debuginformationen zurückgreifen, wie die Registerpipeline lang ist. Die Länge der Registerpipeline ist so auszulegen, daß sie der maximal zu erwartenden Latenz entspricht. Auf- grund der exakten Berechenbarkeit der Latenzzeit ist es nunmehr dem Debug-Programm möglich, die zeitlich korrekte, relevante Debug-Information aus der Registerpipeline auszulesen.
Ein auftretendes Problem bei der Verwendung von Registerpipe- lines ist, daß diese verhältnismäßig lang und damit, bezogen auf die für die Realisierung notwendige Siliziumfläche, teuer sind. 2.3 Sichtbare Debug-Informationen
Bei dieser Methode wird im wesentlichen nach Auftreten der (Vor) Bedingung debugt, da erst danach der Takt verlangsamt oder angehalten wird und das Auslesen der Debug-Information erfolgt. Debug-Informationen, die vor dem Auftreten der (Vor) Bedingung liegen, sind daher zunächst nicht sichtbar.
Es ist jedoch, wenngleich auch unter Verlust an Arbeitsleistung, möglich eine VPU sofort vom Start einer Applikation an mit verlangsamten Takt oder Single-Step-Modus zu betreiben. Vom Start an werden die relevanten Debug-Informationen vom Debug-Prozessor ausgelesen.
3. Methode B
3.1 Grundprinzip
Relevante Debug-Informationen aus den Speichereinheiten, die gemäß P 44 16 881.0-53, DE 196 54 846.2-53, DE 199 26 538.0, DE 101 39 170.6 und deren Zusatzanmeldungen, DE 101 10 530.4 die Anwendungsdaten und Zustände eines bestimmten Arbeits- schrittes beinhalten, werden an das Debug-Programm übertragen. Diese Speichereinheiten, nachfolgend auch Arbeitsspeicher genannt, arbeiten im Maschinenmodell nach der P 44 16 881.0-53, DE 196 54 846.2-53, DE 101 39 170.6 und deren Zu- satzanmeldungen, DE 199 26 538.0, DE 101 10 530.4 quasi als Register zur Speicherung von Daten, die innerhalb eines Kon- figurationszykluses im PA oder Teilen des PAs berechnet wurden. Es wird insbesondere auf die Patentanmeldung DE 101 39 170.6 und deren Zusatzanmeldungen verwiesen, in der die Ver- wendung der Speichereinheiten als Register (REG) zur Realisierung eines Prozessormodells detailliert beschrieben ist. Die DE 101 39 170.6 und deren Zusatzanmeldungen sind zu Offenbarungszwecken vollumfänglich eingegliedert. Eine Speichereinheit besteht dabei aus einer beliebigen Anordnung und Hierarchie von unabhängigen und abhängigen Speichern. Es ist möglich, gleichzeitig mehrere unterschiedliche Algorithmen auf dem PA (Processing Array) auszuführen, die dann unterschiedliche Speicher verwenden.
Wesentlich für die Anwendung dieser Methode ist, daß Daten und/oder algorithmisch relevante Zustände in die den PAEs zugeordneten Speichereinheiten abgelegt sind, wobei eine Speichereinheit jeweils zumindest derart dimensioniert ist, daß alle relevanten Daten und/oder Zustände eines Zyklus gespeichert werden können; hierbei kann die Länge eines Zyklus durch die Größe der Speichereinheit bestimmt sein und ist es bevorzugt auch (vgl. DE 196 54 846.2-53). Mit anderen Worten wird die Zykluslänge der Hardware angepaßt.
Unterschiedliche Daten und/oder Zustände werden derart in die Speichereinheiten gespeichert, daß diese eindeutig dem Algorithmus zugeordnet werden können. Dadurch kann der Debugger die relevanten Daten und/oder Zustände (Debug-Information) eindeutig identifizieren.
Die relevanten Debug-Informationen können - insbesondere auch vorab - durch den Programmierer innerhalb des Debug-Pro- grammes festgelegt werden. Diese Debug-Informationen werden aus den Speichereinheiten ausgelesen. Dazu stehen unterschiedliche Methoden zur Verfügung; einige Möglichkeiten werden nachfolgend näher beschrieben. Nach dem Auslesen aller relevanter Debug-Informationen wird der nächste Konfigurati- onszyklus ausgeführt und erneut die relevanten Debug-Informationen ausgelesen. Dies wiederholt sich so lange, bis der Programmierer/Debugger den Debug-Vorgang abbricht.
Mit anderen Worten werden die relevanten Daten und/oder Statusinformationen nicht taktweise, sondern konfigurationsweise an den Debugger übertragen. Dies geschieht aus den Speichereinheiten, die mit den Registern einer CPU vergleichbar sind.
3.2 Unterstützung durch die Hardware
Wesentlich für die Funktionsweise des Debuggers ist die Mög- lichkeit, durch die CT oder einen anderen extern angeschlossenen Prozessor (im Folgenden DebugProzessor (DB) genannt) , die beispielsweise auch interne (n) Arbeitsspeicher der VPU zu lesen. Eine derartige Möglichkeit ist z.B. durch den Anschluß der CT an die Arbeitsspeicher zum Vorladen und Lesen der Da- ten und/oder durch die in der DE 199 26 538.0 beschriebene
Verfahren zum Herausschreiben der internen Speicher an externe Speicher gegeben. In einer mögliche Ausgestaltung kann auf Arbeitsspeicher durch verschieden Verfahren nach dem Stand der Technik (z.B. Shared Memory, Bank Switching) derart vom DebugProzessor zugegriffen werden, dass der Datenaustausch mit dem DB weitestgehend unabhängig von einer weiteren Datenverarbeitung in der VPU erfolgen kann.
In einer möglichen Ausgestaltung kann z. B. entsprechend Me- thode A durch eine oder mehrere der vorstehend beschriebenen Maßnahmen der Takt der VPU zum Auslesen der Speicher gegebenenfalls entweder entsprechend verlangsamt oder angehalten werden und/oder gegebenenfalls im Single-Step-Modus betrieben werden. Dabei kann je nach Implementierung der Arbeitsspeicher, z. B. beim Bank-Switch-Verfahren, auf einen besonderen Eingriff in den Takt verzichtet werden. Typischerweise geschieht das Anhalten oder Verlangsamen des Taktes nach Metho- de B und das Auslesen und/oder Kopieren und/oder Umschalten der Arbeitsspeicher nur, wenn ein Datenverarbeitungszyklus bzw. Konfigurationszyklus beendet ist.
Mit anderen Worten ist ein wesentlicher Vorteil von Methode B, dass keine besondere Unterstützung durch die Hardware erforderlich ist.
In einer möglichen Ausgestaltung muß ein DB lediglich Zugriff auf die Arbeitsspeicher besitzen. In einer besonders zu be- vorzugenden Ausgestaltung geschieht der Zugriff auf die Arbeitsspeicher -durch eine geeignete Konfiguration der VPU, die dadurch die Arbeitsspeicher selbständig und ohne Modifikation ausliest und an einen DB überträgt.
3.3 Zugriff auf Debug-Information
In der P 44 16 881.0-53, DE 196 54 846.2-53, DE 101 39 170.6, DE 199 26 538.0 sind Datenverarbeitungsverfahren beschrieben, bei denen zyklisch eine Menge an Operationen auf einen rekon- figurierbaren Datenverarbeitungsbaustein abgebildet werden. In jedem Zyklus wird eine Mehrzahl von Daten berechnet, die von einer peripheren Quelle und/oder einen internen/externen Arbeitsspeicher stammen und an eine periphere Quelle und/oder einen internen/externen Arbeitsspeicher geschrieben werden. Dabei können jeweils unterschiedliche und/oder vor allem mehrere unabhängige Arbeitsspeicher gleichzeitig verwendet werden. Beispielsweise können in diesem Datenverarbeitungsver- fahren die Arbeitsspeicher oder ein Teil der Arbeitsspeicher als Registersatz dienen.
Nach der DE 101 39 170.6 und der DE 199 26 538.0 werden dabei sämtliche Daten und Zustände, die für die weitere Datenverarbeitung relevant sind, in die Arbeitsspeicher abgelegt und/oder aus selbigen gelesen. In einem bevorzugten Verfahren werden für die weitere Datenverarbeitung irrelevante Zustände nicht gespeichert.
Die Unterscheidung zwischen relevanten und irrelevanten Zuständen soll an folgendem Beispiel aufgezeigt werden, es soll zu Offenbarungszwecken dabei insbesondere auf die Ausführungen in der DE 101 39 170.6 verwiesen werden:
Die Zustandsinformation eines Vergleichs ist beispielsweise für die weitere Verarbeitung der Daten wesentlich, da dieser die auszuführenden Funktionen bestimmt.
Ein sequenzieller Dividierer entsteht beispielsweise durch Abbildung eines Divisionsbefehles auf eine Hardware, die nur die sequenzielle Division unterstützt. Dadurch entsteht ein Zustand, der den Rechenschritt innerhalb der Division kennzeichnet. Dieser Zustand ist irrelevant, da für den Algorith- mus nur das Ergebnis (also die ausgeführte Division) erforderlich ist. In diesem Fall werden also lediglich das Ergebnis und die Zeitinformation (also die Verfügbarkeit) benötigt .
Die Zeitinformation ist beispielsweise in der VPU-Technologie nach P 44 16 881.0-53, DE 196 51 075.9-53, DE 199 26 538.0 durch das RDY/ACK Handshake erhältlich. Hierzu ist jedoch besonders anzumerken, daß das Handshake ebenfalls keinen rele- vanten Zustand darstellt, da es lediglich die Gültigkeit der Daten signalisiert, wodurch sich wiederum die verbleibende relevate Information auf die Existenz gültiger Daten reduziert.
In der DE 101 39 170.6 wird eine Unterscheidung zwischen lokal und global relevanten Zuständen aufgezeigt:
lokal: Der Zustand ist nur innerhalb einer einzigen abge- schlossenen Konfiguration relevant. Daher muß der Zustand nicht zwingend gespeichert werden. global: Die Zustandsinformation wird für mehrere Konfigurationen benötigt. Der Zustand muß gespeichert werden.
Es ist nunmehr denkbar, daß der Programmierer einen lokal relevanten Zustand debuggen will, der nicht in den Speichern abgelegt ist. In diesem Fall kann die Applikation dahingehend modifiziert werden, daß eine Debug-Konfiguration entsteht (äquivalent zum Debug-Code von Prozessoren) , die eine Modifi- kation zum "normalen" Code der Applikation derart aufweist, daß dieser Zustand zusätzlich in die Speichereinheit geschrieben und damit dem Debugger zur Verfügung gestellt wird. Dadurch entsteht eine Abweichung zwischen Debug-Code und tatsächlichem Code, die zu einem unterschiedlichen Verhalten der Codes führen kann.
In einer daher besonders bevorzugten Ausführung wird keine Debug-Konfiguration verwendet. Vielmehr wird die zu debuggen- de Konfiguration derart terminiert, dass die für Debugging- zwecke zusätzlich erforderlichen Daten die Terminierung überdauern, d.h. weiterhin gültig in den entsprechenden Speicherstellen (REG) (z.B. Register, Zähler, Speicher) verbleiben. Wenn die zu debuggende Konfiguration derart terminiert wird, daß die für Debugging-Zwecke zusätzlich erforderlichen Daten die Terminierung überdauern, ist es möglich, ein Debuggen einfach dadurch durchzuführen, daß nicht die nächste, bei normalem Programmablauf erforderliche Konfiguration geladen wird, sondern stattdessen eine Konfiguration, über welche die zu den Debugging-Zwecken erforderlichen Daten in die Debug- Einheit bzw. das Debug-Mittel übertragen werden. Es sei darauf hingewiesen, daß bei einem solchen Debuggen auch im spä- teren Ablauf des Programmes stets die zu Debug-Zwecken erforderlichen Daten mit abgespeichert werden können, wodurch sichergestellt ist, daß das später ausgeführte Programm in exakt der Weise einem Debug-Prozeß unterworfen wurde wie erforderlich. Nach Auslesen der Debug-Information durch eine dedi- zierte Debug-Konfiguration kann dann mit der normalen Programmausführung fortgefahren werden.
Eine Konfiguration wird geladen, diese verbindet die REG in geeigneter Weise und definierter Reihenfolge mit einem oder mehreren globalen Speicher (n), auf die der DB Zugriff hat (z.B. Arbeitsspeicher).
Vorgeschlagen wird also, daß eine Konfiguration geladen wird, diese die REG in geeigneter Weise verbindet und in definier- ter Reihenfolge mit einem oder mehreren globalen Speichern verbindet, auf die der DB Zugriff hat (z. B. Arbeitsspeicher) .
Die Konfiguration kann beispielsweise Adressgeneratoren ver- wenden, um auf den/die globalen Speicher zuzugreifen. Die Konfiguration kann beispielsweise Adressgeneratoren verwenden, um auf als Speicher ausgestaltete REG zuzugreifen. Entsprechend der konfigurierten Verbindung zwischen den REG wer- den die Inhalte der REG in einer definierten Reihenfolge in den globalen Speicher geschrieben, wobei die jeweiligen Adressen von Adressgeneratoren vorgegeben werden. Der Adressgenerator generiert die Adressen für den/die globalen Spei- cher(n) derart, daß die beschriebenen Speicherbereiche (DEBU- GINFO) der entfernten zu debuggenden Konfiguration eindeutig zugeordnet werden können.
Das Verfahren entspricht dem Kontext-Switch in DE 102 06 653.1 und DE 101 39 170.6, die zu Offenbarungszwecken vollumfänglich eingegliedert sind.
Der DB kann nunmehr auf die Daten innerhalb eines ihm zugänglichen Speicherbereiches (DEBUGINFO) zugreifen. Soll das De- bugging mittels eines Single-Step Verfahrens durchgeführt werden, kann nach jedem Single step einer zu debuggenden Konfiguration ein Kontext-Switch derart durchgeführt werden, dass sämtliche Daten erhalten bleiben und die zu debuggende Information aus den REG in einen Arbeitsspeicher geschrieben wird. Sodann wird wiederum unter Erhalt der Daten die zu debuggende Konfiguration wieder konfiguriert und für einen weiteren Single step ausgeführt. Dies geschieht für jeden zu debuggenden Single step der zu debuggenden Konfiguration. Auf die Möglichkeit eines Debugging unter Verwendung der als „Wa- ve-Rekonfiguration" bekannten Prinzipien sei hingewiesen.
3.4 Sichtbare Debug-Informationen
Ein Debuggen vor der (Vor) Bedingung kann vergleichsweise einfach und ohne große Performance-Verluste durchgeführt werden, da die benötigten Debug-Informationen in Arbeitsspeichern verfügbar sind. Durch das Übertragen der Arbeitsspeicher in andere Speicherbereiche, auf die der DB bevorzugt direkten Zugriff hat, kann die Debug-Information einfach sichergestellt werden. Eine noch schnellere Methode ist, die Arbeitsspeicher durch ein Bank-Switching-Verfahren (nach dem Stand der Technik) derart zwischen den einzelnen Konfigurationen umzuschalten, daß die Debug-Information in einer jeweils neuen Bank liegt. Das Umschalten kann sehr zeitoptimierend, im Optimalfall sogar ohne Auswirkung auf die Verarbeitungsleistung erfolgen.
Es ist bereits offenbart worden, daß bei einer VPU Daten blockweise in einen Speicherbereich übertragen werden können. Dieser kann auch außerhalb des eigentlichen PA liegen und/oder einen Dual-Ported-RAM oder dergleichen aufweisen, so daß es möglich ist, auf die eingeschriebene Information von außen leicht zuzugreifen.
4. Funktionsweise des Debuggers
Das Debugger-Programm selbst kann auf einem DB außerhalb des PAs ablaufen. Alternativ dazu kann eine VPU selbst den DB darstellen, entsprechend der Methoden, die bei Prozessoren angewendet werden. Dazu kann ein Task- oder Kontextswitch (SWITCH) entsprechend den Ausführungen in PACT11 ausgeführt werden. Die Debuginformationen des zu debuggenden Programmes werden bei einem SWITCH zusammen mit den relevanten Daten gesichert und das Debugger Programm geladen, das die Informationen auswertet und/oder interaktiv mit dem Programmierer verarbeitet. Danach wird erneut ein SWITCH durchgeführt (bei welchem die relevanten Informationen des Debuggers gesichert werden) und das zu debuggende Programm wird weitergeführt. Es sei auch erwähnt, daß als Debugger ein Prozessor-Teilbereich vorgesehen werden kann.
Die Debug-Information wird vom Debugger entsprechend Methode A und/oder B gelesen und in einen von der Datenverarbeitung separaten Speicher und/oder Speicherbereich gespeichert, auf den der DB bevorzugt direkten Zugriff besitzt. Durch das Debugger-Programm werden die Breakpoints und (Vor) Bedingungen definiert. Ebenfalls kann das Debugger-Programm die Kontrolle über die Ausführung der Applikation, insbesondere den Ausführungsstart und das Ausführungsende übernehmen.
Der Debugger stellt dem Programmierer eine geeignete Arbeitsumgebung zur Verfügung mit ggf. graphischer Oberfläche. In einer besonders bevorzugten Ausführung ist der Debugger in eine komplexe Entwicklungsumgebung integriert und tauscht mit dieser Daten und/oder Steuerinformation aus. Insbesondere kann der Debugger die aus den Arbeitsspeichern gelesenen Daten zur beliebigen Weiterverarbeitung auf einen Datenträger (Festplatte, CDROM) speichern und/oder innerhalb eines Netzwerkes (wie Ethernet) ablaufen.
Der erfindungsgemäße Debugger kann zudem gemäß DE 101 29 237.6-53 innerhalb einer Entwicklungsumgebung mit anderen Werkzeugen und insbesondere auch Debuggern kommunizieren; wobei in einer bevorzugten Ausgestaltung die Steuerung und/oder Definition der Debugparameter von einem anderen Debugger aus übernommen werden kann. Ebenso kann der Debugger die von ihm generierte Debug-Information einem anderen Debugger zur Ver- fügung stellen und/oder von diesem dessen Debug-Information erhalten. Insbesondere das Feststellen des Auftretens von Breakpoints und/oder (Vor) Bedingung ist durch einen anderen Debugger bzw. den Einheiten, die dieser andere Debugger debugt, durchführbar. Der erfindungsgemäße Debugger und die VPU reagieren dann entsprechend.
Der andere Debugger kann insbesondere der Debugger eines mit einer VPU gekoppelten anderen Prozessors (CT, bzw. ARC bei Chameleon, Pentium, AMD usw.) sein.
Insbesondere kann der andere Debugger auf einem der VPU zugeordneten und/oder gekoppelten Prozessor ablaufen und/oder der zugeordnete Prozessor der DB sein, beispielsweise eine CT bzw. ARC bei Chameleon. In einer besonders bevorzugten Ausge- staltung kann der zugeordnete Prozessor ein Host-Prozessor sein, wie beispielsweise in der 60/317,876 und/oder der DE 102 06 856.9 beschrieben.
5. Bewertung der Methoden
Die Methode A ist erheblich zeit- und ressourcenintensiver als die Methode B, bei der kaum zusätzliche Hardware erforderlich ist und zudem ggf. das zeitaufwendige Auslesen der Debug-Information vom Start der Applikation an entfällt. Daher ist Methode B grundsätzlich vorzuziehen. Für Compiler nach DE 101 39 170.6 und deren Zusatzanmeldungen ist die Methode B eindeutig zu präferieren.
Es wurde erkannt, daß insbesondere die Verwendung beider Methoden A und B gemeinsam zu den besten und transparentesten Debuggingergebnissen führt. Insbesondere kann je nach Tiefe des zu debuggenden Fehlers zunächst unter Zuhilfenahme der schnellen Debuggingmethode B debuggt werden und nach hinreichende Lokalisierung des Fehlers sodann per Methode A die Details in der "Tiefe" analysiert werden.
6. Mixed Mode Debugger
Bei der Anwendung der besonders bevorzugten Methode B kann es zu dem Problem kommen, dass die in den Speichern befindliche sichtbare Information nicht hinreichend ist.
Typischerweise kann ein detaillierteres Debugging folgender- massen erfolgen: a) Die sichtbare Debuginformation (PREINFO) vor der Konfiguration einer einen Breakpoint enthaltenden Konfiguration wird gesichert. Bei Auftreten eines Fehlers bei dem Breakpoint wird die dann sichtbare Debuginformation (POSTINFO) gesichert. Basierend auf der PREINFO Information wird ein Software-Simulator gestartet, der die zu debuggen- de (n) Konfiguration (en) simuliert. Der Simulator kann da- bei jeden Wert innerhalb der PAEs "und der Bussysteme bestimmen und (ggf. auch graphisch und/oder textuell) ausgeben, wodurch ein detaillierter Einblick in den Ablauf des Algorithmus zum Zeitpunkt des Auftretens des Fehlers erreicht wird. Insbesondere ist es möglich, die jeweils simulierten Werte mit den Werten von POSTINFO zu vergleichen, um Differenzen schnell zu erkennen.
b) Die sichtbare Debuginformation vor einem Breakpoint wird gesichert. Bei Auftreten eines Breakpoints wird basierend auf dieser Information ein Software-Visualisierer gestartet. Der zu debuggende Baustein wird nunmehr in einem Single-Step Verfahren betrieben, das das Auslesen sämtlicher relevanter Daten nach Methode A ermöglicht. Diese Daten können nunmehr entweder direkt (ggf. auch graphisch und/oder textuell) ausgegeben werden und/oder an einen Simulator weitergeleitet werden, dessen Simulation sodann auf den detaillierteren Daten beruht, und danach wie bekannt ausgegeben werden.
6.1 Vorteile eines Mixed-Mode-Debuggers
Der Mixed-Mode-Debugger ermöglicht die detaillierte Analyse der Abläufe innerhalb eines Bausteines. Durch die Möglichkeit gemäß Methode B, bis zu einem gesetzten Breakpoint mit voller Geschwindigkeit zu arbeiten und danach ggf. anzuhalten, zu verlangsamen und/oder ggf. in einen Single-Step-Modus zu ge- hen, wird das Debugging zeiteffizient, wodurch das Testen großer Datenmengen und/oder komplexer Algorithmen ermöglicht wird. Das bevorzugte Aufsetzen eines Simulators nach dem Auftreten des Breakpoints auf Basis der aktuellen Daten und Zustände ermöglicht einen genauen Einblick in die Hardware. So- fern der Zeitaufwand für die Simulation zu hoch ist und/oder die 100% Übereinstimmung des Simulators mit der Hardware fraglich ist, ermöglicht das Zurücklesen von Daten im Single- Step-Modus nach Auftreten eines Breakpoints gemäß Methode A oder entsprechend des Kontext-Switch Verfahrens nach DE 102 06 653.1 und DE 101 39 170.6 ein 100% korrektes Debugging des Algorithmus und/oder auch der Hardware selbst.
7. Beschreibung der Figuren
Figur 1 und 2 entsprechen der Patentanmeldung DE 101 39 170.6. Die unterschiedlichen Ansätze der Methoden A und B wurden in die Figuren eingezeichnet (A, B) Figur lb zeigt eine Repräsentation des endlichen Automaten durch eine rekonfigurierbare Architektur nach P 44 16 881.0- 53 und DE 196 54 846.2-53 (DE 196 54 846.2-53, Fig. 12-15). Das kombinatorischen Netz aus Figur la (0101) wird durch eine Anordnung von PAEs 0107 ersetzt (0101b) . Das Register (0102) wird durch einen Speicher (0102b) ausgeführt, der mehrere Zyklen speichern kann. Die Rückkopplung gemäß 0105 erfolgt durch 0105b. Die Eingänge (0103b bzw. 0104b) sind äquivalent 0103 bzw 0104. Der direkte Zugriff auf 0102b kann ggf. durch einen Bus durch das Array 0101b realisiert werden. Der Ausgang 0106b ist wiederum äquivalent 0106.
Figur 2 zeigt die Abbildung eines endlichen Automaten auf ei- ne rekonfigurierbare Architektur. 0201 (x) repräsentieren das kombinatorische Netz (das entsprechend Figur lb als PAEs ausgestaltet sein kann) . Es existiert ein oder mehrere Speicher für Operanden (0202) und ein oder mehrere Speicher für Ergebnisse (0203) . Zusätzlich Daten Ein-/Ausgänge gem. 0103b, 0104b, 0106b) sind der Einfachheit halber nicht dargestellt. Den Speichern zugeordnet ist jeweils ein Adressgenerator (0204, 0205) .
Die Operanden- und Ergebnisspeicher (0202, 0203) sind physikalisch oder virtuell derart miteinander verkoppelt, daß bei- spielsweise die Ergebisse einer Funktion einer anderen als
Operanden dienen können und/oder Ergebnisse und Operanden einer Funktion einer anderen als Operanden dienen können. Eine derartige Kopplung kann beispielsweise durch Bussysteme hergestellt werden oder durch eine (Re) Konfiguration, durch wel- ehe die Funktion und Vernetzung der Speicher mit den 0201 neu konfiguriert wird. Figur 3 zeigt eine mögliche schematische Struktur des Debug- gings nach Methode B. Es sei insbesondere beispielhaft auf die Figuren 19, 20, 21 der Patentanmeldung DE 199 26 538.0 verwiesen, in welcher die Grundlage der Speicher beschrieben ist. Die DE 199 26 538.0 wird hiermit zu Offenbarungszwecken vollumfänglich eingegliedert.
0101b und 0102b ist wie bereits beschrieben dargestellt. Zusätzlich ist eine externer Speichereinheit dargestellt (0302), der möglicherweise ähnlich DE 199 26 538.0 an 0102b angeschlossen (0307) sein kann. Es soll besonders darauf hingewiesen werden, daß sowohl 0102b als auch 0302 externe oder interne Speichereinheiten sein können. Ebenfalls soll eine Speichereinheit als mindestes ein Register, eine Menge von Registern oder ein Speicher (RAM, Flash, o.a.) oder Massenspeicher (Festplatte, Band, o.a.) definiert sein.
Die debuggende Einheit 0301 kann Breakpoints innerhalb 0101b setzen (0303) , auf Basis derer der eigentliche Debug Vorgang ausgelöst wird. Durch das Erreichen eines Breakpoints wird eine Information (0304) an 0301 gesendet, die den Debug Vorgang startet; zugleich werden auch alle 0101b interenen Vorkehrungen zum Debuggen (z.B. ein Anhalten und/oder Verlangsamen des Taktes) ausgelöst. Alternativ kann auch durch 0301 die Information generiert und an 0101b gesendet werden.
Über 0305 und/oder 0306 kann 0301 auf die Daten und/oder Zustände aus dem Speicher 0102b und/oder dem Speicher 0302 zugreifen. Der Zugriff kann zum Beispiel
1. durch eine Speicherkopplung (Block-Move, d.h. kopieren der Speicher in einen anderen, von 0301 kontrollierten Bereich) , 2. durch eine Leitung (serielle oder parallele Leitung, über die ein oder mehrere Speicherbereich (e) übertragen wird/werden, z.B. JTAG) ,
3. Buskopplungen gleich welcher Art (die Speicher werden ähnlich eines DMA-Verfahren arbitriert und von 0301 verarbeitet) erfolgen.
Als Beispiel wurde eine Figur aus der DE 199 26 538.0 ge- wählt. Es soll ausdrücklich darauf hingewiesen werden, daß grundlegend jedes Speicherverfahren und jede Speicherkopplung (Stack, Random-Access, FIFO, usw.) entsprechend bearbeitet werden kann.
Die Figuren 4a und 4b zeigen weitere möglichen Ausgestaltungen und wurden aus der Patentanmeldung DE 102 06 856.9 entnommen, die zu Offenbarungszwecken vollumfänglich eingegliedert ist.
Der Aufbau einer besonders bevorzugten' VPU ist in Figur 4a dargestellt. Vorzugsweise hierarchische Konfigurationsmanager (CT's) (0401) steuern und verwalten eine Anordnung von rekon- figurierbaren Elementen (PACs) (0402). Den CT's ist ein lokaler Speicher für die Konfigurationen zugeordnet (0403) . Der Speicher verfügt weiterhin über ein Interface (0404) zu einem globalen Speicher, der die Konfigurationsdaten zur Verfügung stellt. Über ein Interface (0405) sind die Konfigurationsab- läuft steuerbar. Ein Interface der rekonfigurierbaren Elemente (0402) zur Ablaufsteuerung und Ereignisverwaltung (0406) ist vorhanden, ebenso ein Interface zum Datenaustausch (0407). Beipielsweise kann eine der CT's als DB agieren. Figur 4b zeigt einen Ausschnitt aus einem beispielhaften CPU- System, beispielsweise einem DSP des Types C6000 von Texas Instruments (0451). Dargestellt sind Programmspeicher (0452), Datenspeicher (0453), beliebige Peripherie (0454) und EMIF (0455) . Über einen Speicherbus (0456) und einen Peripheriebus (0457) ist eine VPU als Coprozessor integriert (0458) . Ein DMA-Kontroller (EDMA) (0459) kann beliebige DMA-Transfers, beispielsweise zwischen Speicher (0453) und VPU (0458) oder Speicher (0453) und Peripherie (0454) durchführen. In diesem Beispiel kann 0451 als DB arbeiten und insbesondere auch der erfindungsgemäße Debugger mit dessen Debugger gekoppelt und/oder in diesen integriert sein.
Figur 5a zeigt einen beispielhaften Hardwareaufbau, der zum Debuggen von rekonfigurierbaren Prozessoren benutzt werden kann. Hierzu wird ein gepipelinter Konfigurationsbus 0501 verwendet, ähnlich dem aus DE 100 28 397.7 bekannten. Die Pipeline ist über mehrere Registerstufen (0502) in horizontaler und/oder vertikaler Richtung aufgebaut, um höhere Takt- frequenzen zu erreichen. Der gepipelin'te Konfigurationsbus führt zu den zu konfigurierenden Elementen (PAEs) (0503) , um diese mit Konfigurationsdaten zu versorgen.
Figur 5b zeigt beispielhaft die erforderliche Erweiterung ge- maß der vorliegenden Erfindung. Jede Registerstufe (0502) dekrementiert den Zahlenwert (LATVAL) zum Ausgleich der Latenzzeit um 1 (angedeutet durch -1) . Ebenso dekrementiert jede PAE (0503), die bereits eine Taktsteuerinformation erhalten hat, diese pro Takt um 1 (angedeutet durch -1/T) . Auf die PAEs und insbesondere deren internen Register kann nunmehr nicht nur schreibend, sondern auch lesend zugegriffen werden, z.B. über eine besondere Steuerleitung (RD) , um Debugdaten auszulesen. Zu schreibende und gelesene Daten durchlaufen in diesem Beispiel das Bussystem durch das Array aus PAEs von links nach rechts und in der untersten Zeile in Rückwärtsrichtung. Der Konfigurationsbus ist weiterhin über Registerstufen (0505) pipelineartig zurückgeführt (0504). In die- se Beispiel kann eine übergeordnete Einheit (CT/Ladelogik, Hostprozessor) (0506) ebenso lesend und schreibend auf den Bus zugreifen, wie ein dediziertes Testinterface (0507) . Das Testinterface kann einen eigenen Testkontroller aufweisen und insbesondere kompatibel zu einem oder mehrern marktgängigen Testschnittstellen sein (z.B. JTAG, Tektronix, Rhode&Schwarz, etc) . Die Auswahl der bussteuernden Einheit erfolgt über eine Multiplexer/Demultiplexer-Einheit (0508). In (0509 in Klammern und kursiv dargestellt) oder vor den Einheiten 0506 und 0507 kann eine Schaltung zur Rückrechung der Herkunftsadresse (0509) von Debugdaten, die über 0504 eintreffen, vorgesehen sein. Die Adressberechnungen innerhalb des aufgezeigten Systems geschehen wie folgt: Zunächst wird die Adresse durch
0506 oder 0507 am Bus 0501 angelegt. Die Adresse wird ähnlich der Verarbeitung der Zahlenwerte (LATVAL) zur Latenzberech- nung in jeder Registerstufe (0502 und O505) dekrementiert. Sobald die Adresse gleich 0 ist, wird die nach der Registerstufe liegende PAE selektiert. In der nachfolgenden Registerstufe wird die Adresse negativ, so daß keine weiteren PAEs mehr aktiviert werden. Sofern Daten aus einer PAE gelesen werden, werden diese zusammen mit der Adresse zurückübertragen. Die Adresse wird dabei in jeder Registerstufe weiter dekrementiert. Eine Rückrechnung in 0509 der bei 0506 und/oder
0507 zusammen mit den Debugdaten eintreffenden Adressen ist nunmehr durch eine einfache Addition möglich, indem die An- zahl der dekrementierenden Registerstufen zu dem eintreffenden Adresswert hinzuaddiert werden. Es soll angemerkt sein, dass die Registerstufen 0502 in Figur 5b leicht unterschiedlich gegenüber den Registerstufen 0502 in Figur 5a ausgestal- tet sind. In Figur 5b weisen diese nämlich zusätzlich eine Schaltung (z.B. Multiplexer) zu Auswahl der weiterzuleitenden Daten auf, der entweder die Daten des Busses 0501 weiterschaltet oder den Ausgang der zugeordneten PAE (0503) und so- mit die DebugDaten. Zur Ansteuerung der Schaltung kann das Auftreffen des Adresswertes gleich 0 dienen.
Es wird nochmals darauf hingewiesen, daß das dedizierte Testinterface (0507) den Industriestandards entspricht. Es kann zu Tests während des Software-Debug-Vorgangs eingesetzt werden und/oder zu Test während des Zusammenbaus von Hardwarekomponenten und -Systemen (z.B. dem Zusammenbau der Schaltungen auf der Platine) und/oder zu Funktionstests des Halbleiterbausteins (Chips) im Rahmen der Halbleiterfertigung. Ins- besondere dadurch kann die übliche Scan-Chain zum Test der
Register während des Funktionstests des Halbleiters entfallen oder zumindest entsprechend minimiert werden, da dann nur die Register durch die Scan-Chain geführt werden müssen, die nicht vom Bussystem (0501) ansteuerbar sind.
Ebenfalls wird besonders darauf hingewiesen, daß das in Figur 5 erläuterte Verfahren keinesfalls auf die Anwendung bei Konfigurationsbussen beschränkt ist. Gewöhnliche Datenbussysteme können ebenso zu den unterschiedlichen vorab aufgezählten Test- und Debugging-Zeitpunkten und -arten verwendet werden. Insbesondere sei in diesem Zusammenhang auf das in der DE 197 04 742.4 beschriebene Datenbussystem hingewiesen. Die DE 197 04 742.4 ist hierzu zu Offenbarungszwecken vollumfänglich eingegliedert. Die in Figur 5 beschriebenen Verfahren können, für einen Ingenieur mit gewöhnlichen technischen Kenntnissen leicht nachvollziehbar ebenso auf die DE 197 04 742.4 angewendet werden. Ein Mischbetrieb unterschiedlicher Bussysteme, wie Konfigurationsbussystemen, Datenbussystemen nach DE 197 04 742.4 und gewöhnlichen Datenbussystemen ist desweiteren grundsätzlich möglich. Dazu können mehrere Testinterface vorgesehen sein, oder wie technisch bevorzugt die Multiple- xer/Demultiplexerstufe (0508) auf eine Mehrzahl von Bussystemen (n x 0501, n x 0504) ausgelegt werden.
Abschließend soll noch besonders erwähnt sein, dass durch die Rückführung des Bussystems nach Figur 5b auch die in die PAEs zu schreibenden Konfigurationsdaten zurückgeführt werden. Unter Zuhilfenahme der Adressrückrechung (0509) und der zurückgeführten Statusleitung REJ, die nach DE 100 28 397.7, DE 198 07 872.2, DE 196 54 593.5-53 eine Zurückweisung der Konfigu- rationsdaten anzeigt, kann auf die Verwendung der Konfigura- tionszwischenspeicher-FIFOs nach DE 100 28 397.7 Figuren 8 und 9 (0805, 0903) verzichtet werden, da deren Funktionalität nunmehr vollumfänglich über das beschriebene Bussystem abgebildet wird.
8. Begriffsdefinition
lokal relevanter Zustand Zustand, der nur innerhalb einer bestimmten Konfiguration relevant ist.
global relevanter Zustand Zustand, der in mehreren Konfigurationen relevant ist und zwischen den Konfigurationen ausgetauscht werden muß.
relevanter Zustand Zustand, der innerhalb eines Algorithmus zur korrekten Ausführung dessen benötigt wird und somit durch den Algorithmus beschrieben ist und verwendet wird.
irrelevanter Zustand Zustand, der für den eigentlichen Algorithmus ohne Bedeutung ist und auch nicht im Algorithmus beschrieben ist, der jedoch von der ausführenden Hardware implementierungsabhängig benötigt wird.

Claims

Titel: Verfahren zum Debuggen rekonfigurierbarer ArchitekturenPatentansprüche
1. Verfahren zum Debuggen von rekon igurierbarer Hardware, dadurch gekennzeichnet, daß sämtliche notwendige Debuginformation je Konfigurationszyklus in einen Speicher ge- schrieben werden, der dann vom Debugger ausgewertet wird.
2. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, daß während des Debug-Vorganges nach Auftreten einer Debug-Bedingung, gemäß welcher Information über die zu debuggende Konfiguration benötigt wird, eine Konfiguration geladen wird, mittels welcher die in den Speicher geschriebenen Debug-Informationen ausgelesen und insbesondere in eine Debug-Einheit oder Debug-Konfiguration geschrieben werden.
3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß eine zu debuggende Konfiguration vor dem Ablauf des Debugging derart verändert wird, daß bei normaler, nicht-debuggender Ausführung nicht er- forderliche Information in einem Speicher abgelegt wird.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß zum Auslesen die Taktfrequenz zumindest verlangsamt oder angehalten wird und/oder eine taktweise Abarbeitung der zu debuggenden Konfiguration Schritt für Schritt erfolgt.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die zu debuggende Konfiguration nach Auslesen der relevanten Information oder nach davor- liegender Information simuliert wird.
6. Vorrichtung mit einem Feld konfigurierbarer Elemente, insbesondere grobgranularer logischer und/oder arithmetischer Einheiten sowie einem Debug-Mittel zum Debuggen von Programmen, Programmteilen oder auf dem Array auszufüh- renden komplexen Operationen, dadurch gekennzeichnet, daß das Debug-Mittel ein Speichermittel zur Speicherung von für das Debugging relevanten Informationen während oder am Ende eines Arbeitsschrittes des Feldes konfigurierbarer Elemente umfaßt, wobei das Speichermittel zum Debug- ging auslesbar ist.
7. Vorrichtung nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, daß das Speichermittel als Dual-Ported-RAM mit einem ersten Eingang für abzuspeichernde Information aus dem Prozessorfeld und einem zweiten Eingang zum Auslesen der Information in ein Analysemittel ausgebildet ist .
PCT/DE2002/003278 1995-12-29 2002-09-03 Verfahren zum debuggen rekonfigurierbarer architekturen WO2003023616A2 (de)

Priority Applications (39)

Application Number Priority Date Filing Date Title
EP02772041A EP1449083B1 (de) 2001-09-03 2002-09-03 Verfahren zum debuggen rekonfigurierbarer architekturen
AU2002336896A AU2002336896A1 (en) 2001-09-03 2002-09-03 Method for debugging reconfigurable architectures
US10/487,687 US7480825B2 (en) 2001-09-03 2002-09-03 Method for debugging reconfigurable architectures
DE10297719T DE10297719D2 (de) 2001-09-03 2002-09-03 Verfahren zum Debuggen rekonfigurierbarer Architekturen
DE50210212T DE50210212D1 (de) 2001-09-03 2002-09-03 Verfahren zum debuggen rekonfigurierbarer architekturen
AU2002338729A AU2002338729A1 (en) 2001-09-19 2002-09-18 Router
EP02777144A EP1466264B1 (de) 1995-12-29 2002-09-18 Verfahren zur konfiguration der verbindung zwischen datenverarbeitungszellen
PCT/EP2002/010479 WO2003025781A2 (de) 2001-09-19 2002-09-18 Verfahren zur konfiguration der verbindung zwischen datenverarbeitungszellen
AT02791644T ATE533111T1 (de) 2001-09-19 2002-09-19 Rekonfigurierbare elemente
AU2002357982A AU2002357982A1 (en) 2001-09-19 2002-09-19 Reconfigurable elements
EP02791644A EP1472616B8 (de) 2001-09-19 2002-09-19 Rekonfigurierbare elemente
PCT/EP2002/010572 WO2003036507A2 (de) 2001-09-19 2002-09-19 Rekonfigurierbare elemente
JP2003538928A JP4456864B2 (ja) 2001-09-19 2002-09-19 リコンフィギュアブル素子
PCT/DE2003/000942 WO2003081454A2 (de) 2002-03-21 2003-03-21 Verfahren und vorrichtung zur datenverarbeitung
US10/508,559 US20060075211A1 (en) 2002-03-21 2003-03-21 Method and device for data processing
EP03720231A EP1518186A2 (de) 2002-03-21 2003-03-21 Verfahren und vorrichtung zur datenverarbeitung
AU2003223892A AU2003223892A1 (en) 2002-03-21 2003-03-21 Method and device for data processing
EP03776856.1A EP1537501B1 (de) 2002-08-07 2003-07-23 Verfahren und vorrichtung zur datenverarbeitung
AU2003286131A AU2003286131A1 (en) 2002-08-07 2003-07-23 Method and device for processing data
PCT/EP2003/008081 WO2004021176A2 (de) 2002-08-07 2003-07-23 Verfahren und vorrichtung zur datenverarbeitung
US10/523,764 US8156284B2 (en) 2002-08-07 2003-07-24 Data processing method and device
PCT/EP2003/008080 WO2004015568A2 (en) 2002-08-07 2003-07-24 Data processing method and device
EP03784053A EP1535190B1 (de) 2002-08-07 2003-07-24 Verfahren zum gleichzeitigen Betreiben eines sequenziellen Prozessors und eines rekonfigurierbaren Arrays
JP2005506110A JP2005535055A (ja) 2002-08-07 2003-07-24 データ処理方法およびデータ処理装置
AU2003260323A AU2003260323A1 (en) 2002-08-07 2003-07-24 Data processing method and device
US12/247,076 US8209653B2 (en) 2001-09-03 2008-10-07 Router
US12/354,590 US8069373B2 (en) 2001-09-03 2009-01-15 Method for debugging reconfigurable architectures
US12/570,943 US8914590B2 (en) 2002-08-07 2009-09-30 Data processing method and device
US12/621,860 US8281265B2 (en) 2002-08-07 2009-11-19 Method and device for processing data
JP2009271120A JP2010079923A (ja) 2001-09-19 2009-11-30 処理チップ、チップを含むシステム、マルチプロセッサ装置およびマルチコアプロセッサ装置
US12/729,090 US20100174868A1 (en) 2002-03-21 2010-03-22 Processor device having a sequential data processing unit and an arrangement of data processing elements
US12/729,932 US20110161977A1 (en) 2002-03-21 2010-03-23 Method and device for data processing
US12/947,167 US20110238948A1 (en) 2002-08-07 2010-11-16 Method and device for coupling a data processing unit and a data processing array
US13/023,796 US8686475B2 (en) 2001-09-19 2011-02-09 Reconfigurable elements
US13/279,561 US8407525B2 (en) 2001-09-03 2011-10-24 Method for debugging reconfigurable architectures
US13/796,215 US20130339797A1 (en) 2001-09-03 2013-03-12 Method for debugging reconfigurable architectures
US14/162,704 US20140143509A1 (en) 2002-03-21 2014-01-23 Method and device for data processing
US14/540,782 US20150074352A1 (en) 2002-03-21 2014-11-13 Multiprocessor Having Segmented Cache Memory
US14/923,702 US10579584B2 (en) 2002-03-21 2015-10-27 Integrated data processing core and array data processor and method for processing algorithms

Applications Claiming Priority (22)

Application Number Priority Date Filing Date Title
DE10142894 2001-09-03
DE10142904 2001-09-03
DE10142894.4 2001-09-03
DE10142904.5 2001-09-03
DE10144733 2001-09-11
DE10144733.7 2001-09-11
DE10145795.2 2001-09-17
DE10145795 2001-09-17
US09/967,497 2001-09-28
US09/967,497 US7266725B2 (en) 2001-09-03 2001-09-28 Method for debugging reconfigurable architectures
DE10154259 2001-11-05
DE10154259.3 2001-11-05
DE10202044.2 2002-01-19
DE10202044 2002-01-19
DE10202175 2002-01-20
DE10202175.9 2002-01-20
DE10206856 2002-02-18
DE10206856.9 2002-02-18
DE10207226 2002-02-21
DE10207226.4 2002-02-21
DE10240022.9 2002-08-27
DE10240022 2002-08-27

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US10487687 A-371-Of-International 2002-09-03
US12/354,590 Continuation US8069373B2 (en) 2001-09-03 2009-01-15 Method for debugging reconfigurable architectures

Publications (3)

Publication Number Publication Date
WO2003023616A2 true WO2003023616A2 (de) 2003-03-20
WO2003023616A8 WO2003023616A8 (de) 2003-08-21
WO2003023616A3 WO2003023616A3 (de) 2003-12-18

Family

ID=45871926

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2002/003278 WO2003023616A2 (de) 1995-12-29 2002-09-03 Verfahren zum debuggen rekonfigurierbarer architekturen

Country Status (4)

Country Link
EP (1) EP1449083B1 (de)
AT (1) ATE363098T1 (de)
AU (1) AU2002336896A1 (de)
WO (1) WO2003023616A2 (de)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2043000A2 (de) 2002-02-18 2009-04-01 PACT XPP Technologies AG Bussysteme und Rekonfigurationsverfahren
US9037807B2 (en) 2001-03-05 2015-05-19 Pact Xpp Technologies Ag Processor arrangement on a chip including data processing, memory, and interface elements
US9047440B2 (en) 2000-10-06 2015-06-02 Pact Xpp Technologies Ag Logical cell array and bus system
US9075605B2 (en) 2001-03-05 2015-07-07 Pact Xpp Technologies Ag Methods and devices for treating and processing data
CN112579460A (zh) * 2020-12-24 2021-03-30 中国航空工业集团公司西安航空计算技术研究所 一种基于多核嵌入式系统的多级调试方法
EP3791304A4 (de) * 2018-05-11 2022-03-30 Lattice Semiconductor Corporation Ausfallcharakterisierungssysteme und -verfahren für programmierbare logische vorrichtungen
US11914716B2 (en) 2018-05-11 2024-02-27 Lattice Semiconductor Corporation Asset management systems and methods for programmable logic devices

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6542998B1 (en) 1997-02-08 2003-04-01 Pact Gmbh Method of self-synchronization of configurable elements of a programmable module
US7996827B2 (en) 2001-08-16 2011-08-09 Martin Vorbach Method for the translation of programs for reconfigurable architectures
US8914590B2 (en) 2002-08-07 2014-12-16 Pact Xpp Technologies Ag Data processing method and device

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5425036A (en) * 1992-09-18 1995-06-13 Quickturn Design Systems, Inc. Method and apparatus for debugging reconfigurable emulation systems
US5680583A (en) * 1994-02-16 1997-10-21 Arkos Design, Inc. Method and apparatus for a trace buffer in an emulation system
US5754827A (en) * 1995-10-13 1998-05-19 Mentor Graphics Corporation Method and apparatus for performing fully visible tracing of an emulation

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5425036A (en) * 1992-09-18 1995-06-13 Quickturn Design Systems, Inc. Method and apparatus for debugging reconfigurable emulation systems
US5680583A (en) * 1994-02-16 1997-10-21 Arkos Design, Inc. Method and apparatus for a trace buffer in an emulation system
US5754827A (en) * 1995-10-13 1998-05-19 Mentor Graphics Corporation Method and apparatus for performing fully visible tracing of an emulation

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9047440B2 (en) 2000-10-06 2015-06-02 Pact Xpp Technologies Ag Logical cell array and bus system
US9037807B2 (en) 2001-03-05 2015-05-19 Pact Xpp Technologies Ag Processor arrangement on a chip including data processing, memory, and interface elements
US9075605B2 (en) 2001-03-05 2015-07-07 Pact Xpp Technologies Ag Methods and devices for treating and processing data
EP2043000A2 (de) 2002-02-18 2009-04-01 PACT XPP Technologies AG Bussysteme und Rekonfigurationsverfahren
EP3791304A4 (de) * 2018-05-11 2022-03-30 Lattice Semiconductor Corporation Ausfallcharakterisierungssysteme und -verfahren für programmierbare logische vorrichtungen
US11914716B2 (en) 2018-05-11 2024-02-27 Lattice Semiconductor Corporation Asset management systems and methods for programmable logic devices
CN112579460A (zh) * 2020-12-24 2021-03-30 中国航空工业集团公司西安航空计算技术研究所 一种基于多核嵌入式系统的多级调试方法
CN112579460B (zh) * 2020-12-24 2023-04-14 中国航空工业集团公司西安航空计算技术研究所 一种基于多核嵌入式系统的多级调试方法

Also Published As

Publication number Publication date
EP1449083B1 (de) 2007-05-23
WO2003023616A3 (de) 2003-12-18
AU2002336896A1 (en) 2003-03-24
WO2003023616A8 (de) 2003-08-21
ATE363098T1 (de) 2007-06-15
EP1449083A2 (de) 2004-08-25

Similar Documents

Publication Publication Date Title
EP2224330B1 (de) Verfahren und gerät zum partitionieren von grossen rechnerprogrammen
DE10333817B4 (de) Emulationsschnittstellensystem
DE10196310B4 (de) Vorrichtung und Verfahren zum Verifizieren eines Chip-Designs und zum Testen eines Chips
DE69915377T2 (de) Auf-chip fehlersuchsystem
DE69834892T2 (de) Eingebetteter Logikanalysator
EP1720100B1 (de) Verfahren und Vorrichtung zur Emulation einer programmierbaren Einheit
US20030046607A1 (en) Method for debugging reconfigurable architectures
DE4418892C2 (de) Mikrocomputer
DE19814415A1 (de) Logikanalyse-Untersystem in einem Zeitscheibenemulator
EP2962205B1 (de) Mehrkern-prozessorsystem mit fehleranalysefunktion
EP1449083B1 (de) Verfahren zum debuggen rekonfigurierbarer architekturen
EP0104635A2 (de) Verfahren und Anordnung zum Prüfen eines digitalen Rechners
WO2003081454A2 (de) Verfahren und vorrichtung zur datenverarbeitung
WO2004049159A2 (de) Einrichtung und verfahren zur analyse von eingebetteten systemen
EP0563597A2 (de) Asic-Prototyper
EP1716490B1 (de) Einrichtung und verfahren zur analyse von eingebetteten systemen für sicherheitskritische rechnersysteme in kraftfahrzeugen
DE3037475A1 (de) Schnittstellenschaltungsanordnung fuer eine datenverarbeitungsanlage
EP1283472A2 (de) Programmgesteuerte Einheit
DE3138989A1 (de) Zusaetzliche funktionseinheit in einem mikroprozessor, mikroprozessorsystem und verfahren zu seinem betrieb
DE112019007386T5 (de) Verbesserte jtag-register mit gleichzeitigen eingängen
DE69915788T2 (de) Mikrokontrollgerät mit Fehlerbeseitigungsunterstützung
EP3739479B1 (de) Verfahren zur fehlersuche in der programmlogik eines systems verteilter programmierbarer gatteranordnungen
DE102004008499B4 (de) Verfahren zum Emulieren einer integrierten Schaltung und Halbleiterchip
EP1224480B1 (de) Programmgesteuerte einheit und verfahren zum erkennen und/oder analysieren von fehlern in programmgesteuerten einheiten
DE2848621A1 (de) Verfahren zur rechnergesteuerten simulation der funktion einer mit logikschaltkreisen aufzubauenden schaltungsanordnung

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY CA CH CN CO CR CU CZ DE DK DM DZ EC EE FI GB GD GE GH GM HR HU ID IL IN JP KE KG KP KR KZ LC LK LR LS LT LV MA MD MG MK MN MW MX MZ NZ OM PH PL PT RO RU SD SE SG SI SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ UG ZM ZW AM AZ BY KG KZ RU TJ TM AT BE BG CH CY CZ DK EE ES FI FR GB GR IE IT LU MC PT SE SK TR BF BJ CF CG CI GA GN GQ GW ML MR NE SN TD TG AE AG AL AM AT AZ BA BB BG BR BY BZ CA CH CN CO CR CZ DE DK DM DZ EC EE ES FI GB GD GE GM HR HU ID IL IN IS JP KE KG KP KR KZ LK LR LS LT LU LV MA MD MG MK MN MX MZ NO NZ OM PH PL PT RO RU SD SE SI SK SL TJ TM TN TR TT TZ UA UG UZ VC YU ZA ZM ZW GH GM KE LS MW MZ SL SZ TZ UG ZM ZW

121 Ep: the epo has been informed by wipo that ep was designated in this application
CFP Corrected version of a pamphlet front page
CR1 Correction of entry in section i

Free format text: IN PCT GAZETTE 12/2003 ADD "DECLARATION UNDER RULE 4.17: - AS TO THE APPLICANT?S ENTITLEMENT TO CLAIM THE PRIORITY OF THE EARLIER APPLICATION (RULE 4.17(III)) FOR ALL DESIGNATIONS."

WWE Wipo information: entry into national phase

Ref document number: 2002772041

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 10487687

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2002772041

Country of ref document: EP

REF Corresponds to

Ref document number: 10297719

Country of ref document: DE

Date of ref document: 20050217

Kind code of ref document: P

WWE Wipo information: entry into national phase

Ref document number: 10297719

Country of ref document: DE

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Ref document number: JP

WWG Wipo information: grant in national office

Ref document number: 2002772041

Country of ref document: EP