Re: [openrisc] Bugs detected on or1ksim

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

If nobody disagrees the following will replace description of the PICSR in
the arch manual (Matjaz can you please make a record in your list of
corrections for the arch manual, thanks):

PICSR is used to determine the status of each PIC interrupt input. PIC can
support
level-triggered interrupts or combination of level-triggered and
edge-triggered. Most
implementations today only support level-triggered interrupts.

For level-triggered implementations bits in PICSR simply represent level of
interrupt inputs.
Interrupts are cleared by taking appropriate action at the device to negate
the source of the interrupt.
Writing a '1' or a '0' to bits in the PICSR that reflect a level-triggered
source will have no effect.

The atomic way to clear an interrupt source which is edge-triggered is by
writing a '1' to the corresponding bit in the PICSR. This will clear the
underlying latch for the edge-triggered source. Writing a '0' to the
corresponding bit in the PICSR has no effect on the underlying latch.

regards,
Damjan

----- Original Message -----
From: "Robert Cragie" <rcc@jennic.com>
To: <openrisc@opencores.org>
Sent: Monday, June 16, 2003 11:48 PM
Subject: RE: [openrisc] Bugs detected on or1ksim


> The way I see it working is as follows:
>
> The atomic way to clear an interrupt source which is edge-triggered is by
> writing a '1' to the corresponding bit in the PICSR. This will clear the
> underlying latch for the edge-triggered source. Writing a '0' to the
> corresponding bit in the PICSR has no effect on the underlying latch. In
> this way, there is no need to do a RMW action.
>
> Writing a '1' or a '0' to bits in the PICSR that reflect a level-triggered
> source will have no effect. In this case the interrupt is cleared by
taking
> appropriate action at the device to negate the source of the interrupt.
>
> Therefore, as far as I can tell, there is no need for a separate PIC
> 'Acknowledgement' Register and you can happily mix edge and level
interrupts
> in the PICSR.
>
> Robert Cragie, Design Engineer
> _______________________________________________________________
> Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
> http://www.jennic.com  Tel: +44 (0) 114 281 2655
> _______________________________________________________________
>
> -----Original Message-----
> From: owner-openrisc@opencores.org [mailto:owner-openrisc@opencores.org]On
> Behalf Of Scott Furman
> Sent: 16 June 2003 23:41
> To: openrisc@opencores.org
> Subject: Re: [openrisc] Bugs detected on or1ksim
>
> Damjan Lampret wrote:
>
> I don't see a problem not clearing PICSR in SW.
>
> The way I think most  interrupt handling code running on various OR1200
> systems is the following:
> 1) an interrupt happens, peripheral device will raise its int_o
> 2) PICSR will be set to 1 due to input interrupt raised
> 3) OR1200 will start interrupt exception, SR[IEE] will be cleared
disabling
> any further interrupt exceptions
> 4) Interrupt exception handler, clear interrupt in original device, this
> will also result in clearing PICSR one clock later
>
>
>
> This all goes back to the original point made months ago, which is that
this
> description of the PIC assumes that peripherals generate level-triggered
> interrupts.  That's fine, though it probably ought to be explicitly
> documented in the architecture manual.  (As was also noted long ago, if
the
> PIC were defined to permit edge-triggered interrupts, the lack of an
atomic
> means to clear an interrupt in the PIC could potentially result in lost
> interrupts.)
>
> -Scott
>
> --
> To unsubscribe from openrisc mailing list please visit
http://www.opencores.org/mailinglists.shtml
>

--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml