[libre-riscv-dev] Introduction and Questions

[libre-riscv-dev] Introduction and Questions

[Jeremy Singher]

Hi all,

My name is Jeremy Singher. I'm a graduate student studying computer
architecture, interested in open-source hardware and high performance
microarchitectures. I am looking for an open-source hardware project I can
contribute to through the course of my graduate studies, and I have some
questions about the Libre-SOC project.

1. It seems like you guys are building various components of an
out-of-order microarchitecture, such as the scoreboard, and load-store
ordering units. Do you have a complete microarchitecture diagram of the
core (or a text description)? I could find bits and pieces on specific
components, but I'm interested in details like pipeline width, depth,
branch-to-branch latency, load-use delay, etc.
2. Is the SoC at a state at which I can evaluate performance on simple
benchmarks in simulation? Other similar open-source hardware projects have
make targets to launch verilator simulations, but I could not find an
equivalent in your repos (although I probably am just bad at looking).
3. What is your target performance in terms of an established benchmark
like Coremark, Dhrystone, Embench, or SPEC? I'm trying to compare the
merits and progress of various hardware projects out-there.
4. What is the right way to get started contributing? My experience is with
Verilog, and I've looked at other languages too, including BSV and Chisel.
I'm primarily interested in developing microarchitecture for
performance-critical components, like branch predictors, prefetchers,
instruction schedulers, and load-store units. Ideally, I could contribute
my work as part of graduate studies to this project.

Sorry for the barrage of questions.

Best,
-Jeremy
_______________________________________________
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] Introduction and Questions

[Yehowshua]

I’m guessing this is an old message that just got admitted once Luke flushed the filters.

Yehowshua
_______________________________________________
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] Introduction and Questions

[Luke Kenneth Casson Leighton]

yes, apologies!  (hi jeremy, btw the discussion we had was genuinely
appreciated).
l.

On Sat, Jun 6, 2020 at 11:47 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> I’m guessing this is an old message that just got admitted once Luke flushed the filters.
>
> Yehowshua
> _______________________________________________
> 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 mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] Introduction and Questions

[Jeremy Singher]

Hi all,

My name is Jeremy Singher. I'm a graduate student studying computer
architecture, interested in open-source hardware and high performance
microarchitectures. I am looking for an open-source hardware project I can
contribute to through the course of my graduate studies, and I have some
questions about the Libre-SOC project.

1. It seems like you guys are building various components of an
out-of-order microarchitecture, such as the scoreboard, and load-store
ordering units. Do you have a complete microarchitecture diagram of the
core (or a text description)? I could find bits and pieces on specific
components, but I'm interested in details like pipeline width, depth,
branch-to-branch latency, load-use delay, etc.
2. Is the SoC at a state at which I can evaluate performance on simple
benchmarks in simulation? Other similar open-source hardware projects have
make targets to launch verilator simulations, but I could not find an
equivalent in your repos (although I probably am just bad at looking).
3. What is your target performance in terms of an established benchmark
like Coremark, Dhrystone, Embench, or SPEC? I'm trying to compare the
merits and progress of various hardware projects out-there.
4. What is the right way to get started contributing? My experience is with
Verilog, and I've looked at other languages too, including BSV and Chisel.
I'm primarily interested in developing microarchitecture for
performance-critical components, like branch predictors, prefetchers,
instruction schedulers, and load-store units. Ideally, I could contribute
my work as part of graduate studies to this project.

Sorry for the barrage of questions.

Best,
-Jeremy
_______________________________________________
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] Introduction and Questions

[Yehowshua]

> On May 15, 2020, at 2:24 PM, Jeremy Singher <thejsingher@gmail.com> wrote:
> 
> Hi all,
> 
> My name is Jeremy Singher.

Hello and welcome!

> I'm a graduate student studying computer
> architecture, interested in open-source hardware and high performance
> microarchitectures. I am looking for an open-source hardware project I can
> contribute to through the course of my graduate studies, and I have some
> questions about the Libre-SOC project.
> 
> 1. It seems like you guys are building various components of an
> out-of-order microarchitecture, such as the scoreboard, and load-store
> ordering units. Do you have a complete microarchitecture diagram of the
> core (or a text description)?

Unfortunately, not yet - would you like to help with this?
We’re a bit starved on labor - about 4ish full-time in man-hours?

> I could find bits and pieces on specific
> components, but I'm interested in details like pipeline width, depth,
> branch-to-branch latency, load-use delay, etc.

We’re using a modification on the scoreboard architecture from the Cray CDC 6600.
Our scoreboard is somewhat similar to that of Tomasulo’s algorithm.

> 2. Is the SoC at a state at which I can evaluate performance on simple
> benchmarks in simulation? Other similar open-source hardware projects have
> make targets to launch verilator simulations, but I could not find an
> equivalent in your repos (although I probably am just bad at looking).

No. So since we’re implementing a POWER chip, we decided to start by writing a POWER
Simulator first. There are were a few options for this, QEMU, PearPC, and Gem5.

We’re making tweaks to PearPC and we also writing a simulator in Python that parses the official POWER3.0B spec.

I can’t remember why we decided to fiddle around with PearPC and not use QEMU or Gem5.

> 3. What is your target performance in terms of an established benchmark
> like Coremark, Dhrystone, Embench, or SPEC? I'm trying to compare the
> merits and progress of various hardware projects out-there.

From initial discussion, our first tapeout would be looking at Raspberry Pi rev B 2012 performance wise.
It would be good to get some drystone number down.

> 4. What is the right way to get started contributing? My experience is with
> Verilog, and I've looked at other languages too, including BSV and Chisel.
> I'm primarily interested in developing microarchitecture for
> performance-critical components, like branch predictors, prefetchers,
> instruction schedulers, and load-store units. Ideally, I could contribute
> my work as part of graduate studies to this project.
> 

Are you familiar with Python nMigen - its basically Chisel for Python. You mentioned michroarchitecture… Perhaps you could help Luke on the scoreboard.

Our codebase is a bit of a mess at the moment - there was so much to do for such a large project.
By August, with significant extra funding and labor in the pipeline, there should be more ability to clean things up.

> Sorry for the barrage of questions.
> 

No offense here :)

> Best,
> -Jeremy

Yehowshua

> _______________________________________________
> 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 mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction and Questions

[Jeremy Singher]

> Unfortunately, not yet - would you like to help with this?
> We’re a bit starved on labor - about 4ish full-time in man-hours?

Sure, if you point me to documentation on the core design, I can draw
up a diagram of it.
Is there enough information on the core to make a WikiChip-like diagram?
I find that displaying the pipeline depth, width, and important
components is a good way of
displaying key characteristics of a core, and it makes it easier for
people like me to draw comparisons
against other cores (commercial and open-source).

> We’re using a modification on the scoreboard architecture from the Cray CDC 6600.
> Our scoreboard is somewhat similar to that of Tomasulo’s algorithm.

So you have OOO execution with multiple functional units executing in parallel,
and a scoreboard tracking completion status of writes to registers, right?
Is this a unified-register-file, or register-in-issue-queue design?

> No. So since we’re implementing a POWER chip, we decided to start by writing a POWER
> Simulator first. There are were a few options for this, QEMU, PearPC, and Gem5.

Ah I see, that's ok. You have to start somewhere :).

> From initial discussion, our first tapeout would be looking at Raspberry Pi rev B 2012 performance wise.
> It would be good to get some drystone number down.

Are you targeting IPC as the performance metric? Or IPC x Freq?
The Pi 1 Rev B seems to be a 1-wide in-order design, so it should be a
pretty conservative target to hit.
Any basic OOO core should beat the PI B in IPC, it only needs to run
at an equivalent frequency.

Do you know what the final performance target is? (Or minimal target
for a commercially viable product?)
The Cortex A72 is a 3-w OOO that might be a good point to target (it's
also used the latest Pi 4s).

From running a couple experiments on other open-OOO cores, it seems
like 3-ish DMIPs/MHz is a good
target for a OOO core.

> Are you familiar with Python nMigen - its basically Chisel for Python. You mentioned michroarchitecture… Perhaps you could help Luke on the scoreboard.

Ya, I've been trying to run the script on the website, running into
problems with Yosys, debugging now.

Lastly, have you guys talked to the university efforts to build
open-source cores? I see links to the
Shakti project on the site. Is this a collaboration with them? I
thought they were doing RISC-V?
There's also groups at ETH, Berkeley, and MIT pushing out their own
application-class cores. How does
this design compare to those?

Part of the reason I'm asking so many questions (beyond my own
curiosity) is that I will likely be
a TA for a computer-architecture course in the near future, and I
would like to revamp the course by
having students interact with real RTL for a complex SoC, instead of
just simulators.


Thanks,
-Jeremy
On Fri, May 15, 2020 at 11:45 AM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
>
>
> > On May 15, 2020, at 2:24 PM, Jeremy Singher <thejsingher@gmail.com> wrote:
> >
> > Hi all,
> >
> > My name is Jeremy Singher.
>
> Hello and welcome!
>
> > I'm a graduate student studying computer
> > architecture, interested in open-source hardware and high performance
> > microarchitectures. I am looking for an open-source hardware project I can
> > contribute to through the course of my graduate studies, and I have some
> > questions about the Libre-SOC project.
> >
> > 1. It seems like you guys are building various components of an
> > out-of-order microarchitecture, such as the scoreboard, and load-store
> > ordering units. Do you have a complete microarchitecture diagram of the
> > core (or a text description)?
>
> Unfortunately, not yet - would you like to help with this?
> We’re a bit starved on labor - about 4ish full-time in man-hours?
>
> > I could find bits and pieces on specific
> > components, but I'm interested in details like pipeline width, depth,
> > branch-to-branch latency, load-use delay, etc.
>
> We’re using a modification on the scoreboard architecture from the Cray CDC 6600.
> Our scoreboard is somewhat similar to that of Tomasulo’s algorithm.
>
> > 2. Is the SoC at a state at which I can evaluate performance on simple
> > benchmarks in simulation? Other similar open-source hardware projects have
> > make targets to launch verilator simulations, but I could not find an
> > equivalent in your repos (although I probably am just bad at looking).
>
> No. So since we’re implementing a POWER chip, we decided to start by writing a POWER
> Simulator first. There are were a few options for this, QEMU, PearPC, and Gem5.
>
> We’re making tweaks to PearPC and we also writing a simulator in Python that parses the official POWER3.0B spec.
>
> I can’t remember why we decided to fiddle around with PearPC and not use QEMU or Gem5.
>
> > 3. What is your target performance in terms of an established benchmark
> > like Coremark, Dhrystone, Embench, or SPEC? I'm trying to compare the
> > merits and progress of various hardware projects out-there.
>
> From initial discussion, our first tapeout would be looking at Raspberry Pi rev B 2012 performance wise.
> It would be good to get some drystone number down.
>
> > 4. What is the right way to get started contributing? My experience is with
> > Verilog, and I've looked at other languages too, including BSV and Chisel.
> > I'm primarily interested in developing microarchitecture for
> > performance-critical components, like branch predictors, prefetchers,
> > instruction schedulers, and load-store units. Ideally, I could contribute
> > my work as part of graduate studies to this project.
> >
>
> Are you familiar with Python nMigen - its basically Chisel for Python. You mentioned michroarchitecture… Perhaps you could help Luke on the scoreboard.
>
> Our codebase is a bit of a mess at the moment - there was so much to do for such a large project.
> By August, with significant extra funding and labor in the pipeline, there should be more ability to clean things up.
>
> > Sorry for the barrage of questions.
> >
>
> No offense here :)
>
> > Best,
> > -Jeremy
>
> Yehowshua
>
> > _______________________________________________
> > 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 mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

_______________________________________________
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] Introduction and Questions

[Yehowshua]

> On May 15, 2020, at 3:15 PM, Jeremy Singher <thejsingher@gmail.com> wrote:
> 
> Part of the reason I'm asking so many questions (beyond my own
> curiosity) is that I will likely be
> a TA for a computer-architecture course in the near future, and I
> would like to revamp the course by
> having students interact with real RTL for a complex SoC, instead of
> just simulators.

NO WAYY!!

So how I actually got involved in Libre-SOC was that I was trying to start a open cores effort in Georgia Tech’s ECE department.

A couple GT VC alum’s prodded me into the direction of starting a company with Libre-SOC.

Also, my ECE department hired me to revamp the computer architecture course because I complained about it so much.

So I decided to make a website for the future course here: https://comparch-resources.ece.gatech.edu <https://comparch-resources.ece.gatech.edu/>
We’re beta testing the course with students remotely this summer. I decided to have them use nMigen.

You can see how to install yosys correctly here: https://comparch-resources.ece.gatech.edu/resources/nmigen/nmigen/ <https://comparch-resources.ece.gatech.edu/resources/nmigen/nmigen/>


I’m a grad student about to graduate end of summer at GT.

Yehowshua
_______________________________________________
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] Introduction and Questions

[Yehowshua]

> On May 15, 2020, at 3:15 PM, Jeremy Singher <thejsingher@gmail.com <mailto:thejsingher@gmail.com>> wrote:
> 
> Lastly, have you guys talked to the university efforts to build
> open-source cores? I see links to the
> Shakti project on the site. Is this a collaboration with them? I
> thought they were doing RISC-V?
> There's also groups at ETH, Berkeley, and MIT pushing out their own
> application-class cores. How does
> this design compare to those?

This will be a full SOC with a GPU that supports Vulkan and eventually OpenGL and OpenCL.
AFAIK, there are no other full out GPU projects.

Yes - there has been some discussion with Shakti on Luke’s end and Shakti is informally aware of Libre-SOC.
I’m not sure as to the Curren’t state of Shakti - I think the project went quit e almost a year ago.

We had some unfortunate run-ins with Berkeley and RISCV - and we decided to go with POWER because we have access to some important relations at IBM

Yehowshua
_______________________________________________
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] Introduction and Questions

[Yehowshua]

> On May 15, 2020, at 3:15 PM, Jeremy Singher <thejsingher@gmail.com> wrote:
> 
> Are you targeting IPC as the performance metric? Or IPC x Freq?
> The Pi 1 Rev B seems to be a 1-wide in-order design, so it should be a
> pretty conservative target to hit.
> Any basic OOO core should beat the PI B in IPC, it only needs to run
> at an equivalent frequency.
> 
> Do you know what the final performance target is? (Or minimal target
> for a commercially viable product?)
> The Cortex A72 is a 3-w OOO that might be a good point to target (it's
> also used the latest Pi 4s).
> 
> From running a couple experiments on other open-OOO cores, it seems
> like 3-ish DMIPs/MHz is a good
> target for a OOO core.

I know we initially were targeting 5GFLOPS for the GPU on the first tapeout.

Basically, the way we’re doing the GPU is the add a vector FPU along with
accompanying instructions into the actual CPU.

We would then just write the drivers that translate various shaders and drawing
commands into vector instructions which can be scheduled on the scoreboard.

Realistically, for our first tapeout(we’re using Google’s shuttle service on 1800nm TSMC),
we’d do a CPU with no vector instructions(effectively no GPU) for October.

Since we’re doing FOSS down to the VLSI design cells(we’re using Time Ansell’s OpenPDK as an intermediate), we need somebody to do a PLL.

With a FOSS PLL in place, we can get 300MHZ on the first tapeout. We’re doing a single core for the 
first tape out, with 6 stages I think…

With no PLL, I think we’re limited to 25-50MHz.

Some simple math could give a DMIPS estimate.

Yehowshua
_______________________________________________
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] Introduction and Questions

[Luke Kenneth Casson Leighton]

hi jeremy, welcome.

here you may have noticed, there are two chips: the 180nm test ASIC
which we have a tight deadline to meet, mid-august we need to freeze
the design and immediately move to doing layout using Coriolis2.  this
one we are extremely unlikely to even have FP operations.

beyond that we have a second ASIC to do, the quad-core SMP 800mhz
dual-issue.  that's where you saw the numbers for.

On Fri, May 15, 2020 at 8:33 PM Yehowshua <yimmanuel3@gatech.edu> wrote:

> I know we initially were targeting 5GFLOPS for the GPU on the first tapeout.

this was to be 5-6 GMACs capability for the quad-core SMP 800mhz
dual-issue (second target).  however... *sheepish*... we kinda
drastically overshot that on the internal architecture :)  it was to
be 5-6 GMACS which is of course 10-12 GFLOPS (FP MUL and FP ADD in
FPMAC counting as 2).

also each core - all four of them - is architected to handle a minimum
128-bit-wide LOAD/STORE data path (4x FP32), and there will be 4x FP32
- FMACs - per clock cycle, because they will be issued as 2x 64-bit
operations (2x 32-bit FPs in each 64-bit) and it is dual issue.

800mhz x 2 issue x 2-32 per 64-bit x 4 = 12.8 GMACs which x2 because
FPMUL and FPADD is 2 ops = 25.6 GFLOPs.

a teeny tiny bit over what we initially planned, then :)

> Basically, the way we’re doing the GPU is the add a vector FPU along with
> accompanying instructions into the actual CPU.

by overloading "multi-issue".  a hardware for-loop at the instruction
execution phase will push multiple sequential instructions into the
OoO engine from a *single* instruction.

> We would then just write the drivers that translate various shaders and drawing
> commands into vector instructions which can be scheduled on the scoreboard.

rather than having a ridiculous "Remote Procedure Call" system that
packs up Vulkan / OpenGL commands into a serial marshalled data stream
from the application, communicated to the kernel, shipped over PCIe or
other memory bus architecture, unpacked at the GPU, turned into
instructions, executed, and the results shipped *back* the other way

total insanity.

> Realistically, for our first tapeout(we’re using Google’s shuttle service on 1800nm TSMC),
> we’d do a CPU with no vector instructions(effectively no GPU) for October.

straight POWER9 however still OoO

> Since we’re doing FOSS down to the VLSI design cells(we’re using Time Ansell’s OpenPDK as an intermediate), we need somebody to do a PLL.

a Professor from LIP6 has offered to do that.  i introduced you to him
and Tim, yehowshua.

> With a FOSS PLL in place, we can get 300MHZ on the first tapeout. We’re doing a single core for the
> first tape out, with 6 stages I think…

the DIV pipeline will be... 8 (maybe more), MUL will be 2, ADD (etc.) will be 1.

* fetch: 1.
* decode: 1.
* issue and reg-read: 1 (minimum).
* execute: between 1 and 8 (maybe more)
* write: 1 (minimum)

POWER9 has update mode for LD/ST so those would take 1 extra.  some
ALU operations need to write to the Condition Register, that's another
extra 1 write (possibly).

etc.

basically this is why we're doing OoO because coordinating all that in
an in-order system would be absolute hell.

> With no PLL, I think we’re limited to 25-50MHz.

Staf mentioned that there's no reason why we should not attempt to
drive the external CLK line at 100mhz.  it could potentially radiate
EM like stink, however it might work.  we'll see :)

> Some simple math could give a DMIPS estimate.

it's down ultimately to how wide the register paths are, between the
Regfile and the Function Units.  if we have multiple Register Data
Buses, and can implement the multi-issue part in time, it'll be coded
in a general-purpose enough way that we could consider 4-issue.
however... without the register data paths, there's no point.

it comes down to how much time we have.

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] Introduction and Questions

[Jeremy Singher]

> a teeny tiny bit over what we initially planned, then :)

Thanks Luke, these numbers are closer to what seems reasonable to me.
A simple superscalar core with 2 FPU functional units should be able
to achieve 4 GFLOPS, so a vector unit would need to go higher than
that to be worth the extra silicon.

> by overloading "multi-issue".  a hardware for-loop at the instruction
> execution phase will push multiple sequential instructions into the
> OoO engine from a *single* instruction.

I see, so a form of micro-op fission, essentially you are decoding
complex vector (or "GPU") instructions into a sequential stream of
simple micro-ops? This seems like a pretty reasonable design point.

> the DIV pipeline will be... 8 (maybe more), MUL will be 2, ADD (etc.) will be 1.
> * fetch: 1.
> * decode: 1.
> * issue and reg-read: 1 (minimum).
> * execute: between 1 and 8 (maybe more)
> * write: 1 (minimum)

So this is just for the preliminary tapeout? I would expect an OOO
core targeting 1GHz+ to have more pipeline stages than this (10+). The
A72, Skylake, Zen, and BOOM all seem to target 10+ stages.

> basically this is why we're doing OoO because coordinating all that in
> an in-order system would be absolute hell.

I'm a bit confused now. In-order execution with variable-latency
functional units can be achieved with a scoreboard, and the pipeline
stages you describe reminds me of a in-order core with OOO write-back.
Is this what you are doing? Or are you pursuing true OOO execution
with register-renaming?

> it's down ultimately to how wide the register paths are, between the
> Regfile and the Function Units.  if we have multiple Register Data
> Buses, and can implement the multi-issue part in time, it'll be coded
> in a general-purpose enough way that we could consider 4-issue.
> however... without the register data paths, there's no point.

Fair enough. Balancing the throughput of all the components in a OOO
core is tricky, and register read can certainly be a bottleneck.

> We had some unfortunate run-ins with Berkeley and RISCV - and we decided to go with POWER because we have access to some important relations at IBM

Have you looked at the open RISC-V micro-architectures though? Even if
this core runs POWER, it should be not too difficult to port design
ideas from existing cores, to avoid reinventing the wheel everywhere.



On Fri, May 15, 2020 at 1:12 PM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> hi jeremy, welcome.
>
> here you may have noticed, there are two chips: the 180nm test ASIC
> which we have a tight deadline to meet, mid-august we need to freeze
> the design and immediately move to doing layout using Coriolis2.  this
> one we are extremely unlikely to even have FP operations.
>
> beyond that we have a second ASIC to do, the quad-core SMP 800mhz
> dual-issue.  that's where you saw the numbers for.
>
> On Fri, May 15, 2020 at 8:33 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> > I know we initially were targeting 5GFLOPS for the GPU on the first tapeout.
>
> this was to be 5-6 GMACs capability for the quad-core SMP 800mhz
> dual-issue (second target).  however... *sheepish*... we kinda
> drastically overshot that on the internal architecture :)  it was to
> be 5-6 GMACS which is of course 10-12 GFLOPS (FP MUL and FP ADD in
> FPMAC counting as 2).
>
> also each core - all four of them - is architected to handle a minimum
> 128-bit-wide LOAD/STORE data path (4x FP32), and there will be 4x FP32
> - FMACs - per clock cycle, because they will be issued as 2x 64-bit
> operations (2x 32-bit FPs in each 64-bit) and it is dual issue.
>
> 800mhz x 2 issue x 2-32 per 64-bit x 4 = 12.8 GMACs which x2 because
> FPMUL and FPADD is 2 ops = 25.6 GFLOPs.
>
> a teeny tiny bit over what we initially planned, then :)
>
> > Basically, the way we’re doing the GPU is the add a vector FPU along with
> > accompanying instructions into the actual CPU.
>
> by overloading "multi-issue".  a hardware for-loop at the instruction
> execution phase will push multiple sequential instructions into the
> OoO engine from a *single* instruction.
>
> > We would then just write the drivers that translate various shaders and drawing
> > commands into vector instructions which can be scheduled on the scoreboard.
>
> rather than having a ridiculous "Remote Procedure Call" system that
> packs up Vulkan / OpenGL commands into a serial marshalled data stream
> from the application, communicated to the kernel, shipped over PCIe or
> other memory bus architecture, unpacked at the GPU, turned into
> instructions, executed, and the results shipped *back* the other way
>
> total insanity.
>
> > Realistically, for our first tapeout(we’re using Google’s shuttle service on 1800nm TSMC),
> > we’d do a CPU with no vector instructions(effectively no GPU) for October.
>
> straight POWER9 however still OoO
>
> > Since we’re doing FOSS down to the VLSI design cells(we’re using Time Ansell’s OpenPDK as an intermediate), we need somebody to do a PLL.
>
> a Professor from LIP6 has offered to do that.  i introduced you to him
> and Tim, yehowshua.
>
> > With a FOSS PLL in place, we can get 300MHZ on the first tapeout. We’re doing a single core for the
> > first tape out, with 6 stages I think…
>
> the DIV pipeline will be... 8 (maybe more), MUL will be 2, ADD (etc.) will be 1.
>
> * fetch: 1.
> * decode: 1.
> * issue and reg-read: 1 (minimum).
> * execute: between 1 and 8 (maybe more)
> * write: 1 (minimum)
>
> POWER9 has update mode for LD/ST so those would take 1 extra.  some
> ALU operations need to write to the Condition Register, that's another
> extra 1 write (possibly).
>
> etc.
>
> basically this is why we're doing OoO because coordinating all that in
> an in-order system would be absolute hell.
>
> > With no PLL, I think we’re limited to 25-50MHz.
>
> Staf mentioned that there's no reason why we should not attempt to
> drive the external CLK line at 100mhz.  it could potentially radiate
> EM like stink, however it might work.  we'll see :)
>
> > Some simple math could give a DMIPS estimate.
>
> it's down ultimately to how wide the register paths are, between the
> Regfile and the Function Units.  if we have multiple Register Data
> Buses, and can implement the multi-issue part in time, it'll be coded
> in a general-purpose enough way that we could consider 4-issue.
> however... without the register data paths, there's no point.
>
> it comes down to how much time we have.
>
> 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 mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction and Questions

[Yehowshua]

> 
> I'm a bit confused now. In-order execution with variable-latency
> functional units can be achieved with a scoreboard, and the pipeline
> stages you describe reminds me of a in-order core with OOO write-back.
> Is this what you are doing? Or are you pursuing true OOO execution
> with register-renaming?
> 

Register renaming I believe.

> Have you looked at the open RISC-V micro-architectures though? Even if
> this core runs POWER, it should be not too difficult to port design
> ideas from existing cores, to avoid reinventing the wheel everywhere.
> 

Yeah - there was a thought to use a RISC-V like microarchitecture.
And then do POWER ontop of that.

There are a couple things to consider.

1. SPR registers and TLB and cache behavior are notably different for POWER.
2. All the RISC-V instructions exist in POWER in some form. POWER’s extra instructions
can be composed of simpler instructions - but it may not be worth it

Consider the instruction the POWER instruction ``rlwinm``:
That does a bit rotate - can we guarantee that implementing hardware to translate ``rlwinm`` into some sequence of ``sll``and ``and`` will actually be easier?

We didn’t really have the time or labor to investigate in February.

Before that, we did however do an extensive investigation of RISC-V.
We concluded that the POWER software ecosystem is more mature, for example, POWER has
a well maintained port of V8 as well as a complete vector extension.

Since we wanted to use a vector like extension to implement our GPU, we didn’t want to release an SOC with its own RISCV vector extension, and then perhaps when RISCV in the future finalized their extension, ours would be out of date.

After talks with the OpenPOWER organization, we are allowed to implement special instructions as necessary while still maintaining the official POWER compliance of our chip.

The instructions we implement will be subject to review, but we’ve had healthy dialogue with the POWER foundation.

After some discussion with RVF, we weren’t sure if our chip would be deemed officially RISCV compliant with custom and potentially future conflicting custom instructions.

Yehowshua
_______________________________________________
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] Introduction and Questions

[Jacob Lifshay]

On Fri, May 15, 2020, 13:50 Jeremy Singher <thejsingher@gmail.com> wrote:

>
> > the DIV pipeline will be... 8 (maybe more), MUL will be 2, ADD (etc.)
> will be 1.
> > * fetch: 1.
> > * decode: 1.
> > * issue and reg-read: 1 (minimum).
> > * execute: between 1 and 8 (maybe more)
> > * write: 1 (minimum)
>
> So this is just for the preliminary tapeout? I would expect an OOO
> core targeting 1GHz+ to have more pipeline stages than this (10+). The
> A72, Skylake, Zen, and BOOM all seem to target 10+ stages.
>

We will definitely need more stages in the fetch pipeline for branch
prediction, TLB, and cache handling, I'm guessing 2 or 3 fetch stages.

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] Introduction and Questions

[Luke Kenneth Casson Leighton]

On Fri, May 15, 2020 at 10:20 PM Jacob Lifshay <programmerjake@gmail.com> wrote:

> We will definitely need more stages in the fetch pipeline for branch
> prediction, TLB, and cache handling, I'm guessing 2 or 3 fetch stages.

oh, yes.  good catch.  ah... ok TLB is deliberately kept to very small
sizes (8 entries max)
so that it can respond in 1 cycle (or, same-cycle).  branch prediction and
cache misses, i left out because they're "extra" (but only on misses).

however for higher speeds, TLBs are often cascaded and again end up with
extra misses.  that's according to the wikipedia page on TLB :)

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] Introduction and Questions

[Luke Kenneth Casson Leighton]

On Fri, May 15, 2020 at 9:50 PM Jeremy Singher <thejsingher@gmail.com> wrote:
>
> > a teeny tiny bit over what we initially planned, then :)
>
> Thanks Luke, these numbers are closer to what seems reasonable to me.
> A simple superscalar core with 2 FPU functional units should be able
> to achieve 4 GFLOPS, so a vector unit would need to go higher than
> that to be worth the extra silicon.

the hardware requirements are derived from the software ones.  we
decided though to do a hybrid design rather than a separate CPU
separate GPU approach... because... well... um... that's.... two...
processors :)

hybrid designs are extremely unusual.  there's only 2 that i have
heard of: the ICubeCorp IC3128, and the Broadcom VideoCore IV (based
around an ARC core, ARC - now bought by Synopsis - is known for
providing a wealth of SIMD and other "additional" instructions,
similar to how RISC-V is now set up, except completely secretive and
under the full and total proprietary control of Synopsis).

i've looked at Vector ISAs, and SIMD ISAs: i concluded that there's a
better way to do a Vector ISA, keeping the *semantics* outlined in the
article "SIMD Considered Harmful".

> > by overloading "multi-issue".  a hardware for-loop at the instruction
> > execution phase will push multiple sequential instructions into the
> > OoO engine from a *single* instruction.
>
> I see, so a form of micro-op fission,

yes, in effect.  this reduces I-Cache pressure, which in a *hybrid*
processor is critically important.  in a separate-CPU,separate-GPU
design you have two I-Caches, running two separate executables, you
don't _give_ a damn.

in a hybrid processor, where GPU opcodes are often 64-bit and are more
usually 128-bit (FOUR banks of 32-bit VLIW instructions), because one
64-bit instruction may be doing 16x FP vector operations who _gives_ a
damn.

unfortunately, when the I-Cache is shared, we do give a damn.
therefore we need to reduce the instruction size and came up with
SimpleV (look it up).

> essentially you are decoding
> complex vector (or "GPU") instructions into a sequential stream of
> simple micro-ops? This seems like a pretty reasonable design point.

mmm not quite.  look up SimpleV.  it's basically a Cray Vector Loop
(VL) except that VL, when set, actually *PAUSES* the Program Counter,
and issues MULTIPLE instructions - using the one at the PC as a
"template" - but incrementing the operand register numbers
sequentially on each iteration of the loop from 0 to VL-1.

> > the DIV pipeline will be... 8 (maybe more), MUL will be 2, ADD (etc.) will be 1.
> > * fetch: 1.
> > * decode: 1.
> > * issue and reg-read: 1 (minimum).
> > * execute: between 1 and 8 (maybe more)
> > * write: 1 (minimum)
>
> So this is just for the preliminary tapeout?

yes, in 180nm.  which can only achieve a max of around 300mhz.  if we
had a PLL.  which we do not.  because we are not signing Foundry NDAs.
and the Foundry will only give us the PLL block they normally hand
out.... under NDA.

> I would expect an OOO
> core targeting 1GHz+ to have more pipeline stages than this (10+). The
> A72, Skylake, Zen, and BOOM all seem to target 10+ stages.

yep.  and these are all (except BOOM) USD $100 million custom silicon designs.

> > basically this is why we're doing OoO because coordinating all that in
> > an in-order system would be absolute hell.
>
> I'm a bit confused now. In-order execution with variable-latency
> functional units can be achieved with a scoreboard,

which we have.  using an augmented variant of the 6600, thanks to Mitch Alsup.
https://libre-soc.org/3d_gpu/architecture/6600scoreboard/

> and the pipeline
> stages you describe reminds me of a in-order core with OOO write-back.

pipelines can still be used behind Function Unit "front-ends".  Mitch Alsup
describes them as "Concurrent Computation Units".  basically if the pipeline
is N deep, you put N-or-greater Function Unit "Reservation-Station" style
operand latches on the front, that gives you the ability to track the pipeline
results, match them *back* up with the FU index, and voila, you have
turned what is otherwise considered the exclusive domain of "in-order pipeline"
terminology into something that fits into OoO.

> Is this what you are doing?

no.

> Or are you pursuing true OOO execution

yes.

> with register-renaming?

no / misleading question.

we are using the 6600 design, from 1965.  this has "implicit"
register-renaming automatically built-in to the design.  these are the
Function Unit operand latches.  they are best termed "nameless
registers" rather than "register-renaming".

if you are familiar with the Tomasulo Algorithm: if you make the
number of Reservation Station Rows equal to 1, then the RS latches are
directly equal and equivalent to Function Unit operand latches, and
both are in effect "register renaming"... only the better terminology
is "nameless registers" or "in-flight registers / results".

if you have read his book and consider it to be the last word on
scoreboards, Patterson has completely and utterly misinformed the
general public and the academic community with his book, regarding the
6600 and scoreboards in general.  Mitch Alsup had to write two
additional chapters, as an addendum to James Thornton's book, "Design
of a Computer", in order to correct Patterson's misinformation.

> > it's down ultimately to how wide the register paths are, between the
> > Regfile and the Function Units.  if we have multiple Register Data
> > Buses, and can implement the multi-issue part in time, it'll be coded
> > in a general-purpose enough way that we could consider 4-issue.
> > however... without the register data paths, there's no point.

>
> Fair enough. Balancing the throughput of all the components in a OOO
> core is tricky, and register read can certainly be a bottleneck.

yes.  see https://groups.google.com/d/msg/comp.arch/qeMsE7UxvlI/AmwsomDoAQAJ
i can't find the diagram i drew at the moment... regfile i think...
ah yes here you go:
https://libre-soc.org/3d_gpu/architecture/regfile/

that's a global cyclic buffer at the regfile (acts as an Operand
Forwarding Bus) and
*local* cyclic buffers at the Function Units.

> > We had some unfortunate run-ins with Berkeley and RISCV - and we decided to go with POWER because we have access to some important relations at IBM
>
> Have you looked at the open RISC-V micro-architectures though?

yes.  they are nowhere near the level of comprehensiveness needed.
plus, it would be incredibly irresponsible of us to bring to market a
100 million and above *libre* design where the modifications to the
compiler, toolchain, everything, all needed to be upstream.


> Even if
> this core runs POWER, it should be not too difficult to port design
> ideas from existing cores, to avoid reinventing the wheel everywhere.

because of the way that SimpleV works, and because we need to
drastically extend the target ISA (POWER9) with opcodes that are
everyday common-usage in GPUs (Texture Ops, SIN, COS, RGB2YUV), whilst
on the face of it the idea sounds "perfectly reasonable", the changes
required are so fundamental that starting from someone else's design
would produce massive barriers.

example: we have created PartitionedSignal - a class that not just
"performs add operations", it takes an *additional* (dynamic)
side-argument - a mask - which *dynamically* partitions what would
otherwise be a 64-bit operation into *any* combination of 8, 16, 24,
32, 40, 48 and 56 bit operations.

this class, because we are using python, can be handed in as a kls in
an Object-Orientated fashion, to *replace* nmigen Signal, and thus we
may construct code that on the first usage is a simple pipeline,
however we may then convert that EXACT SAME CODE into a dynamic SIMD
variant purely with a one-line change.

these kinds of techniques are normally the exclusive domain of
experienced Software Engineering teams.  for a *hardware* team to
deploy them?  this is unheard-of, and if attempted with even Chisel3 /
Scala, would have the team running away screaming within about 6
months.  a team that was asked to do that in verilog or VHDL would
flat-out say "no".  or ask for 50 extra engineers.  which, for IBM or
Intel or ARM is not unreasonable, but for us it is not.

hence we started from scratch, in order to be able to deploy these
kinds of Software Engineering techniques.

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] Introduction and Questions

[Jeremy Singher]

> it's basically a Cray Vector Loop
> (VL) except that VL, when set, actually *PAUSES* the Program Counter,
> and issues MULTIPLE instructions - using the one at the PC as a
> "template" - but incrementing the operand register numbers
> sequentially on each iteration of the loop from 0 to VL-1.

So if you decode a vadd instruction, with VL=4, and a 1-wide pipeline,
the design would stall instruction fetch, and issue 4 "scalar" add
micro-ops with incrementing register indices? That seems like it
should work, although you would lose the ability to exploit vector
chaining, since pausing the PC would prevent additional instructions
after the vector instruction from getting issued. I looked a SimpleV a
while ago, and to me it seemed like the difference vs a normal vector
architecture was that SimpleV merged the vector and integer register
files.

> unfortunately, when the I-Cache is shared, we do give a damn.
> therefore we need to reduce the instruction size and came up with
> SimpleV (look it up).

Yep, this seems like a reasonable conclusion to draw.


> this has "implicit"
> register-renaming automatically built-in to the design.  these are the
> Function Unit operand latches.  they are best termed "nameless
> registers" rather than "register-renaming".

I think I understand what you are saying, my terminology for this is
that the core is "renaming" registers into what you call inflight
"nameless registers". At the end of the day, the point is that
register data is stored not just in a logical register file, and that
the scheduler can aggressively execute instructions OOO when their
operands are available, instead of in serializing execution in program
order.
How does the scoreboard handle a WAW hazard... two instructions
writing the same register? Does the second instruction wait for the
first to finish?

> Mitch Alsup had to write two
> additional chapters, as an addendum to James Thornton's book, "Design
> of a Computer", in order to correct Patterson's misinformation.

Do you have a link to the addendum? I have a pdf of the book, but it
doesn't seem to have the addendum.



On Fri, May 15, 2020 at 2:54 PM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> On Fri, May 15, 2020 at 9:50 PM Jeremy Singher <thejsingher@gmail.com> wrote:
> >
> > > a teeny tiny bit over what we initially planned, then :)
> >
> > Thanks Luke, these numbers are closer to what seems reasonable to me.
> > A simple superscalar core with 2 FPU functional units should be able
> > to achieve 4 GFLOPS, so a vector unit would need to go higher than
> > that to be worth the extra silicon.
>
> the hardware requirements are derived from the software ones.  we
> decided though to do a hybrid design rather than a separate CPU
> separate GPU approach... because... well... um... that's.... two...
> processors :)
>
> hybrid designs are extremely unusual.  there's only 2 that i have
> heard of: the ICubeCorp IC3128, and the Broadcom VideoCore IV (based
> around an ARC core, ARC - now bought by Synopsis - is known for
> providing a wealth of SIMD and other "additional" instructions,
> similar to how RISC-V is now set up, except completely secretive and
> under the full and total proprietary control of Synopsis).
>
> i've looked at Vector ISAs, and SIMD ISAs: i concluded that there's a
> better way to do a Vector ISA, keeping the *semantics* outlined in the
> article "SIMD Considered Harmful".
>
> > > by overloading "multi-issue".  a hardware for-loop at the instruction
> > > execution phase will push multiple sequential instructions into the
> > > OoO engine from a *single* instruction.
> >
> > I see, so a form of micro-op fission,
>
> yes, in effect.  this reduces I-Cache pressure, which in a *hybrid*
> processor is critically important.  in a separate-CPU,separate-GPU
> design you have two I-Caches, running two separate executables, you
> don't _give_ a damn.
>
> in a hybrid processor, where GPU opcodes are often 64-bit and are more
> usually 128-bit (FOUR banks of 32-bit VLIW instructions), because one
> 64-bit instruction may be doing 16x FP vector operations who _gives_ a
> damn.
>
> unfortunately, when the I-Cache is shared, we do give a damn.
> therefore we need to reduce the instruction size and came up with
> SimpleV (look it up).
>
> > essentially you are decoding
> > complex vector (or "GPU") instructions into a sequential stream of
> > simple micro-ops? This seems like a pretty reasonable design point.
>
> mmm not quite.  look up SimpleV.  it's basically a Cray Vector Loop
> (VL) except that VL, when set, actually *PAUSES* the Program Counter,
> and issues MULTIPLE instructions - using the one at the PC as a
> "template" - but incrementing the operand register numbers
> sequentially on each iteration of the loop from 0 to VL-1.
>
> > > the DIV pipeline will be... 8 (maybe more), MUL will be 2, ADD (etc.) will be 1.
> > > * fetch: 1.
> > > * decode: 1.
> > > * issue and reg-read: 1 (minimum).
> > > * execute: between 1 and 8 (maybe more)
> > > * write: 1 (minimum)
> >
> > So this is just for the preliminary tapeout?
>
> yes, in 180nm.  which can only achieve a max of around 300mhz.  if we
> had a PLL.  which we do not.  because we are not signing Foundry NDAs.
> and the Foundry will only give us the PLL block they normally hand
> out.... under NDA.
>
> > I would expect an OOO
> > core targeting 1GHz+ to have more pipeline stages than this (10+). The
> > A72, Skylake, Zen, and BOOM all seem to target 10+ stages.
>
> yep.  and these are all (except BOOM) USD $100 million custom silicon designs.
>
> > > basically this is why we're doing OoO because coordinating all that in
> > > an in-order system would be absolute hell.
> >
> > I'm a bit confused now. In-order execution with variable-latency
> > functional units can be achieved with a scoreboard,
>
> which we have.  using an augmented variant of the 6600, thanks to Mitch Alsup.
> https://libre-soc.org/3d_gpu/architecture/6600scoreboard/
>
> > and the pipeline
> > stages you describe reminds me of a in-order core with OOO write-back.
>
> pipelines can still be used behind Function Unit "front-ends".  Mitch Alsup
> describes them as "Concurrent Computation Units".  basically if the pipeline
> is N deep, you put N-or-greater Function Unit "Reservation-Station" style
> operand latches on the front, that gives you the ability to track the pipeline
> results, match them *back* up with the FU index, and voila, you have
> turned what is otherwise considered the exclusive domain of "in-order pipeline"
> terminology into something that fits into OoO.
>
> > Is this what you are doing?
>
> no.
>
> > Or are you pursuing true OOO execution
>
> yes.
>
> > with register-renaming?
>
> no / misleading question.
>
> we are using the 6600 design, from 1965.  this has "implicit"
> register-renaming automatically built-in to the design.  these are the
> Function Unit operand latches.  they are best termed "nameless
> registers" rather than "register-renaming".
>
> if you are familiar with the Tomasulo Algorithm: if you make the
> number of Reservation Station Rows equal to 1, then the RS latches are
> directly equal and equivalent to Function Unit operand latches, and
> both are in effect "register renaming"... only the better terminology
> is "nameless registers" or "in-flight registers / results".
>
> if you have read his book and consider it to be the last word on
> scoreboards, Patterson has completely and utterly misinformed the
> general public and the academic community with his book, regarding the
> 6600 and scoreboards in general.  Mitch Alsup had to write two
> additional chapters, as an addendum to James Thornton's book, "Design
> of a Computer", in order to correct Patterson's misinformation.
>
> > > it's down ultimately to how wide the register paths are, between the
> > > Regfile and the Function Units.  if we have multiple Register Data
> > > Buses, and can implement the multi-issue part in time, it'll be coded
> > > in a general-purpose enough way that we could consider 4-issue.
> > > however... without the register data paths, there's no point.
>
> >
> > Fair enough. Balancing the throughput of all the components in a OOO
> > core is tricky, and register read can certainly be a bottleneck.
>
> yes.  see https://groups.google.com/d/msg/comp.arch/qeMsE7UxvlI/AmwsomDoAQAJ
> i can't find the diagram i drew at the moment... regfile i think...
> ah yes here you go:
> https://libre-soc.org/3d_gpu/architecture/regfile/
>
> that's a global cyclic buffer at the regfile (acts as an Operand
> Forwarding Bus) and
> *local* cyclic buffers at the Function Units.
>
> > > We had some unfortunate run-ins with Berkeley and RISCV - and we decided to go with POWER because we have access to some important relations at IBM
> >
> > Have you looked at the open RISC-V micro-architectures though?
>
> yes.  they are nowhere near the level of comprehensiveness needed.
> plus, it would be incredibly irresponsible of us to bring to market a
> 100 million and above *libre* design where the modifications to the
> compiler, toolchain, everything, all needed to be upstream.
>
>
> > Even if
> > this core runs POWER, it should be not too difficult to port design
> > ideas from existing cores, to avoid reinventing the wheel everywhere.
>
> because of the way that SimpleV works, and because we need to
> drastically extend the target ISA (POWER9) with opcodes that are
> everyday common-usage in GPUs (Texture Ops, SIN, COS, RGB2YUV), whilst
> on the face of it the idea sounds "perfectly reasonable", the changes
> required are so fundamental that starting from someone else's design
> would produce massive barriers.
>
> example: we have created PartitionedSignal - a class that not just
> "performs add operations", it takes an *additional* (dynamic)
> side-argument - a mask - which *dynamically* partitions what would
> otherwise be a 64-bit operation into *any* combination of 8, 16, 24,
> 32, 40, 48 and 56 bit operations.
>
> this class, because we are using python, can be handed in as a kls in
> an Object-Orientated fashion, to *replace* nmigen Signal, and thus we
> may construct code that on the first usage is a simple pipeline,
> however we may then convert that EXACT SAME CODE into a dynamic SIMD
> variant purely with a one-line change.
>
> these kinds of techniques are normally the exclusive domain of
> experienced Software Engineering teams.  for a *hardware* team to
> deploy them?  this is unheard-of, and if attempted with even Chisel3 /
> Scala, would have the team running away screaming within about 6
> months.  a team that was asked to do that in verilog or VHDL would
> flat-out say "no".  or ask for 50 extra engineers.  which, for IBM or
> Intel or ARM is not unreasonable, but for us it is not.
>
> hence we started from scratch, in order to be able to deploy these
> kinds of Software Engineering techniques.
>
> 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 mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction and Questions

[Yehowshua]

Luke, I’ll forward Jeremy the chapters.

Yehowshua
_______________________________________________
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] Introduction and Questions

[Luke Kenneth Casson Leighton]

On Fri, May 15, 2020 at 11:29 PM Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> Luke, I’ll forward Jeremy the chapters.

ah.  remember that the conditions that we received them under - as
requested by their Copyright Holder - are that you MUST ask the
recipient to agree to give credit AND to request those same conditions
to be respected (recursively) by any recipients that *THEY* pass the
book chapters on to.

you are under the same conditions - which you agreed to when i passed
the book chapters on to you, and *unconditionally* passing them on to
Jeremy is a breach of those conditions.

if you have done that already - to him or to anyone else - then you
are actually in breach of Copyright Law.  you would need to then
approach Mitch Alsup, directly, as the Copyright holder, to re-request
his explicit permission to use and distribute his Copyrighted
material.

Copyright Law is the underpinning of everything that we are doing
(LGPL) so we absolutely must be extremely careful, respectful, and
knowledgeable about 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] Introduction and Questions

[Luke Kenneth Casson Leighton]

On Fri, May 15, 2020 at 11:15 PM Jeremy Singher <thejsingher@gmail.com> wrote:
>
> > it's basically a Cray Vector Loop
> > (VL) except that VL, when set, actually *PAUSES* the Program Counter,
> > and issues MULTIPLE instructions - using the one at the PC as a
> > "template" - but incrementing the operand register numbers
> > sequentially on each iteration of the loop from 0 to VL-1.
>
> So if you decode a vadd instruction, with VL=4, and a 1-wide pipeline,
> the design would stall instruction fetch, and issue 4 "scalar" add
> micro-ops with incrementing register indices?

not micro-ops, *actual* scalar add ops.

> That seems like it
> should work, although you would lose the ability to exploit vector
> chaining, since pausing the PC would prevent additional instructions
> after the vector instruction from getting issued.

nope :)  because the Out-of-Order scoreboard takes care of them.
they're *literally* simply as if you had had 4x (or 8x, or 12x, or
16x) scalar ADD multi-issue instructions shoved into the execution
engine.

any following 4x instructions (or however many) *will* still have the
register numbers - different or otherwise - and thus *will* have the
Read and Write Dependency Hazard tracking applied to them.

it's basically c macros... applied to hardware.

> I looked a SimpleV a
> while ago, and to me it seemed like the difference vs a normal vector
> architecture was that SimpleV merged the vector and integer register
> files.

no, it's waaay more than that.

> > this has "implicit"
> > register-renaming automatically built-in to the design.  these are the
> > Function Unit operand latches.  they are best termed "nameless
> > registers" rather than "register-renaming".
>
> I think I understand what you are saying, my terminology for this is
> that the core is "renaming" registers into what you call inflight
> "nameless registers". At the end of the day, the point is that
> register data is stored not just in a logical register file,

correct... it is "in flight".  the distinction is important because a
lot of people try
to *explicitly* add register-renaming hardware, register caches, and *actually*
rename the registers by providing a PRF-ARF (physical / architectural)
register file naming scheme.

we maaay have to do that (because we will have a 128 entry regfile and
the Dependency Matrices need to be of the size of the actual regs in use).

however it will be to *DOWNSIZE* the register numbers... *NOT* "upsize"
them as is normally done with e.g. x86.

> and that
> the scheduler can aggressively execute instructions OOO when their
> operands are available, instead of in serializing execution in program
> order.

correct.

> How does the scoreboard handle a WAW hazard... two instructions
> writing the same register? Does the second instruction wait for the
> first to finish?

sigh over a year ago i understood this enough to be able to answer.
what we will have to do is simply ignore the optimisation opportunity.

> > Mitch Alsup had to write two
> > additional chapters, as an addendum to James Thornton's book, "Design
> > of a Computer", in order to correct Patterson's misinformation.
>
> Do you have a link to the addendum? I have a pdf of the book, but it
> doesn't seem to have the addendum.

no it does not.  you will need to state that you are happy to give
credit if you use the book chapters, and that if you pass them on you
will likewise ask the recipient to guarantee that they also will give
credit to Mitch Alsup.

these are the conditions under which i received the book chapters from
Mitch Alsup, and, as the Copyright holder, he is entitled to request
any conditions that he sees fit.

if that's ok with you then i can send the chapters on to you.

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] Introduction and Questions

[Jeremy Singher]

> not micro-ops, *actual* scalar add ops.

I think we just have different terminology for this. To me, a micro-op
is the smallest unit of compute that is passed through a pipeline, and
a micro-op could indicate that the core should perform a scalar add
op. I'm happy with your explanation, though, thank you.

> it's basically c macros... applied to hardware.

Good analogy, thanks. The one concern I have is that this "vector op
fission" approach will pump the pipeline with tons and tons of
scalar-ops, while a traditional vector execution engine would not
deconstruct the vector instruction into many scalar instructions.

Does the vector pipeline use ALL the same execution resources as the
scalar pipeline? The same issue queues, functional units, read ports,
writeback paths?

> > How does the scoreboard handle a WAW hazard... two instructions
> > writing the same register? Does the second instruction wait for the
> > first to finish?

> sigh over a year ago i understood this enough to be able to answer.
> what we will have to do is simply ignore the optimisation opportunity.

Hmmm, ignoring WAW will significantly limit the ability of the core to
exploit ILP, which is one of the fundamental reasons for going OOO.

> no it does not.  you will need to state that you are happy to give
> credit if you use the book chapters, and that if you pass them on you
> will likewise ask the recipient to guarantee that they also will give
> credit to Mitch Alsup.

Of course, I'm glad to have the conditions of use AOT. Its incredibly
annoying when one is provided some information, only for the provider
of the info to come back months later and tell you "Remember that
document I sent you, yeah, make sure you never reference it in any
published work ever".

> Here are the chapters.

Thanks, Yehowshua.

Best,
Jeremy

On Fri, May 15, 2020 at 3:48 PM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> On Fri, May 15, 2020 at 11:15 PM Jeremy Singher <thejsingher@gmail.com> wrote:
> >
> > > it's basically a Cray Vector Loop
> > > (VL) except that VL, when set, actually *PAUSES* the Program Counter,
> > > and issues MULTIPLE instructions - using the one at the PC as a
> > > "template" - but incrementing the operand register numbers
> > > sequentially on each iteration of the loop from 0 to VL-1.
> >
> > So if you decode a vadd instruction, with VL=4, and a 1-wide pipeline,
> > the design would stall instruction fetch, and issue 4 "scalar" add
> > micro-ops with incrementing register indices?
>
> not micro-ops, *actual* scalar add ops.
>
> > That seems like it
> > should work, although you would lose the ability to exploit vector
> > chaining, since pausing the PC would prevent additional instructions
> > after the vector instruction from getting issued.
>
> nope :)  because the Out-of-Order scoreboard takes care of them.
> they're *literally* simply as if you had had 4x (or 8x, or 12x, or
> 16x) scalar ADD multi-issue instructions shoved into the execution
> engine.
>
> any following 4x instructions (or however many) *will* still have the
> register numbers - different or otherwise - and thus *will* have the
> Read and Write Dependency Hazard tracking applied to them.
>
> it's basically c macros... applied to hardware.
>
> > I looked a SimpleV a
> > while ago, and to me it seemed like the difference vs a normal vector
> > architecture was that SimpleV merged the vector and integer register
> > files.
>
> no, it's waaay more than that.
>
> > > this has "implicit"
> > > register-renaming automatically built-in to the design.  these are the
> > > Function Unit operand latches.  they are best termed "nameless
> > > registers" rather than "register-renaming".
> >
> > I think I understand what you are saying, my terminology for this is
> > that the core is "renaming" registers into what you call inflight
> > "nameless registers". At the end of the day, the point is that
> > register data is stored not just in a logical register file,
>
> correct... it is "in flight".  the distinction is important because a
> lot of people try
> to *explicitly* add register-renaming hardware, register caches, and *actually*
> rename the registers by providing a PRF-ARF (physical / architectural)
> register file naming scheme.
>
> we maaay have to do that (because we will have a 128 entry regfile and
> the Dependency Matrices need to be of the size of the actual regs in use).
>
> however it will be to *DOWNSIZE* the register numbers... *NOT* "upsize"
> them as is normally done with e.g. x86.
>
> > and that
> > the scheduler can aggressively execute instructions OOO when their
> > operands are available, instead of in serializing execution in program
> > order.
>
> correct.
>
> > How does the scoreboard handle a WAW hazard... two instructions
> > writing the same register? Does the second instruction wait for the
> > first to finish?
>
> sigh over a year ago i understood this enough to be able to answer.
> what we will have to do is simply ignore the optimisation opportunity.
>
> > > Mitch Alsup had to write two
> > > additional chapters, as an addendum to James Thornton's book, "Design
> > > of a Computer", in order to correct Patterson's misinformation.
> >
> > Do you have a link to the addendum? I have a pdf of the book, but it
> > doesn't seem to have the addendum.
>
> no it does not.  you will need to state that you are happy to give
> credit if you use the book chapters, and that if you pass them on you
> will likewise ask the recipient to guarantee that they also will give
> credit to Mitch Alsup.
>
> these are the conditions under which i received the book chapters from
> Mitch Alsup, and, as the Copyright holder, he is entitled to request
> any conditions that he sees fit.
>
> if that's ok with you then i can send the chapters on to you.
>
> 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 mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction and Questions

[Luke Kenneth Casson Leighton]

On Sat, May 16, 2020 at 12:49 AM Jeremy Singher <thejsingher@gmail.com> wrote:
>
> > not micro-ops, *actual* scalar add ops.
>
> I think we just have different terminology for this. To me, a micro-op
> is the smallest unit of compute that is passed through a pipeline, and
> a micro-op could indicate that the core should perform a scalar add
> op. I'm happy with your explanation, though, thank you.

:)  allow me to explain for the benefit of future readers.  these discussions
are archived and thus the list is an informational resource for others.

we do intend to do micro-ops.  this because we will be sharing the MUL and
DIV *integer* pipeline(s) with the FP MUL and FP DIV pipelines.

apart from that, there is a direct and one-to-one direct correspondance
between "POWER9 instruction" and what is termed "micro-ops".

that said, microwatt did some really clever munging, which we followed exactly.
so i saaay "direct", but... technically... now that i think about it,
you're correct.

an example:

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/logical/main_stage.py;hb=HEAD

note there, OP_XOR, OP_OR, OP_AND, there's no "OP_NOR" or "OP_NAND"?
this is because the tables (see https://libre-soc.org/openpower/isatables/ which
we extracted from microwatt decode1.vhdl) have *pre-analysed* the operations
and mapped them down to:

* a pre-processing stage (bit-inversion of RA, selection of Carry=1/0/Carry_Reg)
* the main processing stage
* a post-processing stage (bit-inversion of output, setting of
Condition Register CR0)

we *believe* this is a reflection of the intent of the original
designers of POWER,
and the people who designed microwatt have been tracking POWER for 20 years.
many of them work for IBM Research.

so these are kiiinda micro-op'd... except actually what we did was: split those
3 phases into 3 separate combinatorial blocks which are re-used in multiple
pipeline stages.

> > it's basically c macros... applied to hardware.
>
> Good analogy, thanks. The one concern I have is that this "vector op
> fission" approach will pump the pipeline with tons and tons of
> scalar-ops,

i know, right? :)

> while a traditional vector execution engine would not
> deconstruct the vector instruction into many scalar instructions.

yes.  the only real place where there is cause for concern is on losing the
element-stride information from sequential LD/ST operations: see below.

> Does the vector pipeline use ALL the same execution resources as the
> scalar pipeline? The same issue queues, functional units, read ports,
> writeback paths?

yyyup :)

the only "problem" comes in the address-matching when looking to
merge a batch of LDs (or STs) into a single L1 cache-line read.
the address-matching if you lose the fact that the addresses were
originally element-strided and thus sequential, you get hit by a massive
power surge of over 1000 XOR gates to get that information back,
if you have 8 LD/ST CompUnits.

therefore the intention is to "mark" addresses as being sequential, if
they were auto-generated by an element-strided Vector-LD/ST, and
consequently, very few bits need to be examined to detect if the
address rolls over to a new L1 cache-line.

this is *literally* the only "unplanned" design optimisation that needs
to be added at the hardware level, just because of the decision to
jam as many scalar (element) operations into

> > > How does the scoreboard handle a WAW hazard... two instructions
> > > writing the same register? Does the second instruction wait for the
> > > first to finish?
>
> > sigh over a year ago i understood this enough to be able to answer.
> > what we will have to do is simply ignore the optimisation opportunity.
>
> Hmmm, ignoring WAW will significantly limit the ability of the core to
> exploit ILP, which is one of the fundamental reasons for going OOO.

we have a hell of a lot to get done in about 14 weeks, which is the
cutoff point at which we have to begin the actual layout.  our first primary
goal is to meet the Oct 2020 tapeout with "at least something functional".

after that, we can return to examining optimisations.  i have a way to
spot WAW, as well as a chain-elimination of all ongoing cascading
dependencies - it will just take me about an entire month to remember
it, and 3 months to implement it, and we don't have time to do that...
right now, this very minute.

for a 50 mhz proof-of-concept ASIC, i'm not going to worry about it.

> > no it does not.  you will need to state that you are happy to give
> > credit if you use the book chapters, and that if you pass them on you
> > will likewise ask the recipient to guarantee that they also will give
> > credit to Mitch Alsup.
>
> Of course, I'm glad to have the conditions of use AOT.

appreciated.  they are... absolutely fascinating, and extremely
informative, as well
as representing an advancement and significant simplification on how to do
OoO multi-issue designs.

it does have to be said that many Architects _have_ rediscovered the knowledge
from the original 6600, however with the majority of publicly-available designs
using *binary* Q-Tables, it becomes extremely difficult to do multi-issue on top
of binary-encoded Q-Tables.

one of the (many) insights that Mitch provided was that if you convert
the Q-Tables
to an *unary* array, you can perform transitive RaW/WaR/WaW cascade bit-setting
of the register vector numbers across multiple instructions in any
given multi-issue
batch, and thus, with simple single-bit OR and AND gates, throw
multiple instructions
into the Dependency Matrices and have their order still be correctly
preserved in
the Dependency Matrices DAGs.

in addition to that, the chapters describe how to implement Precise Exceptions
on top of a 6600 design.  it's real simple.  i leave it to you to read up on.

the only thing you need to be aware of is that the design concept described in
Chapter 11 is faulty (the one that removes the FU-FU Matrix and replaces it
with a big NOR gate).  it unfortunately took Mitch and I about 3-4 months of
discussion (and implementation) to detect this error.

the description in chapter 10 however is perfectly functional.

*be aware* also that the gate-level diagrams for the FU-Regs, FU-FU
Matrices, and for the Computation Units *require* that certain operations
take place on the RISING edge of CLK, whilst others take place on the
FALLING edge of CLK.

if this is not borne in mind, the diagrams look faulty and will not work if
implemented as-is on a "normal" (rising edge) modern HDL clock design.
i converted the code in libre-soc to work *solely* on the RISING edge.

> Its incredibly
> annoying when one is provided some information, only for the provider
> of the info to come back months later and tell you "Remember that
> document I sent you, yeah, make sure you never reference it in any
> published work ever".

:)

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] Introduction and Questions

[Staf Verhaegen]

[-- Attachment #1.1: Type: text/plain, Size: 686 bytes --]

Jeremy Singher schreef op vr 15-05-2020 om 16:49 [-0700]:
> 
> > 
> > sigh over a year ago i understood this enough to be able to answer.
> > what we will have to do is simply ignore the optimisation opportunity.
> 
> 
> Hmmm, ignoring WAW will significantly limit the ability of the core to
> exploit ILP, which is one of the fundamental reasons for going OOO.

I've wondered about this myself. Can you give concrete example of where
not supporting a WAW hazard blocks ILP ?
I am asking because just a WAW hazard could be easily avoided by a good
peep hole optimizer in software because it would see that the output of
the first write is never used.

greets,
Staf.


[-- Attachment #2: Type: text/plain, Size: 177 bytes --]

_______________________________________________
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] Introduction and Questions

[Staf Verhaegen]

[-- Attachment #1.1.1: Type: text/plain, Size: 1267 bytes --]


Op 16/05/2020 om 11:47 schreef Staf Verhaegen:
> Jeremy Singher schreef op vr 15-05-2020 om 16:49 [-0700]:
>>
>> Hmmm, ignoring WAW will significantly limit the ability of the core to
>> exploit ILP, which is one of the fundamental reasons for going OOO.
> I've wondered about this myself. Can you give concrete example of where
> not supporting a WAW hazard blocks ILP ?
> I am asking because just a WAW hazard could be easily avoided by a good
> peep hole optimizer in software because it would see that the output of
> the first write is never used.

Ok after some reflection I do see the most possible performance
difference in procedures calls. Most of the time in procedures some
scratch registers are pushed on the stack at entering.

Assume a write to a scratch register is still pending when doing a
procedure. With real register renaming the register stack push does not
need to block until write to register is complete, if it doesn't the
register push will block.

The question is special hardware provision need to be done to optimize
this case or if one would rely on proper inlining of functions by the
compiler for performance critical code. Personally I don't see a problem
with relying on the latter.

greets,
Staf.



[-- Attachment #2: Type: text/plain, Size: 177 bytes --]

_______________________________________________
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] Introduction and Questions

[Luke Kenneth Casson Leighton]

(appreciate the compiler analysis, Staf.)

On Saturday, May 16, 2020, Staf Verhaegen <staf@fibraservi.eu> wrote:

>
> Assume a write to a scratch register is still pending when doing a
> procedure. With real register renaming the register stack push does not
> need to block until write to register is complete, if it doesn't the
> register push will block.


fortunately if there are enough Function Units (their operand and result
latches being "storers of in-flight registers without any names"), the
pipelines can continue to produce results, and if there is an operand
forwarding bus the scratch register result can be passed on to other FUs to
continue further work - none of which hits the Register File... yet - all
without stalling.

it has been a year so the details are a little hazy, however i seem to
recall that a WaW with enough FunctionUnits plus operand forwarding will
just have a small one clock cycle penalty of the extra regfile write that
could be optimised out.

not, "total catastrophic performance drop".

the optimisation if i recall correctly involved detecting, at the
Dependency Matrices, that there was not only no reader of a given register
waiting for the result, but that there was an outstanding write as well.

i.e. WaW can only be optimised away if there is no reader *in between* the
two writes.

i.e. if there is W R W you cannot throw away the 1st W until the R has
happened.

this requires tracking of multiple Ws per register actually at the
Dependency Matrices, and that means literally doubling or tripling the size
of the matrices which are already going to be enormous.

hence why the decision was taken to shelve that one for later as it is the
kind of thing that matters for high performance.

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] Introduction and Questions

[Jeremy Singher]

> Ok after some reflection I do see the most possible performance
> difference in procedures calls. Most of the time in procedures some
> scratch registers are pushed on the stack at entering.

Its actually a performance difference on more cases than this. In the
case of W R W R sequence to the same register, the second Write should
be allowed to proceed before the first Write is executed, which also
unblocks the second R.


On Sat, May 16, 2020 at 4:31 AM Staf Verhaegen <staf@fibraservi.eu> wrote:
>
>
> Op 16/05/2020 om 11:47 schreef Staf Verhaegen:
> > Jeremy Singher schreef op vr 15-05-2020 om 16:49 [-0700]:
> >>
> >> Hmmm, ignoring WAW will significantly limit the ability of the core to
> >> exploit ILP, which is one of the fundamental reasons for going OOO.
> > I've wondered about this myself. Can you give concrete example of where
> > not supporting a WAW hazard blocks ILP ?
> > I am asking because just a WAW hazard could be easily avoided by a good
> > peep hole optimizer in software because it would see that the output of
> > the first write is never used.
>
> Ok after some reflection I do see the most possible performance
> difference in procedures calls. Most of the time in procedures some
> scratch registers are pushed on the stack at entering.
>
> Assume a write to a scratch register is still pending when doing a
> procedure. With real register renaming the register stack push does not
> need to block until write to register is complete, if it doesn't the
> register push will block.
>
> The question is special hardware provision need to be done to optimize
> this case or if one would rely on proper inlining of functions by the
> compiler for performance critical code. Personally I don't see a problem
> with relying on the latter.
>
> greets,
> Staf.
>
>
> _______________________________________________
> 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 mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] Introduction and Questions

[Luke Kenneth Casson Leighton]

On Sat, May 16, 2020 at 9:34 PM Jeremy Singher <thejsingher@gmail.com> wrote:

> > Ok after some reflection I do see the most possible performance
> > difference in procedures calls. Most of the time in procedures some
> > scratch registers are pushed on the stack at entering.
>
> Its actually a performance difference on more cases than this. In the
> case of W R W R sequence to the same register, the second Write should
> be allowed to proceed before the first Write is executed, which also
> unblocks the second R.

in a strict historically-accurate 6600 (which we are not doing), it would block
at that 2nd W.

in the precise-augmented 6600-like design, the Operand Forwarding Bus
would provide the means for the second W to communicate the required
result to the 2nd R, allowing it to proceed, because Operand Forwarding
Buses provide the extra missing path that is not in the *original* 6600
that makes the register data paths functionally identical to a Common
Data Bus.

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] Introduction and Questions

[Staf Verhaegen]

[-- Attachment #1.1: Type: text/plain, Size: 649 bytes --]

Yehowshua schreef op vr 15-05-2020 om 15:33 [-0400]:
> 
> Realistically, for our first tapeout(we’re using Google’s shuttle service on 1800nm TSMC),
> we’d do a CPU with no vector instructions(effectively no GPU) for October.

Small correction, the 0.18um TSMC shuttle tape-outs are using the 
Europractice service.
In future very likely an open 0.13um PDK becomes available and some
Google sponsored shuttle service will likely be available but it will
have strict restrictions on area and pin count. When information is
public it will then need to be investigated if it can be used for
Libre-SOC prototyping.

greets,
Staf.


[-- Attachment #2: Type: text/plain, Size: 177 bytes --]

_______________________________________________
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] Introduction and Questions

[Luke Kenneth Casson Leighton]

On Saturday, May 16, 2020, Staf Verhaegen <staf@fibraservi.eu> wrote:

> Yehowshua schreef op vr 15-05-2020 om 15:33 [-0400]:
> >
> > Realistically, for our first tapeout(we’re using Google’s shuttle
> service on 1800nm TSMC),
> > we’d do a CPU with no vector instructions(effectively no GPU) for
> October.
>
> Small correction,


thank you Staf.


>
> the 0.18um TSMC shuttle tape-outs are using the
> Europractice service.


In future very likely an open 0.13um PDK becomes available


>

-- 
---
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] Introduction and Questions

[Yehowshua]

> 4. What is the right way to get started contributing? My experience is with
> Verilog, and I've looked at other languages too, including BSV and Chisel.
> I'm primarily interested in developing microarchitecture for
> performance-critical components, like branch predictors, prefetchers,
> instruction schedulers, and load-store units. Ideally, I could contribute
> my work as part of graduate studies to this project.


Start by reading through section 5.1 here:

https://libre-soc.org/ <https://libre-soc.org/>

There should be some instructions to get you started with the codebase.

_______________________________________________
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] Introduction and Questions

[Luke Kenneth Casson Leighton]

hiya jeremy just coming back to respond to the original message you wrote,
covering things we missed. yes lots of questions, therefore lots of answers
:)

On Friday, May 15, 2020, Jeremy Singher <thejsingher@gmail.com> wrote:

> Hi all,
>
> My name is Jeremy Singher. I'm a graduate student studying computer
> architecture, interested in open-source hardware and high performance
> microarchitectures. I am looking for an open-source hardware project I can
> contribute to through the course of my graduate studies,


great to hear.  we've established that you know a heck of a lot about
out-of-order design and i could really use some help with the precise
scoreboard system and the FSMs in the Computation Units.

you may have noticed that we have funding from NLNet.  therefore if you
complete a task on the pre-agreed list, you receive a donation from NLNet
for doing so. http://libre-doc.org/nlnet

i.e we are not expecting you to help "for free", ok? :)


> 1. It seems like you guys are building various components of an
> out-of-order microarchitecture, such as the scoreboard, and load-store
> ordering units. Do you have a complete microarchitecture diagram of the
> core (or a text description)?


it is pieces, from notes, often drawn as gate level diagrams.  more get
added as they happen, and they are more aide-memoire that we wish to expand
to full technical design documentation.

example, today, i plan to draw out the register port allocations to the
Function Units.  in the 180nm version there will be at least... 10
different types of FUs, each with radically different register port
allocations (!). i need to document those.

some of them are as high as 5 in, 3 out.  fortunately they are across
multiple different regfiles (we treat SPRs, Condition Regs, INT and FP as
completely different and consequently the FU port requirements are not as
deeply scary as they first sound: we do not need to go above 4R1W for any
one actual regfile)

also in particularly involved cases i have done youtube videos
http://youtube.com/user/lkcl and look at libresoc playlist.

see http://libre-soc.org/3d_gpu/architecture and drill down the levels
there.


 I could find bits and pieces on specific
> components,


this because that is our current focus.


> but I'm interested in details like pipeline width,


>
 the 180nm ASIC will likely have around... 20 separate and distinct
(parallel) Function Unit entry points into around... 10 to 12 types of
pipeline.

for a 180nm ASIC that is one hell of a lot.

for the Quad Core dual issue version that will jump to around... 28.



depth,
> branch-to-branch latency, load-use delay, etc.


we are literally in the process of assembling the pieces, for the 180nm
test chip.  consequently this is becoming apparent as each piece is put
together.

in other words we are right at the point where your help could define some
of those characteristics.



> 2. Is the SoC at a state at which I can evaluate performance on simple
> benchmarks in simulation?


as a python-based project we have a huge number of unit tests, you either
run them directly or you use nosetests3

we are still constructing building blocks (rapidly) so consequently the
individual tests are the focus of developer attention.


>  Other similar open-source hardware projects have
> make targets to launch verilator simulations, but I could not find an
> equivalent in your repos (although I probably am just bad at looking).


those will be added when compilation of the whole chip is ready to do so.
FPGA targets etc. these will indeed go at the top level.

however as we use a python-based HDL, python practices apply and that
typically means "python3 setup.py test" or "nosetests3" more than it means
"make test" although that i think was added into the soc top level Makefile.


> 3. What is your target performance in terms of an established benchmark
> like Coremark, Dhrystone, Embench, or SPEC?


really hard to tell right now. the primary focus is more on designing
something that is GPU Capable.  that is such a high performance and data
requirement that i think high SPEC etc figures will inherently drop out.



>  I'm trying to compare the
> merits and progress of various hardware projects out-there.


this one is... the reasons why we are all here are not technical ones,
although it is fascinating but deeply challenging work.

the driving reasons are that there are no SoCs out there at this level of
dedign capability (quad core dual issue SMP and 3D and VPU, and there is no
reason why we should not try quad or 6 issue, and 1.5 ghz and above, later)
that have a full Libre Software stack, intended right from the start for
100 million and above mass volume end user markets.

however even that masks a simpler way to put it:

we're giving citizens back Sovereign control over their computing devices.

if that sounded "merely" cool about 4 months ago, you will be keenly aware
with a little thought and analysis of the world news that that is now not
just cool, it is deeply *urgent*.

no other Libre project is creating an end-user product with a built in
*Libre* GPU and VPU for use in mass volume products.

* SiFive joined forces with ImgTec to use PowerVR. why on earth they did
this when ImgTec has such a dreadful reputation we will never know.

* MIAOW is a SIMT engine, not an actual GPU. there are no Texture opcodes,
nothing like that: they implemented a very small subset of the AMDGPU ISA,
basically.

* Nyuzi is an academic exercise demonstrating why Larrabee was not adequate
as a GPU. it was highly successful in this regard.

* GPLGPU is not actually GPL licensed (its author augmented the GPL, making
it a proprietary license), and it is based on PLAN9 which was a fixed
function (non-shader) design concept anyway.

therefore, even a Libre *GPU* does not exist that can meet commercial
power-performance expectations of today's markets.



> 4. What is the right way to get started contributing?


next step is probably to read http://libre-soc/HDL_workflow to get a feel
for how to get started, what the interaction and development flow is.


>  My experience is with
> Verilog, and I've looked at other languages too, including BSV and Chisel.


just follow the process step by step on the front page.  you did step 1 :)
"join list, say hello".

if you are not immediately familiar with nmigen there are tutorials the
best one is by robert baruch
https://github.com/RobertBaruch/nmigen-tutorial/blob/master/README.md

from there we're happy to give you a small (useful) task, like this:
https://bugs.libre-soc.org/show_bug.cgi?id=316

even just reading that, you will see some of the gotchas to expect.

btw, Cole a few months ago knew virtually nothing about software
development, or linux, or hardware, or python. or git.  for a total
beginner and i do mean total, he's doing really well. i'm kinda seriously
impressed.


I'm primarily interested in developing microarchitecture for
> performance-critical components, like branch predictors, prefetchers,
> instruction schedulers, and load-store units.


goood.  because those are exactly the things that we need help with, quite
urgently.



Ideally, I could contribute
> my work as part of graduate studies to this project.


fantastic.  remember: and receive donations from NLNet for doing so :)

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