New embedded CPU architecture - Page 3

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: New embedded CPU architecture
Hi Anton,

Quoted text here. Click to load it

The IP3000 isn't shipping yet although it should be before the end of
the year.  Once the part is fully in production we'll commit the IP3k
backend code to the FSF and it will be part of future gcc releases.

FWIW the IP2000 code that's in the FSF tree isn't terribly good at
optimizing and needs some work.  The version that we supply with our SDK
generates significantly better code (*much* better in fact) but requires
some tweaks to the FSF tree to do it and so far we haven't had time to
come up with the necessary generic improvements to merge this back to
the FSF tree.


Regards,
Dave


Re: New embedded CPU architecture
Quoted text here. Click to load it

Nah, not a fixed number that limits the amount of tasks.
Better is to have two single instructions that save/restore the entire
processor context and an accompanying pointer register.

Meindert



Re: New embedded CPU architecture
On Thu, 2 Oct 2003 09:53:49 +0200, "Meindert Sprang"

Quoted text here. Click to load it

Time to reinvent the TI TMS9900 architecture ?

It had sixteen 16 bit general purpose register set somewhere in RAM,
so at each context switch, just switch to an other set of 16 memory
words. Unfortunately the processor was slow in normal operation, when
each register reference actually meant a main memory reference. This
was long before caches appeared in single chip microprocessors.

However, with current hardware architectures, all the registers in a
single register set would fit into a single cache line in the L1
cache, so the context switch overhead would be in the same order as a
cache miss.

Paul
 

Re: New embedded CPU architecture
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

Sounds good, BUT:  The critical thing in interrupts is the time
required to switch to a new environment.  The cache is all very
well for execution, but loading that cache requires reading all
those memory items, and ensuring the previous group is safely
stored in real memory.  So there is no real substitute for an
alternate register set.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: New embedded CPU architecture

<TMS9900 style register sets in memory>

Quoted text here. Click to load it

Even with 16 kB of L1 cache, you would have quite a few alternate
register sets :-).

Especially with interrupt service routines, which are quite small, the
likelihood of being forced to write back the interrupted program
register set into main memory is quite small. However, a complete task
switch would sooner or later force writing back the old register set.

Loading or storing a full cache line can be quite effective compared
to programmatically loading or storing registers on to the stack one
by one as must be done in some architectures. A wide memory bus helps
of course a lot. When accessing off-chip memory the data bus can not
be very large due to cost constraints, but for instance in old PC:s
with 64 bit (8 byte) wide data bus, the transfer of 32 bytes (a cache
line on x86 processors) requires a full RAS/CAS cycle for the first 8
bytes (and storing the next 24 bytes into the memory chip I/O
register), but for the next three cycles, only the low address was
supplied, transferring data from the I/O buffers to the CPU, thus
quite good transfer rates can be obtained in loading or storing entire
cache lines. Thus the actual memory width is 256 bits (32 bytes),
which is multiplexed for transmission over the data bus.

Paul
 

Re: New embedded CPU architecture
Quoted text here. Click to load it

You make some good points.  However I wouldn't like to limit it to
'short interrupt routines'.  We are talking about embedded
systems, remember, and I can envision a set of processes each
operating in their own space, as determined by the register set.
A further process could be the scheduler, which is entered by a
timer interrupt (or other condition).  The longer anything runs,
the larger the chance the cache for some other process is swapped
out.  Yet that process may need very short response time.

This sort of system will have a very simple kernel, with very
little kernal data to be maintained.  This helps to make it
reliable.

Probably the cache memory shouldn't even exist - the register set
would be kept in a known set of memory addresses, and those
addresses are using high speed external (or internal) memory.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: New embedded CPU architecture

Quoted text here. Click to load it

I agree. How about an on-chip high-speed "register space"
adequate to provide, say, 256 levels of context switching?

--
Morris Dovey
West Des Moines, Iowa USA
We've slightly trimmed the long signature. Click to see the full one.
Re: New embedded CPU architecture
Quoted text here. Click to load it

Do you really need that many on-chip? IMO, you only need a couple on
chip. The others can be loaded in/out in parallel with the execution
of other threads.

Jon

Re: New embedded CPU architecture

Quoted text here. Click to load it
You can dump the old context while the new thread is executing, but you
can't do much execution on the new thread until you have its context! Some
form of caching for commonly-used threads could therefore be useful - more
than just a couple of register sets.

Peter.



Re: New embedded CPU architecture
Quoted text here. Click to load it

You should put as much on chip as the resource allows.

Since we have established this "New embedded CPU architecture"
is a soft-core, and not intended as single-chip uC, then you should
look at the most common environment, and optimise for that.

Soft-cores can expect BlockRAM, so should be able to context switch
their register set within that block ram with minimal cycle overhead.
That can extend to hardware based slot assign, and support for dual-port
RAM for communicate between these now isloated/weighted threads.

Some uP schemes allow partial register-set overlap, so a smart compiler
can pass procedure parameters this way.

For some good examples of Custom soft cores, Industry Std soft cores,
and mapping to FPGA fabrics, see

http://www.quickcores.com /

They started with a Custom 9 bit opcode device, optimised for the 9 bit
Block RAM, but have moved to support industry std cores.
(8051/6805/8085/z8..)

-jg

Re: New embedded CPU architecture

Quoted text here. Click to load it

...


For some reason, whenever i do a web search on "soft core" I get
a bunch of results that have *nothing* to do with Embedded CPUs...

:)



--
Guy Macon, Electronics Engineer & Project Manager.  Remember Doc Brown
from the 'Back to the Future' movies?  Do you have an "impossible"
We've slightly trimmed the long signature. Click to see the full one.
Re: New embedded CPU architecture

Quoted text here. Click to load it

Ok. It's your Si - how many can I have?  :-)

--
Morris Dovey
West Des Moines, Iowa USA
We've slightly trimmed the long signature. Click to see the full one.
Re: New embedded CPU architecture

Quoted text here. Click to load it

Jon...

I'd like:

[1] A "bool" instruction that can perform all of the sixteen
possible boolean operations. (It can be implemented in two levels
of logic using either all nand or all nor gates.)

[2] I'd like a unix-like clock/calendar with CPU clock resolution
and alarm interrupt capability, so that I can time activities,
and schedule/trigger events.

--
Morris Dovey
West Des Moines, Iowa USA
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline