[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 at gmail.com> wrote:
>
> On Sat, May 2, 2020, 11:47 Yehowshua <yimmanuel3 at 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.