fitstaff.fit.ac.cy/com.tk/aeee561/noc_mb_if.doc · web viewamba ahb simple transfer 5.2.2. arm amba...

NIE – Bus Interface Specifications

Network-on-Chip (NoC) Interface Element (NIE) - Microblaze

Interface Specification

Revision History

Author Ver Date Major/minor

Comments Approved by

K. Tatas 1.0 14/11/08 Initial specs – FSL only

K. Tatas 1.1 30/11/08 Added PLB and OPB IPIF

K. Tatas 1.2 02/12/08 Added Wishbone and AMBA buses

K. Tatas 1.3 09/11/09 Added Microblaze LMB bus

1. IntroductionThis documentsdocument contains the specifications for a NIE – Xilinx Microblaze interface specification covering FSL, PLB and OPB interfaces as well as AMBA and Wishbone bus interfaces.

1.1. Design ParametersDesign using reusable VHDL should include the following parameters in the design package, avoiding hard-coded numbers where possible:

NIE Xbar switch wordlength (WORDLENGTH) = (Default 16, 32)

Alexander Bartzas, 03/01/-1,

Routers switches???


FIFO depth (FIFO_DEPTH = SWITCH_PACKET_NUM×PACKET_SIZE/WORDLENGTH), default=2 packets

Number of words in a flit (FLITSIZE/WORDLENGTH), default = 2

1.2. NIE Crossbar (Xbar) SwitchThe Xbar switch is the basic switching element of the NoC. It provides connection between adjacent Xbar switches in four directions and the host processor. Each input packet arriving from one direction can be connected to eitherany of the other three directions through a dedicated path, therefore there is a total of 12 paths. Table 1 shows the Xbar I/O signals. Fig. 1 shows the Xbar RX and TX transfers for a single port.

Table 1. 5x5 Xbar switch I/OSignal Name Di

rection

Description

CLK I ClockRST_N I Active –low synchronous reset signalDATA_VALID_IN0 I Input Data valid direction #0 (Y-)DATA_VALID_IN1 I Input Data valid direction #1 (X+)DATA_VALID_IN2 I Input Data valid direction #2 (Y+)DATA_VALID_IN3 I Input Data valid direction #3 (X-)DATA_VALID_IN_PE I Input Data valid processing elementDATA_VALID_ OUT0 O Output Data valid direction #0 (Y-)DATA_VALID_OUT1 O Output Data valid direction #1 (X+)DATA_VALID_ OUT2 O Output Data valid direction #2 (Y+)DATA_VALID_ OUT3 O Output Data valid direction #3 (X-)DATA_VALID_ OUT_PE O Output Data valid processing elementDATA_IN0[WORDLENGTH-1:0] I Data input word direction #0DATA_IN1[WORDLENGTH-1:0] I Data input word direction #1DATA_IN2[WORDLENGTH-1:0] I Data input word direction #2DATA_IN3[WORDLENGTH-1:0] I Data input word direction #3DATA_IN_PE[WORDLENGTH-1:0] I Data input word direction processorDATA_OUT0[WORDLENGTH-1:0] O Data output word direction #0DATA_OUT1[WORDLENGTH-1:0] O Data output word direction #1DATA_OUT2[WORDLENGTH-1:0] O Data output word direction #2DATA_OUT3[WORDLENGTH-1:0] O Data output word direction #3DATA_OUT_PE[WORDLENGTH-1:0]

O Data output word direction processor


Figure 1. NIE RX (a) and (TX) data transfer

2. FSL interfaceFSL_V20 Fast Simplex Link (FSL) Bus is a uni-directional point-to-point communic-ation channel bus used to perform fast communication between any two design ele-ments on the FPGA when implementing an interface to the FSL bus. The FSL inter-face is available on the Xilinx MicroBlaze™ processor. The interfaces are used to transfer data to and from the register file on the processor to hardware running on the FPGA. Since the FSL is a unidirectional channel, 2 FSLs are required to communicate with the NIE. Figure 1 shows the MB-FSL-NIE communication block diagram.

Figure 2. MB – FSL – NIE – NoC communication block diagram

The Fast Simplex Link (FSL) Bus is shown in the block diagram in Figure 3.


Figure 3. Xilinx FSL interface block diagram

2.1. FSL0In the FSL0, NIE is the master while MB the slave. Therefore, the signals for the write operation (Figure 4) must be provided by the NIE.

Figure 4. FSL write operation

Therefore, the FSL_M_WRITE signal corresponds to the NIE DATA_VALID_OUT signal, and the FSL_M_DATA signal corresponds to the NIE DATA_OUT signal. The FSL_M_CONTROL signal may not be used.

2.2. FSL1In the FSL1, NIE is the slave while MB the master. Therefore, the NIE must respond to the FSL read operation timing diagram of Figure 5.


Figure 5. FSL read operation

Therefore, the FSL FSL_S_EXISTS signal corresponds to the NIE DATA_VALID_IN signal and the FSL_S_DATA signal corresponds to the DATA_VALID_IN signal. However, there is no NIE equivalent to the FSL_S_READ signal, acknowledging the transfer. Therefore, an interface must provide this signal. Figure 3 shows that all that is required is a one-clock delayed phase of FSL_S_EXISTS for the FSL_S_READ signal; therefore, a D-FF is sufficient.

3. PLB interfaceThe PLB IPIF is designed to provide a User with a quick to implement and highly ad-aptable interface between the IBM PLB Bus and a User IP core. An interface between the PLB_IPIF and the NIE (NIE_IF) is required (Figure 6).

Figure 6. PLB-based systemThe interface between the PLB IPIF and the NIE must provide for/adhere to the fol-lowing signals and the timing of Figure 7.

Signal name Direction

Description

Bus2IP_Clk IN PLB clock, passed through PLB IPIFBus2IP_Reset IN Active high PLB resetIP2Bus_IntrEvent [0: C_IP_INTR_NUM-1]

OUT Interrupt output signals. One is sufficient for NIE

Bus2IP_Data [0: C_DWIDTH-1] IN Write data bus to the user IP. Write data is accepted by the IP by assertion of the IP2Bus_Ack signal at the rising edge of the Bus2IP_Clk (or unconditionally on the cycle presented for posted writes).

Bus2IP_BE [0: C_DWIDTH/8-1] IN Byte enable qualifiers for the requested read or write operation with the user IP.


Bus2IP_RdCE [0: C_NUM_CE-1]

IN Active high chip enable bus. Chip en-ables are assigned per the user’s entries in the C_ARD_NUM_CE_ARRAY. These chip enables are asserted only during active read transaction requests with the target address space and in con-junction with the corresponding sub-ad-dress within the space.

Bus2IP_WrCE [0: C_NUM_CE-1]

IN Active high chip enable bus. Chip en-ables are assigned per the user’s entries in the C_ARD_NUM_CE_ARRAY. These chip enables are asserted only during active write transaction requests with the target address space and in con-junction with the corresponding sub-ad-dress within the space.

Bus2IP_RdReq IN Active high signal indicating the initi-ation of a read operation with the IP. It is asserted for 1 Bus2IP_Clk during single data beat transactions and remains high to completion on burst write opera-tions.

Bus2IP_WrReq IN Active high signal indicating the initi-ation of a write operation with the IP. It is asserted for 1 Bus2IP_Clk during single data beat transactions and remains high to completion on burst write opera-tions.

IP2Bus_Data [0: C_DWIDTH-1] OUT Input Read Data bus from the user IP. Data is qualified with the assertion of IP2Bus_Ack signal and the rising edge of the Bus2IP_Clk.

IP2Bus_Ack OUT Active high data acknowledgement For a write transaction, data on the Bus2IP_Data bus is deemed accepted by the user IP at the rising edge of the Bus2IP_Clk whenever IP2Bus_Ack is asserted and an IPIC write transaction is active.For a read transaction, data on the IP2Bus_Data bus is deemed accepted by the user IP at the rising edge of the Bus2IP_Clk whenever IP2Bus_Ack is asserted and an IPIC read transaction is active.

IP2Bus_Retry OUT Active high signal indicating the user IP is requesting a retry of an active opera-tion.

IP2Bus_Error OUT Active high signal indicating the user IP


has encountered an error with the re-quested operation. This signal is asserted in conjunction with IP2Bus_Ack.

IP2Bus_ToutSup OUT Active high signal requesting suppres-sion of the transaction time-out function in the IPIF for the active read or write operation.

IP2Bus_RdAck OUT Active high read data qualifier. Read data on the IP2Bus_Data Bus is deemed valid at the rising edge of Bus2IP_Clk and the assertion of the IP2Bus_RdAck signal by the User IP.

IP2Bus_WrAck OUT Active high Write Data qualifier. Write data on the Bus2IP_Data Bus is deemed accepted by the User IP at the rising edge of the Bus2IP_Clk and IP2Bus_WrAck asserted high by the User IP.

Figure 7. PLB single data beat read (a) and write (b) operation

The interface between the PLB IPIF and the NIE can be implemented as a pair of FIFOs, each composed of a dual-port RAM and two FSMs controlling the read and


write sides by controlling the EN, WE and ADDRESS signals of the RAM, and implementing the timing diagrams of Figure 4.

4. OPB interfaceThe NIE/OPB interface in the Xilinx EDK flow through an OPB IPIF. The OPB IPIF is a continuation of the Xilinx family of IBM CoreConnect™ compatible LogiCORE products. It provides a bidirectional interface between a user IP core and the OPB 32-bit bus standard. The Xilinx OPB IPIF is available for use with various FPGA device families that support embedded hard or soft processors. Therefore, an interface be-tween the OPB IPIF and the NIE is required (Figure 8).

Figure 8. OPB-based system

The OPB IPIF signals (in respect to the user IP side) are shown in the following table.

Signal name Direction

Description

Bus2IP_Clk IN OPB clock, passed through OPB IPIFBus2IP_Reset IN Active high OPB resetIP2Bus_IntrEvent [0: C_IP_INTR_NUM-1]

OUT Interrupt output signals. One is sufficient for NIE

Bus2IP_Data [0: C_DWIDTH-1] IN Write data bus to the user IP. Write data is accepted by the IP by assertion of the IP2Bus_Ack signal at the rising edge of the Bus2IP_Clk (or unconditionally on the cycle presented for posted writes).

Bus2IP_BE [0: C_DWIDTH/8-1] IN Byte enable qualifiers for the requested read or write operation with the user IP.

Bus2IP_RdCE [0: C_NUM_CE-1]

IN Active high chip enable bus. Chip en-ables are assigned per the user’s entries in the C_ARD_NUM_CE_ARRAY.


These chip enables are asserted only during active read transaction requests with the target address space and in con-junction with the corresponding sub-ad-dress within the space.

Bus2IP_WrCE [0: C_NUM_CE-1]

IN Active high chip enable bus. Chip en-ables are assigned per the user’s entries in the C_ARD_NUM_CE_ARRAY. These chip enables are asserted only during active write transaction requests with the target address space and in con-junction with the corresponding sub-ad-dress within the space.

IP2Bus_Data [0: C_DWIDTH-1] OUT Input Read Data bus from the user IP. Data is qualified with the assertion of IP2Bus_Ack signal and the rising edge of the Bus2IP_Clk.

IP2Bus_Ack OUT Active high data acknowledgement For a write transaction, data on the Bus2IP_Data bus is deemed accepted by the user IP at the rising edge of the Bus2IP_Clk whenever IP2Bus_Ack is asserted and an IPIC write transaction is active.For a read transaction, data on the IP2Bus_Data bus is deemed accepted by the user IP at the rising edge of the Bus2IP_Clk whenever IP2Bus_Ack is asserted and an IPIC read transaction is active.

IP2Bus_Retry OUT Active high signal indicating the user IP is requesting a retry of an active opera-tion.

IP2Bus_Error OUT Active high signal indicating the user IP has encountered an error with the re-quested operation. This signal is asserted in conjunction with IP2Bus_Ack.

IP2Bus_ToutSup OUT Active high signal requesting suppres-sion of the transaction time-out function in the IPIF for the active read or write operation.

The following timing diagrams (Figure 9) correspond to an OPB read and write operation, respectively.


(a)

(b)

Figure 9. OPB IPIF read (a) and write (b) operations

Therefore, the IP2Bus_IntrEvent must be activated when the DATA_VALID_OUT signal is deactivated (end of transaction). The IP2Bus_Data will correspond to the DATA_OUT signal.The IP2Bus_Toutsup, IP2Bus_Retry and IP2Bus_Error will always remain at logic ‘0’.

5. Non-MicroBlaze interfaces5.1. Wishbone bus interfaceThe WISHBONE System-on-Chip (SoC) Interconnection Architecture for Portable IP Cores is a flexible design methodology for use with semiconductor IP cores. Its purpose is to foster design reuse by alle-viating System-on-Chip integration problems. This is accomplished by creating a common interface between IP cores.


Figure 10. Wishbone-based system

Figure 11. Wishbone Master-Slave interface signals

Wishbone Signals Common to MASTER and SLAVE InterfacesCLK_I: The clock input [CLK_I] coordinates all activities for the in-ternal logic within the WISHBONE interconnect. All WISHBONE out-


put signals are registered at the rising edge of [CLK_I]. All WISH-BONE input signals are stable before the rising edge of [CLK_I].

DAT_I(): The data input array [DAT_I()] is used to pass binary data. The array boundaries are determined by the port size, with a max-imum port size of 64-bits (e.g. [DAT_I(63..0)]). Also see the [DAT_O()] and [SEL_O()] signal descriptions.

DAT_O(): The data output array [DAT_O()] is used to pass binary data. The array boundaries are determined by the port size, with a maximum port size of 64-bits (e.g. [DAT_I(63..0)]). Also see the [DAT_I()] and [SEL_O()] signal descriptions.

RST_I: The reset input [RST_I] forces the WISHBONE interface to re-start. Furthermore, all internal self-starting state machines will be forced into an initial state. This signal only resets the WISHBONE in-terface. It is not required to reset other parts of an IP core (although it may be used that way).

TGD_I(): Data tag type [TGD_I()] is used on MASTER and SLAVE in-terfaces. It contains information that is associated with the data in-put array [DAT_I()], and is qualified by signal [STB_I]. For example, parity protection, error correction and time stamp information can be attached to the data bus. These tag bits simplify the task of de-fining new signals because their timing (in tion to every bus cycle) is pre-defined by this specification. The name and operation of a datatag must be defined in the WISHBONE DATASHEET.

TGD_O(): Data tag type [TGD_O()] is used on MASTER and SLAVE interfaces. It contains information that is associated with the data output array [DAT_O()], and is qualified by signal [STB_O]. For ex-ample, parity protection, error correction and time stamp informa-tion can be attached to the data bus. These tag bits simplify the task of defining new signals because their timing (in relation to every bus cycle) is pre defined by this specification. The name and operation of a data tag must be defined in the WISHBONE DATA-SHEET.

Wishbone SLAVE Signals

ACK_O: The acknowledge output [ACK_O], when asserted, indicates the termination of a normal bus cycle. Also see the [ERR_O] and [RTY_O] signal descriptions.

ADR_I(): The address input array [ADR_I()] is used to pass a binary address. The higher array boundary is specific to the address width of the core, and the lower array boundary is determined by the data port size. For example the array size on a 32-bit data port with BYTE


granularity is [ADR_O(n..2)]. In some cases (such as FIFO interfaces) the array may not be present on the interface.

CYC_I: The cycle input [CYC_I], when asserted, indicates that a valid bus cycle is in progress. The signal is asserted for the duration of all bus cycles. For example, during a BLOCK transfer cycle there can be multiple data transfers. The [CYC_I] signal is asserted during the first data transfer, and remains asserted until the last data transfer.

ERR_O: The error output [ERR_O] indicates an abnormal cycle ter-mination. The source of the error, and the response generated by the MASTER is defined by the IP core supplier. Also see the [ACK_O] and [RTY_O] signal descriptions.

LOCK_I: The lock input [LOCK_I], when asserted, indicates that the current bus cycle is uninterruptible. A SLAVE that receives the LOCK [LOCK_I] signal is accessed by a single MASTER only, until either [LOCK_I] or [CYC_I] is negated.

RTY_O: The retry output [RTY_O] indicates that the indicates that the interface is not ready to accept or send data, and that the cycle should be retried. When and how the cycle is retried is defined by the IP core supplier. Also see the [ERR_O] and [RTY_O] signal de-scriptions.

SEL_I(): The select input array [SEL_I()] indicates where valid data is placed on the [DAT_I()] signal array during WRITE cycles, and where it should be present on the [DAT_O()] signal array during READ cycles. The array boundaries are determined by the granular-ity of a port. For example, if 8-bit granularity is used on a 64-bit port, then there would be an array of eight select signals with boundaries of [SEL_I(7..0)]. Each individual select signal correlates to one of eight active bytes on the 64-bit data port. For more in-formation about [SEL_I()], please refer to the data organization sec-tion in Chapter 3 of this specification. Also see the [DAT_I(63..0)], [DAT_O(63..0)] and [STB_I] signal descriptions.

STB_I: The strobe input [STB_I], when asserted, indicates that the SLAVE is selected. A SLAVE shall respond to other WISHBONE sig-nals only when this [STB_I] is asserted (except for the [RST_I] signal which should always be responded to). The SLAVE asserts either the [ACK_O], [ERR_O] or [RTY_O] signals in response to every assertion of the [STB_I] signal.

TGA_I: Address tag type [TGA_I()] contains information associated with address lines [ADR_I()], and is qualified by signal [STB_I]. For example, address size (24-bit, 32-bit etc.) and memory manage-ment (protected vs. unprotected) information can be attached to an


address. These tag bits simplify the task of defining new signals be-cause their timing (in relation to every bus cycle) is pre-defined by this specification. The name and operation of an address tag must be defined in the WISHBONE DATASHEET.

TGC_I(): Cycle tag type [TGC_I()] contains information associated with bus cycles, and is qualified by signal [CYC_I]. For example, data transfer, interrupt acknowledge and cache control cycles can be uniquely identified with the cycle tag. They can also be used to dis-criminate between WISHBONE SINGLE, BLOCK and RMW cycles. These tag bits simplify the task of defining new signals because their timing (in relation to every bus cycle) is pre-defined by this specification. The name and operation of a cycle tag must be defined in the WISHBONE DATASHEET.

WE_I: The write enable input [WE_I] indicates whether the current local bus cycle is a READ or WRITE cycle. The signal is negated dur-ing READ cycles, and is asserted during WRITE cycles.

(a)


(b)

Figure 12. Wishbone single read (a) and single write (b) timing diagram

5.2. ARM AMBA bus interfaceThe Advanced Microcontroller Bus Architecture (AMBA) specification defines an on-chip communications standard for designing high-performance embedded micro-controllers. Three distinct buses are defined within the AMBA specification:

the Advanced High-performance Bus (AHB) the Advanced System Bus (ASB) the Advanced Peripheral Bus (APB).


Figure 13. Typical AMBA system

Figure 14. AMBA-based system


5.2.1. ARM AMBA AHB bus interface


Figure 15. AMBA AHB simple transfer


5.2.2. ARM AMBA ASB bus interface


5.2.3. ARM AMBA APB bus interface

Figure 16. AMBA APB slave interface


Figure 17. AMBA APB slave transfer

6. NIE IF SpecificationsAll the NIE IF blocks described above will require a similar architecture shown in the following block diagram. A FIFO (dual-port RAM), a pair of counters (one for each side) and two FSMs controlling the transfer of data and providing signals according to the timing diagrams.


Figure 18. NIE IF block diagram

Signal Name Direction DescriptionBUS SIGNALS Input Bus control signals according to specific busDATA_BUS_IN Input Data input according to specific busDATA_OUT Output NIE DATA_OUT signal (see Figure 2)DATA_VALID_OUT Output NIE DATA_VALID_OUT signal (see Figure

2)DATA_IN Input NIE DATA_IN signal (see Figure 2)DATA_VALID_IN Input NIE DATA_VALID_IN signal (see Figure 2)EN Internal Counter enable signalsENA Internal RAM enable signals port AENB Internal RAM enable signals port BWEA Internal RAM write enable signals

The FIFOs and FSM_TX_NIE and FSM_RX_NIE blocks are the same in all versions of the NIE_IF. The FSM_TX_BUS and FSM_RX_BUS though, differ according to the bus the NIE will be connected to.Furthermore, the RX FIFO FSM (FSM_RX_BUS) should also detect an overrun condition.

The FSM_TX state machines will require at least two states: IDLE and TXThe FSM_RX state machines will require at least two states: IDLE and RX

fitstaff.fit.ac.cy/com.tk/aeee561/noc_mb_if.doc · web viewamba ahb simple transfer 5.2.2. arm amba...

Documents