The user datapath (UDP) register interface is set up as a register chain. This allows the registers to be accessed both by software or by other modules in hardware. In order to preserve the register chain, each module connected to the chain is responsible for passing along the signals to the next module in the chain. If the current module is the target of the request, then it must raise the reg_ack signal so that other modules know that the request has been handled and thus can be ignored.
Meaning of Address Bits
Once a register request is received by the hardware, there are four major areas that it can end up: the core, SRAM, DRAM, or the user data path (UDP). Your project will deal only with UDP requests, which occupy an 8MB region of the total address space. Once the hardware identifies an incoming request as being inside the UDP region, it passes the request to the UDP along with only the lower 23 bits of the register address. These 23 bits are broken down as follows:
- Tag Address: The upper 17 bits identify which module is responsible for handling the request (Switch or router output port lookup, input arbiter, etc..). This should match the macros `SWITCH_OP_LUT_BLOCK_ADDR for the switch and `ROUTER_OP_LUT_BLOCK_ADDR for the router. These macros are provided automatically as part of the register generation process.
- Register Address: The lower 6 bits identify the individual register that is the target of the register read/write operation
A note about address: If you compare the addresses provided in the software (C/Perl) register file against the addresses in the hardware (verilog) register file, you will note that they are slightly different. The addresses presented to software are shifted two bits to the left compared to hardware. This way, software believes that these registers are word-addressable.
Individual Register Interface Signals
- These signals come in two variants: "in" (from the previous module), and "out" (to the next module). The number is the width of the signal as seen in the output port lookup module.
- reg_req (1)
- When this signal is high, your output port lookup module has received a register interface request. This is the only cycle that the other register interface signals are valid.
- reg_ack (1)
- If low, no other modules have handled this register request. Ignore the register request if this signal is high. If your module is responsible for handling the register request, make sure to set this signal to high when you pass along the reg_req signal.
- reg_rd_wr_L (1)
- 0 means this is a write request; 1 means this is a read request.
- reg_addr_in (23)
- This is the UDP address of the register request.
- reg_data (32)
- On a read, this signal should be filled in by the appropriate module with the requested register data. On a write, this is the data that is to be written to the register by the software.
- reg_src (2)
- Used to identify the source of the register request (hardware or software). You don't need to modify this during the course of the project, so pass it along in the same form that it is received.
Each of these signals must be forwarded to the output of the output port lookup module to preserve the register chain.
Example Timing Diagrams
|Register Read||Register Write|