CSCE 612 - HDL-based Design for VLSI Systems

Spring 2003: Exam #1 Commentary

I'll have a number of things to say here, as I will not be taking up class time to discuss the exam.  It has taken me a long time to grade due to (1) I could not get effective grading the way I wanted it to be done, requiring me to do it myself), and (2) I wanted to provide important, personalized feedback as to the coding styles being used on the exam problems.

This exam was a long one.  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.  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", hoping I would give partial credit for you in solving it a different manner.  Well, I *did* give partial credit if you solved it in a different manner.  However, you need to remember that, when you go to work for some company, they will likely have specific coding standards and "idioms" that they will expect you to follow.  Keep that in mind.

Exam #1 Grades:

Scores ranged from 73 to 100 (yes, someone got all of the modeling problems correct).  The distribution looks as follows, and the mean and median scores are shown below.  The general pattern in the scores indicated to me that higher scores highly correlate to those students that attend class on a regular basis.  A number of you don't attend class regularly, for whatever reason and, therefore, miss important information that I may give out regarding lecture topics and problems to be covered on the exam.  Don't rely on others to take notes or cover for you!  Participate in class, as this is where you have opportunity to learn.  If you haven't been coming to class (and I know who you are!), and you haven't given me a good reason as to *why* you don't come, then don't expect any favors.

Exam #1 Points:

NOTE:  I tried to grade this exam (as I do all exams) as consistently and correctly as possible.  But, when looking over 40 exam papers during a span of several weeks--which is what it took for me to get these back to you (my apologies), I'm bound to make some mistakes.  So, check what I have given you and make sure you understand what points I have taken issue with and how I have graded them.  If you have questions, come see me.

Problem #1:

1.1   I did not take off points for missing WHEN OTHERS clause in the case statement.  Since we had not covered MVL logic by this time, you weren't expected to know that it might be possible to have logic values other than those in the enumerated list.  This is what the WHEN OTHERS is for.  Remember, program "defensively" and anticipate potential problems before they happen--this is the secret to building in Quality into your designs.

1.2   I generally only took off a point or two for small syntax errors (such as ";", "=>", etc.)

1.3  The sensitivity list in part 1a should have had all 3 signals; however, some of you had only S, or only A, B.  The way the first part was stated, I wanted to you to state it in as general a manner as possible.  Some of you placed only S in the sensitivity list, which meant that the MUX would only sample its inputs when the MUX select value changed; this is not the semantics of the MUX behavior.  The only way to correctly state the sensitivity using the Sensitivity List is to place all 3 signals in it.

1.4  In part 1b, the WAIT  statements should have either been embedded within the CASE branches, or outside the CASE statement entirely but within the process.  You could have placed the WAIT  statement either before the CASE or after it.  The behavior would be different, in terms of when the process would execute initially, but I wasn't specific about this behavior in the problem, so I accepted both renditions.  The issue of having the WAIT inside the CASE branches meant that one would be sensitive to A | S, the other would be sensitive to B | S.  Placing the WAIT outside was trickier, as you didn't want to have the process completely sensitive to all three signals, as this behavior would have been no different than the solution for part 1a.  In this case, you'd need to make the process sensitive to changes in either A | B.  It is not the best solution; the best one is to have the WAITs inside the CASE branches for the best interpretation of the MUX semantics.

1.5  For part 1c, vague wording was unacceptable.  Either you understood that the WAITs inside the CASE branches made the process more selective to specific inputs (where it wouldn't re-evaluate for B when it was A that changed, for example).  The issue for this answer was recognizing the scope of sensitivity of the signals in the WAIT  statements and their placement, not anything to do with delay timing.

1.6  Some solutions had the WAIT for a prop_delay, then had the assignment.  This means that the assignment occurred after prop_delay + the delta delay.  This was not correct.  I counted off a couple of points for this.

1.7  Some solutions had separate WAIT statements on A, or B, in the CASE branches, then had another one outside the CASE, on S.  This has the effect of WAITing on A *and* S, or B and S, *not* A or S, or B or S.  Note the difference in the semantics of these.

Problem #2:

2.1  Many of you didn't initialize the values of the individual bit output signals, or set their values when setting one of the outputs of the decoder to '1'.  Since these are all active outputs, you have to either (1) initialize the values to '0', which may or may not work (some of you I have asked to verify your answer via simulation in ModelSim, so that I can give you back the 5 points I took off for this approach), (2) set the values to '0' in the process body, so that each time the process executes, it sets all the other values to '0', or (3) set the values inside the CASE branch itself (which was a cumbersome way to do it, but was correct nonetheless).  This was worth 5 points.

2.2  There were issues about the WAIT statements and the CASE statement, much like the problems some of you had in problem #1.

2.3

2.4

2.5

Problem #3:

3.1  There were a number of syntax errors, in the direction of association operator versus assignment operators.

3.2  The use of a variable assignment style for initializing the values of signals, in my opinion, should be an error; I counted off a point or two for it.  But, as I have been shown, Ashenden shows it as legal syntax in that context.  So, if I took of points for this, see me and I'll give the point or two back.

3.3  Also, on this topic of value assignment, for the associations of values with locations in the truth table array constant, these should be as association operators, "=>", not assignment ":=".  I took off a couple of points for that.

3.4

3.5

Problem #4

4.1  The component instantiation style was what I was looking for here.  I know there are other ways to do it, such as through straight entity implementation.  But I explicitly asked for the other style.  For those who have questioned whether I covered this, I did.  Here is the original example, as discussed from one of the early lectures from Ashenden:  VHDL-quick-start-Ashendenp20-21.pdf  This counted 3 points.

4.2  Also, some of you attempted to reference your entity instantiations (or component instantiations) inside the body of a process.  This is illegal code style, as the entities, by definition, are concurrently executing structures, so they can't be bound inside a sequentially executing set of statements inside a process.  This was worth 5 points.