Hardware Interrupts

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
Post Reply
Posts: 95
Joined: 30 Sep 2020, 22:19

Hardware Interrupts

Post by Sugarplum »

While planning for doing an FPGA design, I've considered the feasibility of doing hardware interrupts. That would make it easier to separate out the video since the syncs could trigger interrupts, and it could make native coding a little easier.

Now, the first thing to do is reflect on all the operations that comprise a hardware interrupt. So the interrupt signal arrives. In a pipelined architecture, there needs to be a way to stall or "bubble" the pipeline. In our case, that may mean stopping the control unit and feeding a NOP while one is busy setting up the interrupt. We may need to be aware of certain instructions such as interrupting before or after a branch. For instance, if the interrupt happens after a jump, the delay slot might not run. It would likely be necessary to preserve the context of the currently executing code. While generally, a stack is used for this, we could allow only a single interrupt at a time and twin the registers. So you would write to both all the time but only use the second register all the time while running an ISR (interrupt service routine). Then you would look up the IVT (interrupt vector table) and then jump to that address. Then once IRET is reached, you reverse the above process.

Some architectures use other strategies. For instance, someone could have a separate core that is dedicated to servicing interrupts. The Propeller microcontrollers have multiple "cogs," and each cog could be dedicated to performing certain hardware operations or emulation. You could have one core for the keyboard, one for the mouse, 1-2 for video, 1-2 for sound, etc.

Now, a question comes to mind. Where would one put the IVT? For the Gigatron, all of the memory is spoken for. On an FPGA, you could provide a private BRAM area just for interrupts. The more I think about this, it likely should be located on the ROM somewhere. However, software wouldn't be able to change it (unless there are instructions for that and perhaps if you shadow it somehow). Now, the ROM isn't the most suitable for doing interrupts since the current architecture would make this difficult. But there is a possible way around this. You could have a dedicated ISR code block with a fixed "page" size. So in 1024 ROM addresses, you could have enough room for 4 ISRs that use 256 instructions each, or 8 using 128 instructions, or 16 using 64 instructions. The beauty of this approach is that you won't need an IVT since the ISR block is the IVT. The lowest bits would make up the "page" or "paragraph" size of the ISRs, the next bits up would be the interrupt number, and the highest bits could be 1 if you want this code at the end of the ROM. Or similarly, make this a jump/call table instead. That could waste less space and allow for future compatibility, such as support for extension ROMs. So the appropriate handlers could be anywhere in upper ROM memory and appropriate to the specific version of the device.
Post Reply