[libre-riscv-dev] GItlab For SOC repo

[libre-riscv-dev] GItlab For SOC repo

[Yehowshua]

Are we currently using a gitlab mirror on our SOC repo?
I saw a ciyaml there…

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] GItlab For SOC repo

[Yehowshua]

Also - we have some experimental files in the SOC repo.
I think it is a good practice to make an experimental branch instead.

Thoughts?

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] GItlab For SOC repo

[Luke Kenneth Casson Leighton]

On Saturday, May 2, 2020, Yehowshua <yimmanuel3@gatech.edu> wrote:

> Are we currently using a gitlab mirror on our SOC repo?


yes.  partly.   it's for CI running on salsa.




> I saw a ciyaml there…
>
> Yehowshua
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>


-- 
---
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

[libre-riscv-dev] experimental code & monorepo

[Jacob Lifshay]

On Sat, May 2, 2020, 11:47 Yehowshua <yimmanuel3@gatech.edu> wrote:

> Also - we have some experimental files in the SOC repo.
> I think it is a good practice to make an experimental branch instead.


> Thoughts?
>

We really should move all code that's not actually used in the final soc to
its own folder or branch -- currently, there is lots of unused code that
either was used in the past or we intend to eventually use or even never
intended to use (lots of minerva and some of the FP code) and was only ever
reference code to base our new code on. All of that makes it very confusing
to newcomers and partially confusing for people who aren't newcomers
anymore -- I myself couldn't point out with any degree of certainty all the
code that we actually intend to use even though I've been here longer than
nearly everyone else.

Additionally, I'd advocate for all HDL code (at least soc, ieee754fpu, and
nmutil) to be moved to one repo (especially including the data files
currently hosted on the wiki -- libre-soc.org shouldn't need to be
online/accessible to build if someone gets the git repos some other way)
and using submodules for often updated external dependencies (nmigen at
least), since that helps tie all the code together so one commit id is
sufficient to describe the state of all the code that's tightly
interconnected. See LLVM switching to a monorepo for an example of how this
is a good idea.

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] experimental code & monorepo

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sun, May 3, 2020 at 5:49 AM Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> On Sat, May 2, 2020, 11:47 Yehowshua <yimmanuel3@gatech.edu> wrote:
>
> > Also - we have some experimental files in the SOC repo.
> > I think it is a good practice to make an experimental branch instead.
>
>
> > Thoughts?
> >
>
> We really should move all code that's not actually used in the final soc to
> its own folder or branch -- currently, there is lots of unused code that
> either was used in the past or we intend to eventually use or even never
> intended to use

sigh this is because we were planning to use RISC-V and consequently,
planning ahead, developed and droppedin a ton of code *specifically*
intended to meet RISC-V MMU requirements for SMP cache-coherent
systems.

i've moved two directories into "unused".  a better name can be chosen later

> (lots of minerva

all of minerva

> and some of the FP code)

there definitely should not be *any* FP-related code in the soc repo.
this is deliberate at the moment


> and was only ever reference code to base our new code on.

no, the reason i dropped minerva into the tree was to *use* that code,
not to "base" our new code on.  definitely not as "reference code to
look at".  actually move or copy that code *out* of the minerva
subdirectory and *adapt* it.

to save a huge amount of time (which we do not have spare to write our
own code), this is still the plan for the entire L1 cache
infrastructure down to the wishbone interfaces, as outlined in the
bottom half of this diagram:

https://libre-soc.org/3d_gpu/180nm_single_core_testasic_memlayout.jpg


* modifying the L1 cache width to 128 bits,
* doubling them up (odd/even, addressable by addr[4]),
* splitting to dual 64-bit interfaces on the output (to meet Wishbone
requirements)
* and locating a suitable Wishbone Arbiter for the purpose of merging
the *four* resultant 64-bit interfaces onto the one 64-bit Wishbone
Bus.

the reason for doing this is as i said i think yesterday, is to save a
huge amount of time (which we *do not have spare*) and to make use of
the Minerva L1 Cache Formal Correctness Proof (which we likewise do
not have the time to replicate)

with no time left to add dual RISC-V support, other than support
modules for the L1 cache code (wishbone utils) the rest of the minerva
code can be discarded.


> All of that makes it very confusing
> to newcomers and partially confusing for people who aren't newcomers
> anymore -- I myself couldn't point out with any degree of certainty all the
> code that we actually intend to use even though I've been here longer than
> nearly everyone else.

you've been focussing on Kazan, which is great.

i _have_ been sending messages to the list (and also through the
bugtracker), describing what i'm doing (and why) - generally i do not
receive a response.

the reason for sending those messages was to give people an
opportunity to review and follow the code.  if people had responded
with questions, there would be less confusion right now because any
issues would have been cleared up at the time.

that said, i appreciate that it's complex code.

in effect, what we have here is: we're not really working together as
a team.  we're not collaborating: we're working in isolation on
separate components, very rarely interacting.

we're now seriously under time pressure: i count approximately 15
weeks before we have to begin the coriolis2 layout.

that's 15 weeks... *in which to complete the entire design*, by
approximately mid-august.

so we *have* to start working together, make as much use of
pre-existing code as possible, and cut some serious draconian corners
on what actually goes into the test chip.

i'd welcome some discussion on how to proceed here.


> Additionally, I'd advocate for all HDL code (at least soc, ieee754fpu, and
> nmutil) to be moved to one repo

see below

> (especially including the data files
> currently hosted on the wiki -- libre-soc.org shouldn't need to be
> online/accessible to build if someone gets the git repos some other way)

that's been changed (as intended, thank you michael) to use the git
submodule version rather than http get.  submodules has been a
nuisance (already) so i'm inclined to agree that not using them for
the .csv (and even the pseudocode .mdwn) is a good idea.

what to replace it with: there's no good options here.


> and using submodules for often updated external dependencies (nmigen at
> least),

the experience we've had - already - of using submodules is a royal
pain in the neck.  commits which involve changing of files *and*
changing submodules do *not* merge properly, and i actually had to use
rebase --skip for the first time - ever - in order to recover the
repository.  this lost some work by michael.

i'm inclined to suggest (as we discussed on the coriolis2 bug,
briefly) that an *independent* top-level repo be created that "joins"
*all* source code - and tools - together.  this to *never*, under any
circumstances, have actual files added to it (with the exception of a
README, saying "please read documentation at location X and please do
not edit this file further").

> since that helps tie all the code together so one commit id is
> sufficient to describe the state of all the code that's tightly
> interconnected. See LLVM switching to a monorepo for an example of how this
> is a good idea.

if the IEEE754 FP code had not been designed - from the start - to be
a general-purpose independent library and toolkit, i would agree
immediately with that.

however it was never intended - ever - right from the start - to be a
specific hard-coded isolated our-use-only FP library.  likewise
nmutil, by virtue of it mirroring the Chisel library from which we got
the Queue class.

this helped us to get additional funding and make the case for the
project being valuable *outside* of the scope of what we are doing, to
a wider community, and helps strengthen NLNet's role as a valuable
backer of Hardware/Software Libre.

nmutil then falls naturally into the category of being useful by
*both* repositories, and that's exactly as it's supposed to be.

all three are therefore actually independent projects.  putting their
source into a single repository has detrimental implications.  it also
results in confusion about what the roles of each of those three
independent projects is.

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] experimental code & monorepo

[Jacob Lifshay]

On Sun, May 3, 2020 at 4:03 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> On Sun, May 3, 2020 at 5:49 AM Jacob Lifshay <programmerjake@gmail.com> wrote:
> >
> > Additionally, I'd advocate for all HDL code (at least soc, ieee754fpu, and
> > nmutil) to be moved to one repo
>
> > and using submodules for often updated external dependencies (nmigen at
> > least),
>
> the experience we've had - already - of using submodules is a royal
> pain in the neck.  commits which involve changing of files *and*
> changing submodules do *not* merge properly, and i actually had to use
> rebase --skip for the first time - ever - in order to recover the
> repository.  this lost some work by michael.

One potential workaround would be to have a server-side git hook that
rejects commits that have changes to a submodule and other files
(other than .gitmodules) in the same commit.

> i'm inclined to suggest (as we discussed on the coriolis2 bug,
> briefly) that an *independent* top-level repo be created that "joins"
> *all* source code - and tools - together.  this to *never*, under any
> circumstances, have actual files added to it (with the exception of a
> README, saying "please read documentation at location X and please do
> not edit this file further").

That could work, but would be difficult to use when developing code.

> > since that helps tie all the code together so one commit id is
> > sufficient to describe the state of all the code that's tightly
> > interconnected. See LLVM switching to a monorepo for an example of how this
> > is a good idea.
>
> if the IEEE754 FP code had not been designed - from the start - to be
> a general-purpose independent library and toolkit, i would agree
> immediately with that.
>
> however it was never intended - ever - right from the start - to be a
> specific hard-coded isolated our-use-only FP library.
>
> <snip>
>
> all three are therefore actually independent projects.  putting their
> source into a single repository has detrimental implications.  it also
> results in confusion about what the roles of each of those three
> independent projects is.

That's seems to work out just fine and even be outright beneficial for
LLVM, where they have many loosely associated libraries/programs all
in the same git repo.

A short list of projects that are mostly unrelated to each other but
are still in the LLVM monorepo:

clangd: a LSP server for adding C++ language support to IDEs
lldb: a interactive debugger
flang: a FORTRAN frontend for LLVM
libc: a WIP C standard library
mlir: a IR originally designed for machine learning, but is now quite
a bit more generic
yaml2obj: a program that converts a YAML description of an object file
to the binary form

Basically all of them can (and are) used nearly independently of the rest.

As long as we state so in all the readmes and other docs, it should be
pretty unambiguous that ieee754fpu can be used independently of most
of the rest of our code. We could even provide a read-only git repo
that mirrors the ieee754fpu directory.

Jacob

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