Re: [openrisc] PIC documentation

["Damjan Lampret" <lampret@opencores.org>]

Scott,

 

yes I think we could consider this case as inadequate description of PICSR in architecture manual. In OR1200 RTL PICSR needs to be cleared in SW. Same is implemented in or1ksim. However there is possibility that PICSR is not implemented, or perhaps entire PIC is not implemented. In this case device driver would only have to clear interrupt in the device itself and not in the PIC. So this needs to be fixed somehow, either by better explanation in the manual or by a requirement that PICSR always needs to be implemented (which in a way a like because it simplifies things and in a way I don't like because it puts restrictions on HW implementations)

 

regards,

Damjan

----- Original Message -----

From: Scott Furman

To: openrisc@opencores.org

Sent: Friday, February 14, 2003 11:57 PM

Subject: [openrisc] PIC documentation

I’ve noticed some possible inconsistencies between how the PIC is described in the architecture manual and how it behaves in the simulator and the or1200 core.

 

The manual says: “Bits in PICSR represent the status of the interrupt inputs and the actual interrupt must be cleared in the device, which is the source of the interrupt”.  However, I’ve found when using the UART in  or1ksim that the PICSR bit corresponding to an interrupt must be cleared for each interrupt.  Indeed, when I look at the simulator’s source code in pic.c, I see that there is code to allow an emulated peripheral to raise an interrupt, but none to allow an interrupt to be cleared.  That makes me wonder: How can any interrupt-driven device drivers run under the simulator (unless they, too, are clearing the PICSR register after every interrupt) ?

 

Another odd thing I’ve noticed with both the simulator and OR1200 is that the lowest two bits of PICMR read as zero, even though IRQs 0 and 1 are treated as unmasked.  I would expect them to always read as 1.

 

-Scott