KR102333544B1 - An interrupt-driven i/o arbiter for a microcomputer system - Google Patents

Abstract

The I/O bus arbiter of the present invention is used with a CPU (processor) to perform burst mode data transfer in all I/O accesses, and DMA signals, bus-request/bus-grant signals, and bridges are unnecessary, so peripheral devices such as PCI It eliminates the need to connect the bus system to The I/O arbiter consists of a circular buffered interrupt controller, FIFO, and port engines to directly connect the device to the appropriate interface buffer with a compatible CPU interrupt signal, and only one arbiter is capable of synchronous data transfer. .

Description

AN INTERRUPT-DRIVEN I/O ARBITER FOR A MICROCOMPUTER SYSTEM

The present invention relates to I/O bus arbitration in microcomputer systems.

Conventional I/O bus arbiter and related technology development

A conventional I/O (Input/Output) bus arbiter is required for a simple as well as a complex multi-bus system of a System-On-Chip (SOC) architecture in which there are multiple arbiters as well as a bus. For example, a newer communications processor such as the Intel IXP435 has three bus arbiters, four buses and two bridges on one chip, if the SOC is a single-CPU based ARM architecture, or two hardware-assisted accelerators or coprocessors. even if so The Intel Pentium series of computer systems and other microcomputer-based SOC systems operate in the same manner.

Most arbiters require at least two signals: a REQ-GNT (Request-Grant) pair for a bus request signal from the device, and a corresponding bus grant signal from the arbiter. The same is true for CPU (processor), DMA (direct memory access), INT (interrupt) and BUSREQ-BUSGNT (bus request-bus grant; bus control signal pair). In other words, a complete understanding and familiarity with a specific system is required to implement a simple mediator. Often, DMA is also the most complex device in a PC system.

Conventional arbiters have little or no knowledge of I/O device conditions, in many cases predicting and simplifying complex hardware schemes such as prioritization algorithms and timestamps for aging, as well as other device transmission capabilities. It is necessary for other systems that can do it. These schemes need to be retrofitted in terms of current processing modules, such as packets required for broadband devices.

An example of how an I/O arbiter is implemented is a method using a popular arbiter chip in a conventional system. The Intel 8289 is one of the experimental stopover chips designed to work with the Intel 8288 bus controller and the Intel 8086 CPU, the predecessor of all Intel-based Pentium computers. It is part of the MCS-86 support chip family that was created after the introduction of the Intel 8086 CPU in 1978. With the 8289, multi-arbitration chips can be more disruptive when devices need bus arbitration as well as when an arbiter needs arbitration.

The development of complex intervention systems is already underway. The arbitration system introduced in US Patent 7096293B2 of Samsung Electronics, which was granted on August 22, 2006, relies heavily on the INT (interrupt) signal, which is the main CPU signal. However, even in this case, the existing REQ-GNT signal pair is still required for arbitration, so this patent makes the PCU bus essential.

Block MOVE, introduced in US Patent 5,185,694 issued on February 9, 1993 by Motorola, uses a CPU to allow a programmer to control burst-transmission of data. Although this invention employs burst-transfer between memories, this idea can also be applied to I/O.

Burst transfer or synchronous data transfer is required for all patented systems since 1993, and the present inventors viewed burst-transfer as the basic operation of the PCI bus specification made by Intel in 1994. From this point on, the same concept can be applied to general SDRAM used in microcomputers, and the same applies to DDR2 in 2002 and DDR2 in 2009.

For burst-transmission of data, a FIFO is needed to match the speed difference between the sending and receiving ports. In line with this trend, the I/O arbitration technology of the present invention was developed.

I/O Arbitrator

Current microcomputer systems see buses, arbiters, interrupts, DMAs, and bridges as separate entities that must be treated separately. The current model treats the Unix logical device driver model as a character device and a block device. Each device must have a different I/O bus. When there is more than one I/O bus, there must be a bridge to isolate these buses and jump from bus to bus. In this case, there must be an arbiter of devices bound to each bus, as well as an additional arbiter to arbitrate between each arbiter. In addition, in order to manage these independent data transfers, DMA signals, which are interrupt signals, must be connected. An example of such a complex system is the Intel IXP435 communications processor and the Intel Pentium series processor, both for PCs.

An object of the present invention is to provide a better model while removing some features to simplify the system while combining all these functional purposes into one.

The new I/O Arbitrator incorporates all proven data transfer technologies after years of use in many modern systems, such as burst-transfer or synchronous data transfer, FIFO, and hardware powered by Field-Programmable-Gate-Array (FPGA). By unifying the engines, we have come up with an I/O arbiter that is simple to understand and adopt, as well as at least equivalent if not better. A key feature is the consistency in handling the device for bus access without other intermediaries other than the present invention.

From the clean design best supported by the clean CPU design, the conventional interface signals used in the I/O arbiter, including the PCI bus, are unnecessary, and only a set of three synchronous clock signals controlled by the CPU and the CPU interrupt signal can be used in the system. can be completely removed.

The reason is that all processing in the computer system is controlled by interrupts. Thus, in creating an interrupt-driven processor that forces the system designer to think in terms of interrupts, other control signals that dampen interrupt signals may not be needed. By observing and doing all I/O operations, the internal operations flow like one uniform interrupt event and push the sources into the interrupt controller.

The paradigm is to view heterogeneous devices such as characters, blocks, boot ROM devices, and network devices as one homogeneous device with FIFOs and buffers. Homogeneous devices provide the same interface to the I/O arbitration engine and CPU, resulting in different sizes of buffers and FIFOs. In this case, the CPU does not have direct access to the control registers in the device and can only read/write complete 32-bit word blocks, eliminating the physical device driver code at the software level.

These models allow direct connection to devices of any complexity and eliminate the need for bus bridges and all buses such as PCI with electrical signal limitations other than one I/O arbiter.

Summary of the invention

1 is a schematic diagram of an I/O arbiter of the present invention with three main elements inside the CPU 100 and a device interface signal 106, an arbiter interrupt controller 105, a FIFO 104 and a port engine 103. shows Regardless of the nature of the character or block data transmission, the device is connected to the port engine, and the port engine is responsible for converting the 32-bit word from the FSM (Finite-State-Machine) or the engine for device format and signal control. .

The main function of this I/O arbiter 101 is to connect one of the seven FIFO buses to the CPU 101 bus, one at a time in a burst transfer. The device activates a dedicated INT signal to request attention by the associated FIFO, where the arbiter interrupt controller 105 queues the request in the circular buffer 216 on a first-in-first-out basis.

The I/O arbitration process begins at the port engine 103, which converts all data formats from the device 102 into a complete 32-bit word. The device sends a 32-bit data packet, and the I/O arbiter must buffer this data into the associated FIFO 104 . As a result, the CPU 100, like all other processes, must put this data in a buffer in the main memory. When the FIFO 104 is charged, the FIFO controller of the FIFO block 104 generates a unique interrupt. The I/O arbiter interrupt controller knows that a unique interrupt is from a particular port and queues the port ID into the pending interrupt circular buffer.

When the port ID activates this queue, the I/O arbiter activates the CPU INT (107) and waits for the CPU INTA (Interrupt-Acknowledgement) signal (108), and the I/O arbiter sends an interrupt vector that is the port ID to this signal. put on The CPU 100 reads this ID, jumps to an interrupt service routine (ISR) for this vector, and states that this port has a block of data in the FIFO 104 and reads all of them into the port's dedicated main memory buffer. know that

The data block writing process of the CPU 100 is reversed. The CPU 100 writes a block of data whenever possible, or in response to an interrupt via the I/O arbiter 101 . Note that in addition to the 32-bit word and port address that the CpU requires, it only reads or writes to the port in burst mode using the synchronous clock signal on the control line.

The I/O arbiter basically works based on the interrupt startup of the I/O port request service. All pending interrupts are queued in a circular buffer, and when an INTA is received from the CPU it is sent to the CPU's single interrupt pin with the associated vector. Each port has its own INT & INTA pins for queuing the I/O arbiter and sends an INT to the CPU.

1 is a schematic diagram of an I/O mediator of the present invention;
Figure 2 is an internal operation diagram of the I/O arbiter by all necessary interface signals.

It will be described in detail with reference to FIG. 2 . The I/O arbiter consists of an arbitration interface 200, an interrupt controller 201, a plurality of FIFO modules 204 including FIFO-0, and a plurality of port engines including a port-0 engine. A number of devices 202 are shown, including device-0, which are indicated by dashed boxes and do not constitute an arbiter. Here, device-0 (202), one of the device data paths, is connected to the I/O arbiter on behalf of other devices.

The key point is to control all synchronous burst transfers between the CPU 100 and the FIFOs with the CPU 100, which is why the CLK 209 signal is unidirectional. All independent DMA transfers by the device are not possible under these conditions. Whether reading or writing a set of data in response to an interrupt request, the initial connection of a FIFO device is initiated by a write command to the desired FIFO. This command is written to the FIFO by activating the WR 210 signal with _{each address line (A 12} -A ₀ ) 206 forming a Chip-Select (CS) signal that selects the FIFO device. When interrupting an instruction, the FIFO device is an open-drain connection and reacts with an active STP2 (207) signal tied to all STP2 (207) signals. Then, the CPU 100 operates the CLK 209, STP1 208, RD 211 and WR 210 signals to start burst mode data transmission.

A burst transfer protocol for a simple complete transfer for a block of data of a given length in main memory or FIFO.

Reading from device-0 202 is initiated by CPU 10 so that the _{WR 210 signal along with the respective address (A 12} -A ₀ ) 206 lines form CS_10 205 to form a FIFO -0 (204) Write the instruction to form the device. The FIFO-0 204 notifies the CLK 208 signal that it has stopped, recognizing that the write operation is in command phase without initiating a burst data transfer.

When FIFO-0 204 decodes that this instruction means that CPU 100 wants to read a set of data, FIFO-0 204 immediately sends signal STP2 207 indicating that it is preparing this instruction. At this point, the CPU 100 triggers the CLK 209 signal synchronously with the 32-bit data block in the FIFO-0 204 to initiate a burst-read sequence. After the predetermined block length has been transmitted, the FIFO-0 204 triggers the STP2 207 signal to inform the CPU that the end of the burst transfer has reached the end of the FIFO buffer.

Similarly when writing to FIFO-0 (204), following the instruction phase, FIFO-0 (204) decodes this instruction into a write instruction, followed by STP2 indicating that FIFO-0 (204) is waiting for this instruction. The (207) signal is activated immediately, at which time the CPU 100 activates the CLK (209) signal synchronously with the 32-bit data word block in main memory to start the burst write sequence. After the predetermined block length is transmitted, the CPU 100 activates the STP1 208 signal to notify the FIFO-0 204 that the burst transmission is over.

Burst transfer protocol for incomplete transfer of data blocks of unknown length in FIFO

The data transfer from the CPU 100 to the FIFO is always known under the control of software. The software always knows the number of data blocks and data length for a device for optimal data transfer. The only unavoidable variable is the data transfer from the device, that is, the burst read by the CPU 100, because there is no way to know in advance the number of data blocks and the data length coming from the device. For example, packets from a LAN device continue to flow in until the FIFO buffer overflows, in which case an interrupt occurs.

At this point, the interrupt controller starts to operate; There may be many devices that require the CPU 100 to read and empty the FIFO.

FIFO-0 (204) taking device-0 (204) as the datapath generates a unique interrupt when full and full. In the I/O arbiter, the interrupt controller 201 knows that the interrupt is from FIFO-0 204 and queues the port ID of the pending interrupt circular buffer 216 .

When the ID is queued, the I/O arbiter 101 activates the CPU INT 212 and waits for the CPU INTA 213 (interrupt-aware) signal, where the I/O arbiter 101 is the port ID. An interrupt vector is loaded into this signal. CPU 100 reads this ID and jumps to an interrupt service routine (ISR) for this vector, noting that this port has a datablock in FIFO-0 204. At the end of the FSM cycle, the interrupt controller 201 determines that the next device to be serviced is from FIFO-0 204, and sends an INTA 217 signal to FIFO-0 204. The FIFO-0 204 activates the STP2 207 signal to recognize that it is ready to transmit, allowing the CPU 100 to know that the burst-read sequence has begun. The CPU 100 then reads all of them into the main memory buffer reserved for port-0 204 . When FIFO-0(204) is empty, FIFO-0(204) operates STP2(207) signal to inform CPU(100) that block transfer is complete, and then waits for the next interrupt from device-0(202). Should be.

When the CPU 100 sends a burst write, the FIFO-0 204 triggers the STP2 207 signal to inform the CPU 100 when the FIFO buffer is full, in this case the CPU100) initiates a burst-write cycle. finish

Interrupt controller 201 manages all pending interrupts in the system, two signal pairs INT 212 - Requiring only INTA 212, it regenerates its own INT-INTA 217 cycle for all connected devices.

The above description describes how to attach any device to a port, whether it be characters or block devices, integrated circuits such as ROMs, hard disk drives, LANs, other CPUs, and DMA mechanisms, bridges, and anything else imaginable without additional buses or intermediaries. It provides the basis for the system.

Claims (10)

In an I/O arbiter block of a microcomputer system:
arbiter interrupt controller;
multiple first-in-first out buffers (FIFOs); and
A plurality of ports-engines; including,
the I/O arbiter block is implemented on a separate chip or integrated into a processor to eliminate many data transfer methods in a computer board, including a microcomputer board or SOC device;
Each FIFO and each port engine are implemented for each I/O device;
The I/O arbiter block uses a common processor interrupt signal pair (INT-INTA) and three synchronization signals (CLK, STP1, STP2) for synchronous burst transfer of data between the CPU and multiple FIFOs, All I/O devices are considered block devices;
and the I/O arbiter block does not require direct memory access (DMA) signals. 2. The method of claim 1, wherein the I/O arbiter block cooperates with a plurality of FIFOs and a plurality of port-engines with a common processor interrupt signal pair (INT-INTA) and three synchronization signals (CLK, STP1, STP2). An I/O arbiter block, characterized in that it is possible to remove all busbridges from the SOC or microcomputer. The I/O arbiter block according to claim 1, wherein the CLK signal is a synchronous data strobe, and STP1 and STP2 each indicate the end of a burst period input/output to/from the FIFO controller. 2. The synchronous burst of data according to claim 1, wherein the I/O arbiter block controls an address channel to a CPU address bus for a direct address of CPU main memory and obviates the DMA interface signals of the CPU for shutting down the CPU; DMA transfer is performed under CPU control using a common processor interrupt signal pair (INT-INTA) and three synchronization signals (CLK, STP1, STP2) to transmit and treat all I/O devices as block devices. I/O arbiter block to 2. The I/O arbiter of claim 1, wherein the I/O arbiter block obviates the conventional BUSREQ-BUSGNT signal pair that controls the CPU's bus mastering disabling the CPU address and databuses. block. The I/O arbiter block of claim 1, wherein the microcomputer system does not include any additional arbiters. delete delete delete delete

Images