Request for L1 cache design comments

[Rick C. Hodgin]

I'd like to ask for input regarding my L1 cache design. Here you see the
data retrieval method in graphical form. The address is input at the top
in blue/cyan. It goes through five address tests which indicate if any
of the 40-bits of the address data block fall into the range of data
associated with that cache row. If so, byte-by-byte per cell they are
pushed onto the bus.

The overall design allows four reads and four writes per cycle, two each
from main thread and love thread, and two each from the other core's
main thread and love thread, which allows for synchronous cache updating
within the core.

This design is intended for use as a 16KB L1 instruction, and 16KB to
32KB L1 data cache (right now I'm planning 16KB L1 data):

https://github.com/RickCHodgin/libsf/blob/master/arxoda/arxoda-documentation/images/cache_4read_4write.png

-----
I have never seen a cache design before, not in hardware or schematic
or even in block form about how they operate. I searched for a design
a few weeks ago and could not find one online, which is what prompted
me to sit down and see if I could design one. Over the years I've read
timing information on various Intel and AMD CPU releases about L1 caches
taking two or three clocks in various CPUs, and asked myself how would
I create a design which did that? This image is the result.

This design was constructed completely off the top of my head. And I
plan to only have an L1 in the first generation of my CPU. And, though
it depends on how the implementation goes, I may just make this cache
design much larger. We'll see though.

This image doesn't include logic for populating addresses, though I have
that in mind. It also doesn't include logic for populating the data in
the cache line, though I also have that in mind.

I plan to have a control mode on each row which allows it to take itself
out of service until it populates the row that was requested. I also
have a retirement policy which is based on the oldest data in the cache
being used to fill new requests, and a memory retrieval system which
enters a wait state until the memory request is able to be filled from
cache. In this way, all data will route through the cache (except for
direct memory-to-memory copies).

Best regards,
Rick C. Hodgin

[Rick C. Hodgin]

On Tuesday, December 13, 2016 at 12:55:27 PM UTC-5, Rick C. Hodgin wrote:
> I'd like to ask for input regarding my L1 cache design...

It has been updated. I've never seen a cache design before. I don't know
if this design is on the right track or not. To my understanding of how
CPUs work, it seems to be at least in the right general direction.

If anyone has feedback I'd be interested to hear it. You can email me
privately if you prefer.

https://github.com/RickCHodgin/libsf/blob/master/arxoda/arxoda-documentation/images/cache_4read_4write.png

-----
It is a 40- or 42-bit design, 4-read, 4-write, two clock cycles per
read or write. Failures pass thru to a main memory read request,
which can be connected to an L2. Spills and fills are updated 64-
bits at a time on a separate 64-bit buses. It is byte addressable,
and byte updateable. Byte writes from four separate sources can
occur in four consecutive bytes in the cache at any location. Writes
which span a single 128-byte cache row are handled.

I'm just curious from any CPU designers to hear what you think?

Thank you in advance.

[MitchAlsup]

On Monday, December 19, 2016 at 12:27:41 PM UTC-6, Rick C. Hodgin wrote:
> On Tuesday, December 13, 2016 at 12:55:27 PM UTC-5, Rick C. Hodgin wrote:
> > I'd like to ask for input regarding my L1 cache design...
>

If you promise never to blather this site again with religious crap
even again, I will give you a complete writeup on your current cache
design and compare it to a similar cache I did some 20 years ago.

Now, just to be certain, the religious crap includes any sentence
with the words "god", jesus", "heaven", "hell", "sin", "pray";
or with the phrases "loves you", bless you".

But you have to promise, and you have to stick with the promise.

[Rick C. Hodgin]

MitchAlsup wrote:
> ... I will give you a complete writeup on your current cache

design and compare
> it to a similar cache I did some 20 years ago.

You should ask yourself why I post the things I do. Do you think I do
it to be rude? Mean? Hurtful? Demeaning? Is it jusr to troll? Or
is it for another reason? I mean what is the central message I post?
It's this:

I want the absolute best for you.
I want you to live on forever in a body like the angels,
young, fit, strong, beautiful, and without limitation.
I want you to prosper greatly, and to help others prosper
greatly by your gifts and talents being given to them.

Jesus is the only one who can make that happen, and it's because if
what He did at the cross. His blood was shed to save our eternal
souls.

It means so much to each of us ... it must be the focus of our lives.

-----

I would love to hear your write-up, but I don't expect anything quite
so formal. Just a, "Well, it won't work because," or, "You're on the
right path, but... " Or, "It looks good."

Since you worked for AMD almost 20 years ago, I'll just assume it's
the basic design that eventually made its way into the 8-series
Opterons. :-)

Oh ... I crack myself up. LOL! :-)

[Quadibloc]

On Tuesday, December 13, 2016 at 10:55:27 AM UTC-7, Rick C. Hodgin wrote:
> If so, byte-by-byte per cell they are
> pushed onto the bus.

That sounds like a problem. If you're taking data out of the cache one byte at a
time, that makes taking data from the cache slower than it needs to be. The whole
point of a cache is to make access to the data in it as fast as possible.

John Savard

[Quadibloc]

On Monday, December 19, 2016 at 5:31:58 PM UTC-7, Rick C. Hodgin wrote:

> You should ask yourself why I post the things I do. Do you think I do
> it to be rude? Mean? Hurtful? Demeaning? Is it jusr to troll?

You have reminded me of a quote from a famous Christian:

Of all tyrannies, a tyranny sincerely exercised for the good of its victims may
be the most oppressive. It would be better to live under robber barons than
under omnipotent moral busybodies. The robber baron's cruelty may sometimes
sleep, his cupidity may at some point be satiated; but those who torment us for
our own good will torment us without end for they do so with the approval of
their own conscience.
- C. S. Lewis

What is true of tyrants is true to a lesser degree of Internet trolls.

Your posts on religious subjects are being done for our own good, rather than
for your own malicious amusement, but they are still in their result and effect
a form of trolling.

John Savard

[Rick C. Hodgin]

If you look at the image at the bottom you'll see what I mean. Those
are memory read/write buses, and they're grouped together in blocks
of eight cells.

What I meant was the cache design examines individual bytes within the
cache line and only writes out those 64-bit blocks that are dirty (if
any of the bytes within the block are dirty, then just those blocks
are written).

[Rick C. Hodgin]

Without Jesus Christ taking away your sin, John, everything that you
are will perish upon your death in this world. You will enter in to
eternal torment where you will writhe in agony forever ... the deemed
punishment for an eternal being of grand form and power (you) who has
turned his back on the truth.

There is a malicious attack of Jesus Christ in this world. It exists
to soil the name of Christ, placing Him in such a regard that people
would find revulsion in those who call upon His name.

It was never intended to be like that. And it is not like that in
truth. It is only that way behind the lie perpetrated by that attack,
by the enemy who would see every human soul in Hell forever.

But Jesus has made a way out for everyone who will come to Him and
ask forgiveness.

It is more important than other things because this world exists for
each of us only for a time ... AND THEN eternity begins.

-----
I position my eyes upon eternity for you, John, and others, because
today you can't see it. I teach you the things you won't learn from
others in this world who are not also focused upon Jesus Christ,
having come to know what His death, resurrection, and eternal reign
in power and authority truly mean.

I pray for you (by name), and the people on these groups (by name),
and I point you to Him so that you will have the opportunity from my
lips (and my fingers) to hear about the One who can save your eternal
soul from death.

Jesus has commanded all men everywhere to repent. We are all under
that request. I merely remind those who are unaware, or who have
placed non-priority on that request, of its reality, and ongoing
existence.

We have an opportunity, John, to be restored to that which God created
us to be before sin entered in and destroyed everything. We were made
in the image and likeness of God, so that as He is, so also will we be
when we see Him on the other side of death. Some will see Him as
Savior and Lord, and others will seem Him as Judge and Jury.

It is my deepest desire that each of you come to repentance so that you
might meet Him as Savior and Lord and hear the words, "Well done, my
good and faithful servant. Enter into my rest," and not, "Depart from
me ye workers of iniquity ... I never knew you."

[MitchAlsup]

So, you really don't want to know how a real cache is built.
So be it.

[Rick C. Hodgin]

On Tuesday, December 20, 2016 at 1:53:04 PM UTC-5, MitchAlsup wrote:
> So, you really don't want to know how a real cache is built.
> So be it.

Mitch, I have a great respect for your abilities, knowledge, experience,
and willingness to share what you know with others. It comprises a vast
gift, and a great attainment by utilizing that gift for real gain in a
very complex discipline.

I would like so very much to learn about how the various aspects of a
CPU are designed, so that I can make my Arxoda CPU the best it can
possibly be. I sent an email to someone the other day telling them
that I was no longer content to set a goal around the few-hundred-MHz
range, but would actually like to design a world-class CPU that is the
best man can produce. I do not expect to do it alone, but I now have
that goal for my project, and have for a few weeks now.

But beyond that, I desire even more so, that you would live on in
eternity and have your tremendous existence asset remain and persist
and thrive and shine on to so many other souls.

You are a tremendous creation of God, Mitch. We all are. It is only
sin that strikes us down and makes us little more than raging animals.
But Jesus Christ gives us the power and ability to change that. By
placing our faith and trust in Him, and in asking Him to forgive our
sin, we are set free from that bondage, set free from only knowing
the flesh, to then also know that which God Himself is: spirit.

I desire that for you more than I desire to create my CPU product.
And if the cost of me perpetuating that stronger, earnest desire for
you to enter into eternity alive (as by me continuing to witness unto
you about Jesus Christ) is that I will never come to know how a cache
is properly designed, then I am content to walk in that ignorance
FOREVER.

Your soul is more important to me than anything I could ever achieve
in this world. You are worth more to me than even my best design. I
would sign away all rights to it in a second if it meant I could save
you, Mitch. But I can't. I can only point you to the one who can,
for only He can save you.

I place great value on you, Mitch, but it's nothing compared to that
which Jesus places on you. He stepped out of paradise, and came here
to live in the filth and the muck, so that He could do for you that
which you cannot do for yourself: save your eternal soul.

He is the greatest of the great. And I ask you to investigate that
claim and see for yourself if He is who I say He is. You will find
that my descriptions of who He is are inadequate. That I am feeble
writer of limited ability alongside His Greatness. You'll find that
I have nothing to offer up but stained words by a citizen of this
sinful world, when what He should be receiving is so much more than
I can ever give in my present form.

I love each of you so much. But it is nothing compared to the love
that Jesus Christ has for you, for His is right now an eternal love
for you. He has His arms out wide to receive you unto His Kingdom.

[thomas....@gmail.com]

@Mitch: If it isn't for Rick (or the reduction of off-topic discussions), maybe you want to share your knowledge nevertheless for the other group-readers?

@Rick #1: I am by no way a cache expert, but still some random notes:
- I had a hard time to understand your drawing - either because I am too stupid, or because it works differently than I would expect. Nevertheless:
- It looks like you access your memory byte-wise. This is of course much too slow if you want to have 40b input/output data finally. (The opposite could be a better strategy: Read/Write 80/160/320b in parallel.) When high-end CPUs have a latency of e.g. 3 clocks, this is only because of the high clock-speed, not e.g. because the access the cache 3 times for one access.
- In some points your drawing is very detailed (gates, individual data lines drawn), some others are higher level, but the meaning is not clear to me (e.g. "cache metric decoder")
- I have not seen a hit/miss detection?

@Rick #2: While I guess that most/all readers can accept your religiousness, everybody here agrees that discussions about this are really off-topic... (It is like someone would try to start to convince people to not eat meat, to not use cars to not pollute the environment, etc., every 2nd post.)

Regards,

Thomas

[Rick C. Hodgin]

On Tuesday, December 20, 2016 at 6:16:31 PM UTC-5, thomas....@gmail.com wrote:
> @Rick #1: I am by no way a cache expert, but still some random notes:
> - I had a hard time to understand your drawing - either because I am too stupid, or because it works differently than I would expect. Nevertheless:

I have never done anything like this before. To be honest, it kind of
"revealed itself" to me as I was designing it. I began with a portion
of the image, which did some function, and then I would have the thought
in the back of my mind how the next portion would go, and so on. The
end result is that image. I did not particularly plan it to turn out
that way, it's just how it came forth.

> - It looks like you access your memory byte-wise. This is of course much too slow if you want to have 40b input/output data finally.

What you see there in the middle is a byte cell. It holds the smallest
directly addressable quantity of memory my CPU will uniquely address (an
8-bit byte). However, you'll note in the top and bottom of the central
cell there are four write (top) and four read (bottom) ports. These
deposit into a 40-bit bus. Each individual byte takes up its slot in
the bus, so that each cell is assembled with other cells to the right
and left in the cache line to create the entire 40-bit quantity.

The cache request circuitry for reads (not shown directly in the image)
wire into the connections indicating which portions of the 8-bits in
the cache cell enter into which portions of the four 40-bit buses

You can see the aggregation of buses in this other image:

Here you see the 128-byte cells per cache row, and the addresses
required to address the data within the cell, as well as the
overflow of addresses in a prior memory range:
https://raw.githubusercontent.com/RickCHodgin/libsf/master/arxoda/arxoda-documentation/images/cache_l1/cache_line.png

The buses along the left show how the data is connected logically.
There are four 40-bit write buses coming in, four 40-bit read buses
coming out, two 64-bit main memory buses (which can be connected to
an L2 rather than directly to a main memory controller buffer), as
well as inputs for incoming addresses.

One feature not directly shown is a way to setup the cache metrics.
I haven't yet finalized how I'm going to do that, but basically it
allows add and subtract operations on the cumulative saturating count
in the middle-right. I believe that logic needs to be moved to a
row-wide metric rather than a cell metric. However, by keeping it
as a cell metric it would allow for metrics to be established based
on heavy hit usage areas, such that single-reads, dual-reads, tri-
reads, and quad-reads to individual cells, all affect the weight of
the data in the cache more or less than do other operations (and the
same for writes and also non-activity).

At first glance, I am thinking that every read and write will increase
the count by 2^n, where n is the number of hits per cell (or per row
if I move it out), and every every non-access will decrease it by one.

> (The opposite could be a better strategy: Read/Write 80/160/320b in parallel.) When high-end CPUs have a latency of e.g. 3 clocks, this is only because of the high clock-speed, not e.g. because the access the cache 3 times for one access.

I'm not sure how to do this in a way that is faster. I would like to do
it asynchronously, and I've considered paths which take a conservative
estimate of the longest wire lengths and maximum path through gates so
that I have a parallel operation which is conducted, with some extra
padding added on for safety, which then signals when the operation
should've been completed in raw switch-speed time, which then completes
and waits for the next bus cycle to populate the data onto the bus for
that duration. I've considered a double-pumped, tri-pumped, or quad-
pumped clock, etc.

For now, I want to get it working in simulation, and in my Altera FPGA
to see if it will even operate.

> - In some points your drawing is very detailed (gates, individual data lines drawn), some others are higher level, but the meaning is not clear to me (e.g. "cache metric decoder")

> - I have not seen a hit/miss detection?

The data returned by the cache cells populates onto their bus slot within
the request, and will either fully populate the portions expected, or not.
That will give the hit/miss determination. In my current thinking, it is
a one clock latency to determine a hit or miss per cache line (there are
four reads per clock possible, and suppose three were issued, and one of
those failed and two succeeded, each would know after one clock cycle if
it succeeded or failed).

> Regards,
> Thomas

Thank you for your response, Thomas. I'll make a video giving a
description outlining the design later on tonight. Right now, I'm
altering some pants for my wife. :-) She's going on vacation and
has some modifications needed.

-----
I understand your #2 point ... but when your eyes have been opened
to eternity, and you realize what's required to enter in, and the
people around you (those you care about the most) are not on the
path to enter in ... it's very difficult to think of other things.
I continue on in my daily work, but I try with great passion and
persistence to come up with new ways of teaching and explaining
the need we have to be forgiven. It may not seem important now,
but now only lasts for a tick of the clock, and then "then" begins.
And whereas now is terminal, then is not terminal. Now yields.
Then never yields. Considering what that truly means to living,
breathing people and their eternal souls ... it's too much for me
to remain silent on.

To put my life in perspective: I currently have zero friends.
Zero family that tolerates me, save my immediate family. Zero
neighbors who want anything to do with me. And very few church
members who regard me positively. My ongoing urging toward closer
walks with the Lord and Savior push nearly everyone away ... because
it is a very real thing that we know deep down we need. It is the
anti-Christ spirit at work in this world which pushes people away
from me because it's trying to keep the people already on the wide
path to destruction away from hearing the truth, because if they
were to ever hear the truth they would know it is the truth and
they too would come out from the deception, repent of their sin,
ask forgiveness, and be saved.

I do not have people in my life who seek me out. I have co-workers
who respect my abilities, but keep me at or beyond arm's length.
I have people who contact me with prayer requests when things begin
to fall apart in people's lives. I have even my immediate family
who wrestles with me at least three out of seven days a week, and
in enough of a form that it affects the entire evening, or even the
entire day.

It is not for nothing that I post these things. My heart was changed
in 2004. I have experienced the transformation, and the lives at
stake here in this world mean something to me. I have personal
interests in things like computers (software and hardware design),
and I pursue those things, but all of it is now tempered with my
faith, which (to be honest) has surprised me completely.

I used to know Rick pretty well before I met Jesus Christ in 2004.
But when I met Him, and I believed, and I asked forgiveness, I really
did change on the inside, which has reflected out to the outside. I
tried to run away from the faith, I tried to fall back into my old
tendencies, etc., but the conviction is real, the guidance of the
Holy Spirit is real. Jesus is called "The Good Shepherd" in scripture,
and He does come after His lost sheep, to guide them back to where
they should be.

A famous Christian comedian has said that God is like a GPS device.
When you make a wrong turn, He doesn't abandon you. He simply re-
calculates, to get you from where you now are to where you should be.

It's a perfect description of how Jesus guides a born again believer's
life. And as I go through each of my days considering the importance
of the people around me, their amazing value as the most beautiful
creations I've ever seen in my entire life (just sit and watch people
interact sometime, watch them do things, watch them play football or
read a book or look over their kid's homework, etc.), then my heart
rattles from within with a real desire to teach them that which they
need to be saved, so that they too can continue on in eternity, as
even more beautiful creations once we are stripped of this limited
sinful flesh.

I know it's difficult for people. I could not receive it for the
first 34 years of my life. But very near to my 35th birthday I did.
And I know for all who will be saved there will come a day. And it
is for that day for each of them that I labor, and indeed it is the
reason why all Christians labor. We are laborers sent out into the
harvest fields to reap what is reapable. We are fishermen, now
knowing if we will catch anything, but still casting out so that the
possibility always exists.

My heart cries out from within, and whereas I have interests like
this CPU project, and my operating system, and the apps which will
run on top of it (compilers, office suites, email, browsers,
everything), none of them are isolated from my heart crying out for
people to be saved. The two work together, which is what God intended
for those who are His. We go about our affairs in this world, but we
keep Him out in front of what we do, permeating what we do, always
sprinkling the things we do with knowledge of Him, knowledge of His
Son, knowledge of sin, knowledge of His call on each of us to repentance,
and more.

It is from there I proceed.

[Rick C. Hodgin]

On Tuesday, December 20, 2016 at 8:21:45 PM UTC-5, Rick C. Hodgin wrote:
> Thank you for your response, Thomas. I'll make a video giving a
> description outlining the design later on tonight.

Here's the video. I recorded it at 10fps and on my computer the video
plays back out of sync with the audio. I'll try to make a corrected
video tomorrow, and one which is much shorter:

34 minutes (first several minutes discuss the cache, then I discuss
some other goals with Arxoda ... I think I tend to ramble in this
video ... so maybe wait for the one tomorrow when I can map out a
presentation rather than doing it ad hoc):

http://www.libsf.org/video/arxoda_l1_cache_design__2016_12_20.ogv

Also, if you have specific questions, or would like me to follow an
outline for presentation, post the request and I'll present the material
that way. We could also do an online join.me event or some such where
immediate Q&A is possible.

[David Brown]

There is a real possibility that they are not done for /our/ own good,
but that they are done for /his/ own good. After all, Rick believes he
has been commanded to irritate people and that his god will send sinners
to eternal damnation (in his infinite mercy). So there is no way to
tell if he really wants to help us avoid being sentenced (by god's
infinite justice) to eternal suffering because a distant ancestor ate an
apple, or if he is just trying to save his own soul. Of course he will
immediately deny any such selfish thoughts and say it is all because he
"loves" us - but then, he is commanded to do that too.

[Rick C. Hodgin]

Here is a new video. I used "recordMyDesktop" for the first one, and
it recorded to .ogv but did not record the frame rate properly. This
is from Kazam, and it recorded to mp4 and seems to work properly:

http://www.libsf.org/video/arxoda_l1_cache_overview__2016_12_21.mp4

If you have any questions please let me know. Thank you!

[MitchAlsup]

On Wednesday, December 21, 2016 at 10:50:16 AM UTC-6, Rick C. Hodgin wrote:
>
> If you have any questions please let me know. Thank you!

I have a question::

Are you ever going to go away and stop spamming this NG?

[Rick C. Hodgin]

Have you read all through what I posted, Mitch?

[Rick C. Hodgin]

Rick C. Hodgin wrote:
> Have you read all through what I posted, Mitch?

I am thinking that reading reviews about a movie is not the same as
experiencing it first hand, and that thinking you have the facts about
something is not the same as having the facts about something.

It comes down to a pursuit of truth, Mitch. If truth means anything
to a person ... then it must be pursued actively, and with rigor.

It's from the inside, not the outside, that people being drawn to
salvation will hear and know the truth of the gospel message, of sin,
of salvation, of eternity. It is from within they will move to save
their soul.

Have you searched the matter out? Or do you just think you have it
nailed without having personally investigated it? Your conscience
will tell you.

[Rick C. Hodgin]

It's occurred to me that if I could get the cache access time down to
one clock cycle, then I would be able to port the read and write buses
into and out of on-board ALUs and conduct direct memory-to-memory ops,
with the ability to dispatch four per clock on this design. And by
adding more buses horizontally, that number could go up. Couple that
design to a compiler that's aware of this, and it would be able to
make sure that schedule conflicts do not take place, removing some of
the hardware burden.

It would be quite a thing to create this "Free Logic Unit" which is
a free-form type of input/output into traditional compute logic units.

I wonder if this is how Intel worked with Itanium? It had a certain
number of hard registers (32 IIRC), but then up to 128 soft registers
which were aliased to memory. If that memory was loaded into some
kind of fast multi-port cache like this, then it could conduct the
work almost as quickly as in registers, and quite possibly as quickly
(being as Intel has lots of resources to figure out the things I may
not be able to figure out :-)).

[Rick C. Hodgin]

On Wednesday, December 21, 2016 at 11:50:16 AM UTC-5, Rick C. Hodgin wrote:
> Here is a new video...:

>
> http://www.libsf.org/video/arxoda_l1_cache_overview__2016_12_21.mp4
>
> If you have any questions please let me know. Thank you!

I've done some directory refactoring. Here's the updated link:

https://github.com/RickCHodgin/libsf/blob/master/arxoda/core/cache_l1/cache_4read_4write.png

[Rick C. Hodgin]

Additional refactoring:

Base directory:
https://github.com/RickCHodgin/libsf/tree/master/arxoda/core

L1 cache design:
https://github.com/RickCHodgin/libsf/tree/master/arxoda/core/cache_l1

L0 cache design:
https://github.com/RickCHodgin/libsf/tree/master/arxoda/core/cache_l0

Integrity Memory:
https://github.com/RickCHodgin/libsf/tree/master/arxoda/core/integrity_memory

Overall design:
https://github.com/RickCHodgin/libsf/blob/master/arxoda/core/overall_design.png

As time allows I plan to update these files with the design (James 4:15,
"Lord willing).

[Rick C. Hodgin]

I have "finalized" my L1 cache cell design. It has been greatly
simplified and colorized:

https://github.com/RickCHodgin/libsf/blob/master/arxoda/core/cache_l1/cache1__4read_4write.png

I made it into a 36" x 48" poster from VistaPrint for $22 plus shipping
using a higher resolution version:

https://github.com/RickCHodgin/libsf/blob/master/arxoda/core/cache_l1/cache1__4read_4write_poster.png

[Rick C. Hodgin]

The poster arrived damaged by UPS. I contacted VistaPrint to tell them
about it. I expected to order another one at a discount, but they sent
me another free of charge because it was damaged.

I'm amazed by their customer service. The poster is excellent quality
otherwise.

[Rick C. Hodgin]

I received the replacement poster on January 11, and have it hanging in
my living room. I also have a large 4004 die that I had made into a 36"
by 48" poster. Both are hanging in my living room.

They are inspiring. I often say to my wife and son, "Have I shown you
the cache design I have here?" They both look at me with grinning
faces and say, "No. Can you teach us about it so that we know every
detail on how it works," referring sarcastically to prior conversations
where I've tried to do just that. LOL! :-)

My family just doesn't appreciate hardware design the way I do. But,
they are quite humorous about it.

Here's the latest iteration. It will probably be the one I keep:

https://github.com/RickCHodgin/libsf/blob/master/arxoda/core/cache_l1/cache1__4read_4write_poster.png

Thank you,
Rick C. Hodgin

[Rick C. Hodgin]

On 1/2/2017 3:08 PM, Rick C. Hodgin wrote:
> I have "finalized" my L1 cache cell design. It has been greatly
> simplified and colorized:
>
> https://github.com/RickCHodgin/libsf/blob/master/arxoda/core/cache_l1/cache1__4read_4write.png
>

> I made it into a 36" x 48" poster...using a higher resolution version:
>
> https://github.com/RickCHodgin/libsf/blob/master/arxoda/core/cache_l1/cache1__4read_4write_poster.png

Updated URL:


http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/arxoda/core/cache_l1/cache1__4read_4write_poster.png

I am posting today because I had some thoughts this past weekend
over two comments made on this group over the past few months.
One comment had me consider, "What would be a natural progression
of my design be if moving on to something better?" And the second
comment made me think, "What if I could fill and spill data in a
stridden manner, so that the cache data is not linear, but more
closely matches patterns that are observed in data use."

Stride memory patterns would be observable by the CPU if it had an
analysis engine which monitored memory access and was able to see
regular heavy-access on intervals over the last few hundred data
request accesses. It could instruct the cache system on which
intervals to load.

But beyond that, it occurred to me that if every cache row size was
reduced from 128-bytes down to 32-bytes, then the overhead for row
control circuitry would increase by ~4x, but it would be much more
conducive to both sequential and random access patterns, which would
be include a superset of any type of genera striding mentioned above,
and it would exist without having to add analysis and stride circuitry
or any type of cache analysis. It would just look for access locat-
ions, and aging cache rows not accessed for the longest time would
be swapped out as new data needs were made.

The 32-byte size would require only 4-reads / writes on a 64-bit
memory subsystem to completely fill and spill, and because Arxoda's
cache system is byte addressable, it would be able to handle any
overflow or underflow into other cache areas bay simply loading in
a new cache row for access.

-----
I was wondering if anybody would be willing to give me some input
on this thought, of reducing the cache row size from 128-bytes to
32-bytes?