SRIO Direct I/O and Doorbells

Hi Matt

I have the same questions.

But I'd also like to know if there is a separate queue for Doorbell tx and rx transactions. It wouldn't make sense to have the doorbell wait for all pending NWRITE packets to be DMA'd to memory.

What are the priority of doorbells? Can't find that in the spec.

Also, is it possible to setup the EDMA to send multiple 256 byte packets that constitute a video "line". Can an LSU_ICSR interrupt condition get tied to a EDMA event input? Its not clear to me how the LSU_ICRR registers route the EDMA event to RIOINT_LOCAL or RIOINT6 or RIOINT7 in Table 7-10 or the C6472 data sheet.

When an external device does a NWRITE_R to the DSP, the DONE response does not mean that the data has been moved from the 4k SRIO buffer to internal memory. True?

Regarding NWRITE vs SWRITE, I found this in teh RapidIO Part 1 spec

The NWRITE transaction allows multiple double-word, word, half-word and byte writes with properly padded and aligned (to the 8-byte boundary) data payload. The SWRITE transaction is a double-word-only version of the NWRITE that has less header overhead.

Cheers

Eddie

Hi Eddie,

Eddie said:

I have the same questions.

It's a bit tricky some of this stuff but I think we're beginning to get to the business end of our project and I'm soon going to find out how well it works in practice!

Eddie said:

But I'd also like to know if there is a separate queue for Doorbell tx and rx transactions. It wouldn't make sense to have the doorbell wait for all pending NWRITE packets to be DMA'd to memory.

I'm still confused by this but keep reading things that imply that you can use Doorbells and know that all the data has arrived. For example from spru976c.pdf Section 4.2 "Thus, a simple counter within the peripheral ensures that data packets have arrived in memory before submitting an interrupt."

I'm worried because I think this might be saying that the SRIO peripheral will guarantee to queue Doorbell interrupts until all memory transfers that arrived before it have completed but this is not the same as saying the transactions will arrive in the order they were sent. In other words you could send an NWRITE followed by a Doorbell but the SRIO switch fabric doesn't guarantee to deliver them in the same order.

In our case we have a short run point-to-point connection and are in total control of the loading hence I guess that if we keep the loading down to avoid buffers becoming full we won't get packet retries or errors and the packets will arrive in the order they are sent.

Eddie said:

When an external device does a NWRITE_R to the DSP, the DONE response does not mean that the data has been moved from the 4k SRIO buffer to internal memory. True?

I don't know whether it is true or false but I think in this case the description in section 4.2 does apply. In other words section 4.2 says interrupts won't be generated until all pending DMA transfers are complete.

Eddie said:

Regarding NWRITE vs SWRITE, I found this in teh RapidIO Part 1 spec

The NWRITE transaction allows multiple double-word, word, half-word and byte writes with properly padded and aligned (to the 8-byte boundary) data payload. The SWRITE transaction is a double-word-only version of the NWRITE that has less header overhead.

I've been reading the spec and also "RapidIO The Embedded System Interconnect" by Sam Fuller and had seen this since writing my original post. I haven't read much of the book yet but it is a bit easier to read than the spec. Sam Fuller also gives examples e.g. on p.26 he talks about typical latencies being less than 100 nanoseconds (I'm not entirely sure what this means but it's better than nothing).

Mainly I'm hoping that SRIO will just work and I won't need to understand it! There's always hope, right? :-}

Matt

Hi Matt

Matt said:

I'm still confused by this but keep reading things that imply that you can use Doorbells and know that all the data has arrived. For example from spru976c.pdf Section 4.2 "Thus, a simple counter within the peripheral ensures that data packets have arrived in memory before submitting an interrupt."

This is where I'm REALLY confused. According to spru976c.pdf, the MAU is responsible for receiving all packets (LSU for transmit). Hence shouldn't there be a register for MAU generated interrupts since it is the manager of received packets sent by a peripheral NWRITE transaction? The only interrupt status and clear registers are for the Doorbell, CPPI, and LSU. No registers are specified for the MAU!!!!

2.3.1 Component Block Diagram
Figure 8 shows the SRIO peripheral component block diagram. The load/store unit (LSU) controls the
transmission of direct I/O packets, and the memory access unit (MAU) controls the reception of direct I/O
packets.

Or when the say "submitting an interrupt", are they referring to the Message Protocol Part II transaction where the CPPI is used. I wish they would better differentiate what is direct IO (Part I) specific and what is Message Protocl (Part II) specific.

I'm trying to transfer large video frames using the direct IO (Part I) facilities, although it would be very handing to use the "Interrupt Pacing" in Message Protocol. But I don't think the FPGA guys want to implement that level of complexity. So I'm stuck with them sending me a Doorbell at the end of N 256 byte packets. Hence the reason for wanting to know about Doorbell priorities and if the NWRITE_R DONE response occurs after the DMA transaction is complete.

Have you seen this thread. It may have some good info for you.

http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/p/11539/117741.aspx#117741

Cheers
Eddie

Hi Eddie,

Section 3.4 Operations and Transactions of "RapidIO: The Embedded System Interconnect" talks about transaction ordering and the idea of a transaction request flow. A transaction request flow contains an ordered sequence of transactions where all the transactions have the same source, destination and priority. The logical layer will follow some rules about transaction request flows which basically mean the logical layer will deal with transactions in order.

Section 3.4.2 talks about 2 types of processing elements: unordered and ordered.

I think this means we are asking questions about stuff that has been fully considered in the design of RapidIO but I unfortunately I still don't really understand what it means to me and my specific application.

I shall continue to think about it as I investigate how our system works!

Matt

Hi Matt

Thats a great find!

Since I only have 2 end points, it sounds like the writes will occur in sequence as long as the priority is the same.

I have a feeling that the DONE response to the NWRITE_R message is sent once the message is received (CRC error free), and not when the DSP's SRIO DMA has moved the message from the 4k buffer to the L2 or DDR memory.

Cheers

Hi

Thought I'd resurrect this ugly thing again to try to gain clarity. Sec 4.2 3rd paragraph of Spru976c.pdf states:

CPU servicing interrupts lag behind the corresponding data, which was generally transferred from an external processing element into local L2 memory. This transfer can use a messaging or direct I/O protocol. When the single or multi-packet data transfer is complete, the external PE (Processing Element), or the peripheral itself, must notify the local processor that the data is available for processing. To avoid erroneous data being processed by the local CPU, the data transfer must complete through the DMA before the CPU interrupt is serviced. This condition could occur since the data and interrupt queues are independent of each other, and DMA transfers can stall. To avoid this condition, all data transfers from the peripheral through the DMA use write-with-response DMA bus commands, allowing the peripheral to always be aware that outstanding transfers have completed. Interrupts are generated only after all DMA bus responses are received. Since all RapidIO packets are handled sequentially, and submitted on the same DMA priority queue, the peripheral must keep track of the number of DMA requests submitted and the number of responses received. Thus, a simple counter within the peripheral ensures that data packets have arrived in memory before submitting an interrupt.

The sending device initiates the interrupt by using the RapidIO defined DOORBELL message. The
DOORBELL packet format is shown in Figure 44. ......................................

First off, are they talking about an external device writing to the DSPs memory? I think this is true based on

.........data, which was generally transferred from an external processing element into local L2 memory.

Next, is the peripheral mentioned on the last line of the above paragraph synonymous with processing element (first line) and  the "sending device" (second paragraph)?

Next, are they referring to the Messaging Protocol where the SRIO's receive peripheral's buffer descriptor is setup to compute how many packets are going to be received from an external device?

If it isn't messaging protocol, and if the peripheral is the DSP's SRIO peripheral, I don't see how this can happen in DirectIO.

"the peripheral must keep track of the number if DMA requests submitted...."

Lets say say the sending device is writing 1024 Bytes. The sending device writes the target memory addr (the DSPs L2 mem) to its SRIO target addr register, then writes 1024 to its size register, and then says go. How does the DSP's SRIO peripheral know that it has to count four 256 byte packets in Direct IO mode when each packet only has an address and size?

If the "peripheral" is synonymous with "sending device" and its external to the DSP, then how does it know that the DSP's SRIO DMA has completed the transfer of the last 245 Byte packet from the SRIO's 4k buffer to the DSPs L2 memory?

Obviously the terminology used by the author is confusing me. Because the purpose of the paragraph is to explain how.......

To avoid erroneous data being processed by the local CPU, the data transfer must complete through the DMA before the CPU interrupt is serviced. This condition could occur since the data and interrupt queues are independent of each other, and DMA transfers can stall.

I've noticed that there has not been any comments from TI on this thread. I wonder if they no longer have SRIO specialists on board.

Cheers

Hi Eddie,

Eddie said:

Sec 4.2 3rd paragraph of Spru976c.pdf

I think this paragraph is trying to reassure us that they have thought of everything and it will all be okay!

Eddie said:

are they talking about an external device writing to the DSPs memory?

I believe they are talking about an external device such as a 2nd DSP or FPGA.

Eddie said:

is the peripheral mentioned on the last line of the above paragraph synonymous with processing element (first line) and  the "sending device" (second paragraph)?

I think not! I believe it is talking about the SRIO peripheral on the receiving DSP. The SRIO peripheral has a count of the outstanding DMA transactions and when it reaches 0 it knows it is okay to assert the Doorbell interrupt.

Eddie said:

are they referring to the Messaging Protocol

I think they are referring to the RIO Messaging Protocol. On the C6455 both RIO Messages and Direct I/O transactions can span multiple packets but only up to a limit. You could send your data using multiple RIO Messages (because you've got a lot to send) and then send a Doorbell.

Eddie said:

Lets say say the sending device is writing 1024 Bytes. The sending device writes the target memory addr (the DSPs L2 mem) to its SRIO target addr register, then writes 1024 to its size register, and then says go. How does the DSP's SRIO peripheral know that it has to count four 256 byte packets in Direct IO mode when each packet only has an address and size?

It doesn't know but it does guarantee to handle packets in the order they arrive (given certain criteria such as same priority). In other words the 4 Direct I/O packets will arrive before the Doorbell packet and the receiver will make sure all packets that have arrived before the Doorbell have been transferred to memory.

I think this is true for a simple point-to-point system (which is what I've got) but if you have a large switch fabric then there are fewer guarantees. I'm hoping to keep things really simple by only using 1 LSU and having the same priority for all transactions.

I wonder what happens if there is an error and a packet is sent again?

If you do NWRITE_R and wait for the response before sending the Doorbell surely it must always work.

If you do NWRITE_R on one LSU and send the Doorbell from another LSU I don't know what will happen but this sounds like an unlikely scenario to me.

If you do NWRITE or SWRITE I think you are accepting the possibility that there may occasionally be errors (I'm hoping that on a short point-to-point connection the errors will be very occasional) but without errors the Doorbell interrupt will occur after the data has arrived.

Eddie said:

If the "peripheral" is synonymous with "sending device" and its external to the DSP, then how does it know that the DSP's SRIO DMA has completed the transfer of the last 245 Byte packet from the SRIO's 4k buffer to the DSPs L2 memory?

I think it means the SRIO peripheral.

Eddie said:

Because the purpose of the paragraph is to explain how

I think the paragraph is trying to explain why the Doorbell will arrive after the data and saying that there is nothing we have to do (apart from send the Doorbell after the data).

Eddie said:

I've noticed that there has not been any comments from TI on this thread. I wonder if they no longer have SRIO specialists on board.

Yes I've been wondering about that too! I'm beginning to feel like I'm a SRIO specialist which is a bit worrying! :-}

Thanks,

Matt

MattB said:

are they talking about an external device writing to the DSPs memory?

I believe they are talking about an external device such as a 2nd DSP or FPGA.

[/quote]

That is correct.

MattB said:

is the peripheral mentioned on the last line of the above paragraph synonymous with processing element (first line) and  the "sending device" (second paragraph)?

I think not! I believe it is talking about the SRIO peripheral on the receiving DSP. The SRIO peripheral has a count of the outstanding DMA transactions and when it reaches 0 it knows it is okay to assert the Doorbell interrupt.

[/quote]

Correct.

MattB said:

are they referring to the Messaging Protocol

I think they are referring to the RIO Messaging Protocol. On the C6455 both RIO Messages and Direct I/O transactions can span multiple packets but only up to a limit. You could send your data using multiple RIO Messages (because you've got a lot to send) and then send a Doorbell.

[/quote]

The description applies to both Messages and DirectIO. What is being counted are the number of outstanding internal DMA transactions when the DOORBELL packet arrives.

MattB said:

Lets say say the sending device is writing 1024 Bytes. The sending device writes the target memory addr (the DSPs L2 mem) to its SRIO target addr register, then writes 1024 to its size register, and then says go. How does the DSP's SRIO peripheral know that it has to count four 256 byte packets in Direct IO mode when each packet only has an address and size?

It doesn't know but it does guarantee to handle packets in the order they arrive (given certain criteria such as same priority). In other words the 4 Direct I/O packets will arrive before the Doorbell packet and the receiver will make sure all packets that have arrived before the Doorbell have been transferred to memory.

I think this is true for a simple point-to-point system (which is what I've got) but if you have a large switch fabric then there are fewer guarantees. I'm hoping to keep things really simple by only using 1 LSU and having the same priority for all transactions.

I wonder what happens if there is an error and a packet is sent again?

If you do NWRITE_R and wait for the response before sending the Doorbell surely it must always work.

[/quote]

That's the idea. The sending device waits until it has the response from an NWRITE_R before it sends the DOORBELL. That way it is assured that the receiving device has received the packet. The DMA to memory still has to be completed on the receiving device and that is where the response regarding the DMA applies.

MattB said:

If the "peripheral" is synonymous with "sending device" and its external to the DSP, then how does it know that the DSP's SRIO DMA has completed the transfer of the last 245 Byte packet from the SRIO's 4k buffer to the DSPs L2 memory?

I think it means the SRIO peripheral.

[/quote]

Correct. The SRIO peripheral in the 6455 has created some number (N) DMA transactions that are still outstanding when the doorbell arrives. The peripheral assures that those transactions have completed before it registers the doorbell.

MattB said:

Because the purpose of the paragraph is to explain how

I think the paragraph is trying to explain why the Doorbell will arrive after the data and saying that there is nothing we have to do (apart from send the Doorbell after the data).

[/quote]

Correct.

JR

 

 

 

 

 

 

 

JayR said:

That's the idea. The sending device waits until it has the response from an NWRITE_R before it sends the DOORBELL. That way it is assured that the receiving device has received the packet. The DMA to memory still has to be completed on the receiving device and that is where the response regarding the DMA applies.

You're saying that the response to the NWRITE_R is sent before the DMA transfer has completed. Is this correct? I'm not sure it's important, I'm just trying to understand.

I'm more interested in what happens if NWRITE (or SWRITE) is used.

Is it true that a Doorbell will not pass a NWRITE (given certain conditions such as no errors, sent from the same LSU and same priorities)?

Thanks,

Matt

Thanks for the info Jay and Matt

MattB said:

Is it true that a Doorbell will not pass a NWRITE

I am concerned about this also. Sec 4.2 of spru976c.pdf states

To avoid erroneous data being processed by the local CPU, the data transfer must complete through the DMA before the CPU interrupt is serviced. This condition could occur since the data and interrupt queues are independent of each other, and DMA transfers can stall.

Are they suggesting here that the doorbell can pass the NWRITE because of separate queues? I've tried to find info on the doorbell queue but there are no other references. Do they mean after the SERDES there is a separate path for  doorbell messages?

Cheers

Not to highjack the thread, but I'm unable to get the RIO DOORBELL to generate an interupt.

I have a clock interupt that polls the DOORBELL _ICSR and it is getting set, but I'm failing to find out how to make that bit proprogate to an event/interupt.

Can someone point me to some example code/documentation?

TIA

dkerns said:

I'm unable to get the RIO DOORBELL to generate an interupt.

I'm not sure how much specific help I can be but I can confirm that it does work if you get the configuration correct.

dkerns said:

I have a clock interupt that polls the DOORBELL _ICSR and it is getting set, but I'm failing to find out how to make that bit proprogate to an event/interupt.

I think this means you've sorted out the interrupt pacing stuff, i.e. written 0 to INTDST_RATE_CNTL.

dkerns said:

Can someone point me to some example code/documentation?

I've always used DSP/BIOS for my tests.

I create a hardware interrupt, e.g. HWI_INT4, and set the 'interrupt selection number' to 20. In main I enable the CPU interrupt, i.e. C64_enableIER(C64_EINT4);.

HTH,

Matt

MattB said:

I create a hardware interrupt, e.g. HWI_INT4, and set the 'interrupt selection number' to 20. In main I enable the CPU interrupt, i.e. C64_enableIER(C64_EINT4);.

This 'interrupt selection number' must be what I'm missing. Is there an API for that or do I just poke a register? (BTW I'm using DSP/BIOS v6)

Here's the interrupt part of my code, perhaps that will shed some light on what I'm missing: ... feel free to point out other problems :)

------

void myhwi(Uarg a1)
{
    // TODO: need to check a1??
    if (G->hSrio->regs->DOORBELL_INTR[0].DOORBELL_ICSR)
    {
        // clear the interrupt
        G->hSrio->regs->DOORBELL_INTR[0].DOORBELL_ICCR = G->hSrio->regs->DOORBELL_INTR[0].DOORBELL_ICSR;
        G->hSrio->regs->INTDST_RATE_CNTL[0] = 0; // TODO: may need to move this to end of readSymbol()
        // notify task to read symbol from SRIO
        Semaphore_post(semRead);
    }
}

int main()
{
...
    Task_Params_init(&taskParams);
    taskParams.arg0 = 1;
    taskParams.arg1 = 0;
    taskParams.priority = 7;
    Task_create(task1, &taskParams, NULL);

    semRead = Semaphore_create(0, NULL, NULL);

    Hwi_Params_init(&hwiParams);
    hwiParams.enableInt = FALSE;
    hwiParams.arg = 6;
    Hwi_create(6, myhwi, &hwiParams, NULL);
    // see BIOS docs:
    // FIXME: should really only map event 6...
    for (i = 5; i < 15; i++)
        Hwi_eventMap(6, i); // "magic" happens here: SRIO -> event 6 -> CPU INTR6
    BIOS_start();
}

int initHw()
{
    enableSRIO();
    ...

    // CPU INTR6 see spru871j.pdf
    G->hSrio->regs->DOORBELL_INTR[0].DOORBELL_ICCR = 0xffffffff; // clear any pending interrupts
    G->hSrio->regs->LSU_ICCR = 0xffffffff;
    G->hSrio->regs->ERR_RST_EVNT_ICCR = 0xffffffff;
    Hwi_enableInterrupt(6);
    Hwi_enable(); // needed??
    this->hSrio->regs->INTDST_RATE_CNTL[0] = 0;
    printf("Hwi module %sready\n", Hwi_Module_startupDone()? "" : "NOT ");
    return(0);
}

void task1()
{
    if (initHw() != 0)
    {
        Fatal("HW init failed");
    }
    for(;;)
    {
        Semaphore_pend(semRead, BIOS_WAIT_FOREVER);
        readSymbol();
    }
}

dkerns said:

Is there an API for that or do I just poke a register?

In DSP/BIOS V5 'interrupt selection number' is a property of the HWI object and I've always set it using the TConf script.

I'm afraid I've never tried to configure interrupts any other way.

dkerns said:

(BTW I'm using DSP/BIOS v6)

I'm afraid I don't know anything about DSP/BIOS v6.

I looked at DSP/BIOS v6 some time ago but because of the lack of library support (DSPLink) I decided to stick with v5.

Matt

dkerns said:

Can someone point me to some example code/documentation?

Have you looked at the DIO library examples? There are a lot and are built for CCSv3.3. You can however import fairly easily to CCSv4.

http://www.tiexpressdsp.com/index.php/DIO_Library

Follow the link to the gforge.ti.com

I've been able to import these libraries into CCSv4 no problem (caveat: when not using the BIOS).

http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/p/37803/132064.aspx#132064

But for doing RTSC, (BIOS 6), I had to first create the an RTSC project

http://rtsc.eclipse.org/docs-tip/Demo_of_RTSC_Project_Creation_in_CCSv4

Then manually add the files and the libraries.

What board are you using and what PCB rev is it?

Cheers

Eddie said:

Have you looked at the DIO library examples?  ... (caveat: when not using the BIOS).

...

What board are you using and what PCB rev is it?

yes I have looked at DIO, and also noticed the lack of BIOS support (which I found both surprising and disappointing)

my EVMC6474 is REV D

I'll take a look at gforge, thanks

Great. You have a rev D. We have Rev B and C and they have SRIO issues.

FYI: the gforge DIO library does not depend on BIOS. I have compiled them in CCSv4 and they appear to work OK.

Cheers

Eddie

Finally made some progress on this today...

Found out (by painfully dumping lots of CIC registers)  that the SRIO doorbell was coming in on EVENT 71 (not 6), so when we mapped that event, the interrupt fired... but only once.
So, now I need to know what bits I need to clear in the Interrupt handler to allow it to fire on every doorbell, not just the first.

here's my current handler:

Void RIOhwint(Uarg a1)
{
    if (G->hSrio->regs->DOORBELL_INTR[0].DOORBELL_ICSR)
    {

        // clear the door bell
        G->hSrio->regs->DOORBELL_INTR[0].DOORBELL_ICCR = G->hSrio->regs->DOORBELL_INTR[0].DOORBELL_ICSR;
        Semaphore_post(semRead);

        // clear the interrupt
        Hwi_clearInterrupt(6);
        G->hSrio->regs->INTDST_RATE_CNTL[0] = 0; //
    }
}

Hi,

In BIOS 6, you need to set eventId to the interrupt selection number to map the vector ID to the interrupt number. In your case, since you have interrupt vector 6 and interrupt number 20:

    Hwi_Params_init(&hwiParams);
    hwiParams.enableInt = FALSE;
    hwiParams.arg = 6;

    hwiParams.eventId = 20;
    Hwi_create(6, myhwi, &hwiParams, NULL);

The following code looks incorrect:

// FIXME: should really only map event 6...
    for (i = 5; i < 15; i++)
        Hwi_eventMap(6, i); // "magic" happens here: SRIO -> event 6 -> CPU INTR6

Hwi_eventMap also does the same, i.e. maps interrupt selection number to vector ID. But by doing this, you are essentially overwriting the event mapping multiple times, and ending up with event map of 14 (the last one in the loop), which is probably incorrect.

Regards,
Mugdha

MugdhaK said:

Hi,

In BIOS 6, you need to set eventId to the interrupt selection number to map the vector ID to the interrupt number. In your case, since you have interrupt vector 6 and interrupt number 20:

    Hwi_Params_init(&hwiParams);
    hwiParams.enableInt = FALSE;
    hwiParams.arg = 6;

    hwiParams.eventId = 20;
    Hwi_create(6, myhwi, &hwiParams, NULL);

Thanks, too bad that's not shown in the example of spruex3c.pdf  in section 6.2.8. Also, people (in this thread) keep referencing eventId 20 for the RIO DOORBELL.

I dumped all the CIC event registers and and found the doorbell to be coming in on event 71, so I'm puzzled by that.

MugdhaK said:

The following code looks incorrect:

// FIXME: should really only map event 6...
    for (i = 5; i < 15; i++)
        Hwi_eventMap(6, i); // "magic" happens here: SRIO -> event 6 -> CPU INTR6

Hwi_eventMap also does the same, i.e. maps interrupt selection number to vector ID. But by doing this, you are essentially overwriting the event mapping multiple times, and ending up with event map of 14 (the last one in the loop), which is probably incorrect.

 

This was a desparate attempt to make all events map to interrupt 6, (clearly, a mis-guided attempt) I blame figure 3 of sprufk6.pdf

I'm dieing for some good DSP/BIOS v6 on C6474 documentation... especially in the area of HWI (ie. it's totally not clear what clean up needs to be done in the handler)

Dave

Dave,

I don't really know about the RIO doorbell. I only mentioned 20 because that was mentioned in the earlier e-mails! Please ignore that part of my e-mail. My input is only for the BIOS HWI configuration.

Regards,
Mugdha

The full list of APIs supported by the 64x+ Hwi module can be found in the "cdoc" documentation which you can get via the CCSv4 on-line help (use Help->Contents and you should see BIOS APIs in the table of contents).   You can also get to this documentation via a link in the DSP/BIOS release notes (at top of bios_6_21_ab_xy directory).  I just checked the cdoc and all of the APIs are there, but I also filed a bug asking that we improve the cdoc documentation for these APIs as it is pretty sparse.

The 6x+ core has 12 user-available core inputs, to support many external interrupts.  The Hwi_eventMap() API is used to map specific eventids to one of these 12 core interrupts.  The full list of eventids for the 6474 is listed in table 7-13 in section 7.6.1 in 6474 data sheet  http://focus.ti.com/lit/ds/symlink/tms320c6474.pdf. 

If you use 'Hwi_create()' API to define your interrupts, then BIOS should do most of the interrupt management.   Hwi_create() has parameters that allow for event-core interrupt mapping or you can use Hwi_eventMap().

Also, you can use the ROV tool in CCSv4 to see which interrupts are in use by your application.

Regards,
-Karl-

Finally got it to work today... as far as I can tell the "thing" that made it work, was switching from interrupt 6 to 8

ROV proved to be quite informative, however, I never got it to display anything other then -1 for the eventId of my interrupt. Looks like a bug to me.

Thanks all for the help!