Computer Engineering Education Experiences with RISC-V Architectures—From Computer Architecture to Microcontrollers

Round 1

Reviewer 1 Report

This paper presents an approach to using a RISC-V soft processor for educational purposes. The paper is very well written and provides interesting and useful information to the readers.

I have enjoyed reading through your paper because both the Introduction/related work and the project itself are nicely explained. I think that the paper presents an interesing approach but I am missing some "experimental results".

In my opinion, the paper is solid, but it seems to be "incomplete". The overall feeling that the paper gives is as if the authors were explaining a field notebook or a letter of intention due to the lack of experimental results.

I think that the paper would be improved if the authors could add some quantitative metrics such as for example the student grades comparing one year without the RISC-V project and the year they implemented it. As well as some qualitative metrics such as feedback from the undergraduates.

If you could add this information in the next version of your manuscript or, at least, some explanations about this topic, the paper would be more complete and your point supported by some results.

Author Response

Thank you for your review of our work.  We address the following to improve the paper:

I have enjoyed reading through your paper because both the Introduction/related work and the project itself are nicely explained. I think that the paper presents an interesing approach but I am missing some "experimental results".

In my opinion, the paper is solid, but it seems to be "incomplete". The overall feeling that the paper gives is as if the authors were explaining a field notebook or a letter of intention due to the lack of experimental results.

I think that the paper would be improved if the authors could add some quantitative metrics such as for example the student grades comparing one year without the RISC-V project and the year they implemented it. As well as some qualitative metrics such as feedback from the undergraduates.

If you could add this information in the next version of your manuscript or, at least, some explanations about this topic, the paper would be more complete and your point supported by some results.

We note the reviewer's comments on the lack of conclusive educational results.  Unfortunately, with the small population of students who chose the described path, there is not much in terms of data that would make this better.  Additionally, we implemented these ideas without IRB (ethical permissions) and cannot report grades or measurements post activity.

We have added the following to the paper in the conclusion section: "As these activities are student chosen, we have no conclusive data to the impact of these activities, but we note that of the students that chose the above activities 3 out of 6 of these students have gone into graduate studies in related fields."

This does not address the reviewer's comments directly, but, hopefully, the ideas and activities are sufficiently valuable in the reviewer's view to consider.

Reviewer 2 Report

1. Overall, this paper shows that students design a RISC-V processor that implements a subset of instructions. Students then use an open-source processor to extend it with some peripherals.

2. It is a good idea and merits some interest. A better organization in how it is presented (for example, tables of tools used, topics covered, etc.) would have improved the paper. In some cases, such details are scattered throughout the text, and in other cases details are missing.

3. More details are needed to give a full evaluation of the contribution. For example, Figure 2 is essentially the basic microarchitecture from Hennessy and Patterson's text. First of all, that should be cited. Additionally, it isn't a full representation of what was implemented.

4. It is great that the authors included the source code, but it is recommended to take the time to make it more usable.

5. Throughout the text, unclear or awkward phrasing and inconsistencies could be improved. Here are some examples (not exhaustive):

>>"For this work, the RV32I is the base ISA that students should start from..." 

Instead: "For this work, the students implemented a subset of the RV32I base ISA, specifically..."

>>"Figure 1 shows a basic block diagram of the major components of the RISC-V system. Note, that the details of the architecture are not observable from this diagram."

Instead, state where you go into detail about the architecture (that part is mostly missing from the paper - a very broad overview is in Figure 2, but more detail would be helpful).

>>"Next, each of the major components, excluding the control, should be created and tested separately, and each should be implemented as a separate module in Verilog."

Instead, use language indicating what you did (instead of "should be created"). For example: "The students successively designed major components starting with the datapath units (ALU, register file,...) and..."

6. Generally, there is too much text and not enough figures and tables. It is presented more as a chronology than a well-defined organization of the suggested course(s).

Author Response

We thank the reviewer for their comments and address the following in this version:

2. It is a good idea and merits some interest. A better organization in how it is presented (for example, tables of tools used, topics covered, etc.) would have improved the paper. In some cases, such details are scattered throughout the text, and in other cases details are missing.

We have added table 2 and 3 to each of the two educational activities to provide the reader a summary of these details in sections 3.6 and 4.4

3. More details are needed to give a full evaluation of the contribution. For example, Figure 2 is essentially the basic microarchitecture from Hennessy and Patterson's text. First of all, that should be cited. Additionally, it isn't a full representation of what was implemented.

We updated the proper citation of Figure 2.  As per the reviewer's comments, we note that the description prescribes a method of design as opposed to a specific design.  Each of the 6 students who did this activity followed this methodology and creates their own diagram similar to Figure 1 with more details.  From this point, they design their architecture in HDL.

4. It is great that the authors included the source code, but it is recommended to take the time to make it more usable.

We will work on this, but at this time do not have undergraduate students around.  We note that none of these processors are recommended as designs that we would hope that others use, and would instead suggest that researchers use the more complete RISC-V processors as described in one of our citations (Höller, R.; Haselberger, D.; Ballek, D.; Rössler, P.; Krapfenbauer, M.; Linauer, M. Open-source risc-v processor ip cores for 696
fpgas—overview and evaluation. 2019 8th Mediterranean Conference on Embedded Computing (MECO). IEEE, 2019, pp. 1–6)

5. Throughout the text, unclear or awkward phrasing and inconsistencies could be improved. Here are some examples (not exhaustive):

>>"For this work, the RV32I is the base ISA that students should start from..." 

Instead: "For this work, the students implemented a subset of the RV32I base ISA, specifically..."

>>"Figure 1 shows a basic block diagram of the major components of the RISC-V system. Note, that the details of the architecture are not observable from this diagram."

Instead, state where you go into detail about the architecture (that part is mostly missing from the paper - a very broad overview is in Figure 2, but more detail would be helpful).

>>"Next, each of the major components, excluding the control, should be created and tested separately, and each should be implemented as a separate module in Verilog."

Instead, use language indicating what you did (instead of "should be created"). For example: "The students successively designed major components starting with the datapath units (ALU, register file,...) and..."

We have attempted to improve the specific sections as specified by the reviewer.  Also, we made a full edit pass of the paper to improve the writing.

6. Generally, there is too much text and not enough figures and tables. It is presented more as a chronology than a well-defined organization of the suggested course(s).

The reviewers comment is noted.  We have not made any changes (other than adding the summary tables as suggested earlier) in this regard as we believe that our approach is reasonable for this type of presentation.  We expect the majority of readers will use this paper as a tutorial on how to have their own students do these activities.

Reviewer 3 Report

The presented paper shows the authors' experience with underground students building a RISC-V processor on a FPGA. The students design their own RISC-V core in Verilog and some of them implemented in FPGA. Later in the course, they design a Arduino-like library to run on a RISC-V core built on a FPGA.

The paper is well structured, with proper explanations of each step they take, citing the previous projects they re-use, lessons learnt, etc.

Author Response

We thank the reviewer for their efforts in reviewing our work.  We have used all the reviews and completed a full edit pass to improve the paper.

The paper is well structured, with proper explanations of each step they take, citing the previous projects they re-use, lessons learnt, etc.

We made a specific attempt to improve the introduction and structure of the work with some summary tables to help the reader with our work.

Reviewer 4 Report

This paper reports experiences of project-based learning to undergraduate students, using a simple RISC-V processor and a microcontroller system based on RISC-V. Students successfully added functionalities of caching and multiprocessing to the processor, and some hardware extensions to the system.

It can be commended that a sufficiently detailed description of the processor and the system. However, there is room for improvement in the introduction section. That is why the reviewer recommend this manuscript as conditional acceptance.

The authors should revise the manuscript to meet the following two conditions.

(1) The contribution of this paper should be clearly described in the introduction section.

The reviewer understood that practical experiences were given to students through the two projects. They seem to have common points that they used RISC-V architecture and they are implemented on DE2-115 boards. However, continuity of these projects is not clear. The authors' arguments by looking back the projects should be clarified.

(2) The introduction section (and the conclusion section if needed) should be revised in order to clarify the relationship between the XLR8 board and the projects.

The projects were performed with the DE2-115 board, according to Sections 3 and 4, but a straightforward reading of Section 1 may lead to a misunderstanding that the project was carried out with the XLR8 board. Do the authors argue for advantages of implementing an Arduino-like system with RISC-V? And do they think that the XLR board is a very platform to this end? Even supposing so, it is a foresight of the project and it should be mentioned in the conclusion section.

In addition, the reviewer found some typoes: prototpye (l. 245), programmaed (l. 410), and intterupt (l. 490). Please recheck the manuscript thoroughly.

Author Response

We thank the reviewer for their efforts and comments.  We have made the following to improve the paper:

However, there is room for improvement in the introduction section. That is why the reviewer recommend this manuscript as conditional acceptance.

The authors should revise the manuscript to meet the following two conditions.

(1) The contribution of this paper should be clearly described in the introduction section.

We have added a traditional itemized list of contributions to the introduction.

The reviewer understood that practical experiences were given to students through the two projects. They seem to have common points that they used RISC-V architecture and they are implemented on DE2-115 boards. However, continuity of these projects is not clear. The authors' arguments by looking back the projects should be clarified.

The reviewer makes a good point here.  The problem with linking the two projects is in the details and complexity of the two tool flows.  We have included this reasoning in the last paragraph of Section 4: "We note that this creates a disconnect between the two educational activities as the students are not using their own RISC-V processors in the second step.  However, the complexities of real compilation flows would require that in the creation of a RISC-V processor, significantly more details are considered and a larger ISA is implemented.  For this reason, we believe that instead of spending undergraduate time on implementing low-level details are left out, we start with an existing RISC-V processor that works with a real compilation flow. "

(2) The introduction section (and the conclusion section if needed) should be revised in order to clarify the relationship between the XLR8 board and the projects.

The projects were performed with the DE2-115 board, according to Sections 3 and 4, but a straightforward reading of Section 1 may lead to a misunderstanding that the project was carried out with the XLR8 board. Do the authors argue for advantages of implementing an Arduino-like system with RISC-V? And do they think that the XLR board is a very platform to this end? Even supposing so, it is a foresight of the project and it should be mentioned in the conclusion section.

The reviewer is correct in this regard.  We have added the following to the introduction at the end of that paragraph to not mislead the reader: "Note, however, in this work we provide a demonstration of our two educational activities on an FPGA available on the DE2-115 and not the XLR8; we, however, believe platforms such as the XLR8 will allow for our ideas to be cheaply actualized across a CpE curriculum in the near future."

In addition, the reviewer found some typoes: prototpye (l. 245), programmaed (l. 410), and intterupt (l. 490). Please recheck the manuscript thoroughly.

We have fixed these typos and made a full pass of the paper attempting to catch as many errors as possible.

Round 2

Reviewer 1 Report

Thank you for your answer and for including the clarification sentence in the conclusions. I understand your point and I still think that it should be interesting to extend the ideas to a larger population of students (maybe in a future work?). However this is not always possible as you mention.

In any case, I think that the activities and ideas behind the paper are interesting and I recommend it for publication. 

Author Response

We thank the reviewer.  We have made improvements based on all the comments.