CSCE 612 - HDL-based Design for VLSI Systems
Spring 2003: Exam #2 Commentary
I'll have a number of things to say here, as I will not be taking up class time to discuss the exam. The exam was complex, involving evaluation of a number of different and interrelated concepts--usually very difficult to evaluate in the course of an exam. It required you to write substantive program parts. I asked for things to be presented in a specific manner.
The first comment I have is that a number of you didn't follow my explicit instructions--just as on Exam #1. This may be because you didn't read them carefully, or because you didn't know how to solve it in the manner requested, and therefore "punted". A number of you figured out a way to present me with the information I asked for in a method that allowed you to not have to rewrite substantive parts of the solution for the given model in each problem and its sub-parts. For those of you who didn't figure out such a strategy, this is where you probably lost considerable time in completing the exam.
The 4 problems were graded like this: #1 was graded in great detail, as it asked for most of the elements of the design model that were also requested in subsequent problems on the exam. You needed to show me whether you could do this well on problem #1. Many of these aspects I didn't grade as closely on the later problems. In problem #2, there were some different aspects of the solution that I was looking for, which some of you figured out and showed me quite elegantly. (Here's a secret about taking exams: a big part of the problem to be solved is the "meta-problem", the problem of the problem itself and presenting its solution clearly, concisely and forthrightly, so that the examiner--in this case, me--can evaluate whether you have command of the material or not.) What I found was a strong correlation between those students who took the time to come up with a problem-solving strategy and a "reporting" scheme, and those who made the higher marks.
Now, when we get the Problems #3 & 4, we run into difficulty. Very few figured out how to implement the given model using VHDL functions. A large number of you didn't declare the functions properly, then many of you neglected to consider the difference between Procedures and Functions in this regards, namely, that (1) a function must be used in the context of an expression, and (3) a "pure" function can return only a single argument. So, for the block decomposition of the ALU, some of the functions for these blocks had to follow the partitioning in terms of a different function for each output signal from the design unit under consideration. For example, the Adder unit needed to be implemented with two functions, one for generating the Sum and another one for generating the Carry Out. I also found a number of problems with Problem #4 in that a number of you had difficulty with the declaration and referencing of Components along with the use of Generics.
The specific problems students had with problem #3--almost everyone, were: (1) function declarations cannot be made with blocks that have more than a single output signal--you must break the block's functionality into multiple functions, one for generating and returning each output signal result, (2) function calls must be made in the context of an assignment statement; this is one of the distinctive properties of Functions versus Procedures in VHDL, and (3) because assignment statements can be concurrent, the function calls could be executed concurrently, unlike Procedure calls, which must be bound within the body of a process. This implies that the passing of values between the functions was also at issue, which few students seemed to grasp. Ashenden is very clear on these points, and we discussed them in detail. As for Problem #4, the main issue was the use of Generics with the Components (many students missed this entirely) in the Component declaration, and then the use of Port Maps and Generic Maps with the instantiation of the components (again, missed by most students).
In many cases, students neglected to include the requested information about the Packages (part b of each problem) for Entities, Procedures, Functions and Components. Those that did answer these parts of the 4 problems did so usually by referring to constructs they had written for the other parts of the problems, and inserting the appropriate Package and Use statements accordingly.
In assessing the exam and its effectiveness at determining what you knew as individuals (what I was after), which is known as "instance selection", I told the class prior to the exam *exactly* what was going to be on it. Yet I was surprised by how many students didn't seem to be prepared. Was this due to the fact that so many of you generally weren't coming to class, and were relying on the memory of others to tell you about what is going on in the class? (Note that it is the policy of the University that the instructor for a course has the option to drop the student by a letter grade for "excessive absences" from class, for which I have probably 2/3rds of the class who fall into this category--this is just a side note, but again, I find that the excessive absence from class directly correlates to performance on my exams--in most cases, although not in all.)
However, I also expect some of you simply "shut down" when you see my exams. I don't make them hard. I make them involved--which usually means that if you don't know how to set up the problem effectively for solution (what I referred to as developing a strategy for the "meta-problem"), then the exam is a long road to travel. Assessing command of a programming language in the context of design problems-solving is admittedly difficult in the confines of an in-class exam. But this is the *only* means where I feel I can actually assess each student's problem-solving capability--without the normal conversing that goes on under other circumstances. Know that I am continuing to try to find a balance in my need to asses you as students on an individual basis, with the need to assess you in the context of the design projects (usually team-oriented), as well as conduct examinations that fit the format of the classroom environment. I have no way to check whether all of your work is your own on the projects--regardless of team-orientation or individual work. This speaks to the old expression that "two heads are better than one", and why not many heads??? However, this is a big part of what is required by the academic standards of the University, and what you must all demonstrate in the context of my design courses. You have to show me that YOU, as an individual, have mastered the material. In that regard, I want to give you every opportunity to do so.
'Nuff said.