RE: [openrisc] PIC documentation

["Robert Cragie" <rcc@jennic.com>]

FWIW, I have been involved in design of intelligent peripherals with
interrupt controllers.

I think that the current implementation is entirely adequate and that it is
sufficient to specify that only level interrupts are supported. There is no
need to have any additional latching of level interrupts built into the
interrupt controller as level interrupts are cleared at source. If edge
interrupts need to be supported, these can be latched externally before
being fed to the PICSR and, in an SoC implementation, you could tie a write
of 1 to the appropriate bit of the PICSR to clearing the external latch, or
you could use an additional register to implement the effective clearing at
source.

Robert Cragie, Design Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655
_______________________________________________________________
Visit our stand (C79) at DATE - Munich 4-6 March 2003
_______________________________________________________________

-----Original Message-----
From: owner-openrisc@opencores.org [mailto:owner-openrisc@opencores.org]On
Behalf Of Damjan Lampret
Sent: 26 February 2003 14:16
To: openrisc@opencores.org
Subject: Re: [openrisc] PIC documentation


Scott,

my worry behind changing/adding architecture is because existing software
needs to be changed. There is not much to change, but as you know, it takes
time to really change it in all the different software places (to name a
few: uclinux, orpmon, test cases that use interrupts). So my mine concern is
that we render this software useless in future implementations. From this
POV it might just be better to say in the manual that only level interrupts
are supported and for edge triggered an external interrupt controller is
needed. My question is, how many interrupt controllers, specifically in
system on chip, are edge triggered? In my opinion most of the stuff today in
SoC is level.

Anyway yes the patch for OR1200 lower two interrupt inputs is OK. I'll
commit to the CVS.

regards,
Damjan


----- Original Message -----
From: Scott Furman
To: openrisc@opencores.org
Sent: Wednesday, February 26, 2003 6:33 AM
Subject: RE: [openrisc] PIC documentation




-----Original Message-----
From: owner-openrisc@opencores.org [mailto:owner-openrisc@opencores.org] On
Behalf Of Damjan Lampret
Sent: Tuesday, February 25, 2003 5:03 AM
To: openrisc@opencores.org
Subject: Re: [openrisc] PIC documentation

Scott,

before we make a rush decision let see what are some other options.

How about clearing pending interrupts in PICSR by reading PICSR register.
This would constitute an atomic interrupt read/clear operation. You get
pending interrupts and ack them by single PICSR read operation. Any current
software would have to be modified if it doesn't store PICSR status already
and therefore this could mean that current software wouldn't have to be
modified and there would be no two version of the software in the future.



One problem I can imagine with this solution is that reading the PICSR
clears *all* pending interrupts, not just the one that originally triggered
the dispatch to the interrupt service routine (ISR).  That means that the
ISR that reads the PICSR will need to service all pending interrupts (or
somehow post them to the OS for deferred servicing).  Whether or not your
proposed change to the PIC would cause lack of forward-compatibility in SW
seems somewhat dependent on how ISRs are implemented.  I would hazard that
some ISRs exist that service only a single interrupt, then resume program
execution, possibly to be interrupted immediately again.  (Actually it’s not
much of a guess; I have written such code for the OpenRISC port of eCos
myself.)

-Scott


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