ADM-XRC SDK 2.8.1 User Guide (Linux)
© Copyright 2001-2009 Alpha Data
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.
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.
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:
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
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:
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. |