Hello, I have noticed lowRISC git repo doesn't rely on rocket-chip <https://github.com/freechipsproject/rocket-chip> and has forked some sub-modules from github.com/ucb-bar/ git repos (like hardfloat), this makes sense. However, for rocket core, it seems UCB removed the sub-module repo from rocket-chip parent repo in July and also the rocket git repo itself is no longer accessible https://github.com/ucb-bar/rocket/ As far as I understand, lowRISC will continue on its own generator, but I think Rocket core has become different from the one used in rocket-chip master branch: https://github.com/freechipsproject/rocket-chip/blob/master/src/main/scal... I believe this will make lowRISC difficult to maintain, and missing new features (like AMOs). most importantly, it will make understanding differences between rocket-chip project and lowRISC difficult. Can you please elaborate on the strategy lowRISC will re-use components from rocket-chip?

Hello Alex, Thank you for the prompt explanation, I checked out the "update" branch and it seems to me following the upstream codebase from rocket-chip is getting tedious. Getting git workflow right isn't easy indeed, UCB Boom project opted for a slightly obvious strategy which is forking rocket-chip into a branch of their own in which they include their git repo as a sub-module. https://github.com/ucb-bar/riscv-boom I'm not sure whether this would work for lowRISC because there is already history in a different structure (in addition to using a SystemVerilog top-level). One option would be to include rocket-chip as a submodule, which will make updates a bit easier and more visible to "outsiders". Regarding AXI, I think there is already an AMBA (AXI4/AHB-lite/APB) package within Rocket-chip project as it's being migrated to use AXI too. I have no idea whether this would be considered an option for lowRISC, as it seems Chisel might not be "the" preferred option here. Best Regards, Ahmed Khalaf On Sat, Nov 11, 2017 at 5:20 PM, Alex Bradbury <asb(a)lowrisc.org&gt; wrote: > On 11 November 2017 at 14:58, Ahmed Khalaf <me(a)ahmedkhalaf.com&gt; wrote: >> Hello, >> >> I have noticed lowRISC git repo doesn't rely on rocket-chip >> <https://github.com/freechipsproject/rocket-chip> and has forked some >> sub-modules from github.com/ucb-bar/ git repos (like hardfloat), this > makes >> sense. >> >> However, for rocket core, it seems UCB removed the sub-module repo from >> rocket-chip parent repo in July and also the rocket git repo itself is no >> longer accessible >> https://github.com/ucb-bar/rocket/ >> >> As far as I understand, lowRISC will continue on its own generator, but I >> think Rocket core has become different from the one used in rocket-chip >> master branch: >> https://github.com/freechipsproject/rocket-chip/ > blob/master/src/main/scala/rocket/RocketCore.scala >> I believe this will make lowRISC difficult to maintain, and missing new >> features (like AMOs). most importantly, it will make understanding >> differences between rocket-chip project and lowRISC difficult. >> >> Can you please elaborate on the strategy lowRISC will re-use components >> from rocket-chip? > Hi Ahmed, thanks for the questions. We build on top of the upstream > Rocket codebase and aim to minimise differences where feasible. > Unfortunately, large-scale refactoring of the rocket-chip codebase has > made it quite difficult to stay in-sync. Wei has been incorporating > code from a more recent Rocket for the next lowRISC release, and you > can see this work in the 'update' branch of lowrisc-chip > https://github.com/lowRISC/lowrisc-chip/tree/update > > In general, we prefer to provide a SystemVerilog top-level, and to > make it as easy as possible to hook up SystemVerilog IP to the AXI > bus, with the aim of minimising the amount of Chisel you need to know > to get started. Integrating upstream changes is an ongoing challenge > and I don't think we've arrived at a final solution yet. In > particular, we do want to spend more time thinking about easy > configuration of the lowRISC SoC, including both the Rocket and minion > core subsystems. > > Best, > > Alex >

Hello again I agree it's isn't easy (nor needed at this point) to port/switch/migrate AXI related interconnects to a different implementation. The approach you mentioned is "agile" and make sense for lowRISC project, other issues are by far more important. like Ethernet interfacing. What I'm suggesting here is having a DRY structure by using baseline from rocket-chip repo (which already includes hardfloat and riscv-tools ..etc). I just remembered rocket-chip have a recommended template project that uses similar structure. https://github.com/ucb-bar/project-template <https://github.com/ucb-bar/project-template> Ideally, the aim of reuse is to maximize focus (and effort) in a project going into features (differentiating factors) by re-using Rocket and PULPino and the corresponding tool-chain and Linux infrastructure since both are FPGA+ASIC proven already. However, this needs to be enabled via a continuous integration strategy. From my point of view, the main drawbacks for the current structure I think at the moment are: 1- Lacking a clear baseline against rocket-chip, prevents me (as potential community) from understanding the differences and being able to efficiently navigate problems/design modifications: Because files are copied into lowRISC and modified, I need to figure out from which change-set does the rocket-chip files come then checkout the corresponding baseline/branch ..etc and diff the files. 2- Hindering the ability to update frequently, the more manual taking over updates from rocket core + linux stuff the more effort it requires Less frequent updates will make it more difficult to catch up with updates "exponentially" over time. 3- Reduced maintainability: ideally, all modifications/patches to rocket-chip shall be submitted back to rocket-chip project to allow configuration and/or contributing a fix/design change. otherwise, lowRISC will have to re-apply these changes with every update (or not .. manually). I'm mainly interested in lowRISC as FPGA based multi-core Linux-capable SMP SoC with interrupt I/O off-loading capabilities (via minion ..etc). Currently, this is not working as far as I understood through experimenting and from the issues on github: #51 when will lowRISC support SMP well [opened on Jun 8] <https://github.com/lowRISC/lowrisc-chip/issues/51> So, even if I wanted to contribute a fix to this issue for example .. I will have to spend significant time on irrelevant logistics just to know where we stand. If needed, please let me know if you agree to refactoring, I might be able to contribute to this effort. Thank you. Best Regards, Ahmed Khalaf On Sat, Nov 11, 2017 at 6:34 PM, Dr Jonathan Kimmitt <jrrk2(a)cam.ac.uk <mailto:jrrk2@cam.ac.uk>> wrote: Hi Ahmed, We several implementations of AXI, the premier one for Xilinx being the MIG dynamic memory interface generator. As long as we need that, there is no harm in using a variety of AXI components from the Xilinx subsystem. There is also the SOCIP subsystem which offers simplified functionality but limited configurability. Then there is the chisel version of AMBA in the rocket tree itself, however as a chisel neophyte I am not clear if we extract standalone AXI interfaces components from this. Finally there is the AXI infrastructure that is delivered as part of the Pulpino (Minion) infrastructure. This seems to me to have a lot of usage limitations also. If and when we get sufficient stability and momentum to make a real chip, we would have to see what components should be used in the ASIC. Regards, Jonathan On 11/11/17 15:54, Ahmed Khalaf wrote: Hello Alex, Thank you for the prompt explanation, I checked out the "update" branch and it seems to me following the upstream codebase from rocket-chip is getting tedious. Getting git workflow right isn't easy indeed, UCB Boom project opted for a slightly obvious strategy which is forking rocket-chip into a branch of their own in which they include their git repo as a sub-module. https://github.com/ucb-bar/riscv-boom <https://github.com/ucb-bar/riscv-boom> I'm not sure whether this would work for lowRISC because there is already history in a different structure  (in addition to using a SystemVerilog top-level). One option would be to include rocket-chip as a submodule, which will make updates a bit easier and more visible to "outsiders". Regarding AXI, I think there is already an AMBA (AXI4/AHB-lite/APB) package within Rocket-chip project as it's being migrated to use AXI too. I have no idea whether this would be considered an option for lowRISC, as it seems Chisel might not be "the" preferred option here. Best Regards, Ahmed Khalaf On Sat, Nov 11, 2017 at 5:20 PM, Alex Bradbury <asb(a)lowrisc.org <mailto:asb@lowrisc.org>> wrote: On 11 November 2017 at 14:58, Ahmed Khalaf <me(a)ahmedkhalaf.com <mailto:me@ahmedkhalaf.com>> wrote: Hello, I have noticed lowRISC git repo doesn't rely on rocket-chip <https://github.com/freechipsproject/rocket-chip <https://github.com/freechipsproject/rocket-chip>> and has forked some sub-modules from github.com/ucb-bar/ <http://github.com/ucb-bar/> git repos (like hardfloat), this makes sense. However, for rocket core, it seems UCB removed the sub-module repo from rocket-chip parent repo in July and also the rocket git repo itself is no longer accessible https://github.com/ucb-bar/rocket/ <https://github.com/ucb-bar/rocket/> As far as I understand, lowRISC will continue on its own generator, but I think Rocket core has become different from the one used in rocket-chip master branch: https://github.com/freechipsproject/rocket-chip/ <https://github.com/freechipsproject/rocket-chip/> blob/master/src/main/scala/rocket/RocketCore.scala I believe this will make lowRISC difficult to maintain, and missing new features (like AMOs). most importantly, it will make understanding differences between rocket-chip project and lowRISC difficult. Can you please elaborate on the strategy lowRISC will re-use components from rocket-chip? Hi Ahmed, thanks for the questions. We build on top of the upstream Rocket codebase and aim to minimise differences where feasible. Unfortunately, large-scale refactoring of the rocket-chip codebase has made it quite difficult to stay in-sync. Wei has been incorporating code from a more recent Rocket for the next lowRISC release, and you can see this work in the 'update' branch of lowrisc-chip https://github.com/lowRISC/lowrisc-chip/tree/update <https://github.com/lowRISC/lowrisc-chip/tree/update> In general, we prefer to provide a SystemVerilog top-level, and to make it as easy as possible to hook up SystemVerilog IP to the AXI bus, with the aim of minimising the amount of Chisel you need to know to get started. Integrating upstream changes is an ongoing challenge and I don't think we've arrived at a final solution yet. In particular, we do want to spend more time thinking about easy configuration of the lowRISC SoC, including both the Rocket and minion core subsystems. Best, Alex

Dear Dr. Jonathan, Thank you for the detailed explanation, it's indeed a tricky issue. Great news there on Ethernet, thanks for sharing .. I will definitely have a look on that branch, Ethernet networking is one of the most "wanted" features on RISC-V. I completely, agree rocket-chip repo is lacking important features and change management practices (similar to the ones lowRISC have) in order to enable cleaner reuse and update. Realistically, I understand that enabling continuous integration from upstream will not be seamless (at least not possible for next few releases after aiming for it). I believe it could be an achievable goal on longer-term and it requires pressure from rocket-chip users in order to push for the needed "configurability" and visibility. I think this is also aligned with the team in UC BAR vision to enable software best practices in hardware design domain as they describe in “the Chisel Plan” and I hope they would support such efforts. By continuous integration, I don't mean fully automatic build as in software .. for sure there needs to be "conflict reconciliation", but semi-structured integration strategy. With my limited knowledge I thought of directory structure, pointing to rocket-chip repo and having lowRISC changes on a branch (via fork if needed). This will make updates a bit easier but as you mentioned "portability" will be still a bit far. I believe this will enhance over time, SiFive had an interesting take on interconnect parameter negotiation with the "diplomacy" package making it possible for parameters to be "dynamically negotiated between modules" .. sorry, it's still a Chisel extension. I do appreciate the openness and ambitiousness lowRISC brings to the digital design ecosystem and I expect no less than a game changer like Raspberry Pi. Thank you very much. Regards, Ahmed Khalaf On Mon, Nov 13, 2017 at 3:01 PM, Dr Jonathan Kimmitt <jrrk2(a)cam.ac.uk <mailto:jrrk2@cam.ac.uk>> wrote: Dear Ahmed,   Thanks for raising this issue. There are several reasons why LowRISC lags behind the latest Rocket release. The primary target for Rocket as far as I am aware is a Zync board, where the Rocket works in conjunction with an ARM host. This does not suit our primary paradigm which is code execution security, since the ARM part of the IP cannot be modified. Hence our focus on untethering the Rocket core from the host interface and running standalone MIG memory interface and exclusively bare-metal compatible peripherals. The update to the latest Rocket has been under investigation for some time and so far we have held back from releasing a LowRISC based on  the latest Rocket because the framework of TileLink2 lacks an L2 cache, which we feel is an important aspect of the whole from a performance, realism, and teaching point of view. We fully understand why SiFive are reluctant to release this part of the code until they have working silicon of their U500 core. The released Chisel requires considerable to integrate our security extensions and for this reason we cannot stabilize our releases without branching the main Rocket repository. It seems unlikely that our changes could be incorporated upstream giving the rapid rate of refactoring of the upstream code. On the Ethernet side of things that you mentioned I have better news, we have a working solution for the Nexys4_DDR in-house, based on the ethernet-v0.5 branch of our code. This uses the userland from the poky-linux project, including dropbear ssh server. As with all our projects, none of our work in progress is held back from our collaborators and users. However, although it is operational, we still need to document and review this code before it can be released with the blessing of LowRISC CIC. If you examine the way Rocket code is released you do not see stable, update and release branches. This makes it difficult to tell when a new feature has stabilized. Furthermore since hardware design is not compositional, it would be difficult to make viable ports based on continuous integration of upstream repositories. There will always be conflicts such as I/O pins, busses, memory maps, conflicting timing constraints, and area constraints needing to be manually reconciled. Regards, Jonathan On 13/11/17 11:35, Ahmed Khalaf wrote: > Hello again > > I agree it's isn't easy (nor needed at this point) to > port/switch/migrate AXI related interconnects to a different > implementation. > The approach you mentioned is "agile" and make sense for lowRISC > project, other issues are by far more important. like Ethernet > interfacing. > > What I'm suggesting here is having a DRY structure by using > baseline from rocket-chip repo (which already includes hardfloat > and riscv-tools ..etc). > I just remembered rocket-chip have a recommended template project > that uses similar structure. > https://github.com/ucb-bar/project-template > <https://github.com/ucb-bar/project-template> > > Ideally, the aim of reuse is to maximize focus (and effort) in a > project going into features (differentiating factors) by re-using > Rocket and PULPino and the corresponding tool-chain and Linux > infrastructure since both are FPGA+ASIC proven already. > However, this needs to be enabled via a continuous integration > strategy. > > From my point of view, the main drawbacks for the current > structure I think at the moment are: > > 1- Lacking a clear baseline against rocket-chip, prevents me (as > potential community) from understanding the differences and being > able to efficiently navigate problems/design modifications: > Because files are copied into lowRISC and modified, I need to > figure out from which change-set does the rocket-chip files come > then checkout the corresponding baseline/branch ..etc and diff > the files. > > 2- Hindering the ability to update frequently, the more > manual taking over updates from rocket core + linux stuff the > more effort it requires > Less frequent updates will make it more difficult to catch up > with updates "exponentially" over time. > > 3- Reduced maintainability: ideally, all modifications/patches to > rocket-chip shall be submitted back to rocket-chip project to > allow configuration and/or contributing a fix/design change. > otherwise, lowRISC will have to re-apply these changes with every > update (or not .. manually). > > I'm mainly interested in lowRISC as FPGA based multi-core > Linux-capable SMP SoC with interrupt I/O off-loading capabilities > (via minion ..etc). > Currently, this is not working as far as I understood through > experimenting and from the issues on github: > #51 when will lowRISC support SMP well [opened on Jun 8] > <https://github.com/lowRISC/lowrisc-chip/issues/51> > > So, even if I wanted to contribute a fix to this issue for > example .. I will have to spend significant time on irrelevant > logistics just to know where we stand. > > If needed, please let me know if you agree to refactoring, I > might be able to contribute to this effort. > > Thank you. > > Best Regards, > Ahmed Khalaf > > On Sat, Nov 11, 2017 at 6:34 PM, Dr Jonathan Kimmitt > <jrrk2(a)cam.ac.uk <mailto:jrrk2@cam.ac.uk>> wrote: > > Hi Ahmed, > > We several implementations of AXI, the premier one for Xilinx > being the MIG dynamic memory interface generator. > > As long as we need that, there is no harm in using a variety > of AXI components from the Xilinx subsystem. > > There is also the SOCIP subsystem which offers simplified > functionality but limited configurability. > > Then there is the chisel version of AMBA in the rocket tree > itself, however as a chisel neophyte I am not clear > > if we extract standalone AXI interfaces components from this. > Finally there is the AXI infrastructure that is > > delivered as part of the Pulpino (Minion) infrastructure. > This seems to me to have a lot of usage limitations also. > > If and when we get sufficient stability and momentum to make > a real chip, we would have to see what components > should be used in the ASIC. > > Regards, > Jonathan > > > On 11/11/17 15:54, Ahmed Khalaf wrote: > > Hello Alex, > > Thank you for the prompt explanation, I checked out the > "update" branch and > it seems to me following the upstream codebase from > rocket-chip is getting > tedious. > > Getting git workflow right isn't easy indeed, UCB Boom > project opted for a > slightly obvious strategy which is forking rocket-chip > into a branch of > their own in which they include their git repo as a > sub-module. > https://github.com/ucb-bar/riscv-boom > <https://github.com/ucb-bar/riscv-boom> > > I'm not sure whether this would work for lowRISC because > there is already > history in a different structure (in addition to using a > SystemVerilog > top-level). > One option would be to include rocket-chip as a > submodule, which will make > updates a bit easier and more visible to "outsiders". > > Regarding AXI, I think there is already an AMBA > (AXI4/AHB-lite/APB) package > within Rocket-chip project as it's being migrated to use > AXI too. > I have no idea whether this would be considered an option > for lowRISC, as > it seems Chisel might not be "the" preferred option here. > > Best Regards, > Ahmed Khalaf > > On Sat, Nov 11, 2017 at 5:20 PM, Alex Bradbury > <asb(a)lowrisc.org <mailto:asb@lowrisc.org>> wrote: > > On 11 November 2017 at 14:58, Ahmed Khalaf > <me(a)ahmedkhalaf.com <mailto:me@ahmedkhalaf.com>> wrote: > > Hello, > > I have noticed lowRISC git repo doesn't rely on > rocket-chip > <https://github.com/freechipsproject/rocket-chip > <https://github.com/freechipsproject/rocket-chip>> > and has forked some > sub-modules from github.com/ucb-bar/ > <http://github.com/ucb-bar/> git repos (like > hardfloat), this > > makes > > sense. > > However, for rocket core, it seems UCB removed > the sub-module repo from > rocket-chip parent repo in July and also the > rocket git repo itself is no > longer accessible > https://github.com/ucb-bar/rocket/ > <https://github.com/ucb-bar/rocket/> > > As far as I understand, lowRISC will continue on > its own generator, but I > think Rocket core has become different from the > one used in rocket-chip > master branch: > https://github.com/freechipsproject/rocket-chip/ > <https://github.com/freechipsproject/rocket-chip/> > > blob/master/src/main/scala/rocket/RocketCore.scala > > I believe this will make lowRISC difficult to > maintain, and missing new > features (like AMOs). most importantly, it will > make understanding > differences between rocket-chip project and > lowRISC difficult. > > Can you please elaborate on the strategy lowRISC > will re-use components > from rocket-chip? > > Hi Ahmed, thanks for the questions. We build on top > of the upstream > Rocket codebase and aim to minimise differences where > feasible. > Unfortunately, large-scale refactoring of the > rocket-chip codebase has > made it quite difficult to stay in-sync. Wei has been > incorporating > code from a more recent Rocket for the next lowRISC > release, and you > can see this work in the 'update' branch of lowrisc-chip > https://github.com/lowRISC/lowrisc-chip/tree/update > <https://github.com/lowRISC/lowrisc-chip/tree/update> > > In general, we prefer to provide a SystemVerilog > top-level, and to > make it as easy as possible to hook up SystemVerilog > IP to the AXI > bus, with the aim of minimising the amount of Chisel > you need to know > to get started. Integrating upstream changes is an > ongoing challenge > and I don't think we've arrived at a final solution > yet. In > particular, we do want to spend more time thinking > about easy > configuration of the lowRISC SoC, including both the > Rocket and minion > core subsystems. > > Best, > > Alex > > > >