FW: rtems on nios2 collaborative efforts

[Sebastian Huber]

On 04/03/2012 07:30 PM, Hill, Jeffrey O wrote:
>
>> Yes, this probably makes sense with the IIC, but do you really need more
>> than
>> two interrupt levels (level 0 == interrupts enabled, level 1 == interrupts
>> disabled)?
>
> In vxWorks we called a CPU independent function to set the interrupt enable level, but this means that the quiescent interrupt level set by one thread is meaningless if it just gets set to some other level later by a different thread. It seems that RTEMS has a better way by making this interrupt enable level private to the thread.
>
> At the moment, I don't know of a requirement for multiple levels, and I admit that if we have a different number of levels with EIC and IIC then it probably doesn't matter if IIC has two or thirty two levels.

Currently the IIC Nios II port in RTEMS has only two levels, the EIC port has 
up to 64 levels.  This is because only the status register will be used.  If 
you use the ienable register to increase the number of levels for the IIC port, 
then things get a bit more complicated.  Do you really need more than two 
level?  From my point of view this per-thread interrupt level feature of RTEMS 
is somewhat problematic with more that two interrupt levels.  To play around 
with interrupt levels in combination with thread priorities leads to some hard 
thinking if you design your application.

>
> Nevertheless, perhaps I can maybe draw some conclusions.
>
> o Altera Avalon drivers shouldn't set the NIOS2 ienable register directly with a macro. We would like for them to run unmodified also on ARM or MIPS, for example.

You should use rtems_interrupt_disable/enable.

> o Threads, and not drivers, should set the interrupt level.

I disagree, the interrupt level should be raised (interrupts disabled) as short 
as possible.

> o It's a nice idea for the thread to have a private interrupt level, but given that interrupt levels are CPU hardware specific, then generic portable threads generally almost always operate at interrupt level zero, or alternatively at a configured interrupt level.

If you exploit the interrupt level feature, then your code is highly 
non-portable.  It is also useless on a SMP machine.

> o One could ask this question; if applications of the EIC might need more than two levels then maybe applications of the IIC might also. But admittedly given the preceding conclusions this is maybe mostly an academic question.
>
>> To increase the context by four bytes is not a problem.
>
> Increasing the context switch and interrupt latency is probably the most substantive argument against multiple levels with IIC? However, at least in the interrupt context we must save the ienable register on the running thread's stack, and restore the original ienable register only at the precise instant the eret runs so that we don't cause the interrupt stack to explode if there is an unquenched interrupt source (we can suppress lower and same interrupt levels in the ienable register while the ISR is running and only re-enable them again when we have interrupts locked globally just before eret restores status from estatus in the low level assembler code). Admittedly, this paradym of interrupt levels might be something that is known only by the cpukit interrupt handler stub, and in contrast the threads might know only of two levels; on or off. And that would probably be sufficient for almost any need.

Currently the context switch code in "nios2-context-switch.S" is independent of 
the IIC and EIC.  This will change once you use the ienable.  The BSP can 
provide special versions for _CPU_Context_switch() (like on the PowerPC).

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.