SimplifyingModuleInterfaces

Table of Contents Simplifying Module interfaces Simplifying interfaces Packet Datapath Register Datapath Module/arbiter interface Register read Register write Connecting modules to the arbiter Tasks

Simplifying Module interfaces

Simplifying interfaces

To encourage wider use, and make it easy for researchers and students to learn how to use the board, we need to implement a simple structure for the reference designs. One such structure is a pipeline with a FIFO pull interface. The design is described in the images below. Would it be possible to implement a FIFO interfaces on ALL modules we implement?

Packet Datapath

Check this link for the latest design document: [1]

Register Datapath

A central arbiter coordinates access to registers within individual modules

Modules that provide register access should be connected to a central arbiter, as shown in the accompanying diagram. All register accesses will be processed by the arbiter. The arbiter will decode the address to determine which module is being accessed. The arbiter will forward the access to the appropriate module and return any read data to the requester.

Module/arbiter interface

The interface between the modules and the arbiter is a simple request/reply interface. The signals are as follows:

Signal	Direction	Description
reg_req	Arb -> Mod	Register read/write action requested
reg_rd_wr_L	Arb -> Mod	Read (high) or Write (low)
reg_addr?:0	Arb -> Mod	Register address. Note: High order address bits are stripped off.
reg_wr_data[31:0]	Arb -> Mod	Write data
reg_rd_data[31:0]	Mod -> Arb	Read data
reg_ack	Mod -> Arb	Acknowledgement

Register read

The arbiter initiates a read on the rising edge of the clock by:

• asserting reg_req
• asserting reg_rd_wr_L
• supplying the read address on reg_addr

The module should return the value of the register being read on reg_rd_data and assert reg_ack . The result can be returned during any cycle after the request is made, including returning the result immediately during the request cycle. The result and ack are read by the arbiter on rising clock edges.

Register write

The arbiter initiates a write on the rising edge of the clock by:

• asserting reg_req
• deasserting reg_rd_wr_L
• supplying the write address on reg_addr
• supplying the write data on reg_wr_data

The module should assert reg_ack once it has registered the write request. The module is free to delay the write until after it has acknowledged the request.

If a module does delay writes it must buffer the address and data internally as the arbiter may issue a new request any cycle after an ack.

Connecting modules to the arbiter

The central arbiter must be modified whenever a new module is added. Dedicated register access ports must be added to the arbiter for each module.

Note: It would be desirable to create a system to auto-generate the arbiter to avoid having to modify it by hand whenever a module is added.

Tasks

See Task list