Hi everyone, I've been looking into the OR1200 core and I have a small question regarding the interrupt handling. We use the PIC of OR1200 with the OR1200_PIC_PICSR defined. Thus as far as I can see in the code and simulations, I have an edge-triggered interrupt system. In the OpenRISC 1000 architecture manual I find that a one written to the corresponding bit should clear a pending interrupt (which is also what is done in the Linux interrupt handler in arch/or32/irq.c). But I can't possibly see how the following code could adhere to that: ---> From or1200_pic.v 0: always @(posedge clk or posedge rst) 1: if (rst) 2: picsr danwi@isy.liu.se +46 13 28 8965 http://www.da.isy.liu.se/~danwi ---- Inter spem curamque, timores inter et iras omnem crede diem tibi diluxisse supremem: grata superveniet quae non sperabitur hora.

Hi Daniel, The status register is a reflector of any interrupt sources. To clear the interrupt you need to cleardown at source eg a UART by writing a one to it's ISR; NOT the the OR1200 ISR. Using a write 1 to clear the or1200 ISR bits doesn't make sense as it wouldn't clear the source & which would be still be signalling IRQ pending Regards Mike Scott ___________________________________________________ Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK www.jennic.com Tel: +44 (0) 114 2812655 Confidential ___________________________________________________ -----Original Message----- From: openrisc-bounces@opencores.org [mailto:openrisc-bounces@opencores.org]On Behalf Of Daniel Wiklund Sent: 13 October 2004 12:28 To: openrisc@opencores.org Subject: [openrisc] Interrupt handling in OR1200 Hi everyone, I've been looking into the OR1200 core and I have a small question regarding the interrupt handling. We use the PIC of OR1200 with the OR1200_PIC_PICSR defined. Thus as far as I can see in the code and simulations, I have an edge-triggered interrupt system. In the OpenRISC 1000 architecture manual I find that a one written to the corresponding bit should clear a pending interrupt (which is also what is done in the Linux interrupt handler in arch/or32/irq.c). But I can't possibly see how the following code could adhere to that: ---> From or1200_pic.v 0: always @(posedge clk or posedge rst) 1: if (rst) 2: picsr danwi@isy.liu.se +46 13 28 8965 http://www.da.isy.liu.se/~danwi ---- Inter spem curamque, timores inter et iras omnem crede diem tibi diluxisse supremem: grata superveniet quae non sperabitur hora. _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc -------------- next part -------------- A non-text attachment was scrubbed... Name: Michael Scott (E-mail).vcf Type: text/x-vcard Size: 619 bytes Desc: not available Url : http://www.opencores.org/forums/openrisc/attachments/20041013/22df74ae/MichaelScottE-mail.vcf

Hi, I agree that reseting a the OR1200 PICSR doesn't clear a level signaling source. But on the other hand, then most parts of the PIC is totally irrelevant since the only thing that it does is mask the incoming interrupts. Thus, the entire picsr part is more or less crap. Here's my motivation why: Looking at the Linux source in arch/or32/irq.c where the picsr is read, I find that the irq level returned is based on the value of the picsr register. But the contents of picsr are not cleared anywhere in the Linux sources! This means that a high-priority interrupt will block lower priority interrupts through the picsr register since this will act as a latch, keeping the interrupts even after the source has been cleared. The higher layer drivers have no way of clearing this without being platform dependent. This is also not in line with the architecture manual (chapter 13) which says: *" 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 leveltriggered source *must have no effect on PICSR content. * *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. " Since the current implementation of the or1200_pic.v looks like a mix of the level-triggered and edge-triggered versions, I would suggest a semi-complete rewrite of the or1200_pic.v so that it can handle BOTH (at the same time for different sources) dependent on configuration. I can also think that "one-shot" interrupt signals (i.e. active during a single cycle) would be nice to handle as well. These can be handled with edge-triggered ints, but a synchronous version would be much better in that case. I am willing to fix this so that the or1200_pic.v is compliant to the arch manual, if nobody objects. // Daniel On Wed, 13 Oct 2004 13:27:36 +0100 "Michael Scott" mike.scott@jennic.com> wrote: // Daniel ---- Daniel Wiklund, MScEE, Lic Eng Computer Engineering, ISY Linköping University SE-581 83 Linköping Sweden danwi@isy.liu.se +46 13 28 8965 http://www.da.isy.liu.se/~danwi ---- Inter spem curamque, timores inter et iras omnem crede diem tibi diluxisse supremem: grata superveniet quae non sperabitur hora.

Hi, And most systems aren't all systems ;) I have made an update that I think is correct. By default, all interrupts are level-sensitive so that the picsr is only a masked and registered copy of the interrupt input. Writes to the register bits corresponding to level-ints are ignored. Through defines it is possible to select individual interrupt sources that should be edge triggered and whether these should be asyncronous or synchronous. A write with a '1' to the corresponding bit clears the int flag. If the int input is still active picsr will return to asserted state in the next cycle. (The asynchronous version infers SR-latches that seemingly synthesizes well in Xilinx XST.) Another change I've made is that if the PICSR is not defined, a read from picsr will return the masked version of the ints, not the inputs directly as before. I believe that the old behavior is a bug since this could confuse irq handlers (e.g. Linux) into serving ints that are not enabled. The new behavior is controlled through two defines. And that's about it. I need to do some more testing and run the code through Leda before releasing it. // Daniel On Thu, 14 Oct 2004 03:25:36 +0200 "Damjan Lampret" damjanl@opencores.org> wrote: // Daniel ---- Daniel Wiklund, MScEE, Lic Eng Computer Engineering, ISY Linköping University SE-581 83 Linköping Sweden danwi@isy.liu.se +46 13 28 8965 http://www.da.isy.liu.se/~danwi ---- Inter spem curamque, timores inter et iras omnem crede diem tibi diluxisse supremem: grata superveniet quae non sperabitur hora.

Hi Michael, I looked at the latest version in CVS (1.1), dated July 13, 2004. (btw, the TOC is kinda screwed up in the pdf... Look around page 307 in the file.) Interesting to see your version, since the implementation didn't reflect that either ;) Regards, // Daniel On Wed, 13 Oct 2004 15:29:08 +0100 "Michael Scott" mike.scott@jennic.com> wrote:

If it doesn't break anything, then nobody objects :-)

The PIC has two objectives:
- to mux from 32 int sources down to 1
- to mask
- (obsolete) to map ints to low and high priority (no longer in the arch)

At the end of the day, for level ints you have to clear it at the source, no
matter what kind of PIC you have. And most systems where OR1200 is used are
level ints.

regards,
Damjan

What async version? What SR latches?

There shouldn't be any async loops or latches in the design. ASIC tools have
problem with this. Design has to be fully synchronous.

regards,
Damjan

Hi, I am fully aware that ASIC tools have problems with this. A person willing to use the async version must understand the problems this may cause (and this I have stated along with the defines). On the other hand, you would have to make an active decision to use the async version since the default defines would favor a synchronous, level-triggered version. Anyway, if the asynchronous version is not allowed at all - then the arch manual should not talk about edge-triggered interrupts ;) An edge triggered int is - by definition - asynchronous. If this is not at all allowed inside the pic module, the arch manual should rather say something about the int being latched (dangerous word, any better suggs? stored?) in the picsr register. I.e. the picsr register for that int acting as a synchronous SR-filp-flop (perhaps sth about one-shot action on S). But I firmly believe that the arch manual should be updated to clarify what is intended in that case. An async int could always be handled outside of the processor which - I agree - may be the better way of doing things. Looking into "Reuse methodology manual" (excellent book) they suggest that latches must be inferred as Synopsys GTECH D-latches which is not necessarily tool-independent. Therefore, I will remove the async version in the released file. I don't need it and that should probably make everyone happy, anyway ;) // Daniel On Thu, 14 Oct 2004 05:13:17 +0200 "Damjan Lampret" damjanl@opencores.org> wrote: What async version? What SR latches? There shouldn't be any async loops or latches in the design. ASIC tools have problem with this. Design has to be fully synchronous. regards, Damjan _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

I think the PIC should only handle level interrupts. Fundamentally, all interrups are level interrupts anyway as an edge-triggered interrupt has to be latched in some form or another to assert the level and then cleared once it has been serviced to negate the level. It is convenient and probably more efficient to provide a clearing mechanism via the PICSR for such type of interrupts but there is nothing to stop the clearing mechanism being more closely associated with the source. So I would suggest having the PIC as level triggered only, possibly 'exporting' a clear signal emanating from a write to the PICSR (excuse the terminology, I am more of a s/w person). Robert Cragie, Design Engineer _______________________________________________________________ Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK http://www.jennic.com Tel: +44 (0) 114 281 2655 _______________________________________________________________ _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc