Finitron Asynchronous Bus (FTA Bus)

FTA Bus is an asynchronous transaction bus meaning that requests and responses are separate, and the bus does not wait for a response before beginning a new request. The fact that it is non-synchronous and need not wait for a response makes it very fast. A typical synchronous bus will not begin a new transaction until the previous transaction is complete. If the peripheral devices are located some ways away from the master it could several clock cycles between the request and the response by the slave. In between request and response, the bus sits idle. With an asynchronous bus more of the bus bandwidth may be used as requests and responses may be overlapped. The drawback of FTA’s asynchronous nature is that it requires additional buffering or queuing of bus responses. It is also necessary to track which response belonged to what request, so there are more signals involved.

FTA bus keeps track of transactions using a channel (cid) and transaction id (tid). The channel id is typically associated with a bus master such as a cpu. In a multi-CPU system, there may be more than one master, and more than one channel id in use. For each channel transactions are also tracked using a transaction id. The same tid may be in use by different channels. The combination of cid and tid is unique though. A bus request is typically fed to several slave peripherals along a common bus. There may be bus bridges or buffers for performance and synchronization purposes. Each slave may then generate a response. The slave responses must be fed individually into a buffer or queue that multiplexes the responses. The queue then selects a slave response to send back to the master. The reason slave response must be buffered is that they may take variable lengths of time to respond meaning two slaves might try to respond on the bus at the same time, even though two different requests occurred at different times.

The listing below shows a simple LED output peripheral. There is no delay between the request and response because it is not needed for the peripheral. The example shows that the response cid, tid pair must correspond to the request cid, tid pair. Also the address of the request is fed back in the response.

import fta_bus_pkg::*;

module ledport_fta32(rst, clk, cs, req, resp, led);

input rst;

input clk;

input cs;

input fta_cmd_request32_t req;

output fta_cmd_response32_t resp;

always_ff @(posedge clk, posedge rst)

if (rst)

led <= 'd0;

else begin

if (cs)

led <= req.dat[7:0];

end

assign resp.cid = req.cid;

assign resp.tid = req.tid;

assign resp.ack = cs;

assign resp.err = 'd0;

assign resp.rty = 'd0;

assign resp.pri = 4'd7;

assign resp.adr = req.padr;

assign resp.dat = 'd0;

endmodule