You are not logged in.
Each packet reception will generate two interrupts --- the first is at the beginning to inform PPC that receiver RF is busy in reception; and the second one is at the end to clear the receiver busy status in PPC. We have verified that in FPGA these two interrupts always happen in pair, which they should be. However, we noticed that the second interrupt is not always served in power PPC. So the rx busy flag in PPC is not cleared, which will causes TX blocking. We would like to know whether Rice team have run into similar situation before? What might be the causes?
One thing we are not sure is that whether interrupt signal in opb_intc has certain life span? In other words, if the interrupt cannot be served right away, since other interrupt with higher priority is being served, will opb_intc hold the low priority interrupt until it can be served?
BTW, anyone knows existing forums for Power PC embedded programming? Thanks.
Last edited by zrcao (2007-Oct-01 14:31:52)
Offline
Are you working with one of our reference designs? If so, there is only one interrupt from the PHY per packet, always either goodPkt or badPkt. The PHY does not trigger an interrupt at the beginning of a packet; it's assumed that the transmitter's carrier sensing will prevent any transmission during this time. If a good packet is received, the MAC will pass it off to the EMAC, which will trigger its own interrupt upon completion of sending the packet over the wire.
Offline
We are working with our SISO OFDM PHY layer model. Ok, so Rice's reference design replies on carrier sense to determine the rx status! The problem maybe associated with multiple interrupt priority order, we are still investigate.
Offline
Another means to monitor the Rx status would be a read-only register tied to a signal in your PHY that indicates whether a packet is being received. Then, prior to carrier sensing, the Tx code just reads the register. This is something we plan to add to our PHYs, to cover the (rare, arguably impossible) case of the PHY receiving a packet with Rx power below the carrier sense threshold.
Offline
Well, there are a few ways to monitor the RX status, and carrier sensing is important in realizing meaningful protocol.
But I think the problem is not the PHY layer issue (or FPGA). Instead, it is a problem in the PPC embedded programming.
Somehow in a particular situation, the interrupt handler is not called while the FPGA actually sends out the interrupt signal to PPC.
This actually brings up the problem of software run-time debugging for Virtex-II Pro. Do you have any suggestion on this topic?
Thanks.
Offline
It looks to me that missing interrupt is possible based on opb_intc data sheet. On pg. 5 of "OPB Interrupt Controller (v1.00c) DS473 Product Specification", it says
Level Sensitive Interrupts
.
.
.
The major problem with level sensitive interrupts stems from their inherent susceptibility to spurious interrupts, and to missed interrupts due to problems that arise when trying to avoid spurious interrupts.
In our design, we have several interrupt sources --- PHY packet detection, PHY rx packet processing finish, PHY tx packet finish, timer expiration, and EMC interrupt. If we keep each interrupt handler function very short, or basically do nothing, we see no missing interrupt. However, when we add stuff into the interrupt handler functions, the missing packet problem occurs.
In particular, the interrupt handler for rx packet processing finish should do quite a bit things, such as send back ack, initiate DMA from BRAM to EMAC FIFO, etc. What we saw is that, occasionally, even the FPGA sends out level high interrupt for rx packet processing finish, the corresponding interrupt handler function is not called at all. So we have some packets received by PHY, but never processed by PPC. Instead, PPC will jump over and process the following received packet until this happens again.
But this only happens to this interrupt handler as we observed so far. The specialty is that this function is relatively long, and it will initiate DMA. If we disable EMAC interrupt, the problem rarely happens. However, if we enable the EMAC, it happens quite often. So it might also be related with DMA process. What will happen if EMAC interrupt handler starts a DMA from its FIFO to BRAM while another DMA on the opposite direction is still going on?
Offline
These are issues we haven't faced so far- I really don't know if/how the DMA handles contention with overlapping operations. My suggestion would be to build simple projects with a test core that could generate the relevant interrupts at controlled times, so you can reliably recreate and isolate the error conditions.
Offline