pipeline and interruptions

Hello:

I'm not sure if I understand what is your concern, but an interrupt (as any other branch) will cause a pipeline flush.

Regards,

Enrique

Hello Enrique,

Is the next sequence possible:

a.: Currently will the instructions for disabling of the interrupts be executed.
b.: At the same time, cause of the prefetch unit, will already instructions from an Interrupt Service Routine (ISR) be prefetched to the instruction pipeline. (somehow it is predicted that the interrupt will occur).
c.: Now are interrupts globally disabled, but since already the first instruction of the ISR were already 
PREFETCHED to the instruction pipeline, the ISR will STILL be executed.
And this is possibly an unintended situation. And this could lead to undesired system behaviour.

-----------------------------------------------

Also, from document DDI0406B_arm_architecture_reference_manual_errata_markup_10_0.pdf, in page 414, chapter "A8.6.49 ISB" the ISB instruction has to be used for:
1) context altering operations:
1.a) changing the ASID
1.b) completed TLB maintenance operations
1.c) branch predictor maintenance operations
2) all changes to the CP15 registers. 

2) is quite clear no problem here.
are 1.a) and 1.b) only regarding virtual memory? If that is the case I think we are not using virtual memory.

but, what does it mean "branch predictor maintenance operations"? When should these maintenance operation be performed?

-------------------------------------------------

Also from document DAI0240A_cortexr4_c_coding.pdf, at the top of page 7

"Note: It is occasionally desirable to force a pipeline flush. As branches are no longer guaranteed to cause a 
pipeline flush, the ARMv7-R architecture provides the ISB"

What does "occasionally desirable" means?

Thanks,

Francis.

Francisco Torres said:

Is the next sequence possible:
a.: Currently will the instructions for disabling of the interrupts be executed. b.: At the same time, cause of the prefetch unit, will already instructions from an Interrupt Service Routine (ISR) be prefetched to the instruction pipeline. (somehow it is predicted that the interrupt will occur). c.: Now are interrupts globally disabled, but since already the first instruction of the ISR were already
PREFETCHED to the instruction pipeline, the ISR will STILL be executed. And this is possibly an unintended situation. And this could lead to undesired system behaviour.

For a MUTEX the CortexR4 has LDREX/STREX and this solution scales better between the single core and dual cores so if you are building an OS for the long term you should probably take a serious look at it.   See http://infocenter.arm.com/help/topic/com.arm.doc.dht0008a/DHT0008A_arm_synchronization_primitives.pdf

Francisco Torres said:

Also, from document DDI0406B_arm_architecture_reference_manual_errata_markup_10_0.pdf, in page 414, chapter "A8.6.49 ISB" the ISB instruction has to be used for:
1) context altering operations:
1.a) changing the ASID
1.b) completed TLB maintenance operations
1.c) branch predictor maintenance operations
2) all changes to the CP15 registers.

2) is quite clear no problem here.
are 1.a) and 1.b) only regarding virtual memory? If that is the case I think we are not using virtual memory.

but, what does it mean "branch predictor maintenance operations"? When should these maintenance operation be performed?

1.a and 1.b apply only to VMSA architectures  -  Cortex R4 is PMSA not VMSA so they do not apply.

Cortex R4 also does not include Branch Predictor Maintenance support.   See the MMFR3 register in CP15.

Francisco Torres said:

Also from document DAI0240A_cortexr4_c_coding.pdf, at the top of page 7

"Note: It is occasionally desirable to force a pipeline flush. As branches are no longer guaranteed to cause a
pipeline flush, the ARMv7-R architecture provides the ISB"

What does "occasionally desirable" means?

I think some cases are documented in this faq:  http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka14041.html

Hello Antony,

Thanks for your very detailed help.

We do not have an OS, this is why we are disabling and enabling interrupts to create  critical sections (but basically we do it only to control access to resources/hardware from different interrupts, e.g, register CRC_CTRL0 is unique for both CRC module channel 0 and 1, so in case both channels are used from different interrupts and this register is modified we need to be sure that we will not have any reentrancy problems). 

So, this question is still open, should we an ISB instruction after disabling/enabling interrupts?

Thanks a lot for your help.

Regards,

Francis.

Francis,

ARM has a knowledge base article for ARMv7 where the question of when ISB is needed is answered and interrupt disable is not in the list - http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0321a/BIHHFHJD.html.

I also haven't seen any examples of interrupt disable (through the CPSR I bit) that indicate the ISB is needed.   And there is information in the Cortex R4 TRM about when the side-effects of writing to the CPSR take effect.  The discussion is about whether the instruction fetches that should follow the CPSR write act like they have seen the change in CPSR bits. 

That much said for an authorative answer you should query ARM... I'm just telling you what I understand from their documention and while most everthing indicates a 'no' I haven't been able to find a 'no' answer explicitly in any docs.

I should not a couple things - there are examples of barriers when you are disabling interrupts through other methods than CPSR so please be aware that if you're writing to the VIM for example it's a different game as that creates a memory STR.

And also keep in mind that the FIQ is configured as an NMI on our Hercules products.  So that's a case where you wouldn't be protected by disabling IRQ and entering a critical section - but the preferred synchronizaton mechanism (LDREX/STREX) would protect you.

Hello Antony, 

Thanks a lot for your help. I think that we have all information we need.

Regards,

Francis.