Summer of Gateware
This (last) summer the MyHDL project participated in the Google Summer of Code (GSoC) as a sub-organization under the Python Software Foundation (PSF). This was our first year participating - there was a lot for us to learn. Overall it was a worthwhile and beneficial activity.
Being a first time sub-org we were limited to a maximum of two students. We had nine students apply and twelve mentors volunteer. Only being able to select two students was a difficult task but one that was dictated to us for fair reasons (past experience has steered PSF to this guideline). We were prepared for the student proposal and application portion of the process. We had created our project ideas and application template pages and started interacting with students. Many of the students were recommended by users/developers of the MyHDL community - this step was easy.
Since we had more project ideas than students our 2016 project ideas are already posted. Students that want to get a jump on next year can start interacting with the community and inquiring about projects.
We had structured the projects into two categories: first creating hardware designs using MyHDL and second, contributions to the MyHDL project. As stated in the MyHDL development guide one of the best ways to support the MyHDL project is to build a design using MyHDL:
The interaction with students during the pre-application (introductory) period went well (communication mainly on IRC but not limited). After breaking the ice the next step was to get the proposals and applications in by the deadline. Getting students to complete their proposals with plenty of time to receive feedback from the MyHDL community was a little more work. Mainly because they are students and procrastination rules (true for many of us, student or not). To be fair, they are students and they have their course work and many have part time jobs.In particular, the best way to help is to use MyHDL in design projects and let people now about it. If you want, you can use the users section on the MyHDL site.
We also ran into a little hiccup not meeting one of the PSF requirements for proposal submission. I had mis-interrupted the emphasis PSF had on the prospective student patch to the project versus an applicable working code sample. The Project Proposal Information mentioned “patch/code sample” so I had all the students prepare a MyHDL “code sample” in the proposal. This was a costly mistake and caused some frustration by the students but we were able to move on past this issue.
Early and frequent interaction had the largest impact on student acceptance. Students that completed their proposal and patch (once we corrected our trajectory to create a patch) with plenty of time to receive feedback and make updates were more likely to be accepted.
Once the proposals were in and we received notification whom was selected - we were off. As mentioned, we had two students: one was working on improvements to the MyHDL conversion code and the second developing an SDRAM controller using MyHDL.
After the students were notified of their acceptance, the community bonding period began. The community bonding allows the students to become more familiar with the project if needed. One of the students had contributed to the project previously and the other was new to the project. There wasn’t too much “bonding” during this period.
During the project period it was a little up and down. One of the students had some issues at the beginning but was able to recover before the midterm and maintain reasonable progress through the rest of the project. At other times there were longer gaps in communication than we would have liked.
This is a very common challenge with GSoC: keeping the students on track and making consistent progress. This is important, the students agreed to the Participation Terms. To make sure that both the host organization (Google), the mentoring projects (PSF+MyHDL), and the students are getting the most out of the program (i.e not wasting anyone's time or money) the students need to uphold their end of the agreement by putting the time and effort defined in the Participation Agreement.
One metric (not all inclusive) we can use to determine if the students completed their projects successfully is to compare the goals/milestones in the proposal to the actual completed tasks. The following table outlines goals and milestones vs. end of project completion. Retrospectively, I am not as concerned if the milestones were completed “on time” because things shift around during the development period. This also is not a quantitative metric because the projects evolve (or devolve) over time as the students learn more.
Goal/Milestone | Completed | Comment |
---|---|---|
SDRAM model | yes | This was intended to be a quick task but took longer than expected (much longer) |
set of tests (TDD) | yes | Some basic tests were created but a more comprehensive set of test was desired. |
first pass design with minimal features | yes | |
full design | yes | |
design tested and verified on hardware | yes | |
modular design | no | Not called out in the student’s milestone but the project idea defined the design to be reusable (modular) with many SDRAM |
remove dead code | yes | there was significant cleanup committed to the code base |
refactor core decorators | yes | this was completed for the most part but has not been integrated into the code base |
modernize test suite | yes | |
centralize symbol tables | no | |
simplified AST | no | demonstrated useful benefits of the implementation |
In the above table “no” does not indicate progress it simply indicates if the goal / milestone was committed and merged into the destination repository. A couple of the “no” had significant progress and will be included in the future.
Note, the above table alone is not enough to determine if a student did well or not. The table along with the trackable-effort (e.g. blog posts, community inquiries) supply the information to determine if a student was successful. Between the goals met and the effort supplied both students had a successful summer of coding.
Both these efforts have, and will, make a positive impact on the MyHDL project.
End results from the students
@jck: blog, PR#1, PR#2, PR#3, PR#4,
@udara28: blog, SDRAM git repo
Additional information
More information on MyHDL and the MyHDL GSoC can be found in the following links:
- Comments
- Write a Comment Select to add a comment
To post reply to a comment, click on the 'reply' button attached to each comment. To post a new comment (not a reply to a comment) check out the 'Write a Comment' tab at the top of the comments.
Please login (on the right) if you already have an account on this platform.
Otherwise, please use this form to register (free) an join one of the largest online community for Electrical/Embedded/DSP/FPGA/ML engineers: