fig1 is a schematic block diagram of a conventional hardware interrupt system . fig1 a is a timing diagram for the conventional hardware interrupt system . fig2 is a schematic block diagram of a hardware interrupt system having an interrupt queue . fig2 a is a timing diagram for the hardware interrupt system having an interrupt queue . fig3 is a schematic block diagram of an interrupt queue . fig4 is a flow chart showing the operation of the interrupt queue . fig5 and 6 are schematic block diagrams of hardware interrupt systems for use with both isa - like data buses and pci data buses . fig7 and 8 are schematic block diagrams of hardware interrupt systems for use with pci data buses . fig9 is a schematic block diagram of an interrupt queue connected serially to a cpu . fig1 is a state diagram of the serially - connected interrupt queue . referring to fig1 a conventional hardware interrupt system 100 , for use with cpu &# 39 ; s compatible with the intel 8086 family of microprocessors , has a central processing unit ( cpu ) 102 ( for example , one of the intel - 8086 family of microprocessors or a compatible equivalent , such as a 386 , 486 or pentium microprocessor ) that connects , via an interface chip 104 , to one or more 8259 family interrupt controllers 106 . usually , two 8259 family controllers are connected serially to one another , using a standard technique called cascading , forming one functional interrupt controller 106 . an industry standard architecture ( isa ) data bus 108 connects to both interface chip 104 and interrupt controller 106 , while cpu bus 109 connects interface chip 104 to cpu 102 . when interrupt controller 106 receives an interrupt request ( irq ) signal 110 from an i / o device 111 , interrupt controller 106 transmits an intr interrupt request 112 to cpu 102 . once cpu 102 acknowledges intr through several interrupt acknowledge signals inta 114 , interrupt controller 106 begins to generate and send the interrupt vector ( corresponding to the intr interrupt ) on the data lines of i / o bus 108 to cpu 102 via interface chip 104 . interrupt vectors are typically 8 bits wide and provide address information for accessing stored interrupt handling routines . fig1 a provides a timing diagram of these signals . the vertical lines represent the successive boundaries of system clock periods . interrupt controller 106 returns valid interrupt vector data 116 during the second assertion of inta line 114 . an access time 118 of 1 - 2 μ sec for the i / o bus causes an acknowledge latency 120 between the first inta acknowledge by the cpu and the receipt of valid interrupt vector 116 . the end of interrupt signal ( eoi ) represents an interrupt clearing signal to be decoded and interpreted by interrupt queue 204 and by interrupt controller 106 . an example of a clearing signal is the end - of - interrupt command that is sent to 8259 family interrupt controllers and that can be decoded by the circuitry of the interrupt queue . however , separate commands also can be sent to the interrupt controller and to the interrupt queue . referring to fig2 an enhanced hardware interrupt system comprises an interrupt queue 204 connected between cpu 102 and interrupt controller 106 . isa bus 108 connects to both interrupt queue 204 and interrupt controller 106 . when interrupt controller 106 receives an irq signal 110 , interrupt request 212 ( now denominated qintr ) from interrupt controller 106 routes to interrupt queue 204 . a secondary interrupt request 216 ( denominated pintr ) is sent by interrupt queue 204 to cpu 102 only when interrupt queue 204 has received a complete interrupt vector from interrupt controller 106 . fig2 a shows a timing diagram for signals in the enhanced hardware interrupt system . after interrupt controller 106 receives an irq signal 110 , it asserts qintr signal 212 to interrupt queue 204 . interrupt queue 204 then asserts two virtual inta ( v - inta ) signals back to interrupt controller 106 . during the second v - inta signal and i / o access delay 118 , interrupt controller 106 places valid interrupt vector 116 onto the data lines of data bus 108 . once interrupt queue 204 receives interrupt vector 116 , it asserts the pintr signal that then signals cpu 102 to begin a canonical interrupt acknowledge cycle uninterrupted by any access time delays . thus , the new acknowledge latency 220 can be as low as 5 clock periods , instead of 1 - 2 μsec . as shown in fig3 in interrupt queue 204 an isa bus arbiter 302 accepts a qintr 212 interrupt signal from interrupt controller 106 anded with inverted cpu interrupt signal pintr 216 ( to ensure that once the cpu interrupt signal is sent , qintr signal is ignored ). the isa bus arbiter then treats qintr interrupt 212 as a bus mastership request , in the same manner as other dma and isa bus requests 304 and 306 . ( references to isa bus arbiter 302 and isa bus cycle generator 314 can apply to their eisa , mca and / or pci equivalents for interrupt queues implemented in other bus architectures ). isa bus arbiter 302 then transfers the appropriate control signals ( e . g ., dma , isa , cpu bus mastership requests 308a , b , c ) as well as new do -- v -- inta request 310 to code type decoder 312 , which decodes these signals and issues appropriate isa cycle commands to isa bus cycle generator 314 . instead of transferring interrupt qintr 212 to cpu 102 , isa bus cycle generator generates virtual interrupt acknowledge signals v - inta back to interrupt controller 106 . during non - interrupt operations , isa bus arbiter 302 instructs isa bus cycle generator to generate normal cpu , isa and dma cycle requests . interrupt queue 204 allows cpu bus 311 to initiate isa accesses directly , and interrupt queue 204 creates virtual isa interrupt acknowledge cycles ( v - inta 214 ) when it grants the isa bus to the interrupt queue . v - inta signals 214 take the place of conventional cpu inta signals , while cpu interrupt acknowledge cycles inta are used to enable the contents of interrupt queue register 318 onto cpu data pins 109 , with a minimum number of wait states for those cycles . when interrupt controller 106 receives two v - inta acknowledge signals 214 , interrupt controller 106 places the appropriate interrupt vector onto the lower 8 bits of data bus 108 , which are then latched by latch 316 and tri - state buffer 318 , connected to cpu data bus 109 . ( depending on cpu requirements -- with 64 - bit data buses -- either the lower 8 bits or bits 32 - 39 can require a valid data value , so tri - state buffer 318 can be configured to place the same vector in both bus locations ). meanwhile , the trailing edge of v - inta signal 214 clocks through flip - flop 320 and latch 322 to provide a properly timed pintr signal 216 to cpu 102 . that is , pintr 216 will go high after two v - inta assertions , at the same time interrupt controller 106 provides the interrupt vector to latch 316 . thereafter , cpu 102 returns an asserted interrupt acknowledge inta to an inta decode block 324 that controls the enable signal for tri - state buffer 318 to properly latch the buffered interrupt vector onto cpu data bus 109 . meanwhile , the inverse of active pintr 216 will cause and gate 303 to temporarily ignore any new interrupts qintr 212 . it is also important for the isa arbiter ( eisa , mca or pci arbiters in other embodiments ) to ignore newly activated requests to generate v - inta , until the qintr deactivation latency after an eoi is met ( typically & lt ; 500 ns ), so that spurious interrupts will not be sent to the cpu due to pintr deactivating faster than qintr . inta decode block 324 can be constructed differently for pipelined and nonpipelined cpu architectures . the following tables represent the j and k inputs , and q outputs of flip - flops that can implement inta decode block 324 . ( the clk for each logic block is that of the cpu , &# 34 ;*&# 34 ; indicates and operations , &# 34 ;+&# 34 ; indicates or operations ). ______________________________________non - pipelinedj - k flip - flop for non - pipeline processors______________________________________input j ads * not mio * not dc * not wrinput k brdy (+ rdy ) + resetoutput q : cpu . sub .-- inta . sub .-- cycle 325______________________________________ ______________________________________pipelined______________________________________1st j - k flip - flop for pipelined processorsinput j ( not ads * not mio * not dc * not wr ) * non . sub .-- pipelined . sub .-- t1 + ( early . sub .-- inta * first . sub .-- t2 ) input k cpu . sub .-- inta . sub .-- cycle * ( brdy (+ rdy )) + resetoutput q : cpu inta . sub .-- cycle 3252nd j - k flip - flop for pipelined processorsinput j ( ads * not mio * not dc * not wr ) * not non . sub .-- pipelined . sub .-- t1input k pipelined . sub .-- t1 * early . sub .-- inta + resetoutput q : early . sub .-- inta3rd j - k flip - flop for pipelined processorsinput j ads * non . sub .-- pipelined t1input k nrdy * blast + rdy + resetoutput q : pipelined . sub .-- t1latch for pipelined processorsinput d pipelined . sub .-- t1 * not reset + non . sub .-- pipelined . sub .-- t1 * not resetoutput q : first . sub .-- t2______________________________________ in both the pipelined and non - pipelined versions , the output of inta decode block 324 , cpu -- inta -- cycle 325 , enables the contents of tri - state buffer 318 ( the interrupt vector ) onto cpu data bus 109 . enable cpu -- data line 330 allows a data transfer by the cpu to commence . the cpu -- rdy * signal 328 is generally a low - active signal that ends a data transfer by the cpu . in some processors , this signal is cpu -- brdy *. nor gate 326 gathers all sources of ready signals to send one combined ready signal to the processor . in interrupt queue 204 , the interrupt clearing signal eoi 332 clears pintr signal 216 from latch 322 , and goes active when the operating software for the cpu writes to interrupt controller 106 to clear the current interrupt . one implementation , that can be incorporated into code type decoder 312 , is shown in logic form in the following table : ______________________________________and gate for eoi signal______________________________________inputs ( cpu . sub .-- addr = 20 ) + ( cpu addr = a0 )! * ( cpu . sub .-- be = 0 ) * ( cpu . sub .-- command = io . sub .-- write ) * ( pipelined . sub .-- t1 + non . sub .-- pipelined . sub .-- t1output q : eoi______________________________________ however , a number of other embodiments could be defined for decoding end -- of -- interrupt signals to form eoi signal 332 . flow chart 400 of fig4 describes the sequential operation of a general interrupt queue , which can be implemented in an isa , eisa , mca , pci or equivalent bus . after the bus arbiter detects 402 a hardware interrupt , it sends 404 a virtual interrupt acknowledge signal v - inta to controller 106 . upon receipt 406 of the interrupt vector from interrupt controller 106 , the interrupt queue relays 408 interrupt signal pintr 216 to cpu 102 . then when interrupt queue 204 receives 410 normal acknowledge cycles inta from cpu 102 , it relays 412 the stored interrupt vector from tri - state buffer 318 to cpu 102 . finally , when cpu 102 writes to interrupt controller 106 to clear the interrupt , appropriate signals are generated 414 to clear the interrupt queue and the interrupt controllers . this scheme for queuing interrupts and corresponding vectors is invisible to software and interrupt controller operation , but acknowledge latency by the cpu is reduced , since cpu 102 can receive a complete interrupt vector as fast as possible after cpu 102 receives pintr 216 . fig5 and 6 show alternative schemes , where both a conventional isa data bus 108 and a peripheral component interconnect ( pci ) data bus 502 transmit information to cpu 102 . in both schemes , interrupts qintr 212 from interrupt controller 106 are sent to interrupt queue 204 . in first scheme 500 , the interrupt vector is sent directly to interrupt queue 204 , contained within an isa - pci bridge interface 504 , via isa bus 108 . the interrupt vector is then sent from interrupt queue 204 to the cpu via pci - cpu bridge interface 506 ( which also receives data inputs from pci bus 502 ). in second scheme 600 , the interrupt vector is sent to interrupt queue 204 , contained in pci - cpu bridge 606 , via isa bus 108 through isa - pci bridge interface 604 . in addition , data lines of pci bus 502 also connect to interrupt queue 204 . interrupts from interrupt queue 204 are then sent to cpu 102 via cpu bus 109 . where an interrupt queue 204 connects to cpu 102 through a pci bus 502 , the reset signal for queue 204 is provided by the pci rst # signal , which is low active . in addition , the apparatus shown in fig3 can be employed in such a pci environment by conforming all the cpu signals with their pci equivalents . in both alternative schemes 500 and 600 , the interrupt queue can be configured to store more than one , and more than one sort of , interrupt and interrupt vector . for example , pci architecture allows for a larger number of interrupts than isa architecture , and also allows interrupts to be handled with greater speed . interrupt vector register 304 can then be more than one vector deep ( 304a , 304b , etc .) to allow for multiple interrupt handling . this allows for pci interrupts and new device interrupts to be included in a personal computer without conflicting with isa or eisa interrupts . fig7 and 8 show further alternative schemes , where an interrupt queue 204 is incorporated into a system having only a pci data bus 502 connect to cpu 102 . again , in these two schemes , interrupts qintr 212 from interrupt controller 106 are sent to interrupt queue 204 . also , since pci interrupt acknowledges have only one cycle ( not two ), acknowledge latency is further reduced . in scheme 700 , the interrupt vector is sent to interrupt queue 204 , contained in pci - cpu bridge 606 , via pci bus 502 . interrupts from interrupt queue 204 are then sent to cpu 102 via cpu bus 109 . in scheme 800 , an interrupt queue 204 is incorporated directly within one or more 8259 family interrupt controllers . otherwise , operation of scheme 800 is the same as in scheme 700 . referring to fig9 in another scheme , a side band interrupt delivery mechanism 900 comprises an interrupt queue 204 connected to cpu 102 in a serial fashion with three wires . to eliminate bottlenecks in cpu bus 109 , interrupt queue 204 can serialize interrupt vectors . a compatible cpu 102 must have a serial - intr input 902 ( or a mode that would use the regular intr pin for this function ), a serial -- inta output pin 904 , and a serial -- clk input pin 906 . referring to fig1 ( a state diagram 1000 for the side band interrupt delivery system 900 ), interrupt queue 204 is normally in idle mode 1002 , keeping pin serial -- intr 902 high ( or inactive ). when interrupt queue 204 asserts serial -- intr 902 ( synchronized to serial -- clk ), cpu registers an interrupt request and interrupt queue 204 changes to an interrupt ready mode intrdy 1006 . interrupt queue 204 stays in intrdy so long as serial -- inta remains unasserted 1008 . once cpu 102 asserts 1010 serial -- inta 904 , interrupt queue 204 registers an interrupt acknowledge 1012 and begins to place the interrupt vector in serial form on serial -- intr 902 for as long as serial -- inta remains asserted ( typically eight serial -- clk 906 clocks ). once serial -- inta goes inactive 1014 , interrupt queue 204 returns to interrupt idle mode 1002 . other embodiments are also within the scope of the claims . for example , the interrupt queue may be useful with other families of microprocessors and other types of buses .