Introduction to The WISHBONE Bus Interface A Systemonchip

Introduction to The WISHBONE (Bus Interface) A System-on-chip (So. C) Interconnection Architecture For Portable IP Cores Taken from the WISHBONE So. C Architecture Specification, Revision B. 3 Andres Cicuttin, ICTP-MLAB 1

www. opencores. org • • • The reference community for Free and Open Source gateware IP cores Since 1999, Open. Cores is the most prominent online community for the development of gateware IP (Intellectual Properties) Cores. It is the place where such cores are shared and promoted in the spirit of Free and Open Source collaboration. The Open. Cores portal hosts the source code for different digital gateware projects and supports the users’ community providing a platform for listing, presenting, and managing such projects; together with version control systems for sources management. Open. Cores is also the place where digital designers meet to showcase, promote, and talk about their passion and work. They do this through forums, news collectors, and much more! (SIC) Andres Cicuttin, ICTP-MLAB 2

So. C Interconnection: WISHBONE • • • Description: The WISHBONE System-on-Chip (So. C) Interconnect Architecture for Portable IP Cores is a portable interface for use with semiconductor IP cores. Its purpose is to foster design reuse by alleviating system-on-a-chip integration problems. WISHBONE itself is not an IP core but a specification for creating IP cores. Open. Cores recommends the WISHBONE System-on-Chip Interconnect as the interface to all cores that require interfacing to other cores inside a chip (FPGA, ASIC, etc. ). The WISHBONE standard is not copyrighted, and is in the public domain. It may be freely copied and distributed by any means. Furthermore, it may be used for the design and production of integrated circuit components without royalties or other financial obligations. Andres Cicuttin, ICTP-MLAB 3

What is Wishbone ? 1) A general purpose interface between IP cores. It defines the standard data exchange between IP core modules. 2) A flexible design methodology for use with semiconductor IP cores. 3) “It is not a bus” Andres Cicuttin, ICTP-MLAB 4

Some of the advantages – Promotes design reuse by alleviating system-onchip integration problems. – Improves the portability and reliability of the system. – Faster design time. – Can be used for soft core, firm core or hard core IP. – Does not require the use of specific development tools or target hardware. – Fully compliant with virtually all logic synthesis tools. – Documentation standards simplify IP core reference manuals. Andres Cicuttin, ICTP-MLAB 5

WISHBONE Features I • Simple, compact, logical IP core hardware interfaces requiring very simple logic cicuits. • Supports structured design methodologies used by large project teams. • Full set of popular data transfer bus protocols including: – READ/WRITE cycle. – BLOCK transfer cycle. – RMW cycle. • Modular data bus widths and operand sizes. • Supports both big endian and little endian data ordering. Andres Cicuttin, ICTP-MLAB 6

WISHBONE Features II • Supports variable core interconnection methods: Point-to-point, shared bus, crossbar switch, and switched fabric interconnections. • Handshaking protocol allows each IP core to throttle its data transfer speed. • Supports single clock data transfers. • Supports normal cycle termination, retry termination and termination due to error. • Modular address widths. • Partial address decoding scheme for slaves. Andres Cicuttin, ICTP-MLAB 7

WISHBONE Features III • User-defined tags. These are useful for applying information to an address bus, a data bus or a bus cycle. • MASTER / SLAVE architecture for very flexible system designs. Andres Cicuttin, ICTP-MLAB 8

WISHBONE Features IV • Multiprocessing (multi-MASTER) capabilities. This allows for a wide variety of System-on-Chip configurations. • Arbitration methodology is defined by the end user (priority arbiter, round-robin arbiter, etc. ). • Supports various IP core interconnection means, including: – Point-to-point – Shared bus – Crossbar switch – Data flow interconnection • Synchronous design (Assures portability, and ease of use) Andres Cicuttin, ICTP-MLAB 9

Specification Keywords 1. 2. 3. 4. 5. RULES RECOMMENDATIONS SUGGESTIONS PERMISSIONS OBSERVATIONS RULES Rules form the basic framework of the specification. Rules are characterized by an imperative style. The uppercase words MUST and MUST NOT are reserved exclusively for stating rules. RECOMMENDATIONS Whenever a recommendation appears, designers would be wise to take the advice given. Doing otherwise might result in some awkward problems or poor performance. These are provided as guidance for the user. Andres Cicuttin, ICTP-MLAB 10

SUGGESTIONS A suggestion contains advice which is helpful but not vital. The reader is encouraged to consider the advice before discarding it. Some design decisions are difficult until experience has been gained. Some suggestions have to do with designing compatible interconnections, or with making system integration easier. PERMISSIONS In some cases a rule does not specifically prohibit a certain design approach, but the reader might be left wondering whether that approach might violate the spirit of the rule, or whether it might lead to some subtle problem. Permissions reassure the reader that a certain approach is acceptable and will not cause problems. The upper-case word MAY is reserved exclusively for stating a permission and is not used for any other purpose. OBSERVATIONS Observations do not offer any specific advice. They usually clarify what has just been discussed. They spell out the implications of certain rules and bring attention to things that might otherwise be overlooked. They also give the rationale behind certain rules, so that the reader understands why the rule must be followed. Andres Cicuttin, ICTP-MLAB 11

Examples: Rules and Permissions • RULE 3. 00 All WISHBONE interfaces MUST initialize themselves at the rising [CLK_I] edge following the assertion of [RST_I]. They MUST stay in the initialized state until the rising [CLK_I] edge that follows the negation of [RST_I]. • RULE 3. 05 [RST_I] MUST be asserted for at least one complete clock cycle on all WISHBONE interfaces. • PERMISSION 3. 00 [RST_I] MAY be asserted for more than one clock cycle, and MAY be asserted indefinitely. • RULE 3. 10 All WISHBONE interfaces MUST be capable of reacting to [RST_I] at any time. • RULE 3. 15 All self-starting state machines and counters in WISHBONE interfaces MUST initialize themselves at the rising [CLK_I] edge following the assertion of [RST_I]. They MUST stay in the initialized state until the rising [CLK_I] edge that follows the negation of [RST_I]. Andres Cicuttin, ICTP-MLAB 12

Examples: Recomendations, suggestions and observations • RECOMENDATION 3. 00 Design SYSCON modules so that they assert [RST_O] during a power-up condition. [RST_O] should remain asserted until all voltage levels and clock frequencies in the system are stabilized. When negating [RST_O], do so in a synchronous manner that conforms to this specification. • SUGGESTION 3. 00 Some circuits require an asynchronous reset capability. If an IP core or other So. C component requires an asynchronous reset, then define it as a non-WISHBONE signal. This prevents confusion with the WISHBONE reset [RST_I] signal that uses a purely synchronous protocol, and needs to be applied to the WISHBONE interface only. • OBSERVATION 3. 20 All WISHBONE interfaces respond to the reset signal. However, the IP Core connected to a WISHBONE interface does not necessarily need to respond to the reset signal. Andres Cicuttin, ICTP-MLAB 13

The Four Wishbone Modules RST_I CLK_I ADR_O() ADR_I() DAT_I() DAT_O() WE_O WE_I SEL_O() SEL_I() STB_O STB_I ACK_O CYC_I TAGN_O TAGN_I TAGN-O INTERCON SYSCON: drives the system clock [CLK_O] and reset [RST_O] signals. WISHBONE SALVE WISHBONE MASTER SYSCON MASTER: IP Core interface that generates bus cycles. SLAVE: IP Core interface that receives bus cycles. INTERCON: an IP Core that connects all of the MASTER and SLAVE interfaces together. Andres Cicuttin, ICTP-MLAB 14

SYSCON master slave INTERCON (Wishbone Interconnection) slave * Point-To-Point * Data Flow * Shared Bus * Crossbar Switch master slave master The Wishbone Interconnection is created by the SYSTEM INTEGRATOR, who has total control of its design! Andres Cicuttin, ICTP-MLAB 15

Interconnections WISHBONE MASTER WISHBONE SLAVE Point-To-Point Interconnection WISHBONE SLAVE IP Core “C” WISHBONE MASTER WISHBONE SLAVE IP Core “B” WISHBONE MASTER WISHBONE SLAVE WISHBONE MASTER IP Core “A” Direction of Data Flow Interconnection Andres Cicuttin, ICTP-MLAB 16

Interconnections WISHBONE MASTER “MA” WISHBONE MASTER “MB” Shared Bus WISHBONE SLAVE “SA” WISHBONE SLAVE “SB” WISHBONE SLAVE “SC” Shared Bus Interconnection Andres Cicuttin, ICTP-MLAB 17

Interconnections WISHBONE MASTER “MA” WISHBONE MASTER “MB” NOTE: Dotted lines indicate one possible connection option CROSSBAR SWITCH INTERCONNECTION WISHBONE SLAVE “SA” WISHBONE SLAVE “SB” WISHBONE SLAVE “SC” Crossbar Switch Interconnection Andres Cicuttin, ICTP-MLAB 18

The Main Wishbone Signals (Ports) RST_I: receives the reset output signal [RST_O] from the SYSCON. RST_I CLK_I: receives the clock output signal [CLK_O] from the SYSCON. ADR_I() DAT_I() DAT_O() WE_O SEL_O() STB_O ACK_I CYC_O ON ADR_O() WE_I SEL_I() STB_I ACK_O ADR_I: receives the address from MASTER WISHBONE SALVE RST_I INTERC WISHBONE MASTER SYSCON ADR_O: drives the address to the SLAVE DAT_I: receives the data DAT_O: drives the data WE_I, WE_O: Write Enable (active high) STB_I, STB_O: Strobe (kind of chip select) CYC_I TAGN_O TAGN_I TAGN-O ACK_I, ACK_O: Acknowledge (active high) CYC_I, CYC_O: Bus Cycle (active high) Andres Cicuttin, ICTP-MLAB 19

WISHBONE Classic Bus Cycles The Reset Cycle CLK_I RST_I STB_O CYC_O Andres Cicuttin, ICTP-MLAB 20

Local Bus Handshaking Protocol CLK_I STB_O ACK_I Andres Cicuttin, ICTP-MLAB 21

Tag Types Master Slave Description TAG TYPE Associated with Address tag TGA_O() ADR_O TGA_I() ADR_I() Data tag input TGD_I() DAT_I() Data tag output TGD_O() DAT_O() Cycle tag TGC_O() Bus Cycle TGC_I() Bus Cycle Andres Cicuttin, ICTP-MLAB 22

SINGLE READ cycle (Master Signals) CLK_I 1 ADR_O () DAT_I () -wss- n VALID DAT_O () WE_O SEL_O () VALID STB_O ACK_I CYC_O Andres Cicuttin, ICTP-MLAB 23

SINGLE WRITE cycle CLK_I 1 -wss- n (Master Signals) ADR_O () VALID DAT_I () DAT_O () VALID WE_O SEL_O () VALID STB_O ACK_I CYC_O Andres Cicuttin, ICTP-MLAB 24

A Simple Example: WISHBONE SLAVE port DAT_O(7… 0) WISHBONE INTERFACE 8 DAT_I(7… 0) D Q PRT_O(7… 0) 8 ACK_O STB_I WE_I RST_I CE RESET CLK_I 8 -BIT D-TYPE REGISTER Andres Cicuttin, ICTP-MLAB 25

VHDL implementation of the 8 -bit output port interface (pag. 109) library ieee; use ieee. std_logic_1164. all; architecture WBOPRT 081 of WBOPRT 08 is signal Q: std_logic_vector( 7 downto 0 ); entity WBOPRT 08 is port( -- WISHBONE SLAVE interface: Begin internal_DAT_I <= DAT_I; ACK_O: out std_logic; CLK_I: in std_logic; DAT_I: in std_logic_vector( 7 downto 0 ); DAT_O: out std_logic_vector( 7 downto 0 ); RST_I: in std_logic; STB_I: in std_logic; WE_I: in std_logic; -- Output port (non-WISHBONE signals): PRT_O: out std_logic_vector( 7 downto 0) ); REG: process( CLK_I ) begin if( rising_edge( CLK_I ) ) then if( RST_I = '1' ) then --synchronous reset Q <= B"0000"; elsif( (STB_I and WE_I) = '1' ) then Q <= internal_DAT_I( 7 downto 0 ); else Q <= Q; end if; end process REG; end entity WBOPRT 08; ACK_O <= STB_I; --(Asynchronous assignments !) DAT_O <= Q; PRT_O <= Q; end architecture WBOPRT 081; Andres Cicuttin, ICTP-MLAB 26

WB Clasic Bus Cycles BLOCK READ (Page 54) BLOCK WRITE (Page 57) RMW (Read-Modify-Write) (Page 60) Andres Cicuttin, ICTP-MLAB 27

Other WB Bus Cycles (WISHBONE Registered Feedback) Both Master and Slave MUST support “Cycle Type Identifier”: [CTI_O()], [CTI_I()] 4. 2 Signal Description CTI_IO() The Cycle Type Identifier [CTI_IO()] Address Tag provides additional information about the current cycle. The MASTER sends this information to the SLAVE. The SLAVE can use this information to prepare the response for the next cycle. Table 4 -2 Cycle Type Identifiers CTI_O(2: 0) Description PERMISSION 4. 05 MASTER and SLAVE interfaces MAY be designed to support the [CTI_I()] and [CTI_O()] signals. Also MASTER and SLAVE interfaces MAY be designed to support a limited number of burst types. RULE 4. 05 MASTER and SLAVE interfaces that do support the [CTI_I()] and [CTI_O()] signals MUST at least support the Classic cycle [CTI_IO()=’ 000’] and the End-of-Cycle [CTI_IO()=’ 111’]. RULE 4. 10 MASTER and SLAVE interfaces that are designed to support a limited number of burst types MUST complete the Andres Cicuttin, ICTP-MLAB ‘ 000’ Classic cycle. ‘ 001’ Constant address burst cycle ‘ 010’ Incrementing burst cycle ‘ 011’ Reserved ‘ 100’ Reserved ‘ 101 Reserved ‘ 110’ Reserved ‘ 111’ End-of-Burst 28

Other WB Bus Cycles Classic Cycle (with wait states –ws-) (Page 77) Constant Address Burst (Page 83) (e. g. for fifos, ports, etc) Incrementing Burst Cycle (Page 86) An incrementing burst is defined as multiple accesses to consecutive addresses. Each transfer the address is incremented. The increment is dependent on the data array [DAT_O()], [DAT_I()] size; for an 8 bit data array the increment is 1, for a 16 bit data array the increment is 2, for a 32 bit data array the increment is 4, etc. Andres Cicuttin, ICTP-MLAB 29

All the information related to the Wishbone So. C Architecture Specification is contained in its official documentation: https: //cdn. opencores. org/downloads/wbspec_b 4. pdf • It is very clear and easy to read and understand • It includes design examples • The specification doesn’t infringe patents, copyright, trademarks or trade secret rights of others Andres Cicuttin, ICTP-MLAB 30

Conclusion 1. There are many and very good reasons to adopt the Wishbone So. C Architecture Specification as the standard interface for open-source projects such as the Reconfigurable Virtual Instrumentation project proposed by ITCP. 2. Your are strongly encouraged to use it to develop reusable IP blocks that can be easily shared by a large community of users and developers Andres Cicuttin, ICTP-MLAB 31

Reconfigurable Virtual Instrumentation based on So. C-FPGA External Memory Hybrid Device Time Critical External Hardware Ext HW Controllers FPGA-u. P communication block u. P Non Time Critical External Hardware Andres Cicuttin, ICTP-MLAB PC Middleware 32

FPGA-u. P communication block Memory mapping of common resources: Registers FPGA Address : offset + u. P Address: offset + 0 x 0000 Register 0 0 x 00000001 Register 1 0 x 00000002 Register 2 0 x 00000002 0 x 000000 FF Register 255 0 x 000000 FF 0 x 00000100 Register 256 0 x 00000100 0 x 00000101 Register 257 0 x 00000101 0 x 00000102 Register 258 0 x 00000102 0 x 000001 FF Register 511 0 x 000001 FF Andres Cicuttin, ICTP-MLAB 33

FPGA-u. P communication block Memory mapping of common resources: FIFOs and TDP-RAMs FPGA Address : offset + u. P Address: offset + 0 x 00000200 u. P-to-FPGA FIFO 1 0 x 00000200 0 x 00000201 u. P-to-FPGA FIFO 2 0 x 00000201 0 x 00000202 u. P-to-FPGA FIFO 2 0 x 00000204 u. P-to-FPGA FIFO 3 0 x 00000204 0 x 00000205 FPGA-to u. P FIFO 1 0 x 00000205 0 x 00000206 FPGA-to u. P FIFO 2 0 x 00000206 FPGA-to u. P FIFO 3 0 x 00000207 0 x 00000208 FPGA-to u. P FIFO 4 0 x 00000208 0 x 00000209 True Dual Port RAM 1 32 Bits x 1024 0 x 00000209 True Dual Port RAM 2 32 Bits x 1024 0 x 00000609 0 x 00000608 0 x 00000609 0 x 00001010 Andres Cicuttin, ICTP-MLAB 0 x 00000608 0 x 00001010 34