Rapid IO SRIO doorbells - how to deal with simultaneous dbells

Hi Eddie,

Eddie3909 said:

1) we receive a dbell on port 0 and another on port 1 almost simultaneously  with info = 0 and info = 1

note: we'll assume that the dbell on port0 got put in the dbell queue first. There is a que right? (the sprue13j documentation only mentions this once)

Ports are really irrelevant here.  Whether the doorbell messages are coming from the same RX port or not, one will arrive first to the MAU block that deals with setting the interrupt bits.  I'm slightly unclear with your description using info=0 and info=1. Let's take the two cases, case 1 - both doorbell info fields are identical, in which case the corresponding ICSR bit is set for the first received doorbell and a DONE response is sent, the second received doorbell would get a RETRY response.  Case 2 - the doorbell info fields of the two doorbell message packets are different, in which case both ICSR bits can be set depending on the previous status of the bits are 0.  There are no doorbell queues.  Essentially, it is one deep if you want to look at it that way.  Are talking about case 1 or case 2?  If it is case 2, then I need to understand your ICRR mapping of ICSR bits to the actually physical INTDST interrupts that are brought to the periphery of the SRIO peripheral.

Eddie3909 said:

2) The dbell ISR fires and for dbell info = 0 we see ICSR0 has bit0 set. We then write this value back to register ICCR

clarification:  The sprue13j documentationstates that ICSR bits 15, 8, and 0 correspond to bits dbell info bits 15, 8, and 0 yet the diagram for the dbell packet on p92 says b15 and b8 are reserved. My understanding is that b6-5 select the register and b0-3 set values in the ICCR (i.e. if dbell info = 0x2a, then ICCR1 will have b10 set. A dbell info = 0x60 will have ICCR2 with bit 0 set. True?.

Ok I finally found the reference "For example, the bits ICS15, ICS8, and ICS0 of DOORBELL0_ICSR correspond to Doorbell 0 information bits 15, 8, and 0." on page 94 of http://www.ti.com/lit/ug/sprue13j/sprue13j.pdf.  The word "information" shouldn't be in that sentence.  Your understanding is correct, it is explicitly explained in section 4.2 on page 93, and examples are given in table 23.  But your example of 0x60 would set ICSR3 bit 0.  You had the wrong register.  Also, ICCR is the clear register.

Eddie3909 said:

3) The write back to the ICCR pops the dbell info = 0 out of the queue.

clarification: there is only one dbell queue shared by port 0 and port 1?

Again, there are no queues here.  Writing to the ICCR register will clear the corresponding ICSR bit, that is all.  I think there is some confusion here, so you may need to ask me more questions if you don't yet understand.

Eddie3909 said:

4) the ISR returns and is fired again for the dbell info = 1

5) we repeat steps 2 and 3 but this time b1 of the ICSR0 is set.

I think we need to clear the confusion above to understand your exact issue.  Basically, the way to think about it is:  RX ports doesn't matter, you basically have 64 interrupt source bits to use as you want.  Each time an interrupt is fired, the ISR needs to check which ISCR bits are set and handle appropriately, clearing the bits with ICCR when done.  ISR also needs to write the pacing register when done, to allow follow-on interrupts to fire to the CPU.  Each ICSR bit can be looked at as a single entry queue.  If the bit is already set, any incoming doorbell that tries to set it will get a RETRY response.  It is up to the sender to resend it and attempt to set the bit again after the RX ISR has run.

Hope that helps,

Travis

Hi Travis

Thanks for the quick reply.

tscheck said:

Case 2 - the doorbell info fields of the two doorbell message packets are different,

Yes. This is the case.

tscheck said:

There are no doorbell queues. 

Enlightenment! Thats helps to explain a lot.

tscheck said:

If it is case 2, then I need to understand your ICRR mapping of ICSR bits to the actually physical INTDST interrupts that are brought to the periphery of the SRIO peripheral.

Its the same as the mapping found in DirectIO_lib_1_1_0\doc\html\main.html -> Click on modules tab, then TST, then scroll down to the block diagram.

tscheck said:

ISR also needs to write the pacing register when done, to allow follow-on interrupts to fire to the CPU. 

Is this sequence correct? (given case 2?)

1) a dbell with info = 0 arrives

2) ISR fires. It starts a SWI (via Swi_inc) that reads ICSR0 and sees b0 set.

3) a dbell with info = 1 arrives

3) the SWI clears b0 in the ICCR

4) the SWI writes to the pacing register.

6) the ISR fires for the dbell info = 1 follow-on interrupt

6) the ISR SWI_inc's

7) the SWI finishes. (because it didn't finish from the first dbell )

8) the new SWI reads ICSR0 and sees b1 set.

Cheers

Eddie,

Your sequence seems correct to me, though some of it would depend on the value written into the pacing register in step 4 for exact timing.  The writing to the ICCR and pacing should be the last steps of the ISR

Regards,

Travis