[lowrisc-dev] Porting TileLink2 to LowRISC

Dr Jonathan Kimmitt jrrk2 at cam.ac.uk
Sun Jun 25 19:29:00 BST 2017


Dear Sean,
  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.

Regards 
Jonathan Kimmitt 
LowRISC team member
University of Cambridge 

Sent from my iPhone

> On 25 Jun 2017, at 17:31, Sean Halle <seanhalle at 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
> LowRISC.
> 
> 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,
> 
> Sean
> 
> 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 at wallentowitz.de
>> wrote:
> 
>>> 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!
>> 
>> Cheers,
>> Stefan
>> 
>> 



More information about the lowrisc-dev mailing list