Yes, I know about that previous thread, but as you have said the outcome was not clear. Anyway, the proposal of making it as in or1ksim/or1200 would make PIC a mandatory part in any implementation, because it wouldn't be possible to maintain same functionality with and without PIC. On the other side, changing or1200 to make PIC follow the manual is as easy as removing a logic 'or' from the line where new PICSR is calculated in the verilog source. If it is wanted to stick to the current implementation, I think at least two lower interrupts must be PIC-transparent, that is, non-maskable and with bits in PICSR following interrupt line inputs. This two lower bits must also be noted in the manual as always working this way, not as an option. With this (rather small) modification, you could use the two lower interrupt lines on the PIC as if they were the interrupt input on the CPU core, thus achieving with/without PIC equivalence. Personally, I think that an architecture in development can't be forced by an existing implementation. If due to whatever reason you don't want/you can't change or1200 implementation, you should (1) note OpenRISC 1000 Development as no longer in development stage an freeze it *exactly* as or1200 works OR (2) continue developing the architecture and permit little deviations in the or1200 implementation. After all, also the MIPS family, that has a lot of processors, has little differences in functionality between some of its members. Please post your comments :) Regards, Carlos > Carlos Sánchez de La Lama wrote: > >> >> (2) PICSR bits don't do back to 0 when interrupt line is deasserted. >> I think it should, as the Architecture Manual says "Bits in PCSR >> represent the status of the interrupt inputs and the actual >> interrupt must be cleared in the device, which is the source of the >> interrupt". >> >> > FYI, there was once a lengthy discussion on this list centering around > just that quoted line from the architecture manual: > > http://www.opencores.com/forums/openrisc/2003/02/00049 > > The outcome wasn't spelled out clearly, but I believe the resolution was > to remove the offending line from the architecture manual and clarify > the PIC operation rather than have to change and re-test existing SW. > > Maybe this goes without saying, but if the patch to or1ksim is applied, > then a corresponding change has to be applied to the or1200 verilog to > keep them in sync. > > -Scott
Esta parte del mensaje esta firmada digitalmente