csr_target_csr

Files
file	csr_target_csr.cdl
	Pipelined CSR request/response interface to simple CSR read/write.

Detailed Description

Modules

module csr_target_csr::csr_target_csr	(	clock	clk,
		input bit	reset_n,
		input t_csr_request	csr_request,
		output t_csr_response	csr_response,
		output t_csr_access	csr_access,
		input t_csr_access_data	csr_access_data,
		input bit	csr_select[16]
	)

This CSR interface is designed to provide a simple CSR access (select, read/write, address, data) to a client from a pipelined request from a master.

The initial design motiviation was to permit a pipelined CSR access from a master to a number of targets, to run off a single fast clock in an FPGA. This requires registering the read data in response to access requests, and registering the request to the targets; the simplest variant being a fixed latency master-to-target and a fixed latency target-to-master. The current design uses a valid/acknowledgement system to replace the fixed latency.

A valid request is received, and if it matches the csr_select field then the request is acknowledged. Since the master is a fair distance away, and the valid signal will not be removed until an ack is seen, the handshake is effectively: valid low, ack low; valid high, ack low; valid high, ack high; valid high, ack low; valid low, ack low.

Hence a valid request starts with valid high in, and ack out low. If this matches the select, then this interface responds with a single cycle of ack high, and the CSR access is performed.

The clock for the client must be based on the same clock as the master. However, it may be a derived clock - in which case the ack will appear to the master to be more than one clock cycle long. The master must manage this, by removing valid when it sees the ack, and waiting until it sees ack is low before starting another transaction.

Read transactions have a further stage, though, compared to writes. A read transaction will follow an 'ack' with a 'read_data_valid' cycle; if a master performs a read then the handshake will be: valid low, ack low; valid high, ack low; valid high, ack high (one target cycle); valid high, ack low, read_data_valid high (one target cycle); valid low, ack low.

In this case the master must again wait until it sees read_data_valid high and then low before starting a new transaction, to allow the target to use a derived clock.

Parameters

[in]	clk	Clock for the CSR interface, possibly gated version of master CSR clock
[in]	reset_n	Active low reset
[in]	csr_request	Pipelined csr request interface input
[out]	csr_response	Pipelined csr request interface response
[out]	csr_access	Registered CSR access request to client
[in]	csr_access_data	Read data valid combinatorially based on csr_access
[in]	csr_select	Hard-wired select value for the client