pid no. 18414b 1 of 3 amd a 29k ? family technical bulletin using slow peripherals with 29k family processors epd systems engineering august 1, 1994 purpose usually, when a peripheral requests an interrupt from a 29k family processor, the interrupt handling software clears the interrupt source and the peripheral de-asserts the interrupt line. however, some peripheral devices are so slow that the 29k family processor is able to begin processing the interrupt again (as if it were a new interrupt) before the peripheral removes the original interrupt. this technical bulletin describes how to work around the disparity in speeds between a slow peripheral and a 29k family processor. affected parts the information in this bulletin affects the following parts: device revision all 29k family microprocessors and microcontrollers all slow peripherals if an external peripheral device requests an interrupt from a 29k family processor, the 29k family-based part clears the interrupt by reading or writing the appropriate external bits from the interrupt handler. then the interrupt handler performs an interrupt return sequence (iret). as part of the interrupt return, the processor looks for active interrupt sources. in the case of a peripheral device that is much slower than the 29k family processor, the peripheral device still has not processed the interrupt-clearing load or store, so the interrupt is still asserted. consequently, the processor sees an active interrupt and begins to process it (for the second time). after the processor determines that an interrupt is pending, and before the processor determines which interrupt is active, the slow peripheral device finally clears the interrupt condition. now the processor is not able to determine which peripheral called for an interrupt, so it defaults to trap 0 (the invalid op code trap). this situation is aggravated because the 29k family pipeline allows load and store bypassing until there is a direct dependency situation. therefore, simply moving the interrupt-clearing load or store earlier in the handler may not help, as the load or store is not guaranteed to actually execute any earlier. work-around the way to work around this situation is to force the load/store to complete and guarantee the peripheral has de-asserted the interrupt before the processor executes the iret. adding a serializing instruction between a load/store and an iret forces a load/store to complete before the iret, allowing more time for the peripheral to de-assert the interrupt line before the processor executes the interrupt return sequence. if the peripheral and processor are somewhat closely matched or if the interrupt handler is long, using a serializing instruction alone will often resolve the situation. however, if the speed disparity between the peripheral and the processor is significant, it may be necessary to guarantee that the peripheral has the time it needs to de-assert the interrupt line. this can be accomplished by using a busy loop or delay loop. using a busy loop is guaranteed to work even if the software is ported to a different-speed platform. however, for some applications the addition of a busy loop will degrade performance. using a delay loop does not involve the bus overhead of the busy loop, but a delay loop needs to be tuned for each system configuration.
pid no. 18414b 2 of 3 serializing instruction using a serializing instruction is generally an adequate work-around when the mismatch between peripheral and processor is on the order of several cycles. a serializing instruction requires that all other instructions in the pipe complete before it executes. as explained earlier, adding a serializing instruction between a load/store and an iret forces a load before the iret, maximizing the amount of time the peripheral has to clear the interrupt before the processor executes the interrupt return sequence. in the 29k family of microprocessors and microcontrollers, the serializing instructions are as follows. (note that for 29k family microcontrollers, any access to an internal peripheral control or status register is also a serializing instruction.) move to special register (mtsr) move to special register immediate (mtsrim) move to translation look-aside buffer (mttlb) interrupt return (iret) interrupt return and invalidate (iretinv) enter halt mode (halt) when adding a serializing instruction, most users choose to serialize using the mtsr gr xx , lru instruction. if the application does not use mmu, or all pages are mapped by the tlbs (page misses never occur), then serialization can be accomplished with this single instruction. otherwise, the special register value must be saved with an mfsr instruction before serialization occurs with an mtsr instruction. for example, an interrupt is cleared in an am85c30 peripheral device by writing a zero to the scc control register for that port. adding the serializing instruction would look like the following: msg_scc8530_tx_intr: ; reset tx interrupt. const it1, scc8530_cha_control consth it1, scc8530_cha_control const it0, 0 store 0, 1, it0, it1 mfsr it0, lru mtsr lru, it0 . {rest of handler} . iret adding the serializing instruction simply ensures that the interrupt-clearing load or store actually appears on the bus as soon as possible, maximizing the amount of time the peripheral has to clear the interrupt before the processor executes the iret. the following sections explain how to guarantee the peripheral has adequate time to clear the interrupt before the processor executes the iret. busy loop the work-around described above can be enhanced by following the interrupt-clearing load/store with a store/load loop that continues until the peripheral has had time to process the clearing of the interrupt. based on the same example from the previous section and using the busy loop approach, an interrupt handler that resets the transmit interrupt would look like the following msg_scc8530_tx_intr: ; reset tx interrupt. const it1, scc8530_cha_control consth it1, scc8530_cha_control const it0, 0 store 0, 1, it0, it1 bsy_loop: load 0, 1, it1, it0 cpeq it0, it0, 0 jmpf it0, bsy_loop nop . . {rest of handler} . iret although this is a guaranteed work-around, remember that the busy loop can degrade system performance for some applications. for this reason, it is desirable to overlap as much of the peripherals response time as possible with the interrupt handling. so, the busy loop in the above example could be moved after {rest of handler}. delay loop an alternate way to enhance the work-around is by adding a delay loop. this requires the developer to know the exact hardware parameters of the system as each delay loop is tuned to the specific parameters of the design under development. the positive tradeoff for this loss of flexibility is that the delay loop involves less bus traffic than the busy-loop, which may be very important in the system. in addition, this approach minimizes the overhead to the minimum required. the delay in the delay loop is determined by: delay = 2 cycles + access_time + periph_time the first two cycles are required to present the interrupt-clearing load/store to the bus. the access_time value is the time in processor cycles that
pid no. 18414b 3 of 3 is required for the peripheral to give a *rdy response to the load or store. the periph_time value is the number of processor cycles required for the peripheral to process the load/store and remove the interrupt request. so, using the same example from the previous two sections, consider a system with a 3-processor-cycle access time to the peripheral, and a peripheral that requires two of its cycles (six processor cycles) to process and clear the interrupt. in this case, the delay loop implementation is the following: msg_scc8530_tx_intr: ; reset tx interrupt. const it1, scc8530_cha_control consth it1, scc8530_cha_control const it0, 0 store 0, 1, it0, it1 mfsr it0, lru mtsr lru, it0 const it0, delay jmpf it0, . nop . . {rest of handler} . iret the value of delay is calculated as: delay = int(([2+3+6]-3) / 2; where 2 is the access time, the first 3 is the *rdy response time, 6 is the process interrupt clear time, the second 3 is the number of cycles to set up the delay loop, and 2 is the number of instructions in the loop. for more information for more information, see the appropriate processor users manual. if you need assistance product support for the 29k family processors is available from our embedded processor division (epd) technical support hotlines located in the u.s. and in the u.k. assistance is available in the u.s. from 9:00 a . m . to 6:00 p . m . central time, monday through friday (except major holidays). in europe assistance is available during u.k. business hours. contact us at one of the following numbers: to reach the u.s. hotline from call u.s. 1-800-2929-amd u.k. 0-800-89-1455 japan 0031-11-1163 any other location +1-512-602-4118 = = toll applies. to reach the u.k. hotline from call u.k. (0)256-811101 france 0590-8621 germany 0130-813875 italy 1678-77224 any other location +44-(0)256-811101 = = toll applies. amd is a registered trademark, and 29k and minimon29k are trademarks of advanced micro devices, inc.
|
