Coding style of Rocket a barrier to adoption of Rocket

[Sean Halle]

   I'd like to follow up on the topic of coding style in Rocket Chip code.  We have been experiencing a phenomenon that is causing friction in our uptake of Rocket.  We're losing now about 2/3 of the Verilog developers that we hire.  They start, ready to go..  do the Chisel tutorial and read the paper and get the cheatsheet, then jump into Rocket Chip to modify the code according to our needs..  and hit a wall.  We have some people on the old July 2016 version, and others on the up to date version.  We lost about 1/3 of those who jumped into the July 2016 version, and we're losing about 2/3 now, on the up to date version.  This is a serious problem for us.

One question I have is..  is it possible that the people contributing to Rocket Chip are the top few percent of RTL developers?  Perhaps this doesn't seem like a problem to those creating Rocket Chip because everyone you know is fine with the style.  You are all operating at a level significantly above the majority of existing Verilog coders.  So, you don't experience how difficult a barrier it is for most existing Verilog coders.

Does that make any sense?

The end effect seems to me that it could present a barrier to the spread of Rocket.  It seems that many are implementing RISC-V directly in Verilog.  That may be an indicator that there are barriers.  We, ourselves, would like to continue to try to use Rocket.  But the advanced coding style is making that difficult.  

That seems like a topic that merits discussion..  have others who are implementing custom processors and are attempting to reuse code from Rocket experienced similar difficulties?

Those who have implemented RISC-V in Verilog, what was behind the reason to avoid reusing existing Chisel based code?

To summarize, one publicly stated goal of the Rocket code base is to gain traction outside of Berkeley and SiFive.  Difficult to learn code runs counter to that goal.  The experiences of Rocket contributors may not be a good indicator of the difficulty because they may be upper echelon developers.  And so, the problem may be festering out there, silently, as friction that reduces the uptake of Rocket code, retarding its reuse.  If so, then this would be more of a social phenomenon, and not a technical one.  The solution would be more of a social solution, where more outreach happens in order to gather measurements of just how much friction there actually is within the larger target community.  Capture what things are most problematic for them, and bring those back to inform coding style choices.

Sorry to be such a downer here :-)  Hopefully it turns out that I'm wrong, and our experience is just a fluke.

Rocket is a wonderful thing.  We have made amazing early progress by reusing the code, and hopefully a solution can be found that allows us to grow the team, now, as we accelerate development.

Thank you for making this all possible, 

Sean

Intensivate

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 Fri, May 5, 2017 at 2:08 AM, Andrew Waterman <and...@sifive.com> wrote:

We do need straightforward RISC-V implementations for educational
purposes.  Bringing Sodor back up to speed is probably the most
expedient route.

On Fri, May 5, 2017 at 12:45 AM, Sean Halle <sean...@intensivate.com> wrote:
>
> Hi Po-wei,
>
>    I wish I were back teaching again, I'd be all over this :-)   In lieu of
> that, I'd just like to give you my support.
>    One of the key blocks that Rocket is facing at the moment would be the
> sophistication of the coding style.  I'm losing people, who are quitting
> because the Rocket code base has grown ever more difficult to understand.
> We started working with the Feb version of the Rocket code base, and gave
> up, due to the coding practices, and went back to July 2016.  The reality is
> that 99% of RTL developers are nowhere near as smart as the Berkeley people
> writing the Rocket code.  We have found that the average developer just
> can't handle the coding style.
>
>    The reason I said all this is because I want to encourage you to retain
> the older version of the code base.  It had a simpler style, and those new
> to Chisel can pick it up more easily.  In a classroom setting, this coding
> style issue will be a key to success of the students and retention in your
> classes.
>
> Best,
>
> Sean
> Intensivate
>
>
>
> 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 Fri, May 5, 2017 at 12:17 AM, Po-wei Huang <poweih...@gmail.com>
> wrote:
>>
>> Hi,
>> Is anybody interested in establishing a mailing list for RISC-V education?
>>
>> It is really a pity that Z-scale, V-scale, and sodor are still compiled
>> for priv 1.7.
>> Because of this, I had to do a lot of workaround when I prepared risc-v
>> materials for students. (find old gcc for priv 1.7…)
>> I know google summer of code has a project on sodor, but before that
>> finished, is anybody interested in establishing a mailing list for RISC-V
>> education?
>>
>> One key advantage of RISC-V would be its openness and open source
>> implementation, which is good for students and for engineers to pick up
>> RISC-V quickly.
>> However, we actually faced some challenges when we prepares the lab
>> material for RISC-V, and the adoption in schools are not so quick.
>>
>> For example, some courses of architecture only focus on cpu
>> microarchitecture, and chisel is not so directly related.
>> So, I have to skip rocket, but some implementation are not for priv 1.9 or
>> not well discussed or documented.
>> These issue about teaching and course design is not so related to Hardware
>> development, so I didn’t hijack this mailing list.
>> However, I believe that this kind of discussion and forum will have a very
>> positive impact for RISC-V community in the long run.
>>
>> Moreover, it seems that more and more schools try to adopt or evaluate
>> RISC-V for their course, so it might be a good time for such a call.
>>
>> How do you think?
>> Best,
>> Po-wei
>>
>>
>>

[Matthew Hicks]

Could the problem be that Chisel is designed to make creating hardware approachable to software developers, not actually make it easier to build hardware for existing hardware developers?  As someone who checks the boxes of hardware developer, software developer, and academic, I decided to avoid Chisel after learning it (in favor of Verilog).  It adds too much overhead to the hardware development process and the Verilog that it generates is horrendous.

I expect the industrial side of the RISC-V community to move towards a more conventional implementation of RISC-V in the near future.  There are many open source implementations that exist today, with RI5CY (https://github.com/pulp-platform/pulpino) and River (https://github.com/sergeykhbr/riscv_vhdl) seeming to be the most viable candidates that don't require Chisel.

---Matthew Hicks

> --
> You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.
> To post to this group, send email to hw-...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/CAJ4GwDKraOBvBcD3TBHzpw6gaKkTvy95XPXy%3DbXLS35h7De%3Dvg%40mail.gmail.com.

[Prof. Michael Taylor]

Hi all,

My team recently completed a TSMC 16-nm tapeout with 5 Linux-capable Rockets and 496 RISC-V 32IM cores in a tiled manycore array. 4 Rockets connect via ROCC to the manycore array, and the 5th uses ROCC to talk to a neural network accelerator. The 32IM cores we designed in-house with SystemVerilog, using the open source Basejump STL library to raise the level of abstraction. The NN accelerator was done in HLS.

I think there are five aspects that challenge today's designers: a) micro-architectural complexity, b) functional languages, c) high-level design patterns, d) 

lack of commenting and documentation and e) challenges integrating Rocket into traditional flows. 

Ultimately highly productive designers should adopt (c). In my own experience, there are three levels of attainment in SystemVerilog. The lowest level is at the syntax level and language construct. The next level is being fluent at writing parameterized, reusable modules, i.e. a reusable N-input, N-to-1 arbiter with  configurable fairness policy. The third is designing libraries of these modules that have good composability properties, including latency insensitive interfaces. All of these are good things but require significant software and hardware design maturity in developers. Possibly Chisel has a fourth level even above what SystemVerilog is capable of, but you need to have levels 1-3 first in any HDL.  Generally Chisel does not get too functional, so it only slightly worsens the learning curve for level 1. But it is really only at level 3-4 that it has advantages over SystemVerilog IMHO.

The complexity in a) has many roots in Rocket's heritage as a research infrastructure. Dual port non-blocking data cache for an in-order processor? Not sure about that. d) comes from the fast rate of change in the code base.

To date, there is no open source alternative to Rocket. But I think/hope eventually that equivalent open source Linux-capables in-order cores will be available with less microarchitectural complexity and more documentation. That could be Rocket, or setting else. On our part, my team has released The RoCC Doc to try to help Rocket with (d). We will also be releasing complete code for the entire design, after the chip returns from fab, as a reference for others, to address (e).

Prof. Michael B. Taylor

Famous West Coast University*

darksilicon.net

--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+unsubscribe@groups.riscv.org.

[Samuel Falvo II]

On Fri, May 26, 2017 at 1:21 PM, Matthew Hicks <mdh...@gmail.com> wrote:
> Could the problem be that Chisel is designed to make creating hardware
> approachable to software developers, not actually make it easier to build
> hardware for existing hardware developers?

I am a software developer first and foremost, and I find Chisel to be
completely opaque to me. When I last attempted to go through online
tutorials, I couldn't even get it to install properly, so I gave up
and moved back to Verilog.


--
Samuel A. Falvo II

[Samuel Falvo II]

On Fri, May 26, 2017 at 12:43 PM, Sean Halle <sean...@intensivate.com> wrote:
> Those who have implemented RISC-V in Verilog, what was behind the reason to
> avoid reusing existing Chisel based code?

Two reasons, for me:

1) Chisel is opaque and, therefore, unmaintainable to me.
2) My target is FPGAs specifically, especially iCE40HX8K FPGAs.
Rocket is too big to fit on such a small device, since it's built for
ASIC development.

[Schuyler Eldridge]

So, I view it as a larger issue in the mammoth disconnect between the "Chisel for Hardware Engineers" as it's presented in the older Chisel documentation (the newer Chisel3 wiki is much better) and what is actually going on in Rocket. You can get very, very far writing Chisel that looks like Verilog, but 99% of the complexity of the internals of Rocket are due to the heavy use of Scala-specific features. Unfortunately, this is also where you can be the most terse, most efficient, and write the most reusable and composable hardware designs.

@Sean -- I feel you. I'm struggling with trying to get people excited about Rocket/Chisel at IBM and I just don't have a good answer... I'm almost two years deep in Chisel and I finally feel comfortable doing deep dives on Rocket (or just confident that I can eventually figure out what's going and make modifications on if I look at it long enough). The downside is that I now routinely write Chisel code that, in my own estimation is highly efficient/extensible/using some interesting design patterns, but my coworkers can't make heads or tails of it. 

Related to this, I've struggled with what is the best way to introduce someone to Chisel and get them up to speed as quickly as possible. Stream of consciousness thoughts:

  * What order should people learn? Is knowledge of Scala (or some other functional programming, e.g., Haskell or computer science knowledge re: the lambda calculus) necessary first or should this be mixed in later?

  * Do people start with very structural Verilog-like Chisel and then scale up from there? This is how I got going, but I think this is highly inefficient. I would routinely run into something that I wanted to do (e.g., pass in the IO to a module as a parameter) and then have to go figure out how to do it in Scala first.

  * Is there a pedagogy here for what concepts should be introduced and when?

  * Alternatively, does it just take effort and time?

All of this can likely be best addressed, or at least anecdotally analyzed, by some of the experience with onboarding at SiFive or possibly of the successful hires that you've seen, Sean. This may be worth keeping track of for the broader Chisel community.

The crux of the problem is that to really gain the power of Chisel is that you need to have largely non-overlapping skill sets of computer science and hardware design. However, the comments in this thread seem to contradict this strongly or imply that this is not a sufficient condition. Rarely do these seem to come in sufficient quantities from an undergraduate program (they didn't for me and only came in graduate school through concerted, directed effort). For those that don't have these skill sets you need to have enough basic knowledge to formulate your queries so you can figure out what's going on. 

Additionally, Chisel-generated Verilog is usually something that you never want to be looking at unless absolutely necessary. I find this concept to be very difficult for hardware engineers to let go of. Hand waving: I find myself looking at Chisel-generated Verilog about as often as I look at compiler-generated assembly (it happens, but not terrifically often).

@Samuel -- I'm curious as to if you could elaborate on the opacity. Maybe this is something in terms of the presentation that could be better dealt with.

@Michael -- this is some awesome news about the tapeout and bravo on the (eventual) open source release. We need way more of that open source commitment from academia. I know your thoughts on SystemVerilog and I do agree, to a point. The lack of support by the EDA vendors for advanced SystemVerilog features in synthesis (e.g., classes) still, however, makes me concerned that SystemVerilog, or something similar, will ever be as useful as it could be. Granted, there's something odd if I have to go the roundabout Chisel -> FIRRTL -> Verilog route. Or, maybe layers of abstraction are inevitable and Verilog is our assembly language.

Alternatively, the Kool-aid tastes good over here.

--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.

To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/CAEz%3DsoktuALG1n0YN%3DHGNauv%3DfOyxiSPWP7g%2BSCbX2r%3DDB5ZxA%40mail.gmail.com.

[Samuel Falvo II]

On Fri, May 26, 2017 at 10:23 PM, Schuyler Eldridge
<schuyler...@gmail.com> wrote:
> @Samuel -- I'm curious as to if you could elaborate on the opacity. Maybe
> this is something in terms of the presentation that could be better dealt
> with.

To be productive with it, first you have to learn Scala. Then you
must learn Chisel itself. THEN you have to learn how Chisel is used
in a particular project. This three-deep stack of languages is
expensive, and the interactions between these "layers" of learning
complects, rather than simplifies, the process of understanding.

Scala has a fair amount of tutorials on-line that you can follow, but
none with an eye for hardware development, so even if you were to
learn Scala, learning Chisel (the domain-specific language) just
steepens the learning curve. The Chisel tutorials further suffer from
the problem of being too basic to adequately cover how it's used in
real-world designs, such as Rocket.

BTW, Chisel is not the only DSL with this problem. Chef suffers
similar issues, where if you don't know Chef, you first must learn
Ruby, then you must learn Chef's unique use of Ruby, then you further
have to learn how Chef is used by a particular devops team. It's
metaphorically (and, for me, physically) painful.

[Richard Herveille]

We decided to do our own implementation in SystemVerilog.

Chisel is just a step too far, too high a learning curve.

Our customer base is a mix of VHDL and Verilog users (slightly more VHDL). Adding Verilog/SystemVerilog is already a step for them. Providing Chisel or Chisel generated code is too much. They won’t accept that.

Richard

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.
To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/CAEz%3Dso%3Dsfk%2BV5PzSV7awgC4V7-Vid6vbXhpjUvxwsHsUC%2Bct%3Dw%40mail.gmail.com.

[Ted Speers]

Interesting discussion.

Folks participating in this discussion might not be aware of chapter 2 of Henry Cook's thesis (https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-89.pdf ) which endeavors to provide insight into the power of Chisel (answer(I think): context dependent environments) and the features of Scala that are leveraged to realize said power.






-----Original Message-----
From: Samuel Falvo II [mailto:sam....@gmail.com]
Sent: Saturday, May 27, 2017 3:36 PM
To: Schuyler Eldridge
Cc: Sean Halle; Andrew Waterman; RISC-V HW Dev
Subject: Re: [hw-dev] Coding style of Rocket a barrier to adoption of Rocket

EXTERNAL EMAIL

--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.
To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/CAEz%3Dso%3Dsfk%2BV5PzSV7awgC4V7-Vid6vbXhpjUvxwsHsUC%2Bct%3Dw%40mail.gmail.com.

[Christopher Celio]

Thanks everyone, this has been a very interesting thread to read.

I think something important to keep in mind is that telling people about Chisel and pointing them to rocket-chip is a lot like trying to convince somebody to use C and pointing them to the GCC code base. Looking at a comparable Verilog project, like the UltraSPARC T1, is a similarly challenging exercise.

When a software engineering project hits a certain level of complexity, each effectively develops its own "DSL" beyond the base language. Rocket-chip is well into that territory with its powerful parameterization system ("context dependent environments") and it's LazyModule evaluation system (the ability to plug and play new tiles, cores, accelerators, and devices).

So given what rocket-chip is capable of doing, it's not obvious to me that the resulting code complexity can be avoided. And it's even less obvious to me how one would re-create rocket-chip with the same flexibility and QoR in a different language/coding style.


-Chris

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/45FC13E809C9A942BC515F7A1E7E7D7AB593CCBF%40sjsrvexchmbx2.microsemi.net.

[Samuel Falvo II]

On Mon, May 29, 2017 at 1:03 PM, Christopher Celio
<ce...@eecs.berkeley.edu> wrote:
> So given what rocket-chip is capable of doing, it's not obvious to me that the resulting code complexity can be avoided.

I recently got hired at Facebook, and their on-boarding process
includes a series of lectures (roughly 1 hour in length) on various
aspects of their massive code-base. This includes labs on how to get
started, and tasks (which are like homework assignments, really) which
you can speak to your assigned mentor about if you need help. It's a
format which I find refreshing. Without this "bootcamp" process, I'd
be terribly lost with Facebook's codebase as well.

It's a pity that no similar set of resources exists for Rocket and
Chisel. I think it would go a long way towards "on-boarding"
contributors to the project.

[Stefan Wallentowitz]

Hi everyone,

a lot of good points were made from "both sides" in this discussion.
Addressing the to-the-point statement of Chris, I think there is maybe
simply a mismatch of expectations in the community. I think Rocket was
communicated and perceived as the "reference implementation of RISC-V".
Many people coming from open source communities expect a certain level
of quality documentation, higher code comment verbosity etc. on such
flagship projects. Adding a new language, where the majority of people
don't have the 99% most experienced users sitting in the same lab, makes
this even more important apparently.

So, while I can fully agree that the nature of the project naturally
leads to complex code, I clearly understand the frustration in the not
overwhelming documentation (on several levels). There is a lot of room
for improvement and this kind of feedback is also normal in the open
source community.

Finally, I have heard about the "Rocket Foundation" before and I think
this is kind of the discussion addressed by this body. Commercially
interested parties can jointly develop a common code base and have
someone (not sure if one has to what for a whole new foundation) can
help steering the efforts. I am not sure if there has been a recent
update, but I would be interested in how people would expect this
foundation would address the issues of this thread?

Cheers,
Stefan

[Dr Jonathan Kimmitt]

Dear all,

If anyone has ever been involved in licensing source code for a commercial

processor, they will know that modifying the code

may or may not be allowed, depending on the license, and if you do try
to modify

anything, this is very difficult because Verilog is not the best format
for modification.

All credit then to Berkeley for coming up with a higher level of
abstraction, which can

be modified effectively, if you don't mind the steep learning curve. If
I could suggest

an improvement, it would be to make the Verilog writer have better names
which relate

to the Chisel source in a meaningful way, instead of T0, T1, T2 etc.
However for most users, the CPU

will be a black box which you run the ISA regression tests on, and if it
passes, you are good to go.

For the remaining users, there will no doubt be frustration that they do
not (yet) belong to the exclusive

club of viable processor designers, but bearing in mind all the problems
of writing in Verilog, such

as dubious semantic corner cases, ambiguous don't care space, and lack
of coverage completeness, it is inevitable

that the search for a better language will continue. Chisel may not be
the end of the journey, but it is

a stepping stone on the way.

Regards,

Jonathan

For further reading: System Verilog behavioural synthesis, System-C,
Bluespec, HardCaml, Lava, LegUp etc.

[Tobias Strauch]

I was wondering why Chisel is compared to Verilog from the 80’s and not with the decade old language SystemVerilog.

For the sake of getting into the Chisel and Rocket blues, I did write a Chisel to SystemVerilog converter and did find a 1:1 match in almost all language constructs – at least for the one that are used in the rocket design.

Chris, I would love to read about features of Chisel, which are ”really” on top of SystemVerilog, maybe even about something essential. Any idea, list, paper ??? I would be delighted.

Cheers, Tobias


> Christopher Celio <ce...@eecs.berkeley.edu> hat am 29. Mai 2017 um 22:03 geschrieben:

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/41AB8403-2DD2-48C9-9CAF-07988E11E5C1%40eecs.berkeley.edu.

[kr...@berkeley.edu]

A few things.

Chisel advocacy/opposition is not a great topic for this mailing list.
Nothing requires using Chisel to use RISC-V. There are many
open-source and commercial RISC-V cores not written in Chisel. While
Rocket Chip has been the largest (but not only) driver of Chisel
language development, there is a separate Chisel users mailng list to
discuss Chisel features and to complain about lack of Chisel tutorial
material, and to volunteer to help write some.

[ Just to thrown in one point here compared with System Verilog
though, a big advantage of Chisel is that every implementation of
Chisel has the same set of supported features, and is freely
available. In an earlier project, we had to file O(100) separate
bug reports on a commercial SystemVerilog implementation because
advanced features weren't working as advertised or not present at
all. This helped convince some at Berkeley to switch to Chisel. ]

Rocket was never meant or marketed as "the" reference implementation,
and the Rocket Chip code base is complex partly because it is a
complete SoC generator, not just a single processor core. If
anything, Spike is the current reference implementation, though we'd
all like a formal spec instead. The new Patterson and Hennessy text
should also help people figure out simple implementations (Rumble
claimed to have done their core in three weeks from the pdf docs back
in 2014).

Rocket was meant to be a usable practical malleable SoC base, not a
RISC-V implementation tutorial. More documentation is always good and
will surely appear over time - there has been a lot of development in
recent months and it takes time for dust to settle to point where
writing docs makes sense (thanks to Wei Song and lowRISC team for
putting some documentation up on earlier Rocket code base).

There are also the Sodor cores, now being updated thanks to Google
summer of code (and Stefan!), which are examples of simpler Chisel
coding style as well as being useful pedagogical processor core
designs.

Due to popular demand, there was an attempt to put out a usable simple
Verilog core from Berkeley, V-Scale, but maintaining this alongside
Rocket was simply too much work and so it was deprecated. Thankfully
now there are multiple open-source Verilog cores maintained by others
to use instead.

What was at one point called the "Rocket Chip Foundation" is now the
more general "Free Chips Project", which is initially a repo where the
Rocket Chip codebase and Chisel/FIRRTL will be maintained in the
future, as well as some other open-source silicon projects (don't have
to necessarily be written in Chisel, and will include commercial as
well as non-commercial open-source projects). The goals of Free Chips
fit within FOSSi agenda, though narrowed in scope to a few particular
projects. In particular, TileLink will probably be, even more than
RISC-V, the glue that holds Free Chips together - and more
documentation is coming for the already released updated TileLink
code. At some point, it will make more sense for Rocket-related
questions to be handled over there though I don't believe mailing
lists are up yet. There's also the SiFive forums for questions
related to SiFive's Freedom platform built around Rocket.

Cheers,
Krste

| To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/83293a8b-2383-1332-4367-80d5aeafebf9%40wallentowitz.de.
| x[DELETED ATTACHMENT signature.asc, application/pgp-signature]

[kr...@berkeley.edu]

I was asked off list about Z-scale status (V-scale was based on
Z-scale).

Z-scale was a much simpler Berkeley Chisel RISC-V core designed to
cover small embedded uses. Instead of maintaining a separate core, we
decided to increase the range of cores Rocket Chip could generate
(e.g., including 32-bit), so now we've also deprecated Z-scale. We'll
update Z-scale repo to make this clearer.

Krste

P.S. Z-scale details and silicon results are in the following
conference and journal publications

Ben Keller, Martin Cochet, Brian Zimmer, Yunsup Lee, Milovan
Blagojević, Jaehwa Kwak, Alberto Puggelli, Stevo Bailey, Pi-Feng Chiu,
Palmer Dabbelt, Colin Schmidt, Elad Alon, Krste Asanović, and Borivoje
Nikolić, "Sub-microsecond Adaptive Voltage Scaling in a 28nm FD-SOI
Processor SoC", 2016 European Solid-State Circuits Conference
(ESSCIRC-2016), Lausanne, Switzerland, September 2016.

Ben Keller, Martin Cochet, Brian Zimmer, Jaehwa Kwak, Alberto
Puggelli, Yunsup Lee, Milovan Blagojević, Stevo Bailey, Pi-Feng Chiu,
Palmer Dabbelt, Colin Schmidt, Elad Alon, Krste Asanović, and Borivoje
Nikolić, "A RISC-V processor SoC with integrated power management at
sub-microsecond timescales in 28nm FD-SOI", To appear, IEEE Journal of
Solid-State Circuits, July 2017. (available online already)

[Stefan Wallentowitz]

Hi Krste and all,

On 30.05.2017 18:34, kr...@berkeley.edu wrote:
> Chisel advocacy/opposition is not a great topic for this mailing list.
> Nothing requires using Chisel to use RISC-V. There are many
> open-source and commercial RISC-V cores not written in Chisel. While
> Rocket Chip has been the largest (but not only) driver of Chisel
> language development, there is a separate Chisel users mailng list to
> discuss Chisel features and to complain about lack of Chisel tutorial
> material, and to volunteer to help write some.

Fully agree. Also please note my comments were not meant as criticism,
but as highlighting the usual problems open source projects at a high
pace face that gain a lot of attraction.

> Rocket was never meant or marketed as "the" reference implementation,
> and the Rocket Chip code base is complex partly because it is a
> complete SoC generator, not just a single processor core.

Sorry, that was my misconception.

> There are also the Sodor cores, now being updated thanks to Google
> summer of code (and Stefan!), which are examples of simpler Chisel
> coding style as well as being useful pedagogical processor core
> designs.

Great chance for advertisement, thanks!

Chris Celio and I are mentoring a Google Summer of Code student, Kritik
Bhimani, that updates the Sodor repository to Chisel3 and the latest
privileged spec. I assume Kritik will soon post an initial blog article
about the roadmap and how to best follow the work. If you are interested
you can join us on Gitter (https://gitter.im/librecores/riscv-sodor) or
follow the Github repo (https://github.com/librecores/riscv-sodor, stuff
will apparently be pushed upstream).

Cheers,
Stefan

[kritik bhimani]

my blog post https://codelec.github.io/gsoc/gsoc1/