CE /
VHDLTeachingProgresssion
Minutes of meeting from 07/03/12 lunch meeting (with updates)
Attendees: Lars, Sven, Bhavi, Alen, Magnus, Dmitry
Problem areas
Following problem areas were discussed during the meeting:
- VHDL skills of students
- Most students have not worked with records and packages. This can be fixed by introducing these concepts in labs of introduction course.
- This point is about what parts of VHDL are taught in the intro course.
- Problems adapting to 2-process method. This can also be fixed by forcing students to use 2-process method in introduction labs.
- This point is about also teaching coding style in the intro course.
- Most don't follow good coding guidelines like indentation, one entity per file, avoiding latches, proper comments, etc. Again, this can be fixed by forcing students to follow a stricter coding guidelines standard. This will also ease the work of TAs when they need to review the code. Alen talked about making students use a lint like tool to help them follow these guidelines and avoid latches.
- This point is about teaching coding style in the intro course, and also about language-based hardware design in general; what hardware does a VHDL statement imply?
- The first thing we teach them about VHDL should be the translation of hardware description to real hardware. Before the DAT110 lab sessions I try to teach time why to avoid latches in flip-flop based designs (the way static timing analysis handled by default etc). We should not give the impression that latches are aliens, because I think they are very important for high-performance computing. This kind of knowledge should be moved to the introduction lecture probably so that they will have more time to digest all this complex information.
- Some students seem to be get by the labs of introduction and methods course without being proficient enough in VHDL skills, which shows up in project course. Individual lab submissions for some labs of the introduction course may be a good solution for fixing this. This will have an impact on the number of resources that needs to be looked into further. To reduce impact on teaching hours, VHDL code submissions will have to be checked in an automated fashion using a testbench.
- This point is about follow-up and examination. There are technical things that could be done here. Anurag has used a script for code acceptance which sticks the submission into a testbench and mails back a result. [Angelos feels it could be improved.] Would something be gained by handling submissions in PingPong? Can an automatic evaluation procedure be linked to PingPong? [Peter L says no.] What can the Fire system do (it is used for managing lab submissions in many programming courses)? [Apparently it cannot automatically run things.]
- Of course, eventually no automatic system can stop students from "floating along". More careful examination is needed as a safeguard. In the mixed-signal course, the lab series is concluded with an individual oral exam of the contents. Takes time but might be possible as the number of students in the intro course is quite small.
- Most students have not worked with records and packages. This can be fixed by introducing these concepts in labs of introduction course.
- Hardware design skills
- Is it clear that the issues are because of lacking VHDL skills or might it be lacking hardware design skills?
- This point connects to Alen's point above.
- Make sure that students are comfortable with basics and actually understand what they design. Simple examples are usually most rewarding. One of Dmitry's favorites is an edge detector, since it quickly checks if students understand signals, clock, registers, and the concurrent nature of hardware.
- Is it clear that the issues are because of lacking VHDL skills or might it be lacking hardware design skills?
- Debugging skills
- Some students may not be up there when it comes to efficient debugging, but it's difficult to gauge and even more difficult to teach. No conclusions were made about it at this point.
- In-circuit debugging using an embedded logic analyzer (ChipScope, if Xilinx) is a must if students are working with FPGAs. This debugging methodology should be introduced as early as possible.
- Co-simulation could be introduced. It is especially practical for DSP applications. Hardware-in-the-loop might also be handy.
- Tools proficiency
- Most of the attendees were of the opinion that tools per se is not a big problem. But some students show resistance to using the linux environment in project course. Magnus suggested that it may be fruitful to use linux in introduction course so that students have similar environment across all the VHDL courses. Alen suggested using ncsim in introduction course, so that students are better equipped for first lab of methods course. But it was pointed out that only methods course is using ncsim, and it may be more efficient to switch ncsim to vsim in methods course, if required.
- Linux is used heavily in both the tools course and in the circuits intro course; but there mostly as a host for Cadence. There is no real exposure to Makefiles, compilers, etc.
- Most of the attendees were of the opinion that tools per se is not a big problem. But some students show resistance to using the linux environment in project course. Magnus suggested that it may be fruitful to use linux in introduction course so that students have similar environment across all the VHDL courses. Alen suggested using ncsim in introduction course, so that students are better equipped for first lab of methods course. But it was pointed out that only methods course is using ncsim, and it may be more efficient to switch ncsim to vsim in methods course, if required.
- Toolchains
- Many students have a hard time dealing with working in the framework of GRLIB in project course and handling the toolchain involved in the project. Bhavi pointed out that this should be okay as this is one of the things they need to learn during the project course. Magnus suggested more lectures in the project course to teach students about GRLIB framework.
- C skills
- Some students have not worked with C, especially with pointers, and have a hard time understanding the mpg123 source code and writing code for talking with hardware modules. Magnus suggested introducing a lab in methods course for hardware/software interaction.
- This point is about what is taught in the methods course.
- Some students have not worked with C, especially with pointers, and have a hard time understanding the mpg123 source code and writing code for talking with hardware modules. Magnus suggested introducing a lab in methods course for hardware/software interaction.
Minutes of meeting from 21/03/12
Attendees: Lars, Sven, Bhavi, Alen, Magnus, Arne
- VHDL Skills
- Lars pointed out that if a student has no previous experience of VHDL or Verilog in EESD program, then we have made a mistake in admitting him to the program.
- Existing introduction course labs can be modified to use records and packages. Sven suggested defining the input and outputs ports of the top module as records.
- 2-process method can be introduced as part of coding guideline for the introduction labs.
- Various suggestions were discussed for coding guidelines. Magnus and Bhavi suggested strict checking and returning labs if students don't follow coding guidelines. Lars suggested giving feedback for individual labs and ask students to submit all the labs at the end with all guidelines followed.
- For preventing students from 'floating along', first 2-3 labs of introduction course can be made individual. Lars suggested interview of individual students at the end of course to make sure that they know their stuff before passing the course.
- Automated testing of lab submissions was discussed. Arne was concerned that Anurag's automated testing method is not very efficient since it can only capture 25% of submissions. This is because many students don't follow the port specifications like reset polarity and port names and it results in a lot of back and forth of submissions. This can be dealt with by specifying strict port specifications. Full/partial testbenches may also be made available to students so that they can test their code before submitting.
- Hardware design skills
- Students can be told to show their designs on paper before working on the actual VHDL code like being done in methods course.
- Debugging skills
- For debugging, students can be given access to tools like chipscope as Dmitry suggested. It needs to be decided if it should be introduced in introduction course or project course. Since, students have more time to play with tools in project course, it may make sense to design a lab to use chipscope there.
- Tools
- For now, introduction course labs can continue to be hosted on Windows platform.
- Toolchains
- More GRLIB lectures should be arranged in project course.
- C skills: There can be a (optional) lecture + lab on hardware related constructs of C
- Hardware/software interaction: It may be a good idea to introduce a lab in methods course to introduce a lab for hardware/software interaction.
To do:
Lars + Alen:
- Sending out pointers to Linux tutorials
- Sending out VHDL pointers + tools / self-test of VHDL skills
- Coding design rule sheet + Design patterns reference?
Sven:
- Re-design intro labs for including records/packages
- (Automated) testing framework for intro labs
Bhavi:
- GRLIB lecture development
Jacob:
- C-lecture and/or lab for hardware constructs in project course
Per LE:
- HW/SW interaction moment in methods course
Dmitry:
- Chipscope lab for project course