ECE352F: Computer Organization

Lab #4: Bus Design

Fall 1998

In this lab you will try to implement a bus to communicate data between the Gizmo board PIT ports and the FPGA. The PIT side will be the master, meaning that all bus transactions will be initiated from the PIT. The protocol will be implemented in software on the gizmo board, and in hardware in the FPGA using VHDL. This will give you an opportunity to contrast how finite state machines can be implemented using software and hardware described with VHDL.

This circuit will be used in future designs as an interface to other circuits that you will build. You will want to make it work!

1. Bus Description

A general picture of the connections is shown in Figure 1.

  

Figure 1: Overview of Connections

The bus should be capable of sending 8-bit addresses and carrying 16 bits of data. There are only eight wires (AD) that will be used to multiplex the address and data in three transactions on the bus. Note that information is carried in both directions on AD so you will have to be careful about the timing of the signals. This will be handled by the bus protocol.

The bus protocol will be asynchronous, meaning that there will be handshaking signals instead of a clock. All transactions are initiated from the PIT side. You should read Section 4.5 in the text, particularly the part about asynchronous buses. In your system the skew will be very small, and is likely not even a problem. However, you can easily account for skew on the bus by ordering the the way you change the data and control registers on the PIT side.

1.1 Read Cycle

Figure 2 shows a timing diagram for the read cycle.

  

Figure 2: Read Cycle

The handshaking signals are RDY on the PIT side and ACK on the FPGA side. In the timing diagram, a level in the middle, as shown for the AD lines indicates that nothing is driving the lines so the lines are floating.

To start a read, the PIT carries out the following actions:

• Set the read/write line (R/W) high to indicate a read cycle
• Drive the address on the AD lines
• Set RDY to indicate that the AD and R/W lines are stable.

The FPGA will handshake with the PIT using the ACK line. When ACK goes high, it means that the FPGA has latched the address into its address register. You can also implement a timeout feature to detect illegal addresses. If ACK does not get set high after a certain amount of time, then you can assume that there is nothing at that address, and abort the transaction.

The next transaction on the bus is to read the high byte of the data.

• The PIT sets the high-byte enable line (HBE), and then sets RDY.
• The PIT waits for ACK to indicate that data is now on the bus.
• When the data has been read from the bus, RDY is dropped.
• ACK is then lowered.

A similar transaction is carried out for the lower data byte, except that LBE is used. With these signals, it is also possible to do single byte transfers. Note that if neither byte enable signal is on when RDY is high, then an address is being transferred. You can use this to indicate that a new bus transaction is being started.

Preparation:

Draw the timing diagram showing a read of only one byte followed by the read of the high followed by the low byte of a 16-bit word.

1.2 Write Cycle

The write cycle is shown in Figure 3.

  

Figure 3: Write Cycle

During a write cycle, the ACK signal is used during all three bus transactions to indicate that the FPGA has captured the information on the AD lines. Here, the R/W line is set low at the same time as the byte strobe lines are set to indicate that a write is occurring.

Preparation:

Draw the timing diagram showing a write of only one byte followed by the write of the high followed by the low byte of a 16-bit word.

2. FPGA Implementation

The FPGA circuit should be implemented with VHDL. It is easiest to implement the logic as a finite state machine, because a controller is really an FSM. Do not try to use the asynchronous logic style used in the text. It is better to use a synchronous FSM design. These days with the possibility of really high-speed clocks, you can generally get fast enough response time this way. In the case where you really have to respond quickly to some input, then you would think about doing that part asynchronously. There are examples in the VHDL Reference Guide on how to do FSMs.

You should also have a separate input for a Reset signal to make sure that your circuit starts in a reasonable state. The worst case is that the FPGA starts up driving the AD lines and you do not realize that from the PIT side. You could end up having the two devices driving the wires at the same time.

As a means of providing some standardization and inter-operability between designs, you should use the following connections:

Signal	PIT 0	FGPA
AD0	Port A 0	XCBUS18
AD1	Port A 1	XCBUS68
AD2	Port A 2	XCBUS6
AD3	Port A 3	XCBUS7
AD4	Port A 4	XCBUS8
AD5	Port A 5	XCBUS9
AD6	Port A 6	XCBUS27
AD7	Port A 7	XCBUS28
RDY	Port B 0	XCBUS24
R/W	Port B 1	XCBUS25
HBE	Port B 2	XCBUS26
LBE	Port B 3	XCBUS23
ACK	Port B 4	XCBUS19
Reset	Port B 5	XCBUS20

You can disable the 8031 by setting XCBUS36 high (RST). This can be done in your VHDL by assigning a `1' to that pin.

You should have three 16-bit registers that are byte-addressable using an addressing model like the 68000. This means that all words are at even addresses, and an odd address refers to the lower byte of a word.

Note that for a port that is bidirectional, you should declare it as inout in your entity declaration. Whenever you are finished outputting data on the AD lines, you should make sure that you drive a high impedance (AD $\Longleftarrow$"ZZZZZZZZ") on those lines to stop the output operation, and stop driving the lines so that they can be used by another device.

2.1 Debugging and Testing Your VHDL

There are various levels of simulation when doing designs in VHDL. The first level is strictly behavioural simulation. In this case you are simply simulating the VHDL source code and debugging it much like you would debug a C program. Then, depending on the technology that you are synthesising to, there can be various levels of netlists that you can get after synthesis. For example, after synthesis to a gate-level netlist, you may use behavioural simulation of the gates to see whether it still has the desired function. This netlist could be further annotated with timing information for more accurate timing simulation.

Attached is a short tutorial on the use of the Synopsys VSS simulator, which can be used for your functional simulations. You can look the online manuals to learn the fancier stuff. The tool is available on the ugsparcs.

I recommend a few modifications to the tutorial sheets:

• Add the following to your .cshrc file to add the synopsys commands into your search path. You will have to login again, or set this manually to get it work the first time.

      setenv SYNOPSYS /CMC/tools/synopsys
      if ( -e $SYNOPSYS/source_vrg.csh ) then
         source $SYNOPSYS/source_vrg.csh
      endif
  

• The various tools in Synopsys use setup files to initialize the environment. Copy the file /profs/pc/352/lab4/dot.synopsys_vss.setup into your working directory and name it just .synopsys_vss.setup. You should also create a directory called WORK. Now all of the temporary files that get created will be put in WORK instead of messing up your current directory.

NOTE:

Remember that your hardware will be running much faster than any human can react. A common error during simulation is to change input signals on every clock cycle when in the real world many, many cycles would be run before an input changes. In these parts of your circuit, it is good to run at least three or four cycles to make sure that your state machines do wait for input changes properly.

Preparation:

Write and functionally simulate the VHDL to implement the protocol required on the FPGA. You should have some timing diagrams to show that your circuit simulates correctly.

If you end up with much more than 3-4 pages of VHDL then you are making this more complicated than necessary.

3. The C Program

For the Gizmo, you should write C routines to handle the control of the PIT. Write two procedures, one for read and one for write. By modifying the I/O parts of your program, you should be able to debug the logic of the program on the ugsparcs.

The two procedures are described below:

int FPGAread(unsigned char Address, char *HighByte, char *Lowbyte, int Byte)

  Address:  8-bit address
  HighByte: pointer for returning the high byte of data
  LowByte:  pointer for returning the low byte of data
  Byte:     set to 1 for a byte read, 0 for a word read

  Return value: 0 for success, 1 for error


int FPGAwrite(unsigned char Address, char HighByte, char Lowbyte, int Byte)

  Address:  8-bit address
  HighByte: high byte of data to be written
  LowByte:  low byte of data to be written
  Byte:     set to 1 for a byte write, 0 for a word write

  Return value: 0 for success, 1 for error

NOTE:

The configuration of the PIT will be similar to what was used in Lab 1. Remember that you will have to keep configuring the data direction register for the AD port depending on what you are doing.

Preparation:

Write and debug, as much as possible, the FPGAread and FPGAwrite procedures.

Using those procedures, write a simple monitor that allows you to examine and deposit data into the registers in the FPGA.

4. Testing and Debugging

Some care must be taken when debugging because you can easily have both the PIT and the FPGA driving the AD wires at the same time. In particular, after each bus transaction, check that your FPGA logic is driving high impedance and your PIT port connecting to the AD lines is set up to be reading or not driving the AD lines. Go back and read your code now! Having two devices drive the wires could damage the chips.

To minimize the possibility of problems, you should try to test the two parts individually. On the Gizmo side, you can have your program stop for input at each stage. This will allow you to probe lines and set values on input lines and test your program that way. You can do the same thing with the FPGA. When you are convinced both sides are working, then you can connect them together.

5. In the Lab

You will need to wire up a Xilinx board according to the specifications given. Do it neatly as we will keep these boards and use them again.

Demonstrate a working system.