* [libre-riscv-dev] GItlab For SOC repo @ 2020-05-02 18:45 Yehowshua 2020-05-02 18:47 ` Yehowshua 2020-05-02 19:30 ` [libre-riscv-dev] GItlab For SOC repo Luke Kenneth Casson Leighton 0 siblings, 2 replies; 6+ messages in thread From: Yehowshua @ 2020-05-02 18:45 UTC (permalink / raw) To: Libre-RISCV General Development 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [libre-riscv-dev] GItlab For SOC repo 2020-05-02 18:45 [libre-riscv-dev] GItlab For SOC repo Yehowshua @ 2020-05-02 18:47 ` Yehowshua 2020-05-03 4:49 ` [libre-riscv-dev] experimental code & monorepo Jacob Lifshay 2020-05-02 19:30 ` [libre-riscv-dev] GItlab For SOC repo Luke Kenneth Casson Leighton 1 sibling, 1 reply; 6+ messages in thread From: Yehowshua @ 2020-05-02 18:47 UTC (permalink / raw) To: Libre-RISCV General Development 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [libre-riscv-dev] experimental code & monorepo 2020-05-02 18:47 ` Yehowshua @ 2020-05-03 4:49 ` Jacob Lifshay 2020-05-03 11:02 ` Luke Kenneth Casson Leighton 0 siblings, 1 reply; 6+ messages in thread From: Jacob Lifshay @ 2020-05-03 4:49 UTC (permalink / raw) To: Libre-RISCV General Development 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [libre-riscv-dev] experimental code & monorepo 2020-05-03 4:49 ` [libre-riscv-dev] experimental code & monorepo Jacob Lifshay @ 2020-05-03 11:02 ` Luke Kenneth Casson Leighton 2020-05-06 0:08 ` Jacob Lifshay 0 siblings, 1 reply; 6+ messages in thread From: Luke Kenneth Casson Leighton @ 2020-05-03 11:02 UTC (permalink / raw) To: Libre-RISCV General Development --- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [libre-riscv-dev] experimental code & monorepo 2020-05-03 11:02 ` Luke Kenneth Casson Leighton @ 2020-05-06 0:08 ` Jacob Lifshay 0 siblings, 0 replies; 6+ messages in thread From: Jacob Lifshay @ 2020-05-06 0:08 UTC (permalink / raw) To: Libre-RISCV General Development 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [libre-riscv-dev] GItlab For SOC repo 2020-05-02 18:45 [libre-riscv-dev] GItlab For SOC repo Yehowshua 2020-05-02 18:47 ` Yehowshua @ 2020-05-02 19:30 ` Luke Kenneth Casson Leighton 1 sibling, 0 replies; 6+ messages in thread From: Luke Kenneth Casson Leighton @ 2020-05-02 19:30 UTC (permalink / raw) To: Libre-RISCV General Development 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, back to index Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-02 18:45 [libre-riscv-dev] GItlab For SOC repo Yehowshua 2020-05-02 18:47 ` Yehowshua 2020-05-03 4:49 ` [libre-riscv-dev] experimental code & monorepo Jacob Lifshay 2020-05-03 11:02 ` Luke Kenneth Casson Leighton 2020-05-06 0:08 ` Jacob Lifshay 2020-05-02 19:30 ` [libre-riscv-dev] GItlab For SOC repo Luke Kenneth Casson Leighton
Libre RISC-V Mailing list Archives (accessible via public-inbox) Archives are clonable: git clone --mirror https://inbox.libre-soc.org/libre-riscv-dev Example config snippet for mirrors AGPL code for this site: git clone https://public-inbox.org/public-inbox.git
