DOC PREVIEW
Berkeley COMPSCI 150 - Project Checkpoint 1 Controller Interface

This preview shows page 1-2 out of 7 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 7 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 7 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

University of California at Berkeley College of Engineering Department of Electrical Engineering and Computer Science EECS 150 R. H. Katz Spring 2001 P. Yan Project Checkpoint 1 Controller Interface Controller Specifications The Nintendo 64â controller has three terminals - VCC, GND, and a data line. The VCC and GND lines supply power, while the data line is a two-way transmission line that is used to communicate with the controller. The data line is normally high (VCC), which indicates that the line is idle. Data bits are sent serially, with bits encoded as follows: To receive the controller button information, the request byte 0x01 (hexadecimal) must first be sent to the controller. Also, a stop bit (logic 1) must be sent as a 9th bit of the transmission. Viewed on the oscilloscope, the request waveform should look like this: Note that the most significant bit (MSB) of the request byte is sent first. Also, each bit is sent immediately after the previous bit, with no idle time in between bits. After the request has been sent, the controller will respond with 32 bits of button information (and a stop bit at the end) within a few microseconds. (The response time is usually around 3 ms, but it varies 1 ms 3 ms logic 1 1 ms 3 ms logic 0 0 0 0 0 0 0 0 1 stop bitdepending on the controller. Some controllers may actually begin sending data while the stop bit of the request byte is still being sent! Be careful…) Each button is sent as one bit, where a 0 indicates that the button is currently not being pressed and a 1 indicates that the button is being pressed. The button states are sent as a sequence of 32 bits in the following order: bit button 0 A 1 B 2 Z 3 START 4 UP 5 DOWN 6 LEFT 7 RIGHT 8 [not used] 9 [not used] 10 L 11 R 12 C-UP 13 C-DOWN 14 C-LEFT 15 C-RIGHT 16 – 23 analog X-AXIS 24 – 31 analog Y-AXIS 32 [stop bit] The state of the analog stick is sent as the last 16 bits, where each axis of the stick is sent as an 8 bit one’s complement number. For example, on the x-axis, the value 0x00 would represent the middle, the value 0x7F would represent the analog stick being all the way to the right, and the value 0xFF would represent the stick being all the way to the left. Prelab Preparations This checkpoint requires three wire wraps, one for each terminal of the controller. The VCC and GND terminals should be connected to the VCC and GND of the board. The data line should be connected to pin 41 of the Xilinx 4010XL chip. Three consecutive pins in the pin array (the upper half of the board with lots of pins) will be used to connect to the controller, so those three pins should be wire wrapped, in the following order: three consecutive pins GND P41 VCCDesign Structure The goal of this checkpoint is to build an independent component of a videogame system. To accomplish this, the only interface to the rest of the system will be a 32 bit register which contains the state of the buttons. For this checkpoint, the system outside of the controller block will only consist of an IO block (used to output to the LEDs) and a clock divider to provide the system with the necessary clocks (only a 4mhz clock is required for this checkpoint). The controller button signals will be output to the two seven-segment LED displays. Controller State Machine The top-level state machine to communicate with the controller is fairly simple, consisting of three general states – idle, request, and receiving-data. controller block clk 32 BUTTON STATE IO block clock divider clk 32 bit register IDLE REQUEST RECEIVING DATA sub-FSM sub-FSMAs seen in the diagram, the request and receive states actually consist of a sub-FSM, which looks similar to the top-level FSM (it’s just a loop). You will need to design those two sub-FSMs. Of course this is not the only way to design the controller interface. There may be other methods that yield more elegant designs; this design is merely a suggestion. But regardless, you will need a sub-FSM for the request and receive processes. FSM Timing The top-level FSM should cycle every 1ms. It should be idle most of the time, but every 1ms it should send a request, then immediately receive the data that the controller sends, and then return to the idle state where it will wait until the next millisecond. For sending the request signal, it is necessary to count 1ms intervals, since each bit consists of four 1ms sections. This can be done by counting four 4mhz clock cycles. Receiving signals is much trickier, since it is asynchronous, i.e. the transmission might start at any point in time. Thus, an edge detector is necessary to detect the start of the transmission (a negative edge). Also, it is necessary to supersample the signal to detect the edge and to keep synchronized. To determine whether each bit is a 0 or 1, we can sample in the middle of the 4ms interval of each bit, since 0 and 1 differ only in the middle two 1ms sections. There is a tricky timing issue in the receiving stage that arises because the board clock is not exactly the same frequency as the controller clock. This may cause the FSM to become unsynchronized with the controller signal. STATE 0ms 1ms IDLE REQUEST RECEIVING REQUEST RECEIVING . . . . . . . . start of transmission / first bit start of next bit supersample interval = 250 ns (4mhz clock) sample hereTo get around this, your FSM should resynchronize at the start of each bit. Once a bit has been sampled, the state machine should wait for the next negative edge (the start of the next bit) and resynchronize with the signal. Design Implementation IO Block In order to input and output signals, there are several fundamental components necessary: IBUF and IPAD for input, OBUF and OPAD for output, IBUF and OBUFT and IOPAD for two-way signals (which is not used in the IO block, but in the controller block). All of the pads (IPAD, OPAD, IOPAD) are used to make connections to pins. They must be configured by right clicking a pad and editing the symbol properties. A “LOC” parameter must be added, and its value should be “P41,” for a connection to pin 41, or “P36” for a connection to pin 36, etc. In addition to pads, each pad should have a corresponding buffer (IBUF, OBUF, or OBUFT). Connections should be made like


View Full Document

Berkeley COMPSCI 150 - Project Checkpoint 1 Controller Interface

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 Project Checkpoint 1 Controller Interface
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 Project Checkpoint 1 Controller Interface 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 Project Checkpoint 1 Controller Interface 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?