2
\$\begingroup\$

I'm considering using an AT32UC3B in my project (the Super OSD Pro version.) However, something about the datasheet has me worried.

Page 31

  • 0 Wait State Access at up to 30 MHz in Worst Case Conditions
  • 1 Wait State Access at up to 60 MHz in Worst Case Conditions

What is a "worst case condition"? The output stage for my OSD needs to be able run at 60 MIPS (the processor's maximum operating frequency), and I presume a "wait state" means it has to wait to load data from the memory... which would limit me to <60 MIPS.

I suppose, worst case, I could load the code into RAM and execute it from there (I presume this is possible with AVR32s?), but it still has me confused.

\$\endgroup\$
9
  • \$\begingroup\$ Execution from RAM is impossible in AVRs, though I haven't used AVR32s. Are you using an OSD IC (e.g. MAX4455) for your OSD or bit banging a micro? \$\endgroup\$
    – Nick T
    Nov 16 '10 at 20:23
  • \$\begingroup\$ This is actually something that is very typical everywhere. This is partially why computer CPUs have a cache. You can pull data from a slower methods and stick it in cache that can be accessed very fast when the instruction needs it. \$\endgroup\$
    – Kellenjb
    Nov 16 '10 at 20:24
  • \$\begingroup\$ @Nick T MAX7456 is the new version :-) \$\endgroup\$
    – Kellenjb
    Nov 16 '10 at 20:26
  • \$\begingroup\$ @Nick T - AVR32 is very different to AVR. They are more like Cortex M3 but with better low power modes (IMHO) \$\endgroup\$
    – uɐɪ
    Nov 16 '10 at 20:34
  • \$\begingroup\$ @Nick T, I am using a software OSD layer, written by myself. If you're interested, it is open source: code.google.com/p/super-osd. \$\endgroup\$
    – Thomas O
    Nov 16 '10 at 21:03
5
\$\begingroup\$

The wait state is an extra bus clock cycle that is added to the memory access to allow time for the information to be extracted and appear on the processor bus. This addition of wait states will limit your processing speed to less than 60MIPS (whatever that means). The AVR32 has a banked/interleaved flash memory design so that the wait states are hidden for straight line code allowing it to access program flash at the full 60MHz but as soon as you execute a branch or CALL then this will break the interleaving and incur a wait state penalty.

The AVR32 can run code from its RAM but this is a somewhat limited resource on the 32B devices.

If you REALLY need the full 60MIP operation for your code to function then you will have problems. How will you cope with interrupts taking processor time.....

\$\endgroup\$
28
  • 1
    \$\begingroup\$ He has actually mentioned before that on his lower end version he is at 80-90% CPU usage (on a slower processor I believe) and can't even have UART interrupt him. But here he says he needs all 60 MIPS. Not sure if hes trying to say hes at 100% cpu usage now or not. \$\endgroup\$
    – Kellenjb
    Nov 16 '10 at 20:29
  • \$\begingroup\$ Well then the very best of British to him - he will need it!! \$\endgroup\$
    – uɐɪ
    Nov 16 '10 at 20:31
  • \$\begingroup\$ This is quickly becoming a case of updating to better hardware, or make some sort of front end to service the I/O while you update a buffer. \$\endgroup\$
    – Kortuk
    Nov 16 '10 at 20:32
  • \$\begingroup\$ Yeah, but that would require higher cost and board space which I am sure Thomas doesn't want. \$\endgroup\$
    – Kellenjb
    Nov 16 '10 at 20:34
  • 2
    \$\begingroup\$ @Thomas O - Microcontrollers are often worse having variable instruction processing times. MSP430 has 1,2 and 3 clock instructions, 8051 has the same problem. \$\endgroup\$
    – uɐɪ
    Nov 16 '10 at 21:12
2
\$\begingroup\$

Often operations are going to run faster then external memory. It is saying that when you are having to load from memory you will have to have wait states. Now they have in their datasheet that it is 30MHz no wait state from flash. they do have it optimized to allow pipelined access to flash to hide the delay cycle.

you are correct that ram is an option, but you should test your algorithm and see if you have issues. If you keep your keep branch instructions out of your code it should be able to pipeline and hide the wait states.

\$\endgroup\$
2
  • \$\begingroup\$ The output stage is branchless, but the computations (e.g. draw line) are typically not. Does this mean I'll get 60 MIPS most of the time, except when doing branches? (In which case, it would be very similar to PICmicros, and in fact many other processors.) \$\endgroup\$
    – Thomas O
    Nov 16 '10 at 20:21
  • \$\begingroup\$ Yes, you are correctly interpreting that. when you are not having branches it should run without wait states. \$\endgroup\$
    – Kortuk
    Nov 16 '10 at 20:33
0
\$\begingroup\$

The AVR32A architecture is a 3 stage pipeline and it doesn't look like that model supports branch prediction so any branches in your code will stall the pipeline. Also not all instructions are single cycle.

Generally speaking never choose a processor based on its MIPS rating. In almost all real world scenarios you'll never get close to its theoretical peak MIPS rating.

\$\endgroup\$
3
  • \$\begingroup\$ Except when you're bit banging (which I am), in which case you use every last MIP! \$\endgroup\$
    – Thomas O
    Nov 16 '10 at 21:12
  • \$\begingroup\$ @thomas, I think you misunderstood mark. He is telling you that directly using mips to correlate to operations is not a great practice as it will not reach that point, especially with memory pipelines and stall instructions. \$\endgroup\$
    – Kortuk
    Nov 16 '10 at 21:42
  • \$\begingroup\$ yep, in addition you can't take an algorithm that work on a 50 MIPS PIC architecture and assume it would work on a 50MIPS AVR32 architecture. The performance on various architectures can vary widely, especially in the microcontroller space where architectures themselves vary quite a lot. \$\endgroup\$
    – Mark
    Nov 16 '10 at 23:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.