ICED Canned System Bus - IBUS

University of Rhode Island

April 13, 1999 (Revised - May 28, 2000)

  1. Overview
  2. IBUS Specifications

1. Overview

The IBUS consists of a total of 64 signals. It accomodates 32-bit data words and unaligned 8-bit bytes. There are three sub-buses: DBUS for data, ABUS for address and CBUS for control.

DBUS is bidirectional and has 32 bits. ABUS is unidirectional (always driven by the bus master) and has 24 bits for an address space of 16 MBytes. CBUS has several different types of signals; see the chart later on for details. There are eight control signals, including a system reset and a two-phase clock.

The outputs of the FPGA going to the IBUS transceivers are all active-high. (The IBUS signals on the actual cables between the d-cards are active-low; the transceivers invert the signals.)

2. IBUS Specifications (Concise)

The ICED bus is a synchronous bus; with the exception of the reset signal, all signals are synchronized with the bus clock (CCLK1). The signal descriptions follow.
 
 
ICED Bus Signal Descriptions
Name
Alternate Name
Size (bits)
Drive Type
Description (positive logic assumed for all signals)
DBUS(31 downto 0)
-
32
tri-state*
 Data signals; driven by the bus slave during a write
    transaction, otherwise driven by the bus master
ABUS(23 downto 0)
-
24
tri-state*
 Address signals; byte address; range: 16 MB;
    always driven by the bus master
CBUS(7 downto 0)
-
8
mixed
 Control signals; defined below; driven by either 
    the bus master or slave, see below
CSYNC
CBUS(7)
1
tri-state*,
pull-up
 SYNChronize; asserted by the bus master 
    during a normal transaction
CWR
CBUS(6)
1
tri-state*
 WRite; asserted by the bus master 
    during a write transaction, 
    de-asserted during a read or other transaction
CACK
CBUS(5)
1
tri-state**,
pull-up
 ACKnowledge; asserted by the addressed bus 
    slave during the last cycle of a normal transaction;
    can be asserted in the first cycle of a transaction;
    must be active much before CCLK1's rising edge
    at the end of the cycle
CINT
CBUS(4)
1
tri-state**,
pull-up
 INTerrupt; asserted by a slave in response to some
    internal condition of the slave; causes CPU
    program execution to pause; current PC value is 
    saved, then PC is loaded with pre-determined value
CBYTE
CBUS(3)
1
tri-state*
 BYTE write; asserted by the bus master during single 
    byte writes; undefined (reserved) for reads
CCLK2
CBUS(2)
1
totem-pole
(controller)
 CLocK phase 2; secondary bus clock; ***
    synchronized with CCLK1 but lags it;
    generated by controller (user-designed)
CCLK1
CBUS(1)
1
totem-pole
(EVC1,
controller)
 CLocK phase 1; primary bus clock; ***
    the rising-edge is used to latch data, address or
    state set-up on the bus in the prior cycle;
    except for CRESET, all other ICED
    bus signals are synchronized with this signal, 
    and except for CCLK2 (see above), all transitions
    nominally lag CCLK1's rising-edge by the register
    propagation delay tcq; tcq ~ tlag > th + clock skew;
    may be EVC1's fclk; usually is user-generated
CRESET
CBUS(0)
1
totem-pole
(Host)
 RESET; asynchronous signal; when asserted causes
    all devices connected to the bus to go to their
    initial power-on or reset state; current transaction
    is aborted

NOTES:
    * These signals are tri-stated so that more than one master can be connected to the bus. In particular, we have the CPU as one master (of course), and the Host as another master (via the EVC slave interface, during program load, debug, etc.). Since we do not have more than two masters, we give priority always to the Host, and thus have the Host control the enables for these tri-stated signals. CSYNC is pulled to logic '0' to avoid false transaction cycles, i.e., when no master is using the bus.
    ** These signals are tri-stated so that more than one slave can be connected to the bus, which is quite normal. An individual slave's tri-state enable is controlled via a combination of the master's control signals and signals internal to the slave (for you to figure out :-).
    *** Usually our digital systems only have one clock; this improves perormance by reducing skew. However, in order to generate the timing signals for the SIMM DRAM (main memory), it is convenient to use two clocks whose duty cycles and lag are adjusted to readily generate the DRAM's signals with the correct timing.
    CAVEAT: You can put pull-ups on XC4000E internal tri-state lines, but not pull-downs, ergo, you might want to make some of the above control signals active-low (negative logic) within the FPGA, before the output buffers.
 
 
 

ICED Bus Transactions:

There are two primary ("normal") bus transactions defined: read and write. Others currently include interrupt and reset transactions. All of these transactions are now described and specified.

To make sure you understand what is going on, sketch timing diagrams of each of the transactions.
 

Write transaction:

  • Bus master:
    1. At beginning of cycle, in synchronism with but after the CCLK1 rising edge, the bus master asserts DBUS (data), ABUS (address), CSYNC and CWR signals.
    2. At end of first and succeeding cycles, with the next CCLK1 rising edge, either: (a) the master receives CACK from the slave and deasserts all signals for this transaction and the transaction is concluded, or (b) CACK is still unasserted; master maintains original state of the bus signals.
  • Bus slave:
    1. At beginning of cycle, all slaves detect assertion of CSYNC by the master.
    2. ABUS (address) is checked by each slave for corresponding slave address; if there is a match, the slave is the correct unit to respond to the transaction, and it continues; otherwise, the slave does not participate in the transaction further.
    3. CWR is decoded by the slave; since this is a write transaction, CWR is asserted and the slave therefore knows it is a write.
    4. The DBUS data is routed to the appropriate storage register or device in the slave.
    5. The slave asserts CACK in the cycle the data is saved.
    6. At the end of the cycle, the data is saved in the slave with the rising edge of CCLK1. End of transaction.
      • NOTE 1: Steps 1-5 can happen concurrently in the slave.
      • NOTE 2: In step 5, the master will see CACK one bus round-trip delay (+ logic delays in the slave) after the start of the cycle, at the earliest. If the master detects CACK in time, it will deassert its signals (see "Bus master: 2." above) with the rising edge of CCLK1, for this transaction.

Read transaction:

  • Bus master:
    1. At beginning of cycle, asserts ABUS (address) and CSYNC signals, and de-asserts CWR signal.
    2. At end of first and succeeding cycles, with the next CCLK1 rising edge, either: (a) the master receives CACK from the slave and deasserts all signals for this transaction and the transaction is concluded, or (b) CACK is still unasserted; master maintains original state of the bus signals.
  • Bus slave:
    1. At beginning of cycle, all slaves detect assertion of CSYNC by the master.
    2. ABUS (address) is checked by each slave for corresponding slave address; if there is a match, the slave is the correct unit to respond to the transaction, and it continues; otherwise, the slave does not participate in the transaction further.
    3. CWR is decoded by the slave; since this is a read transaction, CWR is de-asserted and the slave therefore knows it is a read.
    4. The slave obtains the requested data and places it on the DBUS.
    5. The slave asserts CACK at the about the same time (no earlier than the last possible change of a DBUS signal, and including the bus skew time; this ensures that the register setup time requirement at the master will be met).
    6. At the end of the cycle, the data is saved in the master with the rising edge of CCLK1. End of transaction.
      • NOTE 1: Steps 1-5 can happen concurrently in the slave.
      • NOTE 2: In step 5, the master will see CACK one bus round-trip delay (+ logic delays in the slave) after the start of the cycle, at the earliest. If the master detects CACK in time, it will deassert its signals (see "Bus master: 2." above) with the rising edge of CCLK1, for this transaction.

Interrupt transaction:

Abstract: The basic mechanism is to tell the CPU of the interrupt request; then the CPU polls the I/O devices to find the one that requested the interrupt. One or more slaves initiates an interrupt by asserting CINT.

In more detail: When the master sees that CINT is asserted, it waits until it is finished with the current transaction, then makes the equivalent of a subroutine call by forcing the execution of a Branch and Link instruction (BRL), switching execution to location PC=0x000008 and executing the instruction there. The latter instruction is normally an unconditional branch to the interrupt service routine (ISR). The ISR first saves the return PC value on the stack, then polls all of the I/O devices' status registers to determine the highest priority I/O device requesting an interrupt. The appropriate individual ISR is then executed. At the end of the ISR, an rti instruction is executed, re-enabling interrupts and causing the CPU to resume execution at the instruction after the point of interruption.

And yet more detail:

  • Bus slave:
    1. At the beginning of the cycle, regardless of the state of the other bus control signals, the slave asserts CINT.
    2. The CPU completes the current transaction, i.e., bus transactions are considered to be atomic, or indivisible, except with respect to Reset transactions.
    3. If interrupts are enabled, as indicated by the Interrupts Enabled bit [IE] being set to '1', the CPU performs the ISR invocation steps described above.
    4. The slave de-asserts CINT when it is turned off indirectly by the CPU writing an "interrupt acknowledged" signal to the slave's control register; the latter happens via the ISR. Only when all interrupting devices have been serviced does CINT become deasserted.

      5.  
  • Bus master:
    1. The master checks the state of CINT at the end of every bus transaction, or if no bus transaction is in progress, then at the end of every CPU clock cycle.
      • NOTE: The CPU will NOT service interrupts if its "Interrupts Enabled" bit (IE) is cleared to '0'.
    2. If CINT is set, the execution of a BRL is forced as described above; any necessary pipeline squashing is performed, so that instructions in the pipeline either completely execute or (effectively) not at all, i.e., instructions are also treated as atomic.
      • NOTE: Pending memory loads or stores in the pipeline may be executed before the ISR is invoked.
    3. After the ISR is completed, execution resumes where it left off via popping the old PC value into a register and then loading it into the PC, via execution of an rti instruction. This also allows the CPU to service another interrupt.

Reset transaction:

A bus reset is invoked when the host asserts CRESET via the slave interface.
  • Bus master:
    1. The reset causes immediate cessation of all operations.
      • All bus transactions are aborted and the other bus signals are deasserted.
      • All pipeline registers are either cleared or have their contents marked as "squashed".
      • The control circuitry is reset to the power-on reset (initial) state.
      • The PC is cleared to 0x000000 [it actually only has 22 bits; instructions are aligned to word boundaries, so the 2 LSB's are always "00"].
    2. Program execution starts at location 0x000000 when the CPURUN signal is asserted (and CRESET has been de-asserted). CPURUN is derived from the Host-to-CPU interface's control bits. (It's your job to generate it, and in a clean [synchronized] fashion.)
  • Bus slave:
    1. The reset causes immediate cessation of all operations.
      • The slave's interrupt enable bits and interrupt request bits are cleared to '0'.
      • The slave deasserts all bus signals, and aborts all bus transactions.
      • The control circuitry is reset to the power-on reset (initial) state).
      • Reset signal(s) are sent to the device(s) connected to the slave.
    2. Once CRESET is de-asserted, the slave waits for bus transactions to begin and device operations to begin.



 

May 28, 2000 | Gus Uht | uht@ele.uri.edu