3 Interconnection Architecture for Computers, Microcontrollers, FPGAs
\r
4 Revision: DRAFT 0.01 02.20.2016 by Black Mesa Labs
\r
6 ###############################################################################
\r
8 [ Legal Notices and Disclaimers ]
\r
9 Copyright Notice : Notice is hereby given that this document is not
\r
10 copyrighted, and has been placed into the public domain.
\r
11 It may be freely copied and distributed by any means.
\r
15 The Author has strove to be as accurate and complete as possible in the
\r
16 creation of this document, notwithstanding the fact that he does not warrant
\r
17 or represent at any time that the contents within are accurate due to the
\r
18 rapidly changing nature of information. The Author will not be responsible
\r
19 for any losses or damages of any kind incurred by the reader whether directly
\r
20 or indirectly arising from the use of the information found in this document.
\r
22 This document is not intended for use as a source of legal, business,
\r
23 accounting, financial, or medical advice. All readers are advised to seek
\r
24 services of competent professionals in the legal, business, accounting,
\r
25 finance, and medical fields.
\r
27 No guarantees of any kind are made. Reader assumes responsibility for use of
\r
28 the information contained herein. The Author reserves the right to make
\r
29 changes without notice. The Author assumes no responsibility or liability
\r
30 whatsoever on the behalf of the reader of this document.
\r
32 In no event shall the Author be liable for any direct, indirect, incidental,
\r
33 consequential, exemplary, or special damages (including, but not limited to
\r
34 procurement of substitute goods or services; loss of use, data, or profits;
\r
35 or business interruption) resulting in any way from the use of this
\r
36 specification. By adopting this specification, the user assumes all
\r
37 responsibility for its use.
\r
39 ###############################################################################
\r
42 MesaBus is a scalable chip to chip protocol that expands a single serial
\r
43 interface of any microcontroller, computer or FPGA to a full bus with
\r
44 up to 250 self enumerating nodes. The purpose of MesaBus is to allow simple
\r
45 low cost Internet-of-Thing type microcontrollers and FPGAs with very few pins
\r
46 to be able to easily interface to many device peripherals with minimum wires .
\r
47 MesaBus is scalable from simple UART connections to high performance SERDES
\r
48 chip to chip communications between FPGAs approaching PCI performance.
\r
49 MesaBus readily scales from 115 Kbps over bluetooth wireless to
\r
50 1 GByte/sec between high performance FPGAs over a low cost USB cable.
\r
53 The MesaBus architect was strongly influenced by these factors:
\r
54 1) The MakerCommunity does not have access to low level computer interfaces
\r
55 that existed in the 1980s era of RS232 and Parallel Printer Ports. USB
\r
56 device drivers are so difficult that USB access to a modern computer is
\r
57 essentially an FTDI cable that looks like a legacy RS232 port to software.
\r
58 2) Microcontroller community has no "Bus" standard for interfacing multiple
\r
59 peripherals other than SPI and I2C.
\r
60 3) USB and PCIe are fantastic for consumers, but too complicated for use in
\r
61 interfacing microcontrollers to custom peripherals.
\r
62 4) IC's that can be purchased and hand soldered on to low cost 2-layer PCBs
\r
63 designs are limited in pin count and need a minimal wire bus that isn't I2C.
\r
64 5) Interconnecting FPGAs with each other and peripherals usually involve
\r
65 one-off custom interfaces to reach simplicity and performance.
\r
66 6) Byte transfer interfaces such as SPI, I2C and SERDES are reusable across
\r
67 many different applications but do not scale and require many pins.
\r
70 MesaBus protocol is a streaming byte protocol bus for transferring packets
\r
71 of payload bytes from a single bus MASTER to multiple bus SLAVEs.
\r
72 The default protocol MODE_UART is to transfer ASCII hex nibbles "0"-"F" over
\r
73 an industry standard N81 UART connection to build up a stream of binary bytes
\r
74 internal to each SLAVE chip. Using this ASCII based interface increases
\r
75 compatibility with operating systems, scripting languages and wireless
\r
76 communication modules that otherwise may have difficulties transferring binary
\r
77 data. The MODE_SYNC protocol uses the same byte streams but with a source
\r
78 synchronous binary interface such as SPI or I2C. MODE_SERDES protocol uses
\r
79 8b10b SERDES to transfer the same byte streams over a 3+ Gbps SERDES link.
\r
80 These three modes allow MesaBus compliant designs to easily trade off between
\r
81 compatibility and performance as it readily scales from KBytes/sec between
\r
82 wireless Bluetooth microcontrollers to 40 MBytes/Sec between simple FPGAs to
\r
83 1 GBytes/Sec between advanced FPGAs over a low cost USB cable.
\r
86 o 1-Bit LVCMOS MODE_UART : Payload rate is 1/2 physical baud rate.
\r
87 o 1-Bit LVCMOS MODE_SYNC : Payload rate is 1x physical bit rate.
\r
88 o 1-Bit LVDS MODE_SYNC : Payload rate is 1x physical bit rate.
\r
89 o 1-Bit SERDES MODE_SERDES : Payload rate is 8/10 physical bit rate.
\r
91 Examples: Electrical Payload
\r
92 o 1-Bit LVCMOS MODE_UART : 921kbps = 460kbps or 50 KBytes/s.
\r
93 o 1-Bit LVCMOS MODE_SYNC : 40Mbps = 40Mbps or 5 MBytes/s.
\r
94 o 1-Bit LVDS MODE_SYNC : 320Mbps = 320Mbps or 40 MBytes/s.
\r
95 o 1-Bit SERDES MODE_SERDES : 10 Gbps = 8Gbps or 1 GBytes/s.
\r
97 [ Physical Interface ]
\r
98 o Electrical Signal Levels : The physical interface is point to point with
\r
99 devices interfacing nominally using 3.3V LVCMOS. High performance devices
\r
100 may optionally use differential LVDS in place of single ended LVCMOS for
\r
101 faster performance and/or long cable runs.
\r
102 o Power : MesaBus MASTERs are able to provide +5V DC power to SLAVE devices.
\r
103 Current limit of +5V is design dependent with 500mA a nominal target.
\r
105 Wi : Originates from MASTER and propagates down bus chain to furthest
\r
106 slave node. Carries either asynchronous UART single bit traffic or
\r
107 1 or 4 bits of synchronous traffic clocked by Woc clock.
\r
109 Wo : Output copy of Wi to next slave downstream.
\r
110 Ro : Originates from SLAVE devices and propagates back up to MASTER.
\r
111 Carries either asynchronous UART readback data or interrupt.
\r
113 Ri : Input version of Ro from downstream slave device.
\r
114 o Pullups : Pullups exist on all LVCMOS signals to 3.3V.
\r
116 o Mechanical Connection : Mechanical connections are recommendations only.
\r
117 o Standard LVCMOS Form Factor is FTDI TTL-232R-3V3 USB to TTL cable pinout.
\r
118 - LVCMOS 1-Bit : 1x6 0.100" Pitch 0.040" vias with the following pinout:
\r
119 Pin-1 : Ground ( GND ) Black
\r
120 Pin-2 : Wo ( CTS# ) Brown Roc clock for MODE_SYNC
\r
121 Pin-3 : +5V Power ( VCC ) Red 900mA Max
\r
122 Pin-4 : Wi ( TXD ) Orange
\r
123 Pin-5 : Ro ( RXD ) Yellow
\r
124 Pin-6 : Ri ( RTS# ) Green Wic clock for MODE_SYNC
\r
127 - LVDS : USB 3.1 Type-C Male to Male cables repurposed for LVDS and Power
\r
130 StdA_SSTX+- : Wi Diff Pair ( MODE_UART or MODE_SYNC )
\r
131 StdA_SSRX+- : Wic Diff Pair
\r
132 D+- : Ro Diff Pair ( MODE_UART )
\r
134 - SERDES : USB 3.1 Type-C Male to Male cables repurposed for SERDES and Power
\r
137 StdA_SSTX+- : Wi Diff Pair ( 3-10 Gbps 8b10b )
\r
138 StdA_SSRX+- : Ro Diff Pair ( 3-10 Gbps 8b10b )
\r
141 o Powerup and Wo LVCMOS TriState operation:
\r
142 Wo is normally an active driven signal that parks at '1'. To prevent
\r
143 Wo from potentially powering downstream CMOS devices, it is Tristated
\r
144 with weak pullup on powerup and is not actively driven until the bus
\r
145 segment is activated.
\r
148 o Modes : MesaBus supports MODE_UART, MODE_SYNC and MODE_SERDES.
\r
149 - MODE_UART : Wi and Ri are asynchronously sampled using local
\r
150 >20 MHz oscillator on each slave device using UART N81 protocol.
\r
151 Maximum baud rate is TBD 10 Mbps.
\r
152 Minimum baud rate is TBD 9600 bps.
\r
153 - MODE_SYNC : Wi and Ri are synchronously sampled using source
\r
154 synchronous Wic and Ric clocks. Clocks are nominally 24 MHz for LVCMOS
\r
155 and 320 MHz for LVDS interfaces. Bus sits idle at '1'. Leading 0xF0 header
\r
156 provides framing reference for Byte within stream of Bits. Byte within bits
\r
157 alignment remains for duration of packet.
\r
158 - MODE_SERDES : 8b10b encoded clock and data at 3 to 10 Gbps. Bus is idle
\r
159 sending nulls of 0xFF.
\r
160 o Detection : The local 40 MHz clock is used to detect the presents of Wic
\r
161 and Ric. MODE_UART is automatically used if these clocks are parked.
\r
162 Devices capable of MODE_SYNC automatically switch from MODE_UART to
\r
163 MODE_SYNC when Wic is detected as toggling.
\r
165 [ Signal Description ]
\r
166 o Wi : Input signal to SLAVE from upstream MASTER or SLAVE.
\r
167 o Wo : Output signal from SLAVE to downstream SLAVE.
\r
168 o Ro : Output signal from SLAVE to upstream MASTER or SLAVE.
\r
169 o Ri : Input signal to MASTER or SLAVE from downstream SLAVE.
\r
175 --------------- ------------------ -----------------
\r
176 | Wo |--->| Wi Wo |--->| Wi Wo |--> NC
\r
177 | Ri |<---| Ro Ri |<---| Ro Ri |<-- NC
\r
178 --------------- ------------------ -----------------
\r
182 --------------- ------------------ -----------------
\r
183 | Wo |--->| Wi Wo |--->| Wi Wo |--> NC
\r
184 | Wco|--->| Wci Wco |--->| Wci Wco |--> NC
\r
185 | Ri |<---| Ro Ri |<---| Ro Ri |<-- NC
\r
186 | Rci|<---| Rco Rci |<---| Rco Rci |<-- NC
\r
187 --------------- ------------------ -----------------
\r
191 --------------- ------------------ -----------------
\r
192 | Wo |--->| Wi Wo |--->| Wi Wo |--> NC
\r
193 | Ri |<---| Ro Ri |<---| Ro Ri |<-- NC
\r
194 --------------- ------------------ -----------------
\r
197 o Idle Bus : Optional for MODE_UART, required for MODE_SYNC if clocking.
\r
198 The Packet_Header may optionally be preceded by 1 or more "F"s to
\r
199 ensure nibble within byte alignment is maintained while in
\r
200 MODE_UART. Packet processing only begins when an "F0" is
\r
201 received on a byte wide lane, or a "0" on a nibble wide lane.
\r
202 To guarantee packet alignment, the bus master may always send
\r
203 a string of 260 0xFFs bytes.
\r
205 o Invalid Characters : In MODE_UART, ASCII characters outside of "a-f","A-F"
\r
206 and "0-9" are considered invalid and ignored. Any
\r
207 invalid character >= 0x20 will result in the lock on
\r
208 Autobaud being turned off. The "\n" LF character is
\r
209 an exception to this rule and is used initially for
\r
210 autobauding and ignored after baud lock.
\r
211 o Bit and Byte Ordering
\r
212 Bit ordering for MODE_UART is normal Start Bit, D0 LSB, D1,..D7,Stop Bit.
\r
213 Bit ordering for MODE_SYNC is MSB D7 first and LSB D0 last.
\r
214 Byte ordering for DWORD transfers is D(31:24) 1st and D(7:0) last.
\r
215 Phase alignments for bit, nibble, byte and DWORD boundaries is established
\r
216 using the 0xF0 packet header preamble. Bus always sits idle with 0xFFs.
\r
219 A packet header consists of a 4-bytes DWORD always beginning with 0xF0.
\r
220 D(31:24) : 0xF0 : Header Preamble
\r
221 D(23:16) : 0x00-0xFD : Destination Slot for this packet
\r
222 0xFF : Broadcast all slots
\r
223 0xFE : Nobody ( or Master on Ro Readback packets )
\r
224 D(15:8) : Sub-Slot and Command
\r
225 D(15:12) : Sub-Slot 0x0-0xF within Chip.
\r
226 D(11:8) : Sub-Slot Command 0x0-0xF
\r
227 D(7:0) : 0-255 : Number of payload bytes included in this packet.
\r
229 o Sub-Slot 0x0 : 32bit Local Bus Transport
\r
230 Sub-Slot 0x0 is by default used for transferring 32bit local bus address
\r
231 and data cycles. <ADDR> is 32bits specific to each chip. For writes, one
\r
232 or more DWORDs of data may be written. For reads, <LENGTH> specifies the
\r
233 number of DWORDs to read starting at <ADDR>. For multiple DWORD transfers,
\r
234 the <ADDR> is internally auto incremented by +4 for each DWORD.
\r
236 0x0 : Write Cycle : Payload of <ADDR><DATA>...
\r
237 0x1 : Read Cycle : Payload of <ADDR><Length>
\r
238 0x2 : Write Repeat : Write burst data to single address : <ADDR><DATA>...
\r
239 0x3 : Read Repeat : Read burst data from single address : <ADDR><Length>
\r
241 o Sub-Slot 0xF : Mesa Bus Control
\r
242 Sub-Slot 0xF is reserved for low level control of the Mesa Bus pins.
\r
244 0x0 : Ro pin is assigned to MesaBus Ro function. ( DEFAULT )
\r
245 0x1 : Ro pin is assigned to Wi pin as a loopback.
\r
246 0x2 : Ro pin is assigned to MesaBus Interrupt function.
\r
247 0x3 : Ro pin is assigned to user specific function.
\r
248 0x4 : Wo pin is assigned to MesaBus Wo function. ( DEFAULT )
\r
249 0x5 : Wo pin is assigned to loopback Wi pin.
\r
250 0x6 : Wo pin is assigned to MesaBus Interrupt function.
\r
251 0x7 : Wo pin is assigned to user specific function.
\r
252 0x8 : Ri pin is assigned to MesaBus Ri function. ( DEFAULT )
\r
253 0x9 : Ri pin is assigned to user specific function.
\r
254 0xA : Report device id
\r
256 0xC : Reset autobaud circuit
\r
257 0xD : Turn off fast clocks ( Power Save Mode )
\r
258 0xE : Reboot FPGA to Slot 1of2
\r
259 0xF : Reboot FPGA to Slot 2of2
\r
262 Addressing is an 8bit field that is decremented at each node. Closest node
\r
263 to Master is 0x00, next in line is 0x01, etc. 0xFF is reserved for broadcast
\r
projects / BML_sump2 / blob