New cache

I have a new cache.
Researched it as best as possible and it appears to be new.
Anyone interested?
Address matching in less
than 10% overhead of the cache RAM size in implementation for any size.
Not really interested in developing it myself.
Useful for gigahertz CPUs, missiles, supercomputers, mobile phones,
graphics cards, encryption, compression, and so on.

7

7 <> wrote in message news:<kbpTc.155822$ .uk>...
> I have a new cache.
> Researched it as best as possible and it appears to be new.
> Anyone interested?
> Address matching in less
> than 10% overhead of the cache RAM size in implementation for any size.
> Not really interested in developing it myself.
> Useful for gigahertz CPUs, missiles, supercomputers, mobile phones,
> graphics cards, encryption, compression, and so on.

Its quite unlikely to discover something fundamentally important after
50yrs of computer production. Nothing new rarely is infact new.

Posting such a claim accross such a strange group of NGs doesn't sound
right either. Anybody interested in such a cache design would be in
comp.arch though and many people there have very long memories.

The tiny overhead cache support would come likely from having larger
lines per associative tag or use a hashing technique. Even classic N
way set associative doesn't add alot of real estate compared to ram
array.

Unless you are a qualified sram circuit/mask designer it would be hard
to justify such a claim too. Row/Col periphery take up quite a bit of
space too. The faster the sram must cycle, the larger the periphery
must get to support such speed. Bigger caches with more efficient
row/col periphery are necessarily slower ie multi cycle. Laws of
physics are hard to beat.

regards

johnjakson_usa_com

john jakson

john jakson wrote:

> 7 <> wrote in message
> news:<kbpTc.155822$ .uk>...
>> I have a new cache.
>> Researched it as best as possible and it appears to be new.
>> Anyone interested?
>> Address matching in less
>> than 10% overhead of the cache RAM size in implementation for any size.
>> Not really interested in developing it myself.
>> Useful for gigahertz CPUs, missiles, supercomputers, mobile phones,
>> graphics cards, encryption, compression, and so on.
>
> Its quite unlikely to discover something fundamentally important after
> 50yrs of computer production. Nothing new rarely is infact new.

I would imagine a new is rare - there are only a handful designs that exist.
But mine is different to existing caches as I wasn't trying
to make a cache but something else and this result just popped out.

One of my previous inventions is at
http://www.ecu.pwp.blueyonder.co.uk
Rare and new is not beyond me. I keep an eye open for detail
and curious results.


> Posting such a claim accross such a strange group of NGs doesn't sound
> right either. Anybody interested in such a cache design would be in
> comp.arch though and many people there have very long memories.
>
> The tiny overhead cache support would come likely from having larger
> lines per associative tag or use a hashing technique. Even classic N
> way set associative doesn't add alot of real estate compared to ram
> array.
>
> Unless you are a qualified sram circuit/mask designer it would be hard
> to justify such a claim too. Row/Col periphery take up quite a bit of
> space too. The faster the sram must cycle, the larger the periphery
> must get to support such speed. Bigger caches with more efficient
> row/col periphery are necessarily slower ie multi cycle. Laws of
> physics are hard to beat.

If you were serious, what could you lose?
Its 2 or 3 pages to describe it in full in English.
One or two months to modify vhdl of a 6502 or something
like that to see it working,
and then tape it out as fast as your legs can carry.
I'm only interested in serious business proposal.
Otherwise I will have to catch a plane to the Far East.
But as indicated earlier, I'm not interested in developing it myself.


> regards
>
> johnjakson_usa_com

7

7 <> wrote in message news:<2wSTc.143347$ o.uk>...
> john jakson wrote:
>
> > 7 <> wrote in message
> > news:<kbpTc.155822$ .uk>...
> >> I have a new cache.
> >> Researched it as best as possible and it appears to be new.
> >> Anyone interested?
> >> Address matching in less
> >> than 10% overhead of the cache RAM size in implementation for any size.
> >> Not really interested in developing it myself.
> >> Useful for gigahertz CPUs, missiles, supercomputers, mobile phones,
> >> graphics cards, encryption, compression, and so on.
> >
> > Its quite unlikely to discover something fundamentally important after
> > 50yrs of computer production. Nothing new rarely is infact new.
>
> I would imagine a new is rare - there are only a handful designs that exist.
> But mine is different to existing caches as I wasn't trying
> to make a cache but something else and this result just popped out.
>
> One of my previous inventions is at
> http://www.ecu.pwp.blueyonder.co.uk
> Rare and new is not beyond me. I keep an eye open for detail
> and curious results.
>
>
> > Posting such a claim accross such a strange group of NGs doesn't sound
> > right either. Anybody interested in such a cache design would be in
> > comp.arch though and many people there have very long memories.
> >
> > The tiny overhead cache support would come likely from having larger
> > lines per associative tag or use a hashing technique. Even classic N
> > way set associative doesn't add alot of real estate compared to ram
> > array.
> >
> > Unless you are a qualified sram circuit/mask designer it would be hard
> > to justify such a claim too. Row/Col periphery take up quite a bit of
> > space too. The faster the sram must cycle, the larger the periphery
> > must get to support such speed. Bigger caches with more efficient
> > row/col periphery are necessarily slower ie multi cycle. Laws of
> > physics are hard to beat.
>
> If you were serious, what could you lose?
> Its 2 or 3 pages to describe it in full in English.
> One or two months to modify vhdl of a 6502 or something
> like that to see it working,
> and then tape it out as fast as your legs can carry.
> I'm only interested in serious business proposal.
> Otherwise I will have to catch a plane to the Far East.
> But as indicated earlier, I'm not interested in developing it myself.
>
>
> > regards
> >
> > johnjakson_usa_com

Not suggesting you don't have anything, couldn't say without looking.
But an invention that doesn't want to get further developed by
inventor is likely to not get further.

Theres a book by

Jim Handy "the Cache memory book, THE authoritative reference on cache
design" pub by AP. I couldn't find my cache model in there either but
its a good read.

Funny thing is even terribly mundane ideas get driven into the world
market by driven people, and I am not sure ideas ever fly by
themselves until they reached crit mass.

Funny you'd suggest 6502, never heard of that with cache, why not MIPs
etc, thats what most outsiders might play with, or use the DLX model
or Sparc.

Although the 6502 might seem simple, better to use a 32b risc design
to show off design.


If you are in the semi industry, don't you have colleagues to descibe
idea to under NDA.

Still I'd suggest comp.arc as a place to post, a lot of people there
will have more cache exp.

regards

johnjakson_usa_com

john jakson

john jakson wrote:

> 7 <> wrote in message
> news:<2wSTc.143347$ o.uk>...
>> john jakson wrote:
>>
>> > 7 <> wrote in message
>> > news:<kbpTc.155822$ .uk>...
>> >> I have a new cache.
>> >> Researched it as best as possible and it appears to be new.
>> >> Anyone interested?
>> >> Address matching in less
>> >> than 10% overhead of the cache RAM size in implementation for any
>> >> size. Not really interested in developing it myself.
>> >> Useful for gigahertz CPUs, missiles, supercomputers, mobile phones,
>> >> graphics cards, encryption, compression, and so on.
>> >
>> > Its quite unlikely to discover something fundamentally important after
>> > 50yrs of computer production. Nothing new rarely is infact new.
>>
>> I would imagine a new is rare - there are only a handful designs that
>> exist. But mine is different to existing caches as I wasn't trying
>> to make a cache but something else and this result just popped out.
>>
>> One of my previous inventions is at
>> http://www.ecu.pwp.blueyonder.co.uk
>> Rare and new is not beyond me. I keep an eye open for detail
>> and curious results.
>>
>>
>> > Posting such a claim accross such a strange group of NGs doesn't sound
>> > right either. Anybody interested in such a cache design would be in
>> > comp.arch though and many people there have very long memories.
>> >
>> > The tiny overhead cache support would come likely from having larger
>> > lines per associative tag or use a hashing technique. Even classic N
>> > way set associative doesn't add alot of real estate compared to ram
>> > array.
>> >
>> > Unless you are a qualified sram circuit/mask designer it would be hard
>> > to justify such a claim too. Row/Col periphery take up quite a bit of
>> > space too. The faster the sram must cycle, the larger the periphery
>> > must get to support such speed. Bigger caches with more efficient
>> > row/col periphery are necessarily slower ie multi cycle. Laws of
>> > physics are hard to beat.
>>
>> If you were serious, what could you lose?
>> Its 2 or 3 pages to describe it in full in English.
>> One or two months to modify vhdl of a 6502 or something
>> like that to see it working,
>> and then tape it out as fast as your legs can carry.
>> I'm only interested in serious business proposal.
>> Otherwise I will have to catch a plane to the Far East.
>> But as indicated earlier, I'm not interested in developing it myself.
>>
>>
>> > regards
>> >
>> > johnjakson_usa_com
>
> Not suggesting you don't have anything, couldn't say without looking.
> But an invention that doesn't want to get further developed by
> inventor is likely to not get further.
>
> Theres a book by
>
> Jim Handy "the Cache memory book, THE authoritative reference on cache
> design" pub by AP. I couldn't find my cache model in there either but
> its a good read.
>
> Funny thing is even terribly mundane ideas get driven into the world
> market by driven people, and I am not sure ideas ever fly by
> themselves until they reached crit mass.
>
> Funny you'd suggest 6502, never heard of that with cache, why not MIPs
> etc, thats what most outsiders might play with, or use the DLX model
> or Sparc.

It works well for small CPUs such as 6502 as well as big because of the low
overheads of the address matching circuitry for keeping the costs
right down.

> Although the 6502 might seem simple, better to use a 32b risc design
> to show off design.
>
> If you are in the semi industry, don't you have colleagues to descibe
> idea to under NDA.

I can leg it to Far East and DIY but I feel it better to have
a big corp engaged in licensing it out from a central point.
More revenue, less work.

> Still I'd suggest comp.arc as a place to post, a lot of people there
> will have more cache exp.

Thanks I just checked - they seem more into caches.

> regards
>
> johnjakson_usa_com

7