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 policy.
LowRISC team member
University of Cambridge
Sent from my iPhone
On 25 Jun 2017, at 17:31, Sean Halle
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?
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!