You cannot send a PCI interrupt from SCC core to the MCPC. What you can do is to use the same way of communication that we use for the TCP/IP network connection. The TCP/IP driver on the SCC side writes to a memory location on the MCPC (the address space must be mapped through the LUTs). Because on SCC you cannot directly write to memory, everything must be done using packets/flits, you need to have you own driver code on the MCPC side to filter out the packets and initiate the action that you want. As a first step you could look into the sources of the MCPC driver and the SCC Linux driver to understand how the communication between SCC and MCPC has been implemented for the TCP/IP network.
It also would help us to guide you into the right direction if we would better understand what you exactly wants to achieve. Please elaborate a little bit more on your plans. Describe what should run on MCPC and what should run on SCC.
Here is our exact problem:
We have 48 cores and they want to sporadically communicate with the MCPC, say, for file I/O. We want to be able to write some stuff to memory and signal the host that data is ready. Currently, we have to have the host poll the memory and act when there is a change.
On the other side of the communication, the host can write to the MPB and the core can poll the MPB efficiently and there is no issue.
You could use the unmodified MCPC driver and update the host software (sccGui or a private application sccWhatever) to expect I/O packets from the SCC device (e.g. IO writes that are interpreted as "Data available Interrupt"). By default, the sccKit applications only print a warning when they receive IO requests (which are by default routed to the MCPC)... However, there's a hook in the API to replace the IO handler with special purpose user code. This code could be as simple as acknowleging the IO write and then picking up the data. If you think this could help, we could provide you with an example application as soon as the sccKit is available for download...