Re: Atmel releasing FLASH AVR32 ?

Fixed by compiler pragma...

Easy to say, a bit harder in reality. If you don't care about codesize you
could
align big functions to 512-byte boundaries and pack small functions in the
gaps. But even that is hardly a solution as every minor change in the code
results in a different memory layout making performance unpredictable.
Basically it is an unsolveable problem.´

I assume that there are certain cricitcal paths which needs this
determinism.
Thos can be handled by pragmas.
It is also entirely possible that most threads only execute out of zero
waitstate SRAM.

On an ARM7, adding a cache also adds on waitstate to all non-cache
accesses.

No, a cache doesn't impact other accesses to non-cacheable
memory areas. A local flash cache is something you could
just drop into an existing design without even worrying about
needing to turn it on or flush it. It's completely transparent.

Adding a cache to the ARM7 CPU (not to the flash) will add waitstate
to ALL non-hit accesses according to chip designers.
It also adds waitstates to ARM9's if you put the memory on the AMBA bus.
Only way to allow no waitstate operation is to put the SRAM in TCM.

With multithreading you can swap in a computable process and use EVERY
cycle.

So what? There are few wasted cycles on modern embedded CPUs.
Only very high-end CPUs are waiting a lot for slow memory.

If you make a jump to a location outside the cache, then you are dead in the
water.
Synch with AMBA bus
Synch with bus interface
SDRAM precharge cycle.
70 ns access...

With a multithreaded CPU you can use those cycles for something good.


Multithreading is not relevant in the embedded space, it would add a lot
of complexity and die area for hardly any gain.

Yes it is, just look at a mobile phone, lots of ~20 MIPS CPUs handling
Bluetooth, WLAN, GPS etc , just because noone has designed
a proper multithreading for embedded.

No, phones are extremely integrated and usually have only one CPU,
one DSP and perhaps a micro controller in the flash card.

Then you do not know how a moderm phone looks like.
Each Bluetooth chip normally has an ARM
Each WLAN chip normally has one or more ARMs
On Smart Phones, you have a GSM/WCDMA controller and an application CPU.
GPS functions will add one more ARM.
Then you have a micro doing the charging algorithm.

It quickly adds up.

Hardware multithreading doesn't give much performance on a high
end CPU, and it gives almost no benefit on a low end one. Less than
10% of the memory bandwidth is unused in an ARM7, so running a
second thread either means it runs at 10% of the maximum speed
or it slows down the main thread.

Multithreading for embedded systems is not about increasing performance.
It is about replacing 2 CPUs capable of 50 MIPS which only runs at 20 MIPS
with a single CPU which can run 2 x 20 MIPS threads.
I.E: it is trying to fix the real time response problem.

It is cheaper to have one CPU doing the job of two CPUs
than having two CPUs each doing the job of half a CPU.
Someone is going to get very rich, once they understand this.
I am too lazy...


It really only makes sense on high-end
CPUs, but even there the gains are not that impressive.

You are locked into conventional thoughts on multithreading.

If you believe that, you dont understand multithreading for embedded.
The purpose is not to increase performance, it is to improve real time
response so you do not have to have multiple CPUs.

You don't understand multithreading at all. Interrupt latency is
completely
unaffected by multithreading. Whether you run 2 interrupts in parallel at
half the speed or one after the other at full speed is irrelevant.

Not if you need both interrupts to respond within 200 ns.
With multithreading, you do not even need interrupt,
You can schedule a thread.

You confuse multiprocessing with multithreading. A 2-core CPU can
indeed deal with 2 interrupts in parallel at full speed.

No I dont.
A multithreaded CPU running at 400 MHz can do the task of 40 CPUs
running at 10 MHz.

It is impossible to run code at a predictable speed, so you're
screwed no matter whether you use a cache or not.


No you can measure how many cycles each thread is using
within a certain timq quanta, and ensure that each thread
gets their fair share.




--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB


.

Relevant Pages

  • Re: Atmel releasing FLASH AVR32 ?
    ... the solution is to have more associativity in the cache. ... in a separate CPU to avoid real time response conflicts and can ... I am saysing that it is cheaper to use asymmetric multithreading ... additional constraint to your "interrupt" system. ...
    (comp.arch.embedded)
  • Re: Atmel releasing FLASH AVR32 ?
    ... Same solution: more fast on-chip memory. ... in a separate CPU to avoid real time response conflicts and can ... asymmetric multiprocessing or asymmetric multithreading? ... If you do not understand the differences between cores like Itanium-2, ...
    (comp.arch.embedded)
  • Re: Out of control threads
    ... And during multithreading doesn't CPU pass a token between threads and run ... websites and scrape some info). ... calculation once you have the 10 values. ...
    (microsoft.public.dotnet.framework)
  • Re: How to make threads share CPU (almost) equally?
    ... > priority is set to MAX_PRIORITY at the ... It doesn't make your computer any faster, you'll just be stealing cpu ... > multithreading!!!) ... > the currently running thread sleep for a brief amount of time between ...
    (comp.lang.java.programmer)
  • Re: Pipeline induced interrupt latency jitter
    ... The time spacing between jitter edges is one CPU cycle. ... interrupts keep getting serviced) causes the jitter to disappear. ... cycles jitter. ...
    (comp.arch.embedded)