So here is my personal view on this:
I am inlined for the approach to merging lowRISC with the latest
Rocket-chip from upstream rather than freezing the current version and
diverging as it is.
It is indeed a strong argument that the current Rocket-chip is even more
difficult to digest; however, most of the users do not need to
understand the internals and will use it as black-boxes. The burden of
understanding it inevitably lies on the maintainers, which is very hard
for us who are not a part of SiFive or UC Berkeley. However, I argue
that the burden to keep the overall functionality up-to-date with a
diverged code-base is heavier. To maintain a diverged code-base, we need
to manually understand all the important changes (any thing related to
any future specification) in upstream and figure out a way to port it
back. In this sense, the old problem of understanding the upstream code
remains. The current version also lacks the functions for interrupt
controller and run-control debugger. Unless we say, we do not want
future compliance with the RISCV spec as the current one is good enough.
Of course, if anyone would like help on merging the whole Rocket-chip to
lowRISC, the amount of time to make it happen might be significantly
reduced. The current issues include:
1. There is still no sign of the return of L2.
2. Someone needs to fully understand the diplomacy package, how the
various Parameter case classes used in the LazyModule, Bundle and Module
cake pattern are used to generate the actual Chisel modules, and then
how to synchronise parameters between Chisel and the top level
SystemVerilog at compile time.
On 25/06/2017 19:29, Dr Jonathan Kimmitt wrote:
As was mentioned earlier Wei is the person who can best answer this. We actually had a
meeting of the lowRISC team around the time of the minion-v0.4 release, and he gave a
rough estimate of three-six man months to port the latest Berkeley code base (including
TileLink2, the programmable interrupt controller, and run-control debug) to the lowRISC
platform. The alternative of back-porting these items to the existing code base is
considered to be difficult and ultimately wasted effort as the RISCV spec moves on and
leaves us behind.
The other pertinent question of when we should try to resync with the latest Berkeley
code base is a difficult one to answer because, as I understand it, the Berkeley team do
not have a concept of a stable and/or release branch in the public repository. In our
judgment the head code is not strong and stable enough to be used at present, and we are
reluctant to put the effort into an unstable branch, knowing how difficult it will be to
apply our tag architecture to an unproven code base.
If you only want a plugin replacement for our existing Chisel based Rocket, without tag
protection, then you only need to script the latest Berkeley configuration with external
memory and I/O NASTI master busses, which can then talk to our FPGA wrapper, which we
believe to be a rather simpler job, for somebody skilled in the art. However there are a
number of elements such as device tree contents and device driver adaptations which would
need revising to allow Linux to boot.
It would be difficult to assign probabilities to the various options you mentioned, it
will depend on attracting more funding and perhaps expanding our team as well. We believe
our offering represents good value for the community but not every company wants to invest
in free IP that only returns prestige and good will. Personally I am very excited about
developing commercial traction for free hardware in the same way that free software has
transformed the internet and desktop.
These insights are my own off the cuff opinions and are not official lowRISC team
LowRISC team member
University of Cambridge
Sent from my iPhone
> On 25 Jun 2017, at 17:31, Sean Halle <seanhalle(a)intensivate.com> wrote:
> Hi Stefan,
> Great discussion :-)
> We are actually up against a decision at the moment. We have to decide
> within the next few days whether to put in the work of porting TL2 to
> To do that, I am hoping that we can get some kind of sense from the LowRISC
> community about the likelihood that LowRISC will update to the new Berkeley
> style. What would you say, in your opinion, the probability is that
> LowRISC will update to the new Berkeley Style? Like 10% chance that
> LowRISC will put in the effort to merge the new Berkley code and move to
> Chisel3? Or, is it a 90% chance that LowRISC is committed to staying in
> sync with Berkeley, and so will do the work of updating to Chisel3, will
> adopt the cake pattern, and will then do regular pulls from the Berkeley
> code base? To be clear, the question comes down to something specific --
> will LowRISC at some point be doing frequent pulls from Berkeley code? In
> other words, I see three paths:
> 1) simply pull in pieces here and there -- mainly pull in the priviledged
> spec when it updates -- so the bulk of the LowRISC code is unaffected. The
> bulk of LowRISC code continues as is, diverging from Berkeley.
> 2) bite the bullet and update all LowRISC code to the current Berkeley
> version -- switch to Chisel3, adopt the cake pattern, and so forth -- but
> then let the code diverge again..
> 3) the same as 2, do a full update of all the code, but then additionally
> do frequent merges, to keep the code up to date with Berkeley.
> Of those three paths, what percentage chance would you give to each?
> Thanks Stefan,
> P.S. I'm thinking about reposting this under a new topic, to attract
> everyone to weigh in :-)
> *CONFIDENTIALITY NOTICE*: This e-mail and its attachments contain
> information which is confidential. It's use is strictly limited to the
> stated intent of the provider and is only for the intended recipient(s). If
> the reader of this e-mail is not the intended recipient, or the employee,
> agent or representative responsible for delivering the e-mail to the
> intended recipient, you are hereby notified that any dissemination,
> distribution, copying or other use of this e-mail is strictly prohibited.
> If you have received this e-mail in error, please reply immediately to the
> sender. Thank you.
> On Sun, Jun 25, 2017 at 5:06 AM, Stefan Wallentowitz <stefan(a)wallentowitz.de
>>> On 25.06.2017 12:03, Sean Halle wrote:
>>> I think the crux of this is whether the idea of merging Berkeley code
>>> into LowRISC is realistic or not.. it seems like a very large amount of
>>> work? Do I have that right? For example, might it even be easier be to
>>> simply restart with the current Rocket repo and redo the integration
>>> work, rather then trying to weed through all the merge conflicts..? Or,
>>> do I misunderstand the effort involved?
>> I think Wei can best comment on this. The major addition of lowRISC is
>> Tagged Memory and I agree the better approach is to rebase that work.
>> Beside that it is actually TL2 that remains.
>>> If that is the case, that the effort of a merge is prohibitive, and as a
>>> result LowRISC never actually merge Berkeley code back in, then we would
>>> be fine.. we port TL2 once, and then mainstream it into LowRISC, and
>>> there's no more effort after that. At least as long as that version is
>>> good enough, then there is no strong reason to update it.
>> For now its every privilege spec update that needs to be implemented,
>> possibly further extensions if wanted. Then run-control debug and
>> probably other stuff I am not even aware of.
>>> Has there been any discussion about the likelihood and timing of
>>> updating LowRISC to the new Berkeley style of things? We have some
>>> evidence that the new Berkeley style is less modular, and has a steeper
>>> learning curve than the July 2016 version of the code. We chose LowRISC
>>> in part for this reason -- the older style is simpler, easier for us to
>>> get up and running.
>> Yeah, I agree on the learning curve issue, but am personally undecided
>> if that is a good enough reason to permanently divert.
>> Have a great weekend!