EP0961975A1 - Verfahren zum austausch von signalen zwischen über einen bus verbundenen modulen sowie vorrichtung zur durchführung des verfahrens - Google Patents

Verfahren zum austausch von signalen zwischen über einen bus verbundenen modulen sowie vorrichtung zur durchführung des verfahrens

Info

Publication number
EP0961975A1
EP0961975A1 EP98965282A EP98965282A EP0961975A1 EP 0961975 A1 EP0961975 A1 EP 0961975A1 EP 98965282 A EP98965282 A EP 98965282A EP 98965282 A EP98965282 A EP 98965282A EP 0961975 A1 EP0961975 A1 EP 0961975A1
Authority
EP
European Patent Office
Prior art keywords
bus
module
line
cycle
master
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP98965282A
Other languages
English (en)
French (fr)
Inventor
Hartmut B. Dr. Brinkhus
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Publication of EP0961975A1 publication Critical patent/EP0961975A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
    • G06F13/362—Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
    • G06F13/364—Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control using independent requests or grants, e.g. using separated request and grant lines

Definitions

  • the invention relates to a method for exchanging signals between modules connected via a bus and to an apparatus for carrying out the method.
  • Conventional computers have several hardware modules that are connected to a common bus, such as. B. the known ISA bus or PCI bus, are connected.
  • a common bus such as. B. the known ISA bus or PCI bus
  • additional lines are provided for special purposes, such as. B. special interrupt lines over the individual
  • Modules can request an interrupt from the CPU.
  • the number of modules that can request an interrupt increases.
  • the interrupt lines mentioned are more complicated Systems still other lines for special purposes and for the direct exchange of information between individual modules. These lines are hard-wired and cannot be changed or expanded later. This is the number of transferable between individual modules
  • the object of the present invention is to improve the method and device of the type mentioned at the outset in such a way that any can be used without additional outlay for lines
  • Amounts of information can be exchanged between individual modules.
  • the basic principle of the invention is that the information is exchanged via the common bus. No lines intended for specific signals are necessary for the exchange of information between modules, such as, for. B. for interrupt, DMA (direct memory access; direct memory access), etc.
  • the bus participant (module) that has to send information requests the bus on a single, common line (bus request), whereupon a clock-controlled cycle is started.
  • This cycle is e.g. processed as a command (RAK command) and consists of a RAK command that initiates the cycle and one or more RAK cycles, each the length of a
  • Each module is assigned a predefined period of time, preferably the length of a cycle, within which it sends its information to at least one bus line. During such a predefined period, several modules can also be addressed simultaneously if different bus lines are assigned to them. It is also possible to assign several bus lines to a module within a RAK command. The individual bus part Participants can also be contacted one after the other. The bus participant that has sent the request signal therefore sends its information over the previously defined line within the time window of the cycle assigned to it. Each bus participant is configured so that it can send or receive signals at one or more defined time windows. Several bus users can also be addressed in their function as receivers with one and the same cycle or time window. Conversely, a bus subscriber who has to send different messages to different other bus subscribers can send these messages within a full cycle at different time windows to which the receiver modules are configured.
  • module generally refers to individual bus users, which can be designed both as a plug-in module and as an IC (chip).
  • the invention is therefore also applicable to the exchange of information between individual chips which are integrated in a module, in which case these chips communicate with one another via the bus.
  • the current bus master e.g. the CPU or another module that is the current bus master
  • the bus master or another module can then use the bus again.
  • any number of bus users can send signals within their time window or time windows and during the remaining time periods of the
  • Any number of signals can be transmitted. - All types of signals can be transmitted and not just interrupt requests or DMA (Direct Memory Access) transfers, for example. All bus participants can transmit signals to everyone else. - A bus participant can e.g. B. send a signal, everyone else can receive it. So z. For example, cross-system signals, such as impending voltage failure or bus errors, are also signaled to all bus users. - The connections between the bus participants can be configured using software and reconfigured at any time. Extensions such as B. number of signals, only require a new software configuration. - The same procedure can be used for bus systems that are DMA or bus master capable. The slight additional load on the bus caused by this transmission or transmissions, on the other hand, is of no further importance. - All bus participants are therefore only connected to one another via the bus. There are no function or subscriber-specific lines or any additional lines (with the exception of a request line and possibly the RAK line).
  • Each bus participant consists of a functional part and a bus interface, hereinafter referred to as BIU (for bus interface unit).
  • the BIU is a circuit with which the bus participant is connected to the bus. It takes over certain activities that concern the bus without the functional part being involved. If, for example, a bus subscriber A or its functional part determines that the state of a specific signal has changed, so he reports this to his BIU. This was previously configured so that it should communicate this change to another or more bus users (clock and line). Now the BIU of bus participant A activates the bus request signal (bus request).
  • the bus subscriber B who is currently using or may use the bus is the so-called current bus master.
  • the BIU of the current bus master B places a RAK command (so-called RAK for request acknowledge) on the bus or signals this via an additional bus line. All connected BIUs recognize this command, including the BIU of bus participant A. Then one or more so-called RAK cycles (for request acknowledge) are carried out according to the configuration. If it is the turn of the RAK cycle for which bus node A has been configured, its BIU sends the state of the signal to the bus line for which A's BIU has been configured. This bus line is then regarded as a virtual connection line (VIL) between modules at this time. It leaves all other lines unaffected (tri-state). A number of signals corresponding to the bus width can thus be transmitted with each RAK cycle.
  • VIL virtual connection line
  • the number of RAK cycles in a RAK command is then the number of defined lines (VIL) divided by the bus width.
  • VIL defined lines
  • one and the same RAK cycle can be used by several bus users within a RAK command in accordance with the configuration and the bus width.
  • one or more lines can be assigned, up to
  • a bus participant who wants to become the new bus master must first get the bus. For this purpose, he also sets the bus request line active and the BIU of the current master executes a RAK command. The new bus master then sends a corresponding signal on the line assigned to it during the cycle assigned to it. If several bus participants want to become new bus masters, they all place this request on the corresponding bus lines during the cycle assigned to them. The BIU of the current bus master then determines the person who gets the bus. The algorithm for this is programmed and is set by the configuration master in the initialization phase.
  • Fig. 1 is a block diagram of several modules and some connecting lines; 2 is a timing diagram of a cycle;
  • 3 is a timing diagram of a full cycle and various other signals
  • Fig. 4-6 Time diagrams of signal sequences that are triggered by different events (change of state Fig. 4; signal edge Fig. 5; interrupt
  • FIG. 7 shows a basic circuit diagram of a bus interface unit (BIU) for a receiver
  • FIG. 8 shows a basic circuit diagram of a bus interface unit (BIU) for a master
  • Fig. 9 shows a basic circuit diagram of a bus interface unit (BIU) for a transmitter.
  • BIU bus interface unit
  • BIU Bus interface unit (bus. Interface Unit)
  • IRQ Interrupt Request ( . Interrupt Request)
  • VIL Virtual Interface Line (Virtual ⁇ nterconnection
  • VRQ request for a VIL (Virtual Interconnection
  • RQ Request Management (Request Management)
  • Fig. 1 several modules MO, Ml ... Mn are shown, which are connected at slots SPO, SP1 ... SPn to a bus with the lines BO to Bn.
  • a line RQ (in the following request line) is provided, which is set to a positive potential (logic level 1) by a pull-up resistor R1 and to which all modules are connected via corresponding lines BRQO, BRQ1 ... BRQn.
  • a clock line CLK, a reset line RESET and a bus cycle line AS are also shown here. Additional lines may be present, but are of no importance for the invention.
  • the bus can have any number of lines. In principle, any number of modules can also be connected.
  • one of the modules is the so-called bus master, which in the usual way sends signals via the individual bus lines. gene sends or receives from them. Wil is now another
  • a module that is not a bus master transmits information to one, several or all modules, it sends a bus request signal (bus request signal) to the bus request line RQ at any time via its BRQ line. by having a logic level “0" on it, otherwise being at logic "1" due to the pull-up resistor R1
  • the BRQ signal is therefore "active low”. This can also be done asynchronously to the clock on the CLK line. After the current bus activity has expired, the current bus master recognizes this request and triggers a request confirmation command (in the following RAK command for request acknowledge), even if it has nothing to do with the current request.
  • This cycle shown in Fig. 2 begins with a bus command RAK (for request acknowledge), which is output on any number of bus lines BO ... Bn and thus signals all other bus participants that now one or more RAK - follow cycles. All modules recognize this
  • VAK virtual confirmation cycles
  • VIL Virtual J. Interconnection Line
  • Each time window VAKO, VAKl ... VAKn defined by an individual VAK is assigned to one or more modules.
  • the VAKn can be assigned to the module Mn in the slot Spn, which, when it is the turn, on some or all of the bus lines BO to Bn for one Timing provides a signal on the bus.
  • RAK commands therefore all modules count the clock and thus also the sequence of the individual VAKs and therefore, depending on the initialization phase, know when it is their turn to send signals on the bus and also from which module these signals were sent. You can then read the signals intended for them during the corresponding VAK.
  • the current bus master then triggers a full RAK command and each module that has issued a bus request can then send its message to the line assigned to it during the time window or cycle assigned to it, i.e. during the corresponding VAK Lay bus.
  • the first two VAKs are preferably reserved for master requests, so-called MAKs, for example MAKO, MAK1. It is a special case of VAK's.
  • a MAK is a special case of a Group VIL. So all VILs of a RAK are combined.
  • the transmitters and receivers are predefined. In relation to the transmitters, each master is assigned the bus line corresponding to its slot number, whereby it may send the signal "I want to become master" via this line. With regard to the receivers, it applies that all bus users who want or need to determine the new master must evaluate all VILs of this RAK cycle.
  • the VILs that are not occupied by a master are masked in the receivers as invalid - based on MAK. But they could also be used as "normal" VILs.
  • the so-called configuration master determines the slots in which the master modules are located. In the case of, for example, an 8-bit wide bus and 16 bus participants, the following applies: If a master is in slot number 0 to 7, the corresponding line
  • VAKO kept free for a master acknowledge MAKO; If a master is in slot numbers 8 to 15, the corresponding line BO in VAK1 is kept free for MAK1. All lines not occupied by a MAK can then be occupied by virtual connecting lines VIL.
  • master acknowledge MAK cycles
  • Lines masked. Lines can also be open, since there may be no module or no master-capable module in a slot. If one of the unmasked lines is at "0", each module determines who will become the new master. The old master relinquishes control and the next master takes control, which only takes effect from the next bus command. The old master still applies while the RAK command is running. All master modules can determine and save the new master from the code that is on the bus during VAKO (MAKO) and VAK1 (MAK1), if they want or need this. It is sufficient if the master-capable modules process and evaluate the information during the MAK cycles. After a master change, the new master must always be granted a bus action. In any case, a command is carried out. The old master cannot immediately become the master again. The current master can immediately access the bus without delay due to bus arbitration access if no other master has requested the bus.
  • VAK cycles depends on the bus configuration or the number of modules and the number of VILs. In principle, a VAK cycle is provided for each module. A complete RAK command does not necessarily have to contain all VAK cycles but can be canceled if the last one
  • Module that issued a bus request it was their turn and sent its information. This can be signaled, for example, by the fact that each module, that has issued a bus request, keeps the line RQ at the logic "0" level until its assigned VAK cycle has ended. If other modules in the VAK sequence behind him have issued a bus request, these keep the RQ line on logic
  • each module has a BIU (bus interface unit) that controls the communication between the bus and the module.
  • Each BIU contains a. a memory or a register, in which is written during a configuration phase, which
  • VAK cycle is assigned to the respective module, which e.g. according to the slot of the modules.
  • These memories also contain a register set for the individual VILs, which defines the function of the VIL.
  • VILs There are two types of VILs, namely "single-
  • VIL "and" Group-VIL " While with the Single-VIL only one information can be transmitted on one bus line, with the Group-VIL all bus lines can be used. With the Group-VIL, however, it may be used during the give only one transmitter or only one receiver for each VAK cycle.
  • each line can be transmitted via any virtual line VIL (0 to 7, with 8-bit bus width) in any RAK cycle (e.g. 0 to 15).
  • the lines of a module are combined into a group depending on the bus width and transmitted in a RAK cycle.
  • a PC architecture it is e.g. For example, it makes sense that a master module that contains the PC central processing unit (PC-CPU) and the interrupt controller (s) receives all interrupt requests.
  • PC-CPU PC central processing unit
  • s interrupt controller
  • a special case of a VAK is used for this.
  • all interrupt sources must then put the state of their interrupt line on the bus.
  • the interrupt IRQO can be on line BO and the interrupt IRQn on line Bn, for example.
  • the RAK number and the bus line are specified for each interrupt line in the transmitter, ie modules that report the interrupt.
  • the receiver for PC architecture, the PC master with interrupt controller
  • only the RAK number in which the interrupts are delivered must be specified. In the
  • Configuration registers of the individual BIUs are defined for the virtual connection lines for each VIL, for example:
  • Bit3 Transmission of level or edge Bit4-7: RAK number at which VIL is transmitted (4 bit)
  • Bit8-13 Bus line number on which VIL is transmitted (only for single VIL)
  • the corresponding information is placed on the corresponding bus line with a corresponding RAK number.
  • the remaining lines remain in a so-called tri-state state, which means that they are released and then used by another bus part. can be "driven” and thus be set to logical 0 or 1.
  • the module In the configuration area, e.g. B. of an EEPROM, the module contains information about which type of RAK requires the function and which the BIU of the respective module masters. It also specifies whether there are restrictions on the assignment of a VIL to a bus line. Under certain circumstances, when configuring a VIL, it must be placed on a specific bus line.
  • the bus lines are used as CAD lines (for command / addresses / data).
  • one of the modules wants to send a signal to at least one other module.
  • the bus master ends its current bus activity at time t2 and issues the RAK command (request acknowledge) as a command on the bus in the time interval t2-t3. This is followed by a pause t3-t4, for example the length of a cycle.
  • the bus master sets the AS line to logic "0". This signal shows all bus participants that a command, here the RAK command, is on the bus.
  • this module outputs its information in the time interval t6-t7 to the bus line or lines that function during this time interval of VIL lines.
  • the module that made the request then takes it away from the line RQ. If no further module e has been sent in Request-S igna l, so the line RQ goes back to logic "1". At this point the RAK command can be canceled. However, it is also possible to complete this command until the VAKn in the time interval t8-t9. At time t9, the bus master or possibly a new bus master takes over the bus again and can start its activities.
  • a register can therefore be provided in the configuration area of each BIU, which records whether the corresponding module can suppress pauses and before which VAKs there are no pauses. If all existing modules can suppress these pauses, the distribution of the VILs can also take place from this point of view during the configuration.
  • the configuration master sets the appropriate registers in the BIUs. In this case, a RAK
  • the number of further VAK cycles can be freely defined and can in principle be of any size.
  • the individual VILs are defined in the configuration registers of the BIUs.
  • the modules that have defined one or more output lines for this VAK cycle activate the CAD line configured for them and place them on the current level or edge of the output signal. All modules that have defined an input for this cycle and for this CAD line temporarily store the status of the line and place it at the corresponding input.
  • the signal AS can also be used for another purpose. As shown in Fig. 3 shown, become inactive (HIGH) again immediately after the RAK command. It can but can also be used to inform the addressed bus user of the length of the command or the number of data. An 8-bit wide bus is assumed. With a write command, the recipient of the data does not know the number of data, sometimes for one
  • the master With a read access, the master also shows via AS how long it wants to read data. For a 16-bit wide bus, if the smallest addressable
  • Unit as usual is 1 byte, can be done as follows.
  • the bus delivers 2 bytes to the receiver for every clock cycle.
  • the receiver does not know the number of bytes actually sent by the sender as valid, which of both bytes or whether both are valid. This is then solved so that e.g. in the case of a write access, the recipient of the data is informed, on the one hand, of the receiving address (even or odd) and, on the other hand, of the number as a modulo in the command.
  • the recipient of the data can then determine whether he should only use 1 byte (then always the lower one) or both bytes in the last cycle of a command. As long as it is not yet the last cycle, which it recognizes at AS LOW, it uses both bytes. If AS becomes HIGH inactive, it is the last one
  • the signal AS can also be used by the master to indicate to bus participants that a command has been terminated prematurely. If the end has come too early for a bus participant, because it is only in a later RAK cycle it is his turn to make a bus request again.
  • VAK cycle Another special case of a VAK cycle is triggered by an interrupt request from a module. This is also announced on the RQ line. The corresponding VAK cycle is then defined as PAK (for PC interrupt acknowledge).
  • PAK for PC interrupt acknowledge
  • Outputs can be located on different modules, as with the other VILs.
  • the master is e.g. a PC module and configured for PC compatibility.
  • the modules that have a PC interrupt line for this master activate the corresponding line and set it to the desired level.
  • the master temporarily stores the level and passes it on to its PC-compatible interrupt controller. Interrupts that are not used are masked in the interrupt controller of the master. The unused lines remain in the tri-state state.
  • condition for triggering a request for a VIL can be specified in the configuration phase.
  • the following options are available:
  • the level or. Status is transmitted, whereby positive and negative edges can trigger a request. This is shown in Fig. 4 shown.
  • the status of the corresponding channel is always transmitted in the defined VAK cycle.
  • a request is triggered when the channel value (edge) changes.
  • the request shown in dashed lines in FIG. 4 comes from another module, which is then also served in the current RAK cycle at a corresponding time window.
  • Another possibility is to trigger the request with an edge (cf. FIG. 5). If a positive edge occurs, the will occur once in the corresponding VAK cycle Logically transfer the value "1", otherwise logically "0".
  • a PC interrupt can also be triggered using the VILs.
  • a VIL line is selected for transmission for an interrupt line. All PC interrupts can go from different transmitters to the receiver (Group VIL) during a VAK and can be kept ready for further processing by an interrupt controller.
  • the interrupt controller in PC architectures requires a positive edge on the IRQ line with a subsequent positive level to correctly execute the interrupt.
  • the IRQ line is reset to logic "0" after the IRQ has been processed.
  • an IRQ according to FIG. 6 can be treated on the receiver side.
  • the triggering of an IRQ by a VIL causes the receiver to set its corresponding IRQ register to "0" for a certain duration and then to display the IRQ by a positive edge followed by a high level. Even if the register has not been reset before, the IRQ is recognized correctly. It is therefore no longer necessary to reset the corresponding IRQ.
  • the configuration master determines the requirements and capabilities of the individual modules. This enables him to describe the VIL registers in all configuration areas of the BIUs. For example, if a module A wants to report the occurrence of an event to a module B via a VIL, the VAK and CAD number of the VIL in module A (output) must match the numbers of the VIL of module B (input) during configuration. This ensures that the information at the same time (VAK number) is on a defined
  • CAD number is transferred.
  • the configuration master distributes the VILs in such a way that on the one hand no conflict and on the other hand the lowest possible number of VAKs is required becomes.
  • the number of VAKs is also recorded in each BIU (configured by the configuration master).
  • BIU bus interface units
  • FIG. 7 Receiver (Fig. 7), a bus master (Fig. 8) and a transmitter (Fig. 9) are configured. Since each module can usually work as a transmitter and receiver, the circuits of FIGS. 7 and 9 are of course included in each module, whereby individual modules, such as counters, etc. can of course be used jointly for transmitter and receiver. As far as a module can also work as a master, the circuit of FIG. 8 is also included. 7 to 9 therefore serve only to explain the basic principle of the invention. The following description assumes that all three BIU's le, Im and ls have already been configured. The following description is adapted to the timing. If a module wants to send a signal as a transmitter, this is from the functional part of the module to the BIU ls (FIG. 9) on one line
  • a counter 9m is started in the master, which counts the maximum number of RAK cycles according to the configuration in the BIU of the master.
  • the bus for the CPU of the master is blocked during the RAK command. If the master has set the RAK line 13 active, approximately the same thing runs in parallel in the BIUs of the transmitter (FIG. 9) and the receiver (FIG. 7).
  • a counter 9e or 9s is started in both BIUs, which counts the clocks (CLK) on line 5.
  • the clock is provided here by a clock generator 14 in the BIU of the master and is supplied to all BIUs via a single common clock line 15. The clocks are counted as long as line 13 is active.
  • the outputs of the counters 9e and 9s are fed to a comparator 10e, 10s and compared with the content of a configured register 16e or 16s.
  • the RAK number of the corresponding clock for which the transmitter or receiver is configured is thus stored in these registers 16e, 16s.
  • the comparator 10s determines a match in the transmitter's BIU, ie "its" VIL cycle has been reached, it reports this via a line 12s to a decoder 18s, which is thereby activated, and a preprogrammed line number for the VIL from a register 17s decoded.
  • This activates one of the output signals 0 ... 7 of the decoder, namely that which corresponds to the configured line number of the bus.
  • the state of the signal to be sent is placed on the selected bus line D0 ... D7 via a tri-state buffer 19 assigned to this output and is therefore available to all other bus users.
  • the configured RAK number is recognized in the same way via the counter 9e, the comparator 10e and the configuration register 16e.
  • On Multiplexer 18e to whose inputs IN 0 ... IN 7 the bus lines D0 ... D7 are connected, selects the configured line based on the content of a configuration register 17e for the line number.
  • the output OUT of the multiplexer 18e thus carries the signal on the configured bus line.
  • This signal is fed to a flip-flop 19 which, after a predetermined delay time, which is determined by a delay element 20, clocks the flip-flop 19, at the output Q of which the received signal is conducted on a line 2e to the module of the receiver.
  • the maximum number of RAK cycles or RAK clock cycles is configured in a register lim and is compared in a comparator 10m with the content of the counter 9m. If the configured number of clock cycles has been reached, this is reported by the comparator 10m to the arbitration 7, which thus deactivates the "Grant BIU" signal, resets the start / stop unit 8, stops the counter 9 and the RAK signal the line 13 deactivated.
  • the RAK line 13 to which all BIUs are connected is shown in addition to the request line 5. This line is active as long as the RAK cycle is running.
  • this flip-flop can be reset and line 5 can be switched inactive. This can be recognized by the arbitration 7 in the BIU of the master, whereupon the RAK cycle is terminated prematurely via the start / stop unit 8. If several modules send a request at the same time or during a RAK cycle, the BIU of the sender that is configured to be the last to act will keep line 5 active, which ensures that all requests are serviced.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Bus Control (AREA)
  • Small-Scale Networks (AREA)

Abstract

Zum Übertragen von Information zwischen Modulen, die an einem gemeinsamen Bus angeschlossen sind, legt das Modul, das eine Information senden will, ein Anforderungssignal auf eine gemeinsame Bus-Anforderungsleitung. Das Modul (Bus-Master), das die Bus-Aktivitäten steuert, empfängt dieses Signal, sendet ein Kommando über den Bus an alle Bus-Teilnehmer und startet damit einen Zyklus von Taktimpulsen. Jedem Bus-Teilnehmer ist ein bestimmter Takt innerhalb eines Zyklus zugewiesen, währenddessen er auf einer oder mehreren vordefinierten Bus-Leitungen je ein Signal senden oder empfangen kann.

Description

Verfahren zum Austausch von Signalen zwischen über einen Bus verbundenen Modulen sowie
Vorrichtung zur Durchführung des Verfahrens
Beschreibung
Die Erfindung bezieht sich auf ein Verfahren zum Austausch von Signalen zwischen über einen Bus verbundenen Modulen sowie auf eine Vorrichtung zur Durchführung des Verfahrens. Herkömmliche Computer haben mehrere Hardware-Module, die an einen gemeinsamen Bus, wie z. B. den bekannten ISA-Bus oder PCI-Bus, angeschlossen sind. Zum Austausch bestimmter Signale zwischen den einzelnen Bus-Teilnehmern sind dort jedoch zusätzliche Leitungen für spezielle Zwecke vorgesehen, wie z. B. spezielle Interrupt-Leitungen, über die einzelne
Module einen Interrupt der CPU anfordern können. Je nach Anzahl der Module, die einen Interrupt anfordern können, steigt die Anzahl der entsprechenden Leitungen. Je komplexer die Systeme werden, desto mehr Leitungen werden benötigt, was den Verdrahtungsaufwand enorm ansteigen läßt. Neben den genannten Interrupt-Leitungen sind bei komplizierteren Systemen noch weitere Leitungen für spezielle Zwecke und zum direkten Informationsaustausch zwischen einzelnen Modulen vorgesehen. Diese Leitungen sind fest verdrahtet und können später nicht mehr geändert oder erweitert werden. Damit ist die Anzahl der zwischen einzelnen Modulen übertragbaren
Informationen bei diesen bekannten Systemen begrenzt.
Aufgabe der vorliegenden Erfindung ist es, Verfahren und Vorrichtung der eingangs genannten Art dahingehend zu verbes- sern, daß ohne zusätzlichen Aufwand für Leitungen beliebige
Mengen von Informationen zwischen einzelnen Modulen ausgetauscht werden können.
Diese Aufgabe wird für das Verfahren durch die im Anspruch 1 und für die Vorrichtung für die im Anspruch 7 angegebenen
Merkmale gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung sind den Unteransprüchen zu entnehmen.
Das Grundprinzip der Erfindung liegt darin, daß die Informa- tionen über den gemeinsamen Bus ausgetauscht werden. Für den Informationsaustausch zwischen Modulen sind keine für bestimmte Signale vorgesehene Leitungen notwendig, wie z. B. für Interrupt, DMA (direkter Speicherzugriff; Direkt Memory Access) , etc. Derjenige Bus-Teilnehmer (Modul) , der eine Information zu senden hat, fordert auf einer einzigen, gemeinsamen Leitung den Bus an (Bus-Request) , woraufhin ein taktgesteuerter Zyklus gestartet wird. Dieser Zyklus wird z.B. als Befehl (RAK-Befehl) abgewickelt und besteht aus einem RAK-Kommando , das den Zyklus einleitet und aus einem oder mehreren RAK-Zyklen, die je die Länge eines
Taktes haben. Jedem Modul ist ein vordefinierter Zeitraum von vorzugsweise der Länge eines Taktes zugeordnet, innerhalb dessen er seine Information an mindestens eine Bus-Leitung sendet. Während eines solchen vordefinierten Zeitraumes können auch mehrere Module gleichzeitig angesprochen werden, wenn ihnen unterschiedliche Bus-Leitungen zugeordnet sind. Auch ist es möglich, einem Modul innerhalb eines RAK-Befehles mehrere Bus-Leitungen zuzuordnen. Die einzelnen Bus-Teil- nehmer können auch zeitlich nacheinander angesprochen werden. Derjenige Bus-Teilnehmer, der das Request-Signal abgesandt hat, sendet seine Informationen also innerhalb des ihm zugewiesenen Zeitfensters des Zyklus über eine vorher defi- nierte Leitung. Jeder Bus-Teilnehmer ist dabei so konfiguriert, daß er zu einem oder mehreren festgelegten Zeitfenstern Signale senden oder empfangen kann. Mehrere Bus- Teilnehmer können in ihrer Funktion als Empfänger auch bei ein und demselben Takt bzw. Zeitfenster angesprochen werden. Umgekehrt kann ein Bus-Teilnehmer, der an unterschiedliche andere Bus-Teilnehmer unterschiedliche Nachrichten zu senden hat, diese innerhalb eines vollen Zyklus zu verschiedenen Zeitfenstern, auf die die Empfänger-Module konfiguriert sind, Nachrichten absenden.
Allgemein sei noch angemerkt, daß der Begriff "Modul" allgemein einzelne Bus-Teilnehmer bezeichnet, die sowohl als steckbare Baugruppe als auch als IC (Chip) ausgebildet sein können. Die Erfindung ist also auch auf den Informa- tionsaustausch zwischen einzelnen Chips anwendbar, die in einer Baugruppe integriert sind, wobei dann diese Chips über den Bus miteinander kommunizieren.
Hat ein Bus-Teilnehmer ein Request-Signal abgesetzt, so unterbricht bzw. beendet der aktuelle Bus-Master (z. B. die CPU oder ein sonstiges Modul, das aktueller Bus-Master ist) die laufende Bus-Aktivität und gibt den Bus für kurze Zeit frei, damit der oder die Bus-Teilnehmer, die den Bus-Re- quest abgesetzt haben, ihre Signale übertragen können. Danach kann der Bus-Master oder ein anderes Modul wieder den Bus nutzen.
Während eines solchen Zyklus können beliebig viele Bus-Teilnehmer innerhalb ihres Zeitfensters bzw. ihrer Zeitfenster Signale senden und während der übrigen Zeitabschnitte des
Zyklus Signale von anderen Bus-Teilnehmern empfangen. Mit der Erfindung erreicht man unter anderem folgende Vorteile: Es sind keine zusätzlichen Bus-Leitungen erforderlich außer der Request-Leitung und ggf. noch einer Steuerleitung (RAK) .
Es können beliebig viele Signale übertragen werden. - Es können alle Arten von Signalen übertragen werden und nicht nur beispielsweise Interrupt-Anforderungen oder DMA-Übertragungen (Direct Memory Access) . Alle Bus-Teilnehmer können Signale an alle anderen übertragen. - Ein Bus-Teilnehmer kann z. B. ein Signal senden, alle anderen können es empfangen. So können z. B. auch systemübergreifende Signale, wie drohender Spannungs- ausfall oder aufgetretener Busfehler, an alle Bus-Teilnehmer signalisiert werden. - Die Verbindungen zwischen den Bus-Teilnehmern können per Software konfiguriert und jederzeit neu konfiguriert werden. Erweiterungen, wie z. B. Anzahl der Signale, erfordern lediglich eine neue Software-Konfiguration. - Bei Bus-Systemen, die DMA- oder Bus-masterfähig sind, kann dasselbe Verfahren verwendet werden. Die geringfügige zusätzliche Belastung des Bus durch diese Übertragung oder Übertragungen fällt demgegenüber nicht weiter ins Gewicht. - Alle Bus-Teilnehmer sind somit einzig und allein über den Bus miteinander verbunden. Es gibt keine Funktionsoder Teilnehmer- spezifischen Leitungen oder irgendwelche Zusatzleitungen (mit Ausnahme einer Request-Leitung und ggf. der RAK-Leitung) .
Jeder Bus-Teilnehmer besteht aus einem Funktionsteil und einer Bus-Schnittstelle, im folgenden BIU (für Bus-Interface- Unit) genannt. Die BIU ist eine Schaltung, mit der der Bus-Teilnehmer an den Bus angeschlossen ist. Sie übernimmt bestimmte Aktivitäten, die den Bus betreffen, ohne daß der Funktionsteil involviert ist. Stellt beispielsweise ein Bus-Teilnehmer A bzw. dessen Funktionsteil fest, daß sich der Zustand eines bestimmten Signals geändert hat, so meldet er dies seiner BIU. Diese wurde zuvor so konfiguriert, daß sie diese Änderung an einen anderen oder mehrere Bus-Teilnehmer mitteilen soll (Takt und Leitung) . Nun setzt die BIU des Bus-Teilnehmers A das Bus-Anforderungssignal (Bus-Request) aktiv. Der Bus-Teilnehmer B, der den Bus gerade nutzt oder nutzen darf, ist der sog. aktuelle Bus- Master. Er erkennt den Bus-Request, beendet bzw. unterbricht seine laufende Bus-Aktivität und führt folgende Bus-Aktivitäten durch, wobei der Funktionsteil des Bus-Masters davon nichts "merkt", außer daß er für einen Moment den Bus nicht nutzen kann. Die BIU des aktuellen Bus-Masters B legt ein RAK-Kommando (sogenanntes RAK für Request Acknowledge) auf den Bus oder signalisiert das über eine zusätzliche Bus-Leitung. Alle angeschlossenen BIU's erkennen dieses Kommando, auch die BIU des Bus-Teilnehmers A. Sodann werden entsprechend der Konfiguration ein oder mehrere sog. RAK- Zyklen (für Request Acknowledge) durchgeführt. Ist der RAK-Zyklus an der Reihe, für den der Bus-Teilnehmer A konfiguriert wurde, so legt dessen BIU den Zustand des Signals an die Bus-Leitung, für die die BIU von A konfiguriert wurde. Diese Bus-Leitung wird dann zu diesem Zeitpunkt als virtuelle Verbindungsleitung (VIL) zwischen Modulen angesehen. Alle anderen Leitungen läßt sie unbeeinflußt (Tri-State) . Bei jedem RAK-Zyklus können somit eine Anzahl Signale entsprechend der Bus-Breite übertragen werden.
Die Anzahl der RAK-Zyklen in einen RAK-Befehl ist dann Anzahl der definierten Leitungen (VIL) geteilt durch die Bus-Breite. Der Bus-Teilnehmer A erkennt auch, daß die Änderung des Signals übertragen wurde und beendet dann den Vorgang. Alle übrigen Bus-Teilnehmer, wenn entsprechend konfiguriert, beobachten diese RAK-Zyklen und stellen so fest, ob für sie ein Signal dabei ist. Ist dies der Fall, so speichern sie die übertragene Information. Damit ist der Vorgang beendet.
Prinzipiell sind zwei Typen von Signalen zu übertragen: 1 • Zustand eines Signais
Bei jeder Änderung des Zustands des Signals wird ein Bus-Request mit nachfolgendem RAK-Befehl ausgelöst. Über die Bus-Leitungen wird in diesem Fall der aktuelle Zustand des Signals gemeldet.
2. Änderung eines Signals von logisch "0" auf logisch "1" (positive Flanke)
Wenn eine positive Flanke an einem Signal auftritt, wird ein Bus-Request mit nachfolgendem RAK-Befehl ausgelöst. Über die Bus-Leitungen wird in diesem Fall gemeldet, ob die Flanke aufgetreten ist (= 1) oder nicht (= 0) .
Bei jedem Bus-Request mit nachfolgendem RAK-Befehl werden immer alle Signale übertragen. Es ist aber auch möglich, die Anzahl der RAK-Zyklen dynamisch anzupassen, also abzubrechen, nachdem das gewünschte Signal übertragen wurde. Wenn ein Bus-Request mit nachfolgendem RAK-Zyklus durch einen dritten Bus-Teilnehmer ausgelöst wird, so wird bei den übrigen Signalen, die für "Zustand" konfiguriert sind, auch der jeweils aktuelle Zustand übertragen. Bei den Signalen, die für "Flanke" konfiguriert sind, wird eine logische "0" übertragen, d.h. es ist keine Flanke aufgetreten.
Auch können mehrere Signale von unterschiedlichen Bus-Teilnehmern gleichzeitig einen Bus-Request anfordern. Dann werden sie in einem einzigen RAK-Befehl bedient.
Für die RAK-Zyklen gilt, daß ein und derselbe RAK-Zyklus innerhalb eines RAK-Befehls entsprechend der Konfiguration und der Bus-Breite von mehreren Bus-Teilnehmern genutzt werden kann. Im RAK-Zyklus eines Bus-Teilnehmers können eine oder mehrere Leitungen zugeordnet werden, bishin zum
Extremfall, daß der entsprechende Bus-Teilnehmer in seinem RAK-Zyklus alle Bus-Leitungen nutzt, wobei in diesem Fall dann nur dieser eine Bus-Teilnehmer den RAK-Zyklus für sich alleine hat. Im anderen Extremfall, bei dem in einem RAK-Zyklus jedem für diesen konfigurierten Bus-Teilnehmer nur eine Leitung zugeordnet ist, können so viele Bus-Teilnehmer in diesem Zyklus senden, wie Bus-Leitungen vorhanden sind.
Mit der Erfindung ist es auch möglich, einen Multi-Master- fähigen Bus zu betreiben. Die Ermittlung des jeweiligen Masters wird nach demselben Prinzip vorgenommen. Ein Bus- Teilnehmer, der neuer Bus-Master werden will, muß sich zunächst den Bus holen. Hierfür setzt er ebenfalls die Bus-Request-Leitung aktiv und die BIU des noch aktuellen Masters führt einen RAK-Befehl durch. Der neue Bus-Master sendet dann während des ihm zugeordneten Zyklus ein entspre- chendes Signal auf der ihm zugeordneten Leitung. Falls mehrere Bus-Teilnehmer neuer Bus-Master werden wollen, so legen sie alle während des ihnen zugeordneten Zyklus diesen Wunsch auf die entsprechenden Bus-Leitungen. Die BIU des aktuellen Bus-Masters ermittelt dann daraus denjeni- gen, der den Bus bekommt. Der Algorhithmus hierzu ist programmiert und wird vom Konfigurationsmaster in der Initialisierungsphase festgelegt.
Im folgenden wird die Erfindung anhand eines Ausführungsbei- spiels im Zusammenhang mit der Zeichnung ausführlicher erläutert. Es zeigt:
Fig. 1 ein Blockschaltbild mehrerer Module und einiger Verbindungsleitungen ; Fig. 2 ein Zeitdiagramm eines Zyklus;
Fig. 3 ein Zeitdiagramm eines vollen Zyklus sowie verschiedener weiterer Signale;
Fig. 4-6 Zeitdiagramme von Signalfolgen, die durch unterschiedliche Ereignisse ausgelöst werden (Zustands- änderung Fig. 4; Signalflanke Fig. 5; Interrupt-
Request Fig. 6) ; und Fig. 7 ein Prinzipschaltbild einer Bus-Schnittstellen- einheit (BIU) für einen Empfänger; Fig . 8 ein Prinzipschaltbild einer Bus-Schnittstelleneinheit (BIU) für einen Master; und
Fig . 9 ein Prinzipschaltbild einer Bus-Schnittstel- leneinheit (BIU) für einen Sender.
Verwendete Abkürzungen:
BIU = Bus-Schnittstellen-Einheit ( Bus .Interface Unit)
CAD = Kommando/Adressen/Daten ( Commando/ Adressen/Daten )
CLK = Takt ( Clock)
DMA = Direkter Speicherzugrif f ( Direct Memory Access )
IRQ = Interrupt Anforderung (.Interrupt Request)
MAK = Master Bestätigung (Master Acknowledge)
MRQ - Master Anforderung (Master Request)
RAK = Bestätigung auf Anforderung (Request Acknowledge)
SP-Nr . = Steckplatz-Nummer f Steckplatz -Nr . )
VAK = Virtuelle Bestätigung (Virtual Acknowledge)
VIL = Virtuelle Schnittstellen-Leitung (Virtual ^nterconnection
Line )
VRQ = Anforderung einer VIL (Virtual Interconnection
Line Reguest)
RQ = Anf orderungs-Leitung (Request Leitung)
In Fig. 1 sind mehrere Module MO, Ml ... Mn dargestellt, die an Steckplätzen SPO, SP1 ... SPn an einen Bus mit den Leitungen BO bis Bn angeschlossen sind. Zusätzlich ist eine Leitung RQ (im folgenden Requestleitung) vorgesehen, die durch einen Pull-Up-Widerstand Rl auf positives Potential (logischen Pegel 1) gesetzt ist und an die alle Module über entsprechende Leitungen BRQO, BRQ1 ... BRQn angeschlossen sind. Weiter sind hier noch eine Taktleitung CLK, eine Resetleitung RESET und eine Bus-Zyklusleitung AS gezeigt. Weitere Leitungen können vorhanden sein, sind für die Erfindung aber ohne Bedeutung. Der Bus kann eine beliebige Anzahl von Leitungen haben. Prinzipiell kann auch eine beliebige Anzahl von Modulen angeschlossen sein.
Während des normalen Betriebes (nach der Initialisierungsphase) ist eines der Module der sogenannte Bus-Master, der in üblicher Weise Signale über die einzelnen Bus-Leitun- gen sendet oder von ihnen empfängt . Wil l j etzt ein anderes
Modul , das nicht Bus-Master ist , eine Information an eines , mehrere oder alle Module übermitteln , so sendet es zu einem beliebigen Zeitpunkt über seine Leitung BRQ ein Bus-Anforde- rungssignal (Bus-Request-Signal) zur Bus-Requestleitung RQ, indem es einen logischen Pegel " 0" auf diese ansonsten durch den Pull-Up-Widerstand Rl auf logisch " 1 " stehende
Leitung RQ legt . Das Signal BRQ ist also "aktiv Low" . Dies kann auch asynchron zum Takt auf der Leitung CLK erfolgen . Nach Ablauf der gerade laufenden Bus-Aktivität erkennt der aktuelle Bus-Master diese Anforderung und löst einen Anforderungs-Bestätigungs-Befehl ( im folgenden RAK-Befehl für Request-Acknowledge) aus, auch wenn er mit der aktuellen Anforderung nichts zu tun hat .
Dieser in Fig. 2 dargestellte Zyklus beginnt mit einem Bus-Kommando RAK (für Request-Acknowledge) , das auf beliebig vielen Bus-Leitungen BO ... Bn ausgegeben wird und damit allen anderen Bus-Teilnehmern signalisiert, daß jetzt ein oder mehrere RAK-Zyklen folgen. Alle Module erkennen dieses
Bus-Kommando und reagieren darauf. Nach dem Kommando RAK, das aktiv vom aktuellen Bus-Master auf den Bus übertragen wird, folgen virtuelle Bestätigungszyklen (im folgenden VAK genannt, für Virtual Acknowledge) VAKO, VAK1 ... VAKn, die durch den Takt auf der Leitung CLK definierte Zeiträume sind, wobei die einzelnen VAK's jeweils durch einen Takt Pause - sofern erforderlich - getrennt sind. In diesen virtuellen Acknowledge-Zyklen können dann die einzelnen Module Informationen über den Bus übertragen, dessen Leitungen dann nicht mehr die Funktion von normalen Bus-
Leitungen haben sondern als virtuelle Verbindungsleitungen VIL (für Virtual J.nterconnection Line) wirken.
Jedes durch ein individuelles VAK definierte Zeitfenster VAKO, VAKl...VAKn ist einem oder mehreren Modulen zugeordnet.
Beispielsweise kann das VAKn dem Modul Mn auf dem Steckplatz Spn zugeordnet sein, das dann, wenn es an der Reihe ist, auf einigen oder allen Bus-Leitungen BO bis Bn für einen Zeittakt ein Signal auf den Bus liefert. Während eines
RAK-Befehles zählen also alle Module den Takt und damit auch die Abfolge der einzelnen VAK's mit und wissen daher entsprechend der Initialisierungsphase, wann sie an der Reihe sind, Signale auf den Bus zu senden und auch, von welchem Modul diese Signale ausgesandt wurden. Die für sie bestimmten Signale können sie dann während des entsprechenden VAK lesen.
Es ist möglich, daß mehrere oder sogar alle Module zu einem
Zeitpunkt gleichzeitig einen Bus-Request absetzen. Der aktuelle Bus-Master löst dann einen vollen RAK-Befehl aus und jedes Modul, das einen Bus-Request abgesetzt hat, kann dann während des ihm zugeordneten Zeitfensters bzw. Zyklus, also während des entsprechenden VAK's, seine Mitteilung auf die ihm zugeordnete Leitung des Bus legen.
Bei der nachfolgenden Beschreibung handelt es sich um den
Sonderfall der Bus-Verteilung bei mehreren Bus-Mastern, die über denselben Mechanismus durchgeführt werden kann.
Wie aus Fig. 2 ersichtlich, sind vorzugsweise die beiden ersten VAK's (hier VAKO und VAK1) für Master-Requests, sog. MAK's, z.B. MAKO, MAK1, reserviert. Es handelt sich dabei um einen Sonderfall der VAK's. Allgemein formuliert ist ein MAK ein Sonderfall eines Group-VIL. Es sind also alle VIL's eines RAK zusammengefaßt. Die Sender und Empfänger sind vordefiniert. Bezogen auf die Sender wird jedem Master die seiner Steckplatznummer entsprechende Bus-Leitung zugeordnet, wobei er über diese Leitung gegebenenfalls das Signal "ich möchte Master werden" absetzt. Bezogen auf die Empfänger gilt, daß alle Bus-Teilnehmer, die den neuen Master ermitteln wollen oder müssen, alle VIL's dieses RAK-Zyklus auswerten müssen. Die VIL's, die nicht von einem Master belegt sind (z.B. weil kein Master auf dem Steckplatz sitzt) , werden in den Empfängern als ungültig - bezogen auf MAK - maskiert. Sie könnten aber auch als "normale" VIL's benutzt werden. In einer Konfigurationsphase stellt der sogenannte Konfigurationsmaster fest, auf welchen Steckplätzen Mastermodule sitzen. Bei dem Fall von z.B. einem 8 Bit breiten Bus und 16 Bus-Teilnehmern gilt folgendes: Sitzt ein Master auf Steckplatz-Nummer 0 bis 7, so wird die entsprechende Leitung
BO in VAKO für ein Master-Acknowledge MAKO freigehalten; sitzt ein Master auf Steckplatznummer 8 bis 15, so wird die entsprechende Leitung BO in VAK1 für MAK1 freigehalten. Alle nicht durch ein MAK besetzte Leitungen können dann durch virtuelle Verbindungsleitungen VIL belegt werden.
Entsprechend der Anzahl der möglichen Master werden ein oder zwei unmittelbar auf das RAK-Kommando folgende Zyklen als sog. Master Acknowledge (MAK-Zyklen) durchgeführt. Diese werden in den Zyklen VAKO und VAK1 abgebildet. Alle masterfähigen Module schalten während der MAK-Zyklen die ihnen zugeordnete Bus-Leitung RAKx aktiv und legen sie auf "0", wenn sie einen Master Request (MRQ) angefordert haben bzw. auf "1", wenn sie keinen MRQ angefordert haben (x = 0 für Master auf Slot 0, x = 1 für Slot 1 bis x = 15 für Slot 15) . Auf jedem Modul werden die nicht belegten
Leitungen maskiert. Leitungen können auch offen sein, da eventuell auf einem Steckplatz kein Modul oder kein masterfähiges Modul vorhanden ist. Wenn eine der nicht maskierten Leitungen auf "0" liegt, wird in jedem Modul ermittelt, wer neuer Master wird. Der alte Master gibt die Kontrolle ab und der nächste Master übernimmt die Kontrolle, die aber erst ab dem nächsten Bus-Command wirksam wird. Während des laufenden RAK-Befehls gilt noch der alte Master. Alle Mastermodule können den neuen Master aus dem Code, der während VAKO (MAKO) und VAK1 (MAK1) auf dem Bus liegt, ermitten und speichern, falls sie dies wollen oder brauchen. Es genügt, wenn die masterfähigen Module die Informationen während der MAK-Zyklen verarbeiten und auswerten. Nach einem Masterwechsel muß dem neuen Master in jedem Fall eine Bus-Aktion zugestanden werden. Es wird auf jeden Fall ein Befehl durchgeführt. Der alte Master kann somit nicht sofort wieder Master werden. Der aktuelle Master kann ohne Verzögerung durch die Bus-Arbitrierung sofort auf den Bus zugreifen, sofern kein anderer Master den Bus angefordert hat.
Da auf einem Bus mehrere Master liegen können und alle Module den aktuellen Master ermitteln können, ist vorgesehen, daß man in der Initialisierungsphase in den Modulen vorgeben kann, auf welchen Masters sie überhaupt reagieren. In der Initialisierungsphase wird ja auch die Adresse festgelegt, unter der die Module angesprochen werden können. Somit können also zwei Module auf dieselbe Adresse aber unterschiedliche Master konfiguriert werden. Damit wirkt die Angabe des Masters wie eine Erweiterung der Adresse. Das hat zum Beispiel eine Bedeutung bei einem Bus-System mit zwei Mastern. Jeder Master stellt einen PC dar, mit dem für die PC-Architektur festgelegten Adressen für 10-
Einrichtungen, wie z.B. für die Druckerschnittstelle LPT 1. Wenn jeder dieser beiden PC's eine Druckerschnittstelle LPT 1 haben soll, die jeweils auf einem Modul realisiert ist, gäbe es ein Problem, weil die IO-Adresse der Drucker- Schnittstelle dann im System zweimal vorkäme. Die Lösung besteht darin, daß in der Initialisierungsphase jedem Druckermodul zusätzlich zur selben IO-Adresse auch der Master mitgeteilt wird, dem es zugeordnet ist, von dem es also angesprochen werden kann. Damit können also in einem System mehrere gleichartige Architekturen realisiert werden, die parallel aber über denselben Bus arbeiten. Über andere, von allen Mastern ansprechbare Module, z.B. gemeinsame Speicherbereiche, können die Master untereinander Daten austauschen.
Die Anzahl der VAK-Zyklen hängt von der Bus-Konfiguration bzw. der Anzahl der Module und der Anzahl von VIL's ab. Prinzipiell ist für jedes Modul ein VAK-Zyklus vorgesehen. Ein kompletter RAK-Befehl muß nicht unbedingt alle VAK-Zyklen enthalten sondern kann abgebrochen werden, wenn das letzte
Modul, das einen Bus-Request abgesetzt hat, an der Reihe war und seine Informationen abgesetzt hat. Dies kann beispielsweise dadurch signalisiet werden, daß jedes Modul, das einen Bus-Request abgesetzt hat, die Leitung RQ so lange auf dem Pegel logisch "0" hält, bis sein zugeordneter VAK-Zyklus beendet ist. Haben noch weitere in der VAK- Reihenfolge hinter ihm liegende Module einen Bus-Request abgesetzt, so halten diese die Leitung RQ weiter auf logisch
"0". Hierdurch kann ein RAK-Befehl auch abgebrochen werden, sobald die Leitung RQ wieder auf logisch "1" geht, da dann alle Module wissen, daß kein weiterer VAK-Zyklus mehr folgen kann. Durch diese Maßnahme kann Übertragungszeit gespart werden und der Bus wird früher wieder für andere Bus-Teilnehmer freigegeben. VIL's, die häufig sich ändernde Signale übertragen, die also viele RAK-Befehle auslösen, sollten vorzugsweise RAK-Zyklen unmittelbar am Anfang des RAK-Befehls zugeordnet (konfiguriert) werden.
Zur Abwicklung der VIL-Funktionen hat jedes Modul eine Einheit BIU (Bus-Interface-Unit) , die die Kommunikation zwischen dem Bus und dem Modul steuert. Jede BIU enthält u. a. einen Speicher bzw. ein Register, in welches während einer Konfigurationsphase eingeschrieben wird, welcher
VAK-Zyklus dem jeweiligen Modul zugeordnet ist, was z.B. entsprechend dem Steckplatz der Module erfolgt. Weiter ist in diesen Speichern für die einzelnen VIL's ein Register- satz enthalten, der die Funktion der VIL festlegt. Dabei kann man zwei Typen von VIL's unterscheiden, nämlich "Single-
VIL" und "Group-VIL" . Während bei der Single-VIL nur eine Information auf einer Bus-Leitung übertragbar ist, können bei der Group-VIL alle Bus-Leitungen verwendet werden. Bei der Group-VIL darf es dann aber während des einzelnen VAK-Zyklus nur einen Sender oder nur einen Empfänger geben.
Bei der Funktion Single-VIL kann jede Leitung über eine beliebige virtuelle Leitung VIL (0 bis 7, bei 8 Bit Bus- Breite) in einem beliebigen RAK-Zyklus (z.B. 0 bis 15) übertragen werden.
Bei einer Group-VIL werden die Leitungen eines Moduls je nach Bus-Breite zu einer Gruppe zusammengefaßt und in einem RAK-Zyklus übertragen . Für eine PC-Architektur ist es z. B. sinnvoll, daß ein Mastermodul, das die PC-Zentraleinheit (PC-CPU) und den/die Interrupt-Controller enthält, alle Interrupt-Anforderungen gemeldet bekommt. Hierzu wird ein Spezialfall eines VAK verwendet. Alle Interrupt-Quellen müssen dann im Falle eines Bus-Request anschließend den Zustand ihrer Interrupt- Leitung auf den Bus legen. Der Einfachheit halber kann beispielsweise der Interrupt IRQO auf der Leitung BO und der Interrupt IRQn auf der Leitung Bn liegen. In der Konfi- gurationsphase kann trotzdem standardmäßig vorgegangen werden. Im Sender, d. h. Modulen, die den Interrupt melden, wird je Interrupt-Leitung die RAK-Nummer und die Bus-Leitung angegeben. Beim Empfänger (bei PC-Architektur der PC-Master mit Interrupt-Controller) muß nur die RAK-Nummer angegeben werden, in der die Interrupts geliefert werden. In den
Konfigurationsregistern der einzelnen BIU's wird für die virtuellen Verbindungsleitungen je VIL beispielsweise festgelegt:
VIL:
BitO: enable/disable der VIL
Bitl: Single-/Group-VIL
Bit2: Input/Output
Bit3 : Übertragung von Pegel oder Flanke Bit4-7: RAK-Nummer, bei der VIL übertragen wird (4 Bit)
Bit8-13: Bus-Leitung-Nummer, auf der VIL übertragen wird (nur bei Single-VIL)
Weitere Bits können reserviert bleiben.
Die genannten Sätze der Konfigurationsregister werden in einer Konfigurationsphase beschrieben.
Bei dem RAK-Befehl nach einem Bus-Request wird die entspre- chende Information bei entsprechender RAK-Nummer auf die entsprechende Bus-Leitung gelegt. Die übrigen Leitungen bleiben in einem sogenannten Tri-state Zustand, wodurch sie freigegeben sind und dann von einem anderen Bus-Teil- nehmer "getrieben" und dadurch auf logisch 0 oder 1 gelegt werden können .
Im Konfigurationsbereich , z . B . eines EEPROM' s , der Module steht die Information , welche Art von RAK die Funktion erfordert und welche die BIU des j eweiligen Moduls beherrscht . Dabei ist dort auch festgehalten , ob Einschränkungen der Zuordnung einer VIL auf eine Bus-Leitung besteht. So muß unter Umständen bei der Konfiguration auf den Wunsch einer VIL, auf eine bestimmte Bus-Leitung gelegt zu werden,
Rücksicht genommen werden .
Fig. 3 zeigt noch einmal detailierter den zeitlichen Ablauf . Vor dem Zeitpunkt tl werden die Bus-Leitungen als CAD-Leitun- gen (für Command/Adressen/Daten) verwendet. Zum Zeitpunkt tl möchte eines der Module ein Signal an mindestens ein anderes Modul senden. Es gibt daher zum Zeitpunkt tl ein Request-Signal auf die Leitung RQ , zieht diese also auf logisch "0" . Der Bus-Master beendet seine laufende Bus-Aktivität zum Zeitpunkt t2 und gibt das RAK-Kommando (Request Acknowledge) als Befehl im Zeitintervall t2-t3 auf den Bus . Darauf folgt eine Pause t3-t4 von beispielsweise der Länge eines Taktes . Gleichzeitig legt der Bus-Master die Leitung AS auf logisch " 0" . Dieses Signal zeigt allen Bus-Teilnehmern an , daß ein Kommando , hier das RAK-Kommando auf dem Bus liegt .
Alle Bus-Teilnehmer werten das Signal AS und das Kommando aus und erkennen , daß ein RAK-Befehl eingeleitet ist . Aufgrund ihrer Konfiguration kennen sie ebenfalls die Anzahl der VAK ' s , wodurch es ihnen möglich wird , den kompletten RAK-Befehl zu verfolgen . Ist für dasj enige Modul , das den
Bus-Request abgesetzt hat , die konf igurierte VAK-Nummer erreicht , beispielsweise die VAK-Nummer VAKx zum Zeitpunkt t6 , so gibt dieses Modul im Zeitintervall t6-t7 seine Information auf die Bus-Leitung oder -Leitungen , die während dieses Zeitintervalles die Funktion von VIL-Leitungen haben.
Zum Zeitpunkt t7 nimmt dann dasjenige Modul , das den Request abgesetzt hat , dieses wiederum von der Leitung RQ weg . Hat kein weiteres Modul e in Request-S igna l abgesetzt , so geht die Leitung RQ wieder auf logisch " 1" . Zu diesem Zeitpunkt kann der RAK-Befehl abgebrochen werden . Es ist aber auch möglich , diesen Befehl vollständig zu Ende zu führen bis zum VAKn im Zeitintervall t8-t9 . Zum Zeitpunkt t9 über- nimmt der Bus-Master oder eventuel l ein neuer Bus-Master wieder den Bus und kann seine Aktivitäten starten .
Prinzipiel l ist vorgesehen , daß nach j edem VAK innerhalb eines RAK-Befehl ein Takt Pause vorgesehen ist , um eine eventuelle Bus-Umkehrung zu ermöglichen . Es ist aber auch denkbar, daß bei aufeinanderfolgenden VAK' s keine Umkehrung des Bus erforderlich ist . In diesem Fall kann die Pause entfallen . Im Konf igurationsbereich j eder BIU kann daher ein Register vorgesehen sein , das festhält , ob das entspre- chende Modul Pausen unterdrücken kann und vor welchen VAK' s keine Pausen vorhanden sein müssen . Können alle vorhandenen Module diese Pausen unterdrücken, kann während der Konfiguration die Verteilung der VIL' s auch unter diesem Gesichtspunkt stattfinden. Der Konfigurationsmaster setzt die entsprechen- den Register in den BIU ' s . In diesem Fal le kann ein RAK-
Befehl schneller ablaufen .
Die Anzahl der weiteren VAK-Zyklen kann frei def iniert werden und im Prinzip beliebig groß sein . In den Konfigura- tionsregistern der BIU' s sind die einzelnen VIL festgelegt .
Selbstverständlich werden nur so viele VAK-Zyklen durchgeführt, wie nötig sind, um alle definierten VIL' s abzuwickeln. Während eines VAK-Zyklus schalten die Module, die für diesen VAK-Zyklus eine oder mehrere Ausgangsleitungen def iniert haben , die dafür konfigurierte CAD-Leitung aktiv und legen sie auf den aktuellen Pegel bzw. Flanke des Ausgangssignals . Alle Module, die für diesen Zyklus und für diese CAD-Leitung einen Eingang def iniert haben , speichern den Zustand der Leitung zwischen und legen sie an den entsprechenden Eingang.
Das Signal AS kann auch noch für einen anderen Zweck verwendet werden . Es könnte , wie in Fig . 3 gezeigt , nach dem RAK-Kommando sofort wieder inaktiv (HIGH) werden . Es kann aber auch weiter dazu benutzt werden, um dem angesprochenen Bus-Teilnehmer die Länge des Befehls bzw. die Anzahl der Daten mitzuteilen. Es sei ein 8-Bit breiter Bus angenommen. Bei einem Schreibbefehl ist dem Empfänger der Daten die Anzahl der Daten nicht bekannt, was manchmal auch für einen
Sender zutrifft, der am Anfang noch nicht weiß, wie viele Daten in einem Befehl geschrieben werden sollen. Der Bus- Master (CPU) kann z.B. nur 1 Byte, 1 Wort (= 2 Byte), ein Doppelwort (4 Byte) oder noch mehr Daten in einem Befehl übertragen wollen. Deshalb läßt er das Signal AS aktiv
LOW, solange er noch Daten senden will. Vor dem letzten zu schreibenden Byte setzt er AS dann inaktiv HIGH und beendet damit den Befehl. Bei einem Lesezugriff zeigt der Master über AS ebenfalls an, wie lange er Daten lesen will. Bei einem 16-Bit breiten Bus, wenn die kleinste adressierbare
Einheit wie üblich 1 Byte ist, kann folgendermaßen vorgegangen werden. Der Bus liefert bei einem Schreibbefehl bei jedem Takt 2 Byte an den Empfänger. Der Empfänger kennt aber nicht die Anzahl der tatsächlich vom Sender als gültig abgeschickten Byte, welche von beiden Byte oder ob beide gültig sind. Dies wird dann so gelöst, daß z.B. bei einem Schreibzugriff dem Empfänger der Daten zum einen die Empfangsadresse (gerade oder ungerade) und zum anderen die Anzahl als Modulo im Kommando mitgeteilt wird. Bei einem 16-Bit Bus benötigt man dazu im Kommando 1 Bit. Der Empfänger der Daten kann daraus dann ermitteln, ob er beim letzten Takt eines Befehls nur 1 Byte (dann immer das untere) oder beide Byte verwerten soll. Solange es noch nicht der letzte Takt ist, was er an AS aktiv LOW erkennt, verwertet es beide Byte. Wenn AS inaktiv HIGH wird, ist es der letzte
Takt. Bei einem noch breiteren Bus ist es prinzipiell genauso, nur daß es dann bei 32 Bit z.B. 2 Bit bedarf, um die Anzahl Modulo im Kommando zu übertragen.
Ansonsten kann das Signal AS auch vom Master benutzt werden, um den Bus-Teilnehmern den vorzeitigen Abbruch eines Befehls anzuzeigen. Wenn das Ende für einen Bus-Teilnehmer zu früh gekommen ist, weil er erst bei einem späteren RAK-Zyklus an der Reihe ist, muß er selbst noch einmal einen Bus-Request absetzen.
Ein weiterer Sonderfall eines VAK-Zyklus wird durch einen Interrupt-Request eines Moduls ausgelöst. Auch dies wird auf der Leitung RQ angekündigt. Der entsprechende VAK-Zyklus ist dann als PAK (für PC-Interrupt-Acknowledge) definiert. Aus Vereinfachungsgrunden werden alle VIL's eines VAK's zusammengefaßt und vordefiniert. Alle VIL-Eingänge eines PAK's sind auf einem einzigen Master lokalisiert. Die VIL-
Ausgänge können auf verschiedenen Modulen lokalisiert sein, wie bei den sonstigen VIL's auch. Der Master ist z.B. ein PC-Modul und für PC-Kompatibilität konfiguriert. Während eines PAK-Zyklus schalten die Module, die eine PC-Interrupt- Leitung für diesen Master haben, die entsprechende Leitung aktiv und legen sie auf den gewünschten Pegel. Der Master speichert den Pegel zwischen und gibt ihn an seinen PC-kompatiblen Interrupt-Controller weiter. Nicht benutzte Interrupts werden im Interrupt-Controller des Masters maskiert. Die nicht benutzten Leitungen bleiben im Tri-State-Zustand.
Die Bedingung für das Auslösen eines Request bei einem VIL kann in der Konfigurationsphase festgelegt werden. Dabei sind folgende Möglichkeiten gegeben:
Der Pegel bzw . Zustand wird übertragen , wobei positive und negative Flanken einen Request auslösen können . Dies ist in Fig . 4 dargestellt . Im def inierten VAK-Zyklus wird immer der Zustand des entsprechenden Kanals übermittelt . Ein Request wird bei einer Änderung des Kanalwertes (Flanke) ausgelöst. Der in Fig. 4 mit gestrichelten Linien dargestellte Request stammt von einem anderen Modul , das dann in dem laufenden RAK-Zyklus zu einem entsprechenden Zeitfenster mit bedient wird .
Eine weitere Möglichkeit besteht im Auslösen des Requests durch eine Flanke (vgl. Fig. 5). Beim Auftreten einer positiven Flanke wird im entsprechenden VAK-Zyklus einmal der Wert logisch "1" übertragen, sonst logisch "0".
Auch die Auslösung eines PC-Interrupts ist mit Hilfe der VIL's möglich. Für eine Interrupt-Leitung wird eine VIL-Lei- tung zum Versenden gewählt. Alle PC-Interrupts können so von verschiedenen Sendern während eines VAK's zum Empfänger (Group VIL) gelangen und zur Weiterverarbeitung durch einen Interrupt-Controller bereit gehalten werden.
Der Interrupt-Controller bei PC-Architekturen verlangt zur korrekten Ausführung des Interrupts eine positive Flanke an der IRQ-Leitung mit anschließendem positiven Pegel. Im Normalfall (PC) wird die IRQ-Leitung nach dem Abarbeiten des IRQ wieder auf logisch "0" gesetzt. Bei den VIL's würde dies zum Auslösen eines weiteren RAK-Zyklus führen, um den IRQ zurückzusetzen. Um dies zu sparen, kann auf Seiten des Empfängers ein IRQ gemäß Fig. 6 behandelt werden. Die Auslösung eines IRQ's durch ein VIL veranlaßt den Empfänger, sein entsprechendes IRQ-Register für eine bestimmte Dauer auf "0" zu setzen und anschließend den IRQ durch eine positive Flanke mit anschließendem hohen Pegel anzuzeigen. Selbst wenn das Register vorher nicht zurückgesetzt wurde, wird der IRQ korrekt erkannt. Ein Rücksetzen des entsprechenden IRQ's ist also nicht mehr nötig.
Während der Konfigurationsphase ermittelt der Konfigurationsmaster die Anforderungen und Fähigkeiten der einzelnen Module. Dadurch ist es ihm möglich, die VIL-Register in allen Konfigurationsbereichen der BIU's zu beschreiben. Will beispielsweise ein Modul A über eine VIL einem Modul B den Auftritt eines Ereignisses melden, so muß während der Konfiguration die VAK- und CAD-Nummer des VIL's im Modul A (Output) mit den Nummern des VIL's von Modul B (Input) übereinstimmen. Damit ist gewährleistet, daß die Information zum selben Zeitpunkt (VAK-Nummer) auf einer definierten
Leitung (CAD-Nummer) übertragen wird. Der Konfigurationsma- ster verteilt die VIL's so, daß zum einen kein Konflikt, zum anderen eine möglichst geringe Anzahl von VAK's benötigt wird. Die Anzahl der VAK's ist ebenfalls in jeder BIU festgehalten (vom Konfigurationsmaster konfiguriert) .
Die Fig. 7 bis 9 zeigen schematische Blockschaltbilder von Bus-Schnittstellen-Einheiten (BIU) , die für einen
Empfänger (Fig. 7) , einen Bus-Master (Fig. 8) und einen Sender (Fig. 9) konfiguriert sind. Da jedes Modul im Regelfall als Sender und Empfänger arbeiten kann, sind selbstverständlich die Schaltungen der Fig. 7 und 9 in jedem Modul enthalten, wobei einzelne Baugruppen, wie Zähler, etc. natürlich für Sender und Empfänger gemeinsam genutzt werden können. Soweit ein Modul auch als Master arbeiten kann, ist zusätzlich auch die Schaltung der Fig. 8 enthalten. Die Fig. 7 bis 9 dienen also ausschließlich zur Erläuterung des Grundprinzips der Erfindung. Bei der folgenden Beschreibung wird davon ausgegangen, daß alle drei BIU's le, Im und ls bereits konfiguriert wurden. Die folgende Beschreibung ist an den zeitlichen Ablauf angepaßt. Möchte ein Modul als Sender ein Signal senden, so wird dieses vom Funktions- teil des Moduls zu der BIU ls (Fig. 9) auf einer Leitung
2 übermittelt, beispielsweise in Form einer Impulsflanke, die ein Flip-Flop 3 setzt. Der Ausgang Q des Flip-Flops
3 aktiviert ein Tri-State-Gatter 4, dessen Ausgang mit der Request-Leitung 5 verbunden ist. Diese Leitung hat einen Pull-up-Widerstand 6 und ist "active Low" betrieben.
Dadurch können auch mehrere Busteilnehmer ggf. gleichzeitig diese Leitung 5 aktivieren. Alle BIU's aller Module sind an diese gemeinsame Leitung 5 angeschlossen.
Die BIU Im des aktuellen Bus-Masters (Fig. 8) erkennt dieses
Signal auf Leitung 5 und weiß damit, daß "jemand etwas zu melden hat" und löst einen RAK-Befehl aus. Dieses Signal auf der Request-Leitung 5 geht in der BIU Im des Masters an eine Arbitrierung 7, wo ermittelt wird, wann der Bus frei ist, um den RAK-Befehl durchzuführen. Diese Prüfung erfolgt über Signale "Request CPU" und "Grant CPU". Das Signal "Request CPU" kommt von der CPU des Masters und fordert den Bus für die CPU dieses Masters an. Das Signal "Grant CPU" zeigt der CPU des Masters an, wann der Bus frei ist. Ist der Bus frei, so setzt die Arbitrierung 7 ein Signal "Grant BIU" aktiv, wodurch eine Start/Stop-Einheit 8, die beispielsweise ein Flip-Flop sein kann, die RAK- Leitung 13 aktiv setzt und die VIL-Zyklen startet. Mit diesem Signal wird ein Zähler 9m im Master gestartet, der entsprechend der Konfiguration in der BIU des Masters die maximale Anzahl von RAK-Takten mitzählt. Während des RAK- Befehls ist der Bus für die CPU des Masters blockiert. Wenn der Master die RAK-Leitung 13 aktiv gesetzt hat, läuft in den BIU's des Senders (Fig. 9) und des Empfängers (Fig. 7) parallel in etwa dasselbe ab. In beiden BIUs wird jeweils ein Zähler 9e bzw. 9s gestartet, der die Takte (CLK) auf der Leitung 5 mitzählt. Der Takt wird hier von einem Takt- generator 14 in der BIU des Masters bereitgestellt und allen BIUs über eine einzige gemeinsame Taktleitung 15 zugeführt. Das Mitzählen der Takte erfolgt solange, wie die Leitung 13 aktiv ist. Die Ausgänge der Zähler 9e und 9s werden einem Vergleicher lOe, 10s zugeführt und mit dem Inhalt eines konfigurierten Registers 16e bzw. 16s verglichen. In diesen Registern 16e, 16s ist somit die RAK-Nummer des entsprechenden Taktes gespeichert, für den der Sender bzw. Empfänger konfiguriert ist. Sobald der Vergleicher 10s in der BIU des Senders eine Übereinstimmung feststellt, also "sein" VIL-Zyklus erreicht ist, meldet er dies über eine Leitung 12s an einen Decoder 18s, der damit aktiviert wird und aus einem Register 17s eine vorprogrammierte Leitungsnummer für die VIL decodiert. Dadurch wird eines der Ausgangssignale 0...7 des Decoders aktiv und zwar das, das der konfigurierten Leitungsnummer des Bus entspricht. Über ein diesem Ausgang zugeordnetem Tri-State-Buffer 19 wird der Zustand des zu sendenden Signales auf die ausgewählte Bus-Leitung D0...D7 gelegt und ist somit für alle anderen Bus-Teilnehmer verfügbar.
In der BIU des Empfängers wird über den Zähler 9e, den Vergleicher lOe und das Konf igurationsregister 16e in gleicher Weise die kon igurierte RAK-Nummer erkannt. Ein Multiplexer 18e, an dessen Eingänge IN 0... IN 7 die Bus- Leitungen D0...D7 angeschlossen sind, wählt die konfigurierte Leitung aus, aufgrund des Inhaltes eines Konfigurationsregisters 17e für die Leitungsnummer . Der Ausgang OUT des Multiplexers 18e führt somit das Signal auf der konfigurierten Bus-Leitung. Dieses Signal wird einem Flip-Flop 19 zugeführt, das nach einer vorgegebenen Verzögerungszeit, die durch ein Verzögerungsglied 20 bestimmt ist, das Flip- Flop 19 taktet, an dessen Ausgang Q das empfangene Signal auf einer Leitung 2e an das Modul des Empfängers leitet.
Um also ein Signal vom Sender zum Empfänger zu übertragen, müssen in beiden BIU's die Angaben "Konfiguration RAK-Nr." und "Konfiguration Leitung-Nr." übereinstimmen.
Die gesamte Abwicklung eines RAK-Zyklus wird durch die
BIU Im des Masters gesteuert. In einem Register lim ist die maximale Anzahl der RAK-Zyklen bzw. RAK-Takte konfiguriert und wird in einem Vergleicher 10m mit dem Inhalt des Zählers 9m verglichen. Ist die konfigurierte Anzahl von Takten erreicht, so wird dies von dem Vergleicher 10m an die Arbitrierung 7 gemeldet, die damit das Signal "Grant BIU" deaktiviert, die Start/Stop-Einheit 8 zurücksetzt, den Zähler 9 stoppt und das RAK-Signal auf der Leitung 13 deaktiviert.
Im Ausführungsbeispiel der Fig. 7 bis 9 ist zusätzlich zur Request-Leitung 5 noch die RAK-Leitung 13 gezeigt, an die alle BIU's angeschlossen sind. Diese Leitung ist solange aktiv, wie der RAK-Zyklus läuft.
Weiter oben wurde auch der Fall behandelt, den RAK-Zyklus zu verkürzen, d.h. nur solange laufen zu lassen, bis derjenige Zyklus erreicht ist, der dem Sender, der einen Bus- Request abgesetzt hat, sein zu sendendes Signal abgesetzt hat. Da bei der hier beschriebenen Konfiguration das Signal auf der Leitung 5 nur zum Auslösen eines RAK-Befehls verwendet wird, während des RAK-Befehls aber nicht mehr benötigt wird, kann diese Leitung dazu verwendet werden, ein ggf. vorzeitiges Ende des RAK-Befehls anzuzeigen. Hierzu kann in der BIU des Senders zu Beginn des RAK-Befehls "eingefroren" werden, daß sie einen Request angefordert hat. Beispielsweise könnte am Ausgang des Tri-State-Gatters 4 ein weiteres Flip-Flop vorhanden sein, das diesen Zustand speichert und die Leitung 5 solange aktiv hält, bis vom Vergleicher 10s die Meldung kommt, daß die konfigurierte RAK-Nummer erreicht ist. Danach - ggf. mit einer Verzögerung von einem oder mehreren Takten - kann dieses Flip-Flop rückgesetzt werden und die Leitung 5 inaktiv geschaltet werden. Dies kann von der Arbitrierung 7 in der BIU des Masters erkannt werden, worauf über die Start/Stop-Einheit 8 der RAK-Zyklus vorzeitig abgebrochen wird. Wenn mehrere Module gleichzeitig oder während eines RAK-Zyklus einen Request absetzen, so nält die BIU desjenigen Senders, der laut Konfiguration als letzter an der Reihe ist, die Leitung 5 aktiv, womit sichergestellt ist, daß alle Requests bedient werden.

Claims

Patentansprüche
1. Verfahren zum Austausch von Signalen zwischen an einen gemeinsamen Bus angeschlossenen Modulen, dadurch gekennzeichnet, daß dasjenige Modul, das ein Signal senden möchte, ein Bus-Anforderungssignal an eine gemeinsame Lei- tung (RQ) legt, daß dasjenige Modul (Bus-Master) , das den Bus zu diesem Zeitpunkt steuert, auf das Bus-Anforderungssignal seine momentane Bus-Aktivität beendet oder unterbricht und anschließend über den Bus ein Bestätigungskomman- do (RAK) an alle Bus-Teilnehmer sendet, daß darauffolgend jedes Modul Taktsignale auf einer gemeinsamen Taktleitung (CLK) mitzählt, wobei jeder Takt einen Zyklus (VAKO ...VAKn) definiert und jedem Modul (Mx) ein vorbestimmter Zyklus (VAKx) zugewiesen ist, und daß dasjenige Modul (Mx) , das das Bus-Anforderungssignal abgesetzt hat , während des ihm zugewiesenen Zyklus (VAKx) ein Signal auf mindestens eine vordefinierte Bus-Leitung ausgibt .
Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß einige oder alle der vorbestimmten Zyklen (VAKO...VAKn) durch mindestens einen Takt, der eine Pause bestimmt, voneinander getrennt sind.
3. Verfahren nach Anspruch 1 oder 2 , dadurch gekennzeichnet , daß dasjenige Modul, das das Bus-Anforderungssignal abgesetzt hat, nach Ablauf des ihm zugewiesenen Zyklus das Bus-Anforderungssignal beendet.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß auf ein Bus-Anf orderungssignal eine Zyklusfolge mit einer Anzahl n Zyklen abläuft, mit n gleich Anzahl von vordefinierten Verbindungen (VIL) geteilt durch die Bus-Breite.
5. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß auf ein Bus-Anf orderungssignal eines Moduls (Mx) eine Zyklusfolge mit nur so vielen Zyklen (x) abläuft, wie der dem anfordernden Modul (Mx) zugeordneten Anzahl von Zyklen entspricht.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß bei gleichzeitigem Absetzen mehrerer Bus-Anforde- rungssignale von mehreren Modulen so viele Zyklen ablaufen, wie dem Modul entspricht, dessen zugeordneter Zyklus zeitlich als letzter folgt.
7. Schaltungsanordnung zum Austausch von Signalen zwischen an einen gemeinsamen Bus angeschlossenen Modulen, dadurch gekennzeichnet, daß alle Module (M0...Mn) an eine gemeinsame Bus-Anforderungsleitung (RQ) angeschlossen sind, daß jedes Modul (M0...Mn) eine Bus-Schnittstellenschal- tung (BIUO ... BlUn) aufweist, daß jede Schnittstelleneinheit (BIUO...BlUn) ein programmierbares Register und einen Zähler aufweist, der Taktimpulse auf einer gemeinsamen Taktleitung (CLK) mitzählt, daß jede Schnittstelleneinheit eine Einrichtung aufweist, die die gemeinsame Bus-Anforderungsleitung (BQ) auf einen vordefinierten Pegel setzt, wenn das Modul ein Signal auf den Bus liefern will, daß mindestens ein Modul (Bus-Master) eine Schaltungs- einheit aufweist, die ständig den Zustand der Bus-Anforderungsleitung (RQ) überwacht und bei Auftreten des vorbestimmten Signals ein vordef iniertes Kommando auf den Bus ausgibt, daß die Bus-Schnittstelleneinheiten (BIUO ... BlUn) aller Module nach diesem Kommando die Takte mitzählen, daß in dem Register jeder Bus-Schnittstelleneinheit eine dem individuellen Modul zugewiesene Taktzahl gespeichert ist und daß dasjenige Modul, das das Bus-Anforderungssignal abgesetzt hat, bei Erreichen der ihm zugewiesenen Taktzahl ein Signal auf einige oder alle Leitungen (BO...Bn) des Bus gibt.
EP98965282A 1997-12-19 1998-12-18 Verfahren zum austausch von signalen zwischen über einen bus verbundenen modulen sowie vorrichtung zur durchführung des verfahrens Withdrawn EP0961975A1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE19756885A DE19756885B4 (de) 1997-12-19 1997-12-19 Verfahren zum Austausch von Signalen zwischen über einen Bus verbundenen Modulen sowie Vorrichtung zur Durchführung des Verfahrens
DE19756885 1997-12-19
PCT/EP1998/008318 WO1999032983A1 (de) 1997-12-19 1998-12-18 Verfahren zum austausch von signalen zwischen über einen bus verbundenen modulen sowie vorrichtung zur durchführung des verfahrens

Publications (1)

Publication Number Publication Date
EP0961975A1 true EP0961975A1 (de) 1999-12-08

Family

ID=7852750

Family Applications (1)

Application Number Title Priority Date Filing Date
EP98965282A Withdrawn EP0961975A1 (de) 1997-12-19 1998-12-18 Verfahren zum austausch von signalen zwischen über einen bus verbundenen modulen sowie vorrichtung zur durchführung des verfahrens

Country Status (5)

Country Link
US (1) US6425031B1 (de)
EP (1) EP0961975A1 (de)
CA (1) CA2281589C (de)
DE (1) DE19756885B4 (de)
WO (1) WO1999032983A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6775328B1 (en) * 1999-08-11 2004-08-10 Rambus Inc. High-speed communication system with a feedback synchronization loop
DE10011934A1 (de) * 2000-03-11 2001-09-13 Tenovis Gmbh & Co Kg Elektrisches Gerät
EP1150467A1 (de) * 2000-04-28 2001-10-31 STMicroelectronics S.r.l. Kodierstruktur für Parellelbusse
DE102009027625A1 (de) * 2009-07-10 2011-01-13 Robert Bosch Gmbh Elektrische Schaltung zur Übertragung von Signalen zwischen zwei Mastern und einem oder mehreren Slaves

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5088024A (en) * 1989-01-31 1992-02-11 Wisconsin Alumni Research Foundation Round-robin protocol method for arbitrating access to a shared bus arbitration providing preference to lower priority units after bus access by a higher priority unit
US5263163A (en) * 1990-01-19 1993-11-16 Codex Corporation Arbitration among multiple users of a shared resource
US5301283A (en) * 1992-04-16 1994-04-05 Digital Equipment Corporation Dynamic arbitration for system bus control in multiprocessor data processing system
US5623672A (en) 1994-12-23 1997-04-22 Cirrus Logic, Inc. Arrangement and method of arbitration for a resource with shared user request signals and dynamic priority assignment
US5907689A (en) * 1996-12-31 1999-05-25 Compaq Computer Corporation Master-target based arbitration priority
US6223237B1 (en) * 1998-07-07 2001-04-24 Adaptive Systems, Inc. Expandable communications bus

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9932983A1 *

Also Published As

Publication number Publication date
CA2281589C (en) 2005-02-08
CA2281589A1 (en) 1999-07-01
WO1999032983A1 (de) 1999-07-01
DE19756885B4 (de) 2005-04-21
US6425031B1 (en) 2002-07-23
DE19756885A1 (de) 1999-06-24

Similar Documents

Publication Publication Date Title
DE3300262C2 (de)
DE3300260C2 (de)
DE3909948C2 (de)
DE3204905C2 (de)
EP0179936B1 (de) Verfahren und Einrichtung zur Steuerung einer Sammelleitung
DE3300261C2 (de)
DE69825915T2 (de) Verfahren und vorrichtung zur umschaltung zwischen quellen-synchron-takt/- und gemeinsam-takt-datenübertragungs-modi in einem mehragent-übertragungs-system
EP0929041B1 (de) Verfahren und Anordnung zum Betreiben eines Bussystems
EP0772832B1 (de) Arbitrierung bei verzögernder buskopplung
DE2944497C2 (de)
DE3704056A1 (de) Peripherer dma-controller fuer datenerfassungssysteme
EP0006164B1 (de) Multiprozessorsystem mit gemeinsam benutzbaren Speichern
DE2230119C2 (de) Einrichtung zur elektronischen Überwachung des Auftretens von Ereignissen innerhalb bestimmter Zeitabschnitte
DE3606211A1 (de) Multiprozessor-computersystem
EP0772830A1 (de) Datenreduktion für buskoppler
DE2746064A1 (de) Datenspeicher mit auffrischung
DE102013113262B4 (de) Auslöser-Leitwegeinheit
DE19614237C1 (de) Kommunikationssystem mit einer Meisterstation und mindestens einer Sklavenstation
EP0892952B1 (de) Kommunikationssystem mit einer meisterstation und mindestens einer sklavenstation
DE2530599C2 (de) Verfahren und Schaltungsanordnung zur Steuerung von Ein-/Ausgabe-Geräten
EP0175095B1 (de) Datenübertragungsverfahren über einen Multiprozessorbus
DE19756885B4 (de) Verfahren zum Austausch von Signalen zwischen über einen Bus verbundenen Modulen sowie Vorrichtung zur Durchführung des Verfahrens
EP1308846B1 (de) Datenübertragungseinrichtung
EP1567938B1 (de) Speichersystem mit mehreren speichercontrollern and verfahren zu deren synchronisierung
EP0104638B1 (de) Verfahren zur Vorbereitung der Anschaltung einer von mehreren datenverarbeitenden Einrichtungen an ein zentral taktgesteuertes Mehrfach-Leitungssystem

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

17P Request for examination filed

Effective date: 19991125

17Q First examination report despatched

Effective date: 20070116

RBV Designated contracting states (corrected)

Designated state(s): AT CH DE FR GB IE IT LI SE

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

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

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

18D Application deemed to be withdrawn

Effective date: 20100219