Nios II has no sleep/idle/wfi instruction?

Indeed it has something like a sleep mode.

Look here: http://www.alteraforum.com/forum/showthread.php?t=25661

There is also told that this is no low power mode if this is your intention...

Personally (on embedded systems) I tend to not use interrupts and just poll what would be the interrupt sources directly.

I will use interrupts for anything that is really timing critical, but a hardware buffer will usually solve the problem.

There are various ways to force an instruction pipeline stall, they might lead to very slightly lower power consumption, but it is unlikely to be measurable unless you have no instruction cache and are reading instrcutions from SDRAM (which will be very, very, very slow at the best of times).

1) Stall a multi-cycle custom instruction.

2) Stall an Avalon read to a specific slave - accesses to other slaves won't be affected.

During the latter I know that the 'clock enable' of tightly coupled data memory is deasserted which might reduce power marginally.

--- Quote Start ---

If you read the thread carefully you will see that it is said in fact that the Nios CPU doesn't have a sleep mode.

--- Quote End ---

I didn't say it has a sleep mode, I said it has something like a sleep mode, but with no power saving.

That's what it is. You could also take a counter or a while(true).

If I wrote it in a misunderstanding way, then I say SORRY...

But what I wrote now, was what I intended to write...:)

I've neglected "my" thread a bit...

Thanks for the answers. Indeed I wasn't talking about a wait loop, but an instruction to suspend the CPU while waiting for an interrupt, to save power and all the traffic that goes along with instruction fetching.

For example, imagine a system with a cacheless Nios /e, running from an external RAM. When e.g. kicking off a DMA transfer to copy stuff around that RAM, and waiting for it to finish, the CPU would obstruct the DMA a lot because it fetches instructions from the same memory all the time.

@dsl: Personally, my embedded code style is the opposite, I tend to avoid polling and use interrupt whereever possible, sleeping sometimes pretty deep while waiting for them. (Maybe because I've done low power systems living from button cells or harvested energy.) But even if not, I don't like systems that eat up all resources.

Stalling in a multi-cycle custom sleep instruction seems to me like an elegant way to implement. But what's the condition to end the stall? Is there a convenient way to access the interrupt condition?

Jörg

PS: For me, the subject is currently academic, in my current system I have caches, but I felt something is missing for the Nios...

Most of the stuff I've done is mains powered, saving a few mW isn't worth the effort. What is more important is the throughput and latency, interrupt entry exit is typically slow (due to all the register saves), and has to be disabled for some code paths.

I'd use interrupts if the cpu had anything else to do.

To sleep in a customn instruction you'd have to feed the irq/wakup line into the custom instruction code. Not difficult, but it might need a separate interrupt enable mask (or use your own interrupt controller).

I don't know how much gets stalled by custom instructions, we have looked at directly coupled data memory during an avalon bus stall. The clock enable (address latch enable if single clock and qsys) is used to hold the data from an earlier cycle valid during the stall, so that will have fewer transitions and be lower power.