Re: [openrisc] PIC documentation

[Bryan Richter <bryan@hilbrichter.com>]

I would agree with Scott.   Most interrupt controllers that I've worked on 
lately are designed such that any bits written to one in the status register 
are cleared, no masking required.  That way, software can either only clear 
the interrupt it cares about or it can keep the last status in a variable and 
just write the value it read back into the status register.  Any different 
interrupts that have arrived in the meantime are guaranteed not to be 
inadvertently cleared.

This of course doesn't get rid of the problem of interrupts from the same 
device (interrupt line) arriving between clearing the device interrupt 
request register and clearing the PICSR bits.  Software will have to be 
carefully written to avoid problems in this area.

--bryan

On Thursday 20 February 2003 08:29 am, Scott Furman wrote:
> Damjan Lampret wrote:
> > software sould clear PICSR after it cleared device's interrupt request
> > register. So if there is new interrupt from a device, it will
> > automatically set the bit in PICSR again.
>
> My point is that the *architectural* description of the PIC is tied to
> its current *implementation*, the OR1200.  If another implementation
> ever arises in which the peripherals deliver an edge-triggered interrupt
> signal to the PIC rather than a level-triggered interrupt, then software
> can not safely clear the PICSR due to the race condition I mentioned in
> my last message, i.e. without risking dropping an interrupt from a
> different device than the one being serviced.  I believe that it is for
> this reason every interrupt controller I have ever seen (other than the
> OR1k PIC) provides a means to *atomically* mask out a particular pending
> interrupt without affecting other pending interrupts.
>
> If the PIC becomes a mandatory part of the OR1k architecture, then the
> specification probably ought to make it clear that it is only suitable
> for use with level-sensitive interrupts and that an external interrupt
> controller is necessary to employ edge-triggered interrupts.  IMHO, the
> PIC in its current form is not sufficiently general compared to typical
> interrupt controllers to require it as a mandatory part of the or1k
> architecture.
>
> > The main point of PICSR is to connect several devices to a single
> > interrupt request of the OR1200 and the software can see which device
> > tree asserted an interrupt and only look in that device tree for the
> > device that asserted interrupt.
>
> I don't think there's any misunderstanding on the purpose of the PIC.
>
> -Scott

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