[libre-riscv-dev] memory interface diagram woes

[libre-riscv-dev] memory interface diagram woes

[Jacob Lifshay]

I had an idea for a memory interface design that I've been slowly
working on for more than a week, though have not been able to draw it
out adequately because I keep getting frustrated by the lack of nice,
power-of-2 alignment features and support for structurally recursive
diagrams in Dia and the lack of copy-paste when using physical paper.
I'll try to write it out as text on the wiki tomorrow.

It is a bit different than the design Luke came up with and I think it
addresses several of that design's shortcomings.

Jacob

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] memory interface diagram woes

[Luke Kenneth Casson Leighton]

On Thursday, April 23, 2020, Jacob Lifshay <programmerjake@gmail.com> wrote:

> I had an idea for a memory interface design that I've been slowly
> working on for more than a week, though have not been able to draw it
> out adequately because I keep getting frustrated by the lack of nice,
> power-of-2 alignment features and support for structurally recursive
> diagrams in Dia and the lack of copy-paste when using physical paper.


doh :)

there is a reason why i write things out as diagrams (and why i look at
graphviz all the time).  they map easier in my head to gates, and as a
result it becomes possible to check that it hasn't any surprise pathways in
HW


> I'll try to write it out as text on the wiki tomorrow.


ok.


> It is a bit different than the design Luke came up with and I think it
> addresses several of that design's shortcomings.


ok i can grok that.

thanks for explaining jacob.




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] memory interface diagram woes

[Luke Kenneth Casson Leighton]

btw a word to the wise jacob, the current code is even though not complete,
ridiculously comprehensive and tied directly into the Dependency Matrix
system.

* LDSTs have regs therefore they need standard FU-Regs and FU-FU presence.

* FU-Regs takes care of the Reg RaW and WaR dependencies

* FU-FU takes care (in the case of LD) of the *order* of which FU is
waiting for which result, it is like a linked list using unary bits and
consequently is a square matrix

on *top* of that we have an additional problem to solve:

* preserving the order of memory accesses (if they matter)

* ensuring that overlaps result in order preservation but that when there
are no overlaps at least respect Weak Memory Order (LDs separate from STs)

on top of *that* we have an *additional* requirement to merge multi-issued
LD/STs that can fit into a single cache line hit, because of the enormous
bandwidth requirements of 3D Vectors.

it is ridiculous but necessary that even in a 180nm single core we need a
staggering 256 bit wide data path to the L1 cache and that this width will,
when we go to faster speeds, also be needed to the L2 cache as well.

the overlapping address conflict and Weak Order Preservation is achieved
with an addressmatch Matrix, last year, thanks to Mitch Alsup.

however Mitch's scheme works by comparing bits 4 thru 11 or 5 thru 11
(avoiding the VM bits and aldo avoiding bits 0 to 3) and ending up with
0.5% additional overzealous hits which make *no significant performance
degradation* in real world usage.

but his scheme was *not* possible, as-is, to use for our needs, because it
missed opportunities to merge byte level accesses because of only comparing
bits 4 thru 11 of the address.

i therefore expanded the LDST LENGTH and bits 0 thru 3 into a 24 bit
bytemask / bitmap, then split that into 2 requests.

why 2 requests, because of misaligned LDST, the 1st 16bits of the bytemap
are 1 cache line and the remaining 8 bits the 2nd cache line.

with "Weak" memory rules in place, and with the other job of the
addressmatch matrix taking care of separating LDs and STs into mutually
exclusive batches, splitting into multiple operations is perfectly "fine".

now with these bytemasks available, and the remaining bits of the binary
form of the address (bits 4 thru 48) being aligned to a cache line
boundary, all we need do is identify which requests have the exact same
upper bits and we can merge the bytemasks for all of those and thus make
only the one single L1 cache line request for all of them.

this is the task of the L0 Cache/Buffer and as you can see it very closely
and very specifically depends on the criteria being satisfied by earlier
components.

the datapath requirements are also absolutely MENTAL and we really,
*really* cannot have 8 or 16 way to 4 or 8 way multiplexers, it is just too
much as it will result in literally thousands of wires because we have 48
bit addresses, 64 bit data, and additional control signals.

assume 128 bits per LDST Function Unit, if we have 8 LDST FUs, each with 2
ports (one for aligned, one for misaligned), that is 128 x 2 x 8 bits wide
i.e. 2048 bits datapath!

now imagine we design an algorithm that needs a 4 or 8 way multiplexer on
that, to get 4 or 8 simultaneous requests into even just an 8 entry
"Queue", implemented as a standard 4R4W (or 8R8 W) Memory or registers, and
that is a staggering 8192 or 16384 wires through multiplexers!

that is completely mental and there is no way we can do that, the layout
would be far too complex even if it was practical.

this is just one of the things that we have to be extremely careful about
and it is why i am taking time to draw out these diagram.

so the current proposed L0 Cache/Buffer has *independent* ports on each
row, for use by each Function Unit.

and onto the L1 side the connection is 1R *or* 1W at 128 bit (cache line)
width.

yesterday i made some corrections that merged the pair of L0 Cache/Buffers
into a single dual ported one.  i explain why on the 6600 scoreboard page.

thus each FU produces up to 2 requests, one goes left, the other goes
right, into one of two "lanes", mutually exclusively separated by address
bit 4.

there are therefore *two* 128 bit wide ports to *two* separate L1 caches,
one for addr[4] = 0 and the other for = 1 and they interleave alternate
cache lines nicely.

the number of ways is a standard L1 cache decision as is everything else
about the L1 cache.

so please do take into account, Jacob, that the data path sizes are
completely mental, and that multi way multiplexing is not an option.

the multiplexing for the design that i did is only a 2x2 crossbar for each
FU, with 192 bit datapaths on each (might be able to get that down to 128
or slightly less).  that is *all* because on the other side, after the
bytemask merge, it is straight 1R or 1W to the L1 cache.

l.






-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] memory interface diagram woes

[Luke Kenneth Casson Leighton]

illustration, jacob.

with 8 LDST FUs, each with 2 64-bit data ports, how will those 16
entries be inserted into MemoryQueue?
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/memory_pipe_experiment/memory_queue.py;hb=HEAD

as in, not so much "how" (because in "coding terms" it's a "simple"
matter of writing the code).

i mean "how many wires will be required in order to multiplex up to
16x simultaneous 64-bit chunks into the same (one) MemoryQueue"?

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] memory interface diagram woes

[Luke Kenneth Casson Leighton]

On Thursday, April 23, 2020, Jacob Lifshay <programmerjake@gmail.com> wrote:

>
>  not been able to draw it
> out adequately because I keep getting frustrated by the lack of nice,
> power-of-2 alignment features and support for structurally recursive
> diagrams in Dia and the lack of copy-paste when using physical paper.


if it makes you feel any better i'm on to the 10th redraw of the LDST
CompUnit...


> I'll try to write it out as text on the wiki tomorrow.


how you getting on?

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] memory interface diagram woes

[Jacob Lifshay]

On Sun, Apr 26, 2020, 05:28 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> On Thursday, April 23, 2020, Jacob Lifshay <programmerjake@gmail.com>
> wrote:
>
> I'll try to write it out as text on the wiki tomorrow.
>
>
> how you getting on?
>

still working on it... sorry I'm taking so long

Jacob

>
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] memory interface diagram woes

[Luke Kenneth Casson Leighton]

On Mon, Apr 27, 2020 at 7:06 AM Jacob Lifshay <programmerjake@gmail.com> wrote:

> > how you getting on?
> >
>
> still working on it... sorry I'm taking so long

if it will help, let's talk it through on the bugreport.  (we're on
the clock to meet that october 2020 deadline so cannot afford long
delays).

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] memory interface diagram woes

[Luke Kenneth Casson Leighton]

On Mon, Apr 27, 2020 at 11:07 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> On Mon, Apr 27, 2020 at 7:06 AM Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> > > how you getting on?
> > >
> >
> > still working on it... sorry I'm taking so long
>
> if it will help, let's talk it through on the bugreport.  (we're on
> the clock to meet that october 2020 deadline so cannot afford long
> delays).

following software engineering practices, can i suggest starting with
writing out the requirements?  one step at a time.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] memory interface diagram woes

[Luke Kenneth Casson Leighton]

scream! 2 days writing out the 10th version of the logic-diagram for
LD/ST in 12 months, only to note that POWER has a 2-in 2-out variant
of LD called "update" which optionally puts the computed Effective
Address out on RA as a 2nd write source!

fortunately i can i believe cookie-cut an existing diagram
(https://libre-soc.org/3d_gpu/architecture/6600scoreboard/600x-compunit_multi_rw.jpg)
this contains multi-write protection already however the difference is
that it needs to switch between single-write and dual-write. i think i
can do that by "fake" setting one of the SR Latches to "already
acknowledged".

patience, patience...

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] memory interface diagram woes

[whygee]

On 2020-04-28 13:56, Luke Kenneth Casson Leighton wrote:
> fail.  on to version *12*.  it's about 90 minutes to draw and verify
> each diagram.

have a look at http://www.falstad.com/circuit/circuitjs.html
it has some digital simulation capabilities, and lets you
exchange the designs with simple minified links.
Then you can integrate digital (sub-)circuits as IFRAMEs
in webpages to explain and expose the principles of your design.
It's not the very best system but it's incredibly useful
and flexible. You won't use DIA anymore ;-)

> l.
yg

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] memory interface diagram woes

[Luke Kenneth Casson Leighton]

On Tue, Apr 28, 2020 at 2:33 PM <whygee@f-cpu.org> wrote:
>
> On 2020-04-28 13:56, Luke Kenneth Casson Leighton wrote:
> > fail.  on to version *12*.  it's about 90 minutes to draw and verify
> > each diagram.
>
> have a look at http://www.falstad.com/circuit/circuitjs.html
> it has some digital simulation capabilities, and lets you
> exchange the designs with simple minified links.

oooo i looove it.
https://github.com/sharpie7/circuitjs1

another one, circuitdiagram
https://github.com/circuitdiagram/circuitdiagram


> Then you can integrate digital (sub-)circuits as IFRAMEs
> in webpages to explain and expose the principles of your design.
> It's not the very best system but it's incredibly useful
> and flexible. You won't use DIA anymore ;-)

that's a great idea.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] memory interface diagram woes

[Jacob Lifshay]

On Tue, Apr 28, 2020, 07:27 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> On Tue, Apr 28, 2020 at 2:33 PM <whygee@f-cpu.org> wrote:
> > have a look at http://www.falstad.com/circuit/circuitjs.html
> > it has some digital simulation capabilities, and lets you
> > exchange the designs with simple minified links.
>
> oooo i looove it.
> https://github.com/sharpie7/circuitjs1


Didn't occur to me to use it -- even though I created the QAM-256
Modulator/Demodulator example:
https://github.com/sharpie7/circuitjs1/commit/323f530ce4c409316e2bab8277636deced3070fc

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] memory interface diagram woes

[Luke Kenneth Casson Leighton]

On Tue, Apr 28, 2020 at 3:38 PM Jacob Lifshay <programmerjake@gmail.com> wrote:

> > oooo i looove it.
> > https://github.com/sharpie7/circuitjs1
>
> Didn't occur to me to use it -- even though I created the QAM-256
> Modulator/Demodulator example:
> https://github.com/sharpie7/circuitjs1/commit/323f530ce4c409316e2bab8277636deced3070fc

ooo, wooow, shiny :)

although i am currently spaced-out at how sparkly and shiy circuitjs
is (just ran the adder circuit example) i'm also really liking it from
the "educational" perspective.  being able to have *interactive*
subsets of the circuits we're deploying would be absolutely fantastic.

i'm even tempted to suggest putting in a new NLNet Grant request to cover it.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] circuitjs

[Jacob Lifshay]

On Tue, Apr 28, 2020, 07:44 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> On Tue, Apr 28, 2020 at 3:38 PM Jacob Lifshay <programmerjake@gmail.com>
> wrote:
>
> > > oooo i looove it.
> > > https://github.com/sharpie7/circuitjs1
> >
> > Didn't occur to me to use it -- even though I created the QAM-256
> > Modulator/Demodulator example:
> >
> https://github.com/sharpie7/circuitjs1/commit/323f530ce4c409316e2bab8277636deced3070fc
>
> ooo, wooow, shiny :)
>
> although i am currently spaced-out at how sparkly and shiy circuitjs
> is (just ran the adder circuit example) i'm also really liking it from
> the "educational" perspective.  being able to have *interactive*
> subsets of the circuits we're deploying would be absolutely fantastic.
>

If we were to try to run much more than some really simple circuits, it
would need things like multi-bit buses and a much faster simulator and
subcircuits (though I think it may already have subcircuits).

Try and see how fast the QAM-256 example is, since that's a more
complicated circuit.

BTW, the offline Java version is quite a bit faster than the online version
which is made using a Java to Javascript translator (GWT).

>
> i'm even tempted to suggest putting in a new NLNet Grant request to cover
> it.
>

Maybe write a BLIF to CircuitJS translator :)
allows us to export from yosys to circuitjs

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] circuitjs

[Luke Kenneth Casson Leighton]

On Tue, Apr 28, 2020 at 3:54 PM Jacob Lifshay <programmerjake@gmail.com> wrote:

> If we were to try to run much more than some really simple circuits, it
> would need things like multi-bit buses and a much faster simulator and
> subcircuits (though I think it may already have subcircuits).

yes, looks like it.

> BTW, the offline Java version is quite a bit faster than the online version
> which is made using a Java to Javascript translator (GWT).

which is good to have in mirroring scratch having an online and offline version.

GWT.  *scream*!  i remember GWT - i was the lead developer of the
python-to-javascript language translator, pyjs.  ha, that's amazing
that people still use GWT.

> Maybe write a BLIF to CircuitJS translator :)
> allows us to export from yosys to circuitjs

that would save an awful lot of time.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] circuitjs

[Jacob Lifshay]

On Tue, Apr 28, 2020, 08:04 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

>
> GWT.  *scream*!  i remember GWT - i was the lead developer of the
> python-to-javascript language translator, pyjs.  ha, that's amazing
> that people still use GWT.
>

I heard that most of google's web frontends (like gmail) are written using
GWT (or something similar).

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] circuitjs

[Luke Kenneth Casson Leighton]

On Tue, Apr 28, 2020 at 4:11 PM Jacob Lifshay <programmerjake@gmail.com> wrote:

> I heard that most of google's web frontends (like gmail) are written using
> GWT (or something similar).

and it makes for an incredible effectiveness as a result.  the team
only need write code *once* and it can run on desktop *and* as a
mobile app, but not only that, the subdivision into (close to)
Model-View-Controller by inherent design means that actual front-end
GUI code is pretty much completely separate from "stuff that does
stuff".

using pyjs a client commented on how sparse (how little) code was.
and it was because everything that was "active" - handling data - was
done using a JSON RPC client-server architecture.  the actual
server-side implementation of a JSONRPC server was done in a mere *50*
lines of code.  25 of those lines involved exception/error handling!
other JSONRPC servers that i've seen are thousands of lines of
completely unnecessary code.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] HTTaP and Design for Test (was Re: circuitjs)

[whygee]

On 2020-04-28 17:35, Luke Kenneth Casson Leighton wrote:
> the actual
> server-side implementation of a JSONRPC server was done in a mere *50*
> lines of code.  25 of those lines involved exception/error handling!
> other JSONRPC servers that i've seen are thousands of lines of
> completely unnecessary code.

speaking of which : did I mention I rebooted the design of my HTTaP 
server ?

http://httap.org : It's a protocol for TAP over (hidden in) HTTP.

It's currently live on http://httap.org:60075 if you want to see
(the port number may change and it's not running 24/7)

The total number of lines in C is 1203 for now and I have not yet
added much support for user-provided functions but don't laugh yet.
it's convoluted but really required !

It was initially designed about 8 years ago to run INSIDE GHDL and
control/report VHDL simulations. For example you provide your own user
"words" to control the state of input and output signals then "plug" the
commands to actual VHDL code. Then write the testbenches in JS
or whatever, co-simulate with FPGA or compare between different
models...

My recent designs include a TAP (Test Access Port) that exactly
mimics the real pins that would be provided on the outside of the
FPGA or ASIC, it could be JTAG or anything convenient. I use a
half-duplex SPI-like interface to send and receive control/status
data, inject and exfiltrate given signals from a design...

The HTTaP interface is very friendly to microcontrollers and Raspberry 
Pis,
which is an obvious choice for this kind of application.

The protocol/interface looks the same to the JS GUI, just change the 
backend.
Thus, the emulation, the simulation, the FPGA and the ASIC look
exactly the same. That's "design for test".

It's even a great idea to start the design (and assembly of all the 
modules)
from the TAP interface itself, building from there and expanding.
This makes sure ALL circuits can be thoroughly tested and accessed,
little by little while the circuit is built, not at the last moment,
which is a great insurance of having your chips tested and running
very fast after delivery from the fab.

I hope this sparks some more ideas and boosts Libre-SOC :-)

> l.
yg

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] circuitjs

[whygee]

On 2020-04-28 16:53, Jacob Lifshay wrote:
>> https://github.com/sharpie7/circuitjs1/commit/323f530ce4c409316e2bab8277636deced3070fc
wait, YOU did it ? :-O
awesome !
For now I play with :
incremeters http://tinyurl.com/y7mseqfd
Carry-lookahead adders
complete ALU datapath http://tinyurl.com/rhonlsz
latches http://tinyurl.com/y8jjxd2x
shift registers, sequencers and so on,
very low-level but absolutely indispensable...
circuitjs has many quirks and bugs but
the qualities are not matched yet.

>> being able to have *interactive*
>> subsets of the circuits we're deploying would be absolutely fantastic.
that's all the point of a recently published article I wrote about it.
Can Jacob tell the developers about it ? :-)

> If we were to try to run much more than some really simple circuits, it
> would need things like multi-bit buses and a much faster simulator and
> subcircuits (though I think it may already have subcircuits).
I have not run into hard limitations so far, except screen size :-D

> BTW, the offline Java version is quite a bit faster than the online 
> version
> which is made using a Java to Javascript translator (GWT).
for now speed is not the point for me :
on hackaday.io we use circuitjs a LOT to discuss circuit topologies,
ping and pong ideas at each other, demonstrate stuff...

the circuitjs system allows sharing with much fewer limits than "normal 
programs"
and can be embedded in tutorials and educational webpage. A bit of JS 
could
detect a click to swap an <img> into an <iframe> that simulate the 
principle.

For number theory I have used JS-animated SVG but it's so painful and 
long to write,
but Luke could "build" the scoreboard before our eyes in a long HTML 
page,
showing each sub-element one by one and assembling them, then show their 
combined
behaviours...

The scheduler has long reached a state where even Luke has difficulties 
managing
its subtleties so that method would not only help him, but more 
importantly OTHERS
so they can take over his work when needed. So far, I don't feel I could 
ever,
despite my little understanding of the CDC6600.

>> i'm even tempted to suggest putting in a new NLNet Grant request to 
>> cover it.
> Maybe write a BLIF to CircuitJS translator :)
> allows us to export from yosys to circuitjs
I've been considering finding ways to convert from/to circuitjs
to/from VHDL... that would be a killer.
At least a "filter" to transform the .txt outputs, recognize
the basic gates and map them to those of my library (or sxlib)
and/or vice versa.

> Jacob
yg

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] memory interface diagram woes

[Luke Kenneth Casson Leighton]

https://libre-soc.org/3d_gpu/ld_st_comp_unit.jpg

okaaaaay, finally.  (btw don't tell no-one i watch American Ninja
Warrior re-runs whilst drawing these).

there's three modes:

* LD mode - OP1 READ, OP2 WRITE, memory read
* LD-UPDATE mode - OP1 READ *and* WRITE, OP2 WRITE
* ST mode - OP1 READ, OP2 READ, memory write

notes:

* ALU and ADR latch covers the case where the Adder only triggers
"result ok" for 1 cycle, latching the output EA (effective address)
indefinitely, where ALU-SR's job is to signal that the address is
ready.  the two separate latches are because you musn't de-latch the
address from the LD/ST-Port just because GoAddr acknowledgement
occurred

* likewise LD-sr latches on "LD_OK" and captures the LD Data output
from the LD/ST-Port, where the WR-sr latch reacts differently.  i am
not entirely certain that two separate latches are needed here, to be
honest, however i believe it is "safe" to have them separate.

* SHADOW_N stops all write activity until it is *definitely* known
that the possibility for exceptions has passed.  this is *the* reason
why we can do a full O-o-O design with "precise exceptions": something
that the "Academic" literature does *NOT* recognise as being possible
with a 6600-style architecture.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] memory interface diagram woes

[Luke Kenneth Casson Leighton]

aw god this isn't funny any more! (actually... it is).  there's a
store-with-update that's separate from load-with-update.  so there are
*four* combinations:

* LD Mode will activate Issue, GoRead1, GoAddr then GoWrite1
* LD-UPDATE Mode will *additionally* activate GoWrite2.
* ST Mode will activate Issue, GoRead1, GoRead2, GoAddr then GoStore.
  ST-UPDATE Mode will *additionally* activate GoWrite2.

i might be able to recover the current diagram without rewriting it.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] memory interface diagram woes

[Luke Kenneth Casson Leighton]

oh god!  POWER LD/ST has an indexed version and an immediate version
of instructions!  so that's *eight* possible variants:

* LD/ST
* Update y/n
* Immediate/Indexed

fortunately i have the logic for an immediate-or-OP2 already drawn out.

this is getting ridiculous! :)

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev