Pipelined 6502/z80 with cache and 16x clock multiplier

EETimes had an interesting article asking if 4-bits was dead.
http://www.eetimes.com/discussion/other/4211452/Is-4-Bits-Dead-

These chips have been pad limited for 2 decades, and as such are
probably manufactured at fabs that are beyond obsolete.

You could take a public CPU design like OpenRISC and replace the
instruction decoder, and get an easy ~4x performance jump running
65c802/65c816 code.

Compatibility with the Apple// disk controller would be poor. ;)
But lets ignore that for the moment, Apple made some work arounds
for the Apple2GS, so that can be fixed.

Step 2 would be to add a boot loader to set the cache modes up
correctly for your memory spaces, so everything is not write through.
That will get you another ~2x speedup.

One should be able to do at least a 16x local clock multiplier, 
especially if the base clock is a pathetic 2 MHz.
That will get you another ~8x speedup.

The end result will be a ~quarter of the speed of the native OpenRISC
opcodes, due to being register starved, but close enough not to matter?
Compatibility is important.

The end result would still be pad limited and tiny, and made at a
still obsolete if newer fab.

Is there a market for a 6502 era CPU that ran ~10x faster at 
~10% more cost?

I think I just described the AVR8 family of CPUs, so the answer
would be yes...

Brett

- Merry Christmas

On 12/19/2010 6:25 PM, Brett Davis wrote:
> EETimes had an interesting article asking if 4-bits was dead.
> http://www.eetimes.com/discussion/other/4211452/Is-4-Bits-Dead-
>
> These chips have been pad limited for 2 decades, and as such are
> probably manufactured at fabs that are beyond obsolete.
>
> You could take a public CPU design like OpenRISC and replace the
> instruction decoder, and get an easy ~4x performance jump running
> 65c802/65c816 code.
>
> Compatibility with the Apple// disk controller would be poor. ;)
> But lets ignore that for the moment, Apple made some work arounds
> for the Apple2GS, so that can be fixed.
>
> Step 2 would be to add a boot loader to set the cache modes up
> correctly for your memory spaces, so everything is not write through.
> That will get you another ~2x speedup.
>
> One should be able to do at least a 16x local clock multiplier,
> especially if the base clock is a pathetic 2 MHz.
> That will get you another ~8x speedup.
>
> The end result will be a ~quarter of the speed of the native OpenRISC
> opcodes, due to being register starved, but close enough not to matter?
> Compatibility is important.
>
> The end result would still be pad limited and tiny, and made at a
> still obsolete if newer fab.
>
> Is there a market for a 6502 era CPU that ran ~10x faster at
> ~10% more cost?

Perhaps, but I don't think that is the target market for 4 bit 
processors.  ARAIR the bit market for 4 bit processors is in the really 
low requirements consumer areas, such as remote controls for TV's etc. 
and things like microwave ovens, clothes washers, etc.  As such, speed 
isn't an issue, but low cost and perhaps low power (i.e. longer battery 
life) is.  So the market you are talking about may very well exist, but 
that doesn't mean it will replace the 4 bit market.


-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)

Hi Brett,

On 12/19/2010 7:25 PM, Brett Davis wrote:
> EETimes had an interesting article asking if 4-bits was dead.
> http://www.eetimes.com/discussion/other/4211452/Is-4-Bits-Dead-

I no longer read EETimes... are they considering the
6502 and Z80 "4 bit" parts because they have 4 bit
ALUs within?  Or, are they restricting their 4 bit
handle for things like the 4004?

> These chips have been pad limited for 2 decades, and as such are
> probably manufactured at fabs that are beyond obsolete.
>
> You could take a public CPU design like OpenRISC and replace the
> instruction decoder, and get an easy ~4x performance jump running
> 65c802/65c816 code.
>
> Compatibility with the Apple// disk controller would be poor. ;)

Or anything else that uses timing loops or implicitly
counts on execution speed wrt peripheral interfaces, etc.
(e.g., some devices have internal synchronizers which
won't run faster just because the processor wants to
run faster -- "recovery times").

> But lets ignore that for the moment, Apple made some work arounds
> for the Apple2GS, so that can be fixed.
>
> Step 2 would be to add a boot loader to set the cache modes up
> correctly for your memory spaces, so everything is not write through.
> That will get you another ~2x speedup.
>
> One should be able to do at least a 16x local clock multiplier,
> especially if the base clock is a pathetic 2 MHz.
> That will get you another ~8x speedup.
>
> The end result will be a ~quarter of the speed of the native OpenRISC
> opcodes, due to being register starved, but close enough not to matter?
> Compatibility is important.
>
> The end result would still be pad limited and tiny, and made at a
> still obsolete if newer fab.
>
> Is there a market for a 6502 era CPU that ran ~10x faster at
> ~10% more cost?

The military, IIRC, still uses 6502's in some weapon systems (?)

> I think I just described the AVR8 family of CPUs, so the answer
> would be yes...

Rabbit tried this approach with the Z80.  But, decided to make
something that wasn't 100% compatible with the original Z80.
At least the Z180 devices didn't suffer this fate.

On Dec 19, 9:25=A0pm, Brett Davis <gg...@yahoo.com> wrote:

> These chips have been pad limited for 2 decades, and as such are
> probably manufactured at fabs that are beyond obsolete.

People keep saying this, and never mind that it is totally untrue.
Many 4-bit applications are speaking toys, which have a huge (multi
megabit) mask ROM array on-chip. Yes, the processor core would be pad-
limited if it was made on a die by itself. But it never is.

larwe wrote:
> On Dec 19, 9:25 pm, Brett Davis<gg...@yahoo.com>  wrote:
>
>> These chips have been pad limited for 2 decades, and as such are
>> probably manufactured at fabs that are beyond obsolete.
>
> People keep saying this, and never mind that it is totally untrue.
> Many 4-bit applications are speaking toys, which have a huge (multi
> megabit) mask ROM array on-chip. Yes, the processor core would be pad-
> limited if it was made on a die by itself. But it never is.

I would add that anyone working on a 4-bit
implementation probably wouldn't be discussing
it on comp.arch.embedded.

On Dec 19, 6:25=A0pm, Brett Davis <gg...@yahoo.com> wrote:
> EETimes had an interesting article asking if 4-bits was dead.http://www.e=
etimes.com/discussion/other/4211452/Is-4-Bits-Dead-
>
> These chips have been pad limited for 2 decades, and as such are
> probably manufactured at fabs that are beyond obsolete.

They are pad limited only for the app.  Why build/bond more pads than
necessary?  You can build the exact number of pads in ASIC.

>
> You could take a public CPU design like OpenRISC and replace the
> instruction decoder, and get an easy ~4x performance jump running
> 65c802/65c816 code.

The article never mention 65XX as 4 bit.

>
> Compatibility with the Apple// disk controller would be poor. ;)
> But lets ignore that for the moment, Apple made some work arounds
> for the Apple2GS, so that can be fixed.

Who care about Apple Compatibility?  Not even Apple.

On Mon, 20 Dec 2010 13:45:05 -0800 (PST), linnix
<me@linnix.info-for.us> wrote:

>On Dec 19, 6:25&#4294967295;pm, Brett Davis <gg...@yahoo.com> wrote:
>> EETimes had an interesting article asking if 4-bits was dead.http://www.eetimes.com/discussion/other/4211452/Is-4-Bits-Dead-
>>
>> These chips have been pad limited for 2 decades, and as such are
>> probably manufactured at fabs that are beyond obsolete.
>
>They are pad limited only for the app.  Why build/bond more pads than
>necessary?  You can build the exact number of pads in ASIC.

In this context pad-limited most probably means that the die size is
decided strictly by the number of pads one has to put around the die
even if there is significant core area is left unused. Of course there
technologies where one doesn't need to put the pads around the die and
they can be placed inside but the cost for such a technique would
probably be too high for the applications mentioned.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

On Dec 20, 9:42=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
> On Mon, 20 Dec 2010 13:45:05 -0800 (PST), linnix
>
> <m...@linnix.info-for.us> wrote:
> >On Dec 19, 6:25 pm, Brett Davis <gg...@yahoo.com> wrote:
> >> EETimes had an interesting article asking if 4-bits was dead.http://ww=
w.eetimes.com/discussion/other/4211452/Is-4-Bits-Dead-
>
> >> These chips have been pad limited for 2 decades, and as such are
> >> probably manufactured at fabs that are beyond obsolete.
>
> >They are pad limited only for the app. =A0Why build/bond more pads than
> >necessary? =A0You can build the exact number of pads in ASIC.
>
> In this context pad-limited most probably means that the die size is
> decided strictly by the number of pads one has to put around the die
> even if there is significant core area is left unused. Of course there
> technologies where one doesn't need to put the pads around the die and
> they can be placed inside but the cost for such a technique would
> probably be too high for the applications mentioned.
> --

Around the die could be small (<100) or big (>500).  For example, some
LCD and OLED controllers are very thin and long, in order to have as
many pads as possible.  So, if the app requires it, it could be done.

In article <ien6lu$8n9$1@speranza.aioe.org>,
 D Yuniskis <not.going.to.be@seen.com> wrote:

> Hi Brett,
> 
> On 12/19/2010 7:25 PM, Brett Davis wrote:
> > EETimes had an interesting article asking if 4-bits was dead.
> > http://www.eetimes.com/discussion/other/4211452/Is-4-Bits-Dead-
> 
> > These chips have been pad limited for 2 decades, and as such are
> > probably manufactured at fabs that are beyond obsolete.
> >
> > You could take a public CPU design like OpenRISC and replace the
> > instruction decoder, and get an easy ~4x performance jump running
> > 65c802/65c816 code.
> >
> > Compatibility with the Apple// disk controller would be poor. ;)
> 
> Or anything else that uses timing loops or implicitly
> counts on execution speed wrt peripheral interfaces, etc.
> (e.g., some devices have internal synchronizers which
> won't run faster just because the processor wants to
> run faster -- "recovery times").
> 
> > Is there a market for a 6502 era CPU that ran ~10x faster at
> > ~10% more cost?
> 
> The military, IIRC, still uses 6502's in some weapon systems (?)
> 
> > I think I just described the AVR8 family of CPUs, so the answer
> > would be yes...
> 
> Rabbit tried this approach with the Z80.  But, decided to make
> something that wasn't 100% compatible with the original Z80.
> At least the Z180 devices didn't suffer this fate.

I looked at the Rabbit CPUs, its a quite nice upgrade that makes
using C code for it viable. 

Its not pipelined, 2 cycles per opcode byte and data byte.

Something I would have expected ~6 years after the Z80 came out, 
not ~26 years. ;)

The 20 year RISC fad has caused designs in the low end to needlessly
fall behind the times.

Brett

Hi Brett,

On 12/23/2010 6:26 PM, Brett Davis wrote:
>> Rabbit tried this approach with the Z80.  But, decided to make
>> something that wasn't 100% compatible with the original Z80.
>> At least the Z180 devices didn't suffer this fate.
>
> I looked at the Rabbit CPUs, its a quite nice upgrade that makes
> using C code for it viable.

I didn't see that it bought you anything "appreciable".
I.e., if you aren't going to make a "100% compatible"
device, then why not come up with an entirely different
design (instead of reheating one that was decades old)?

> Its not pipelined, 2 cycles per opcode byte and data byte.

Most of its "improvements" come from a full 8-bit ALU
(the original Z80 had a 4 bit ALU so had to push things
through, "twice")

> Something I would have expected ~6 years after the Z80 came out,
> not ~26 years. ;)

You can blame that on Zilog's unbelievable ineptitude.
They announced many "nice" (potentially) successors to
the Z80 but failed to deliver on any of them.  Company
had the market in its hands to *lose* -- and promptly
*did* exactly that!

> The 20 year RISC fad has caused designs in the low end to needlessly
> fall behind the times.

Nowadays, you can take many of these low end design cores
and roll your own processor.  E.g., I think there is an "open
core" version of the Z80 (T80?).  Go play with it!  :>