DOC PREVIEW
Berkeley COMPSCI 150 - Checkpoint 1 N64 Controller

This preview shows page 1-2-3 out of 9 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1.0 Motivation2.0 Introduction2.1 Bidirectional Serial Protocols2.2 Asynchronous Serial Protocols2.2.1 Transmitting2.2.2 Receiving2.3 N64 Commands2.4 N64 Serial Bit Timings3.0 Prelab4.0 Lab Procedure4.1 N64.v4.2 N64Controller.v4.2.1 Self Testing5.0 Checkpoint 1 Check-offEECS150 Spring 2006 Checkpoint 1UNIVERSITY OF CALIFORNIA AT BERKELEYCOLLEGE OF ENGINEERINGDEPARTMENT OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCEASSIGNED: Week of 2/28DESIGN DUE: Week of 2/28, 10 minutes after start (xx:20) of your assigned lab section.CHECK-OFF DUE: Week of 3/7, 10 minutes after start (xx:20) of your assigned lab section.Checkpoint 1N64 Controller1.0 MotivationThis checkpoint serves two purposes:1. Create the first and simplest module for your final project: a module toreceive and process input from the N64 controllers.2. Acquaint you with bit serial bus communications.With the first goal in mind you should make sure to design your verilog ahead oftime, comment you code and test everything thoroughly. Because you will be keepingand relying on this code for months, it will actually save you many stressful hours toensure it works well now, rather than when you are about to finish the project.Once upon a time it was too expensive to run parallel wires to form multi-bitbusses as board and chip space were tight. Over time, as board space became lessexpensive and chips got bigger and more complicated, serial busses became tooinefficient simply because they couldn’t run fast enough, leading to a change to mostlyparallel busses. In recent years however serial connections have become more importantagain with USB, 1GB Ethernet, SATA, PCI-Express, I2C and SPI not to mention thestandard PS/2, RS232 and RS485 systems which have been around for decades. As suchlearning to work with bit-serial protocols is a vital part of EECS150 and any digitaldesign course.“BECAUSE YOU WILL BE KEEPING AND RELYING ON THIS CODE FOR MONTHS, ITWILL ACTUALLY SAVE YOU MANY STRESSFUL HOURS TO ENSURE IT WORKS WELL NOW,RATHER THAN WHEN YOU ARE ABOUT TO FINISH THE PROJECT”2.0 IntroductionIn this checkpoint you will be build what is at its heart nothing more than a shiftregister, or perhaps a pair of shift registers, implementing a polling controller. Thesections below outline a more exact specification of how your circuit will need tooperate, but the basic operation sequence is as follows:1. Wait for initialization purposes2. Send a 8bit “Get Button Status” command to the N64 Controller3. Receive a 32bit button status word4. Return to step 2UCB 1 2006EECS150 Spring 2006 Checkpoint 1Of course this outline makes the checkpoint seem very simple, which is true froma functional standpoint. However for the first time, guaranteeing timing will be amajor part of your design and debugging time.2.1 Bidirectional Serial ProtocolsBecause the interface between your circuit and the N64 controller isbidirectional, bit serial and asynchronous, it presents several interesting design pointsthat a normal point to point unidirectional bus does not. For example, in a single sourcebus, there is no need for arbitration because only one module ever drives the bus,whereas in a bi- or multi-source architecture, there must be some scheme to preventmore than one module from driving the bus simultaneously.The most common solution, historically called an open-collector bus, is to use apullup resistor as shown in figure 1 below to keep the serial data line high at all timesand then pull the line low to send a 1’b0 or leave it alone to send a 1’b1. The onlydifference between this and a fully tristated bus is the pullup resistor used to ensure thatthe line is always driven by some source, and cannot be shorted.As a mental exercise, you should try work through why this bus design cannotresult in a short circuit.Figure 1: Generalized Bidirectional Open-Collector Bus DesignTo implement this bus on the Xilinx chips, you will be using the tristate driversbuilt into the Virtex chips. Shown in figure 2 below is the exact circuit you will needto implement in order to connect the N64 controller. The entire circuit can beimplemented using a single assign statement, if you keep in mind that 1’bZ is theverilog notation for tristating a wire.UCB 2 2006EECS150 Spring 2006 Checkpoint 1Figure 2: Virtex Open-Collector Driver2.2 Asynchronous Serial ProtocolsFor many years the most common serial connection on computers was theasynchronous RS232 serial port running at 9600baud (bits per second). The main reasonthis connection survives even today is because it is electrically robust, requires only 3wires and is completely asynchronous.One of the primary reasons to use asynchronous serial protocols is to obviate theneed for a clock signal to be transmitted along with the data. Because the clock line mustswitch at a minimum of twice the frequency of the data lines, it is much harder totransmit a clean clock signal. Even if the clock could be transmitted to the other end ofthe line, this would force the systems to be asymmetric as one would be sending and onereceiving a clock, if we are to avoid any clock boundary crossing.Using an asynchronous serial protocol means that there are no clock distributionproblems, there is no power wasted in transmitting a clock, each node can be identical(they don’t have to send or receive clock signals) and we can build a large system ofidentical nodes. The cost paid is in speed and receiver complexity.2.2.1 TransmittingTransmitting is simple, bits are send out at approximately the right ratealong with parity or CRC error checking information, and some gaps betweenblocks of data. Because the protocol is asynchronous, we can just send bits out, and notworry about them; as long as the clocks at the two ends are “close enough” things willwork out just fine.Figure 3: Asynchronous Serial TransmitUCB 3 2006EECS150 Spring 2006 Checkpoint 1The CRC or parity information is used to check the data recovery in case the lineis long, or the clocks are too far off.The gaps between blocks of data are inserted in case the transmit speed isfaster than the receive speed. If the clock tolerance of the protocol is ±5%, then the busmust remain unused 10% of the time so that even if the transmitter is 5% fast and thereceive 5% slow,


View Full Document

Berkeley COMPSCI 150 - Checkpoint 1 N64 Controller

Documents in this Course
Lab 2

Lab 2

9 pages

Debugging

Debugging

28 pages

Lab 1

Lab 1

15 pages

Memory

Memory

13 pages

Lecture 7

Lecture 7

11 pages

SPDIF

SPDIF

18 pages

Memory

Memory

27 pages

Exam III

Exam III

15 pages

Quiz

Quiz

6 pages

Problem

Problem

3 pages

Memory

Memory

26 pages

Lab 1

Lab 1

9 pages

Memory

Memory

5 pages

Load more
Download Checkpoint 1 N64 Controller
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Checkpoint 1 N64 Controller and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Checkpoint 1 N64 Controller 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?