Re: [libre-riscv-dev] Markdown on the wiki?

Re: [libre-riscv-dev] Markdown on the wiki?

[Luke Kenneth Casson Leighton]

On Wed, Jul 15, 2020 at 2:40 AM Samuel Falvo II <sam.falvo@gmail.com> wrote:
>
> Hi Luke,
>
> I wrote up a summary of what I've learned by reviewing the source
> code.  But, when I view the notes that I've written[1],
> https://libre-soc.org/Documentation/notes_on_formal_proofs/

excellent.  i'll find a location for it.  thank you for creating that page.

> the formatting
> of fixed-width code snippets enclosed in `backticks` results in the
> snippets being on a completely new HTML division, as if I'd written
> ```backticks``` instead.

yes.  there's a bug where fixed-width code following bullet-points
does not get marked up as fixed-width.  to sort that i had to change
the css:
https://libre-soc.org/local.css

> Is this a limitation of ikiWiki that cannot be easily fixed?

no - it's just a matter of someone having the time to properly investigate.

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] Markdown on the wiki?

[Luke Kenneth Casson Leighton]

On Wed, Jul 15, 2020 at 11:05 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> On Wed, Jul 15, 2020 at 2:40 AM Samuel Falvo II <sam.falvo@gmail.com> wrote:
> >
> > Hi Luke,
> >
> > I wrote up a summary of what I've learned by reviewing the source
> > code.  But, when I view the notes that I've written[1],
> > https://libre-soc.org/Documentation/notes_on_formal_proofs/
>
> excellent.  i'll find a location for it.  thank you for creating that page.

i've put some comments inline, samuel, particularly referencing the
investigation last night and this morning:
https://bugs.libre-soc.org/show_bug.cgi?id=429#c3

if you create a bugreport for it we can actually put in an rfp for you
(request for payment) - it's a small budget for documentation.

key notes:

* the pipeline API is inviolate.  you do not break it.   *at no time*
will there *ever* be circumstances where it is bypassed.  evverrrr.
* the only "exception" to that is LDSTCompUnit - and it achieves this
by *not using the pipeline API at all*.
* the ASCII art diagram is slightly misleading to refer to its inputs
and outputs as "Registers" because this could be confused with
"Register File".
* FPPipeContext (dut.o.ctx, dut.i.ctx) is not a Record.  this would
have been the source of the issue you encountered

> > the formatting
> > of fixed-width code snippets enclosed in `backticks` results in the
> > snippets being on a completely new HTML division, as if I'd written
> > ```backticks``` instead.
>
> yes.  there's a bug where fixed-width code following bullet-points
> does not get marked up as fixed-width.  to sort that i had to change
> the css:
> https://libre-soc.org/local.css

i wrote some code last week which auto-altered all of the isa
pseudocode sections - every single one of which (hundreds) had that
bug i mentioned.  having "fixed" that i've removed the css "code"
block change.
https://libre-soc.org/openpower/isa/

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] Markdown on the wiki?

[Luke Kenneth Casson Leighton]

samuel, hi,

i updated the page you started, a bit more, this morning. you should be
getting the impression now as to why i described this pipeline as dead
simple to start from, because the code itself in spr main_stage.py really
does not actually do very much.

no regfile reading, no decisions, no instruction decoding: nothing.  its
*sole* job is to process its inputs and create some outputs.  it doesn't
even know which registers that data actually comes from or goes to because
*that is not its responsibility*.

thanks to the pipeline API it doesn't even need to know a thing about
pipelines or even how those are set up: you noted that stages are all
combinatorial.

all pipelines are designed this way, as pure combinatorial blocks.
therefore, the formal proofs for each stage are correspondingly trivial in
nature, too.

as you are discovering, the context *around* each pipeline is pretty
involved, especially when you compare it to e.g. Minerva, which is the main
other nmigen core around.

however Minerva is designed as a low performance 32 bit single issue
processor, where this is a high performance multi-issue parallel processor
with OoO instruction order preservation.  data paths in Minerva are 32 bit,
addresses are 32 bit: we have a massive **256** bit wide data path and will
be doing at least a 48 bit physical address space.

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] Markdown on the wiki?

[Samuel Falvo II]

Sorry; just getting to this email now.  You'd think that being
unemployed would give you loads of time.  And, maybe it does, but only
after you clear your queue of other honey-dos and deliverables that's
queued up for others over time.  Uugh.

I can appreciate why people say that being "retired" is exhausting.  ;)


On Wed, Jul 15, 2020 at 10:13 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
> i updated the page you started, a bit more, this morning. you should be getting the impression now as to why i described this pipeline as dead simple to start from, because the code itself in spr main_stage.py really does not actually do very much.

Thanks; I'll take a read later this evening.

> no regfile reading, no decisions, no instruction decoding: nothing.  its *sole* job is to process its inputs and create some outputs.  it doesn't even know which registers that data actually comes from or goes to because *that is not its responsibility*.

Yeah, and I'm getting a lot of ideas for my future KCP53000
refinements as well.  In *theory*, it should be possible to use the
exact same combinatorial building blocks in a single-issue design as
it would in a pipelined, multi-issue design; only the wiring between
the blocks would need to be handled differently.  (Of course, theory
and reality are only theoretically related; still, I can see how this
would significantly *ease* the prospect of re-architecting the design
if ever became necessary.)

And if the libresoc becomes affordably available for me to hack with,
maybe I can design a CPU card around it for the Kestrel-3.  (Of
course, I'll need to migrate all the code currently running in M-mode
to U-mode first.)

-- 
Samuel A. Falvo II

_______________________________________________
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] Markdown on the wiki?

[Luke Kenneth Casson Leighton]

On Saturday, July 18, 2020, Samuel Falvo II <sam.falvo@gmail.com> wrote:

>
> I can appreciate why people say that being "retired" is exhausting.  ;)


my aunt kicked my uncle out, told him to go back to work when he retired.
he was too annoying :)


> Yeah, and I'm getting a lot of ideas for my future KCP53000
> refinements as well.  In *theory*, it should be possible to use the
> exact same combinatorial building blocks in a single-issue design as
> it would in a pipelined, multi-issue design;


precisely.  increase the number of pipelines, increase the register ports
and data bandwidth and aside from deoendency tracking that's pretty much it.


>
> only the wiring between
> the blocks would need to be handled differently.


i originally designed a way to use the same blocks for FSMs as well as
pipelines.  it was difficult to maintain, unfortunately.

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