Untitled
EECS 150 Components and Design Techniques for Digital Systems    
CS 150 Fall 2007

TTh 2:00-3:30PM
306 Soda Hall
Home | Grades | Schedule | Calendar | Old News | Staff | Syllabus | Documents | Old Websites | Newsgroup

Old News

12-17-2007

Final Exam Location

The final exam will be held in 125 Cory, not 106 Stanley Hall, despite what Bearfacts may say. Please tell your classmates. Good luck tomorrow!

12-6-2007

Final Project Presentations

All groups must present on Friday. The presentation will count toward a small part of your project grade.

12-3-2007

Partner Evaluations

Please submit partner evaluations by Friday, December 7 at 2PM.

12-3-2007

SDRAM

A number of you have chosen to incorporate SDRAM into your project for extra credit (good choice!). Unfortunately, last semester's CP0 has a minor bug in it: it will still show 0 errors in the presence of some bugs. For example, if your SDRAM controller fails to initialize (by never asserting the Ready signal), the testing mechanism inside the black box will never start, so it will show 0 errors because it didn't test anything.

Here's how to test if your SDRAM module is really working:

  • Set all of the dipswitches to 0 and reset the board.
  • The output of the LEDs is the error count (it should be 0).
  • Switch switch9[2:1] to 01 - it should read c6c042d2.
  • Switch switch9[2:1] to 10 - it should read 89419813.
    • Now press switch2 - it should read 16422d91.
    • Push switch 2 again - it should be 2c845b22
    • Continually pressing switch 2 will keep generating random outputs.

Additional notes:
  • The "Ready" signal is really a "done initializing" signal that is used by the black box to kick start the read/write requests. Once the black box sees the Ready signal, it will rapidly fire a series of write requests, followed by a series of read requests, without checking the "Ready" signal. Thus, the Ready signal is only used once, so if you lower the "Ready" signal to perform an Auto Refresh, you won't pass the test, because your controller will miss the requests.
  • Previous semester's students did not have to implement the Auto Refresh counter because the SDRAM was read often enough so that the data never deteriorates. However, if you are using SDRAM to store audio, you will most likely have to issue Auto Refresh every few microseconds (but don't implement Auto Refresh for CP0 of last semester, because the black box assumes that you won't be using it).
  • The black box assumes you will use a burst length of 8.
  • The RAMDone signal should be asserted the same cycle that the last piece of data in the burst is valid.
  • If you have more questions, don't hesitate to post on the newsgroup.


12-3-2007

Labs and Final Report

No labs this week. Please work on your final report. We've printed out some sample reports from last semester and put them at the TA station.

12-1-2007

Extended Late Deadline

Due to Xilinx license server issues, the 90% credit deadline will be extended to Sunday 11:59PM.

11-30-2007

CP4 Deadline

Checkpoint 4 deadline has been extended to 11:59PM on Friday November 30. You may submit by 11:59PM on Saturday for 90% credit, or Sunday by 11:59PM for 80% credit. We will not be accepting submissions after 11:59PM on Sunday.

11-29-2007

Extra Credit

We will accept and evaluate extra credit features next week during presentations. Groups that checked off this week are still eligible for extra credit next week. Keep in mind that extra credit features must be built on top of the basic project (not in a separate bit file) and should not break your original phone.

Although you have this extra week to extend your project, please do not cut back on the quality of your final report to work on extra credit. We will be grading the final reports very carefully and expect very high quality writeups and diagrams.

Please return all N64 controllers and microphones next week during your presentation.

Good luck to everyone still in lab!

11-22-2007

Additional Clarifications
There are two different timeouts during an Init Call/Ack Init exchange:

  • The timeout for receiving an Init Call/Ack Init packet
  • The timeout for receiving an Accept Call/Reject Call packet

The first timeout period should be 1 second, corresponding to a dropped connection. The second timeout period should be 15 seconds, corresponding to an ignored call.

Sorry for the confusion.

11-19-2007

Checkpoint 4 Clarifications
Please note that the serial width for the shift registers in the audio buffer is 16 bits, not 32 bits, so each packet of audio data should hold 20 samples.

Also, the timeout period for the Init Call/Ack Init exchange should be 15 seconds, not 1 second. You don't want to only have a 1 second window to accept a call. See above.

11-13-2007

Checkpoint 4 Update
An important update has been made to Checkpoint 4 regarding the audio buffer. The use of the small synchronous FIFO (audio_fifo) we provided is required for functionality. You will need to use it properly buffer incoming data from the wireless transceiver. Please read the spec for additional details.

10-22-2007

IMPORTANT ANNOUNCEMENTS
Please read the entire post!

Checkpoint 2 Updated
The checkpoint 2 files were updated to include the checkoff sheet.

Checkpoint Due Dates
The due dates of all checkpoints are getting pushed back by one week!

  • Checkpoint 2 is now due in Week 10 (week of 10/29).
  • Checkpoint 3 is now due in Week 12 (week of 11/12).
  • Checkpoint 4 is now due in Week 14 (week of 11/26).
  • Checkpoint 5 is being merged with Checkpoint 4.

Note that the dates for design reviews will remain the same, i.e. one week after the lab lecture for that checkpoint. Thus, the design review for checkpoint 3 will still happen this week!

Use this extra week to catch up on checkpoint 1 and 2, come up with a good design for checkpoint 3, study for the midterm, or catch up on sleep .

Design Documents
A specification on what to include in your design documents has been uploaded. We expect the design documents for Checkpoint 3 to follow all these guidelines. Although we have been lenient in the past, we will begin to grade the designs more critically to ensure that you have thought through all aspects of the checkpoint. There is a high correlation between the amount of time a group spends on their design document and their likelihood of successfully completing a checkpoint.

Submit Lab5 (Network Audio) Code
This is optional, but if you still have your Lab5 code, please submit it to cs150fa07@gmail.com. Ofer will be walking through the solution for Lab5 in this Friday's lab lecture. We would like to get an idea of the different design choices that were made.

Grading of Verilog
For all future checkpoints, including Checkpoint 2, 10% of the checkpoint grade will be based on Verilog style and synthesis warnings. Multiple major synthesis warnings such as latch generated, combinational loop, incomplete sensitivity list, and/or port width mismatch will result in a 0% for this section, even if the synthesized design works.

Food in Lab
Although food is allowed in the lab, it must not be brought to the stations. Also, please make sure all spilled drinks and leftover food is cleaned up and thrown away. We've received some complaints about this.

Review Session
Review session for the midterm will be held next Tuesday, October 30, from 8-10PM in 125 Cory. Food will be provided again!

- CS150 Staff

10-22-2007

CHECKPOINT 3
A TA solution bitfile has been uploaded in the Checkpoint3 zip file. A readme file describes how to set channel, source/dest address, etc. The FPGA Top file provided to you should behave exactly as the TA solution when your transceiver is intantiated within it. For now, the transmit rate is substantially slower than it will be for the final checkpoint, but we want the channels to remain relatively clear during this early phase of the project. Also worth noting are that there are discrepancies in the length field in the spec and the lab lecture. The packet size will have a 41-byte payload. I have updated the checkpoint spec, but the ultimate source of all your information should be the CC2420 documentation.

10-09-2007

Microphone Test bit file
The microphones that we gave you should all work when we gave them to you as we tested them. However, if they break or you think they may not be working or the board microphone input isn't working, we have added a microphone bit file to the website (MicTest.bit), that will output to the speakers what you are saying into your microphone.

10-11-2007

LAB 5 MICROPHONE
If you or your partner did not receive a microphone in your lab, please make sure that you are at lab lecture, as we will hand out microphone to those groups that did not already receive one.

10-09-2007

IMPORTANT ANNOUNCEMENTS REGARDING LAB 5 AND THE PROJECT
Please read the entire post!

Topics of this post include:

  • Lab 5 (Chipscope)
  • Project
    • Design Reviews
    • Checkoff Procedures and Code Submission
    • Late Policy and Slip Days
    • Partial Credit / Black Boxes

Lab 5 (Chipscope)
  • We've noticed that many groups are retroactively putting Chipscope into their designs after getting audio output working. These groups have missed the entire point of this lab, which is to learn how to use Chipscope to debug hardware.
  • Perhaps we didn't emphasize this enough, but Chipscope will be absolutely essential in helping you debug your project. The sooner you start learning the ins and outs of Chipscope, the better off you'll be when working on the project.
  • Note that in Lab 5, you will be required to demonstrate your knowledge of Chipscope in reading the signals coming in and out of the FIFO (as indicated on p.5, section 4.1 of the lab document).


Project

Design Reviews
  • Prepare a thorough design document for each project checkpoint.
  • Worth 10% of your checkpoint grade.
  • Due within the first 10 minutes of your lab section.
  • Both partners must be prepared to discuss and defend the design
  • we will be asking both partners questions!
  • **IMPORTANT** Please make a copy of your design document before your design review! We will be keeping a copy for grading purposes. You don't want to be stuck without a design document.
  • We suggest using Microsoft Visio to make the block diagrams and FSMs. This is beneficial for several reasons:
    • You'll have your own copy after we collect your document for the review
    • Diagrams are easier to read
    • You can reuse the diagrams for the final report.
  • Although we did not explicitly require timing diagrams for the first design document, we highly recommend making some timing diagrams for the first checkpoint, especially for the tricky SDATA_IN signal Udam mentioned.
    • You might find this stencil useful for making timing diagrams in Visio:
    • http://www.mvps.org/visio/FTP/TIMEDIA.VSS
  • Recall, your design document should be thorough enough so that any other group can implement the entire checkpoint based solely on your document.

Checkoff Procedures and Code Submission
  • For each project checkpoint, you will be required to submit the bit file for the checkpoint and all relevant Verilog and black box modules.
  • Email your submissions to cs150fa07@gmail.com
  • Submissions are due within the first 10 minutes of your lab section (see section below for policy on late submissions and slip days)
  • During your checkoff, we may ask you to synthesize your design on the fly and/or ask you questions about the checkpoint.

Late Policy and Slip Days
  • We are granting each group a total of four (4) slip days to distribute among the entire project.
  • Slip days are rounded up (e.g., if you are in a 5-8PM lab, and we receive a submission at 5:21PM, it counts as an entire slip day) You may submit as many times as you like within a slip day.
  • SLIP DAYS ARE NOT APPLICABLE ON WEEKENDS
    • The latest we will accept a project checkpoint using a slip day is Friday 5:09:59PM.
    • This is to prevent you from falling behind on later checkpoints (see section below for partial credit black box policy).
    • We realize that students in the Thursday evening section will only be able to use at most one slip day per checkpoint, but they have the advantage of having the most days after lab lecture to work on the checkpoint.
  • Stay tuned for policy on late submissions after all 4 slip days have been used.

Partial Credit and Black Boxes
  • For each project checkpoint (except perhaps the last), you will have the choice of accepting a 0 on the checkpoint in exchange for a black box implementation of the checkpoint.
    • However, you may redeem up to 50% of the points if you can fully fix your checkpoint within two weeks after the checkpoint is due.
    • The black box will allow you to move on for the later parts of the project.

Again, please make sure to read the entire post.

Good luck with the project!
-Allen

9-28-2007

Mid Term 1 Results

Max: 97
Mean: 70
Median: 71

Range %Count 00-39 | 00% | 0
40-49 | 03% | 2
50-59 | 22% | 13
60-69 | 24% | 14
70-79 | 27% | 16
80-89 | 17% | 10
90-100| 7% | 4

9-28-2007

The midterms have been graded. Please pick up your exam in discussion or lab lecture today.

9-26-2007

HW4 Solution posted.
As per discussion in class, one page note sheet permitted on Midterm 1.

9-25-2007

Mid 1 review session, Tu 8-10 in 125 Cory.
HW4 due wed 2 pm, so solutions can be posted.
Mid 1 thurs, 2-3:30 in 125 Cory. Lecture & Reading material thru Tu.
No Discussion Th.
Yes, labs this week.
Yes, discussion and lab lecture on friday.

9-15-2007


HW3 is posted.

9-6-2007


Lab2 is online. Please start working on it before coming to the lab.


On HW1 3 part B, you may assume for each input A, B, C you have either the input or its complement available.

Cardkey access should be ready. You still need to visit 253 Cory.

8-23-2007


Welcome to the Fall 2007 semester of CS150! Please check this web site often, as course updates and materials will be posted here. We look forward to a great semester!

-CS150 Staff

[ top | home ]

UC Berkeley http://www-inst.eecs.berkeley.edu/~cs150/ EECS 150 Fall 2007