Forum Discussion
Altera_Forum
Honored Contributor
14 years agoHere's what *should* happen with a PCI board.
If I plug a board into a PCI slot, and do not install a driver, then the BIOS should configure the PCI interface on boot, and the interrupt line from the board should stay *disabled*. It sounds to me like your board is asserting its interrupt line onto the PCI bus when it should not. The OS is getting interrupted, an no one (no driver) is claiming the interrupt, so the OS gives up and crashes (Hey, it is Windows!). Try rebooting your machine with a 'real' device driver development OS like Linux, and the kernel will give you a warning indicating that there has been unhandled interrupts, so it will disable the IRQ. You would also be able to tell which IRQ the board has been assigned and whether any other devices on the bus are also using that interrupt. If for example your network interface and your MAX II card share the same IRQ line, then you *must* have a driver that handles interrupts correctly, otherwise the OS will disable the IRQ and you'll lose your networking. My recommendation is to keep trying PCI slots until you find an IRQ line that is exclusive to your board (under Linux lspci can be used to list the resources used by PCI boards). Having an exclusive IRQ will help in debugging code. If you are doing this for your job, then you really should have a PCI bus logic analyzer on hand too. So, take a step back. Operate the board in standalone mode on the bench. Run the design in Modelsim and see what happens when you push the push-button. Confirm this in hardware. Then modify the design to only enable the IRQ output if a control register is used to enable it, i.e., only if a device driver writes to the interrupt enable register. If you use the board under Linux, then you can use the sysfs PCI interface to access the registers on the board. What are you trying to do with the board? Cheers, Dave