ADM-XRC SDK 2.8.1 User Guide (Linux)
© Copyright 2001-2009 Alpha Data


The arbiter_3 component

Overview

HDL source code

Parameters

Signals

Performance

Overview

The arbiter_3 component is part of the memif package and enables a memory port to be shared by up to three clients. The component follows the generic user interface for memory ports, so that as far each client is concerned, it appears to be communicating with a memory port.

The arbiter_3 module requires a client to assert its request signal reqi when the client wishes to access the memory port. In response, the arbiter_3 (eventually) grants access to the memory port by asserting readyi. Once the client sees readyi asserted, it is permitted to issue commands to the memory port by asserting cei, subject to the timing rules for readyi and cei as described in note 5 below.

HDL source code

Projects making use of this component must include all of the following source files (relative to root of SDK installation):

fpga/vhdl/common/memif/memif_pkg.vhd
fpga/vhdl/common/memif/memif_int_pkg.vhd
fpga/vhdl/common/memif/memif_def_synth.vhd OR fpga/vhdl/common/memif/memif_def_sim.vhd
fpga/vhdl/common/memif/arbiter_4.vhd
fpga/vhdl/common/memif/arbiter_3.vhd

If synthesizing, the file fpga/vhdl/common/memif/memif_def_synth.vhd must be included. If simulating, the file fpga/vhdl/common/memif/memif_def_sim.vhd must be included instead.

Parameters

Name Type Function Note
a_width natural Width in bits of the logical address busses a, a0, a1 and a2. 1
bias natural If unfair is true, specifies which client (0 to 2) to favor, otherwise ignored. 2
d_width natural Width in bits of the logical data busses d, d0, d1, d2, q, q0, q1 and q2. 3
latency natural Specifies the number of consecutive clock cycles for which a client is granted access to the memory port before access can be granted to a different client. 4
ready_delay natural Specifies both the maximum number of clock cycles of delay permitted between the deassertion of readyi and the deassertion of cei, and the minimum number of clock cycles of delay permitted between the assertion of readyi and the assertion of cei. 5
registered boolean Specifies whether or not the memory port signals (ce, w etc.) are registered in order to improve timing. 6
tag_width natural Width in bits of the tag values tag, tag0, tag1, tag2, qtag, qtag0, qtag1 and qtag2. respectively.  
unfair boolean If true, specifies that the client identified by bias should be given absolute priority over the other clients. 7

Notes:

  1. The a_width parameter is the width of the logical address busses a, a0, a1 and a2. Generally, it must be sufficiently wide to be able to address all of the memory in a memory bank. Hence, the required value of a_width depends on what type of memory devices are in use and their density.
  2. Assuming that the unfair parameter is true, the bias parameter specifies the favored client, i.e. which client is given priority access to the memory port. The favored client can interrupt a burst of memory accesses by one of the unfavored clients regardless of the value of latency. A value of 0 represents client 0 and a value of 2 represents client 2. If the unfair parameter is false, however, bias is ignored and there is no favored client.
  3. The d_width parameter is the width of the logical data busses d, d0, d1, d2, q, q0, q1 and q2. It is generally determined by the physical data width of the memory bank and the type of memory devices in use. DDR memory devices in particular generally have a logical data width that is 2 or 4 times the physical data width.
  4. The latency parameter is the minimum number of consecutive clock cycles that a particular client is awarded access to the memory port without being interrupted by another unfavored client. The purpose of this parameter is to enable a reasonable efficiency to be achieved for memory types that benefit from bursting and locality of access, for example DDR and DDR-II SDRAM. Note however, that if unfair is true and the favored client requests access to the memory port, the favored client will be granted access to the memory port regardless of the value of latency and regardless of any unfavored clients.
  5. The ready_delay parameter specifies the timing relationship between a client's readyi signal and its cei signal. ready_delay must be at least 0 and no greater than 4. The following figures illustrate this relationship:

    Relationship between ready0 and ce0 when ready_delay = 0

     

    Relationship between ready0 and ce0 when ready_delay = 1

     

    Relationship between ready0 and ce0 when ready_delay = 2

  6. If the registered parameter is false, the memory port output signals ce, w etc. are generated combinatorially from the client port input signals ce0, w0, ce1, w1 etc. If the registered parameter is true, the memory port output signals ce, w etc. are registered before being output. This adds one cycle of latency but is recommended for ease of timing closure. This parameter has no effect on the timing relationship between readyi and cei.
  7. If the unfair parameter is true, the client identified by the bias parameter is given priority access to the memory port. This overrides the latency parameter, meaning that the favored client can interrupt a burst of memory accesses by one of the unfavored clients.
Signals

The arbiter_3 module has the following infrastructure ports:

Signal Type Function Note
clk in Clock

All other signals except rst are synchronous to clk.
 
rst in Asynchronous reset.

This port should be mapped to the asynchronous reset signal, if there is one, or to a constant logic 0 signal if an asynchronous reset is not required.
 
sr in Synchronous reset.

This port should be mapped to the synchronous reset signal, if there is one, or to a constant logic 0 signal if a synchronous reset is not required.
 

The interface presented to clients by the arbiter_3 module is as follows:

Signal Type Function Note
a0
a1
a2
in Client logical address

A client must place a valid address on ai when it asserts cei.
 
be0
be1
be2
in Client byte enables to memory

A client must place valid byte enables on bei whenever a write command is entered (cei and wi both asserted). A logic 1 in a given bit of be means that the corresponding byte within bei will be written to memory, while a zero means that the corresponding byte will not be written to memory.
 
ce0
ce1
ce2
in Client command entry

A client asserts this signal to enter a new read or write command into the memory port. When asserted, ai and wi must be valid. When asserted along with wi, tagi must also be valid.

A client must observe the rules for assertion of cei with respect to readyi, as illustrated by note 5 above.

Other than that, there are no restrictions on how few or how many clock cycles cei can remain asserted. It can be pulsed for single clk cycles, or asserted for many clk cycles (readyi permitting).

The address, byte enables, tag etc. of a command need not bear any relationship to that of the previous command, but the performance of certain types of memory (for example, DDR SDRAM) benefits from locality of access.
 
d0
d1
d2
in Client data to memory

A client must place valid data on di whenever a write command is entered (cei and wi both asserted).
 
q0
q1
q2
out Client data from memory

When validi is asserted is asserted by the memory port (as a result of a read command), qi reflects the data read from memory.
 
qtag0
qtag1
qtag2
out Client tag out

When validi is asserted by the memory port (as a result of a read command), qtagi reflects the tag value that was assocated with that read command.
 
ready0
ready1
ready2
out Client ready

When readyi is asserted, a client is permitted to assert cei.

The readyi signal for a client is asserted when two conditions are met: the arbiter grants access to the memory port for that client, and the memory port itself is asserting ready.
 
req0
req1
req2
in Client request

A client asserts reqi in order to request access to the memory port. When the arbiter grants access to the client, it will assert readyi.
 
tag0
tag1
tag2
in Client tag in

When a client asserts cei with wi deasserted, it must also place a valid tag on the tagi signal. When, as a result of the read command, the memory port asserts validi, the qtagi output reflects the tag value originally passed.
note 8
valid0
valid1
valid2
out Client read data valid

When validi is asserted by the memory port, it is as a result of a read command (client asserted cei with wi deasserted). When validi is asserted, both qi and qtagi are valid.
note 9
w0
w1
w2
in Client write select

When a client asserts cei, it must place either a logic 1 on the wi signal in order to select a write command, or 0 in order to select a read command.
 

Notes:

  1. In order for a client to be able to correctly identify data from its own read commands, a client must use a set of tags that is completely disjoint from the set of tags used by another client. For example, if client 0 uses the set of 4-bit tags { "0000", "0001", "0010" }, then no other client may use those tags. If client 1 uses the set of tags { "0100", "0101", "0110", "0111" }, then there is no risk that client 0's reads can be confused for client 1's reads, and vice versa.

  2. The valid0, valid1 and valid2 outputs are always asserted together by arbiter_3. If one of the validi signals is asserted, then all must be asserted. This is because it is the responsibility of each client to recognize its own tags. The arbiter_3 module does not attempt to decode the qtag signal (see below) in order to determine which client issued the corresponding read command. The following figure illustrates a read command issued by client 1:

    All validi signals are always asserted together.

    With reference to the above figure, client 1 issues the read and recognizes its own data by decoding qtag1. However, clients 0 and 2 must also respectively decode qtag0 and qtag2 and determine that the data does not belong to them. Depending on how many clients there are, decoding a tag may be as simple as checking the top bit or top couple of bits of a qtagi value.

The interface presented to the shared memory port by the arbiter_3 module is as follows:

Signal Type Function Note
a out Memory port logical address

The arbiter_3 module drives this signal with a valid address when asserts ce in order to access the memory port on behalf of a client.
 
be out Memory port byte enables

The arbiter_3 module drives this signal with a valid set of byte enables when it asserts ce and w together in order to perform a write to the memory port on behalf of a client. A logic 1 in a given bit of be means that the corresponding byte within be will be written to memory, while a zero means that the corresponding byte will not be written to memory.
 
ce out Memory port command entry

The arbiter_3 module asserts this signal when it must access the memory port on behalf of a client. When arbiter_3 asserts ce, it also drives valid values on a and w. Depending on whether or not w is asserted along with ce, arbiter_3 also drives either tag or be and d with valid values.
 
d out Memory port write data

The arbiter_3 module drives this signal with a valid set of byte enables when it asserts ce and w together in order to perform a write to the memory port on behalf of a client.
 
q in Memory port read data

This signal carries the data read from the memory port as a result of arbiter_3 reading the memory port on behalf of a client. It is qualified by the valid signal.
 
qtag in Memory port returned tag

This signal carries the tag that accompanies data read from the memory port as a result of arbiter_3 reading the memory port on behalf of a client. It is qualified by the valid signal.
 
ready in Memory port ready

When ready is asserted, the memory port is ready to accept commands. The arbiter_3 module uses this signal in generating the ready0, ready1 and ready2 signals for the clients.
 
tag out Memory port tag

The arbiter_3 module drives this signal with a valid tag when it asserts ce with w deasserted in order to perform a read of the memory port on behalf of a client.
 
valid in Memory port data valid

When valid is asserted, it is as a result of arbiter_3 performing a read of the memory port on behalf of a client. The signals q and qtag are both qualified by valid.
 
w out Memory port write select

The arbiter_3 module asserts this signal along with ce when it performs a write to the memory port on behalf of a client.
 

 


 Top of page